blueprint setup cancellation

[golfmiketango]

I would like to know when the user is in the blueprint setup gui, and what blueprint they are tooling around with. Problem is there doesn't seem to be any way to know if they cancelled blueprint setup, or are still working on it.

Another limitation in 0.16.22 is that when players enter the blueprint setup GUI for an existing (already setup/specialized) blueprint, on_player_setup_blueprint does not fire.

also IIRC on_player_configured_blueprint also is not fired.

An already-setup blueprint via the setup gui will generate on_player_configured_blueprint, as it should. But only if they change something.

So that we can always know whether the setup screen is active or not, I'd be grateful for these changes:

• When players re-configure already-configured blueprints, on_player_setup_blueprint fires, with the player's blueprint_to_setup indicating the correct LuaItemStack.
• When players cancel the blueprint setup gui, a new event, on_player_cancelled_blueprint_setup is fired (including if they press "OK" but no changes were made).

This way mods could be sure that in-between on_player_setup_blueprint and either of (on_player_configured_blueprint and on_player_cancelled_blueprint_setup), and only then, the setup gui is active.

tia!

[Rseding91]

on_player_setup_blueprint won't fire when a player opens a blueprint because they haven't setup a blueprint. They simply opened a new GUI - which fires the on_gui_opened event.

Additionally when the player cancels a blueprint it will fire the on_gui_closed event.

[golfmiketango]

on_player_setup_blueprint won't fire when a player opens a blueprint because they haven't setup a blueprint. They simply opened a new GUI - which fires the on_gui_opened event.

Additionally when the player cancels a blueprint it will fire the on_gui_closed event.

Ah, I was wondering if there might be something like that I was missing. I'll check it out, thanks! Out of curiosity, thought, when you say they "haven't setup a blueprint" this suggests to me don't understand what that term means.

My assumption was that setup must mean... well, you know, setting it up , i.e., you genetically selected some rectangle of ground on a surface, but now you get the Blueprint Setup GUI and can specify precisely what you meant, by setting filters, and customize by naming it, giving it icons, etc.... ?

In addition to "setup" a clear definition of blueprint "configuration" would probably help me to factorio-internals-jargon-speak gooder... neither term seems terribly self-evident to me.

[golfmiketango]

on_player_setup_blueprint won't fire when a player opens a blueprint because they haven't setup a blueprint. They simply opened a new GUI - which fires the on_gui_opened event.

Additionally when the player cancels a blueprint it will fire the on_gui_closed event.

It seems I'm closer to knowing if the blueprint setup gui is open or not, but not all the way. I just don't see how the information in that event is going to get me there.

First, this event tells me some defines.gui_type.item gui has opened, but, which? Or is the blueprint setup gui the only one so that I can just treat that define as meaning precisely "the blueprint setup gui"?

Second, when user is differentiating a generic blueprint item for the first time, no "item" property is provided. By contrast, when they are modifying an already differentiated blueprint, there is an "item" property provided. But it does not appear to point to a LuaItemStack as the documentation suggests ... Maybe it's pointing to a LuaGui or something?

It would help if I knew a generic way to retrieve the factorio-mod-api class-name of random userdata objects that I end up with a handle to (instead of having to try random property names and see if the engine crashes over and over). If there is an API or some prior-art I could borrow for that I'd really appreciate a pointer as I've searched without success for this.

If any kind soul wanted to give me another hint as to where the clue bus stops in this neighborhood, it would be sincerely appreciated.

[Zanthra]

You could try registering the on_gui_opened and on_gui_closed events and print the event.element.name property to find the name of the blueprint configuration window, probably unique, then use that to determine whether they opened the blueprint window or some other window.

[golfmiketango]

You could try registering the on_gui_opened and on_gui_closed events and print the event.element.name property to find the name of the blueprint configuration window, probably unique, then use that to determine whether they opened the blueprint window or some other window.

That sounds like the kind of thing I am looking for but I get:

Code: Select all

>>> event: on_gui_opened
> name == 83
> tick == 391
> player_index == 1
> gui_type == 5
<<< event: on_gui_opened

Just in case some metaclasstable.__pairs is lying to me (or some metatable.__index is willing to lie to me) I tried a hard-coded lookup... no such property

[Zanthra]

Is there perhaps an "item" property? http://lua-api.factorio.com/0.16.22/eve ... gui_opened points to http://lua-api.factorio.com/0.16.22/def ... s.gui_type which if 0 indexed would be an item gui type, so it would be expected to fill the optional "item" property with a reference to the blueprint? Lua is 1 indexed though, so would be "production" which does not make a lot of sense, unless internally the list is sorted differently. If you can do a reverse lookup to defines to get the type name it might help.

Perhaps you can find something in "players[1].gui.children" or "players[1].gui.center.children" after the event triggers?

[golfmiketango]

Perhaps you can find something in "players[1].gui.children" or "players[1].gui.center.children" after the event triggers?

Way ahead of you but I struck out there, they are all as empty as the soul of a medium biter (I found nothing in there but rage and chewed up transport belts ).

That other "item" thing is worth looking into and I do have a couple of other leads to follow up on, however, so all hope is not lost. TIL: it's hard to write a good feature request when you are stumbling around in the Rumsfeldian world of Unknown Unknowns... My preference is ofc that I will either persevere or ask nicely for whatever is missing but I've definitely started to look for ways forward without solving this.

[golfmiketango]

Is there perhaps an "item" property?

There is and there isn't. It's really strange. It depends on whether you are setting up(*) the blueprint for the first time, or reconfiguring the a blueprint that is already set up. In the former case, there is no item property. But the good news is that this is the one case where an out-of-band means already exists to get it done: the on_player_setup_blueprint event.

If I can figure out what the "item" is when reconfiguring a blueprint, and it happens to provide a means to confirm that the blueprint setup gui is active and retrieve the linked-up stack, then there is a path to victory for almost-sure.Sure enough, that item is the LuaItemStack of the blueprint, despite my assertion above that it isn't. I haven't experimented to see if it is the item stack wired up to the blueprint setup gui (pretty sure these are not one and the same), but then, with any luck, blueprint_to_setup would get me to it, anyhow -- we'll see....

So, ... more hope now. I know that some "item" type gui was opened. If I previously (subsequently? can't remember) got on_player_setup_blueprint then I know for sure the blueprint gui is open and where the right stack is to mess with it. If I instead see the "item" event property and that item is a blueprint, ... well I am not sure how safe this is, but I'll pretend I know that means it's the blueprint setup gui and we'll see what happens

The on_gui_closed events look less broken than the on_gui_opened ones, so I think it's just enough to figure it out, although it will definitely require some unfortunate state tracking or hack to make it work. At least in single player, that GUI survives save/reload which may present additional woes, but I guess that just means I can put my state-tracking stuff in the global global and the right thing might happen.

Having a real handle to the actual gui elements would be nice but maybe that's not allowed here or bugged. If the latter, maybe if I watch click handlers or something there's a way to find it. Anyhow that is well within nice-to-have territory. Looks like a good chance exists that my needs will be met.

So, speaking fairly optimistically, thanks for helping me figure this out!

__
(*) I suspect I'm using this term wrong -- I mean specializing the blueprint, by filling it with content, so that it is now a unique-snowflake item in the game rather than "just some free blue square you get by pressing 'b' that will fill your trash slots up when you change your mind and throw it away".