[raiguard] [1.0.0] Updated blueprint has no entities during on_player_setup_blueprint

[Therax]

Observed behavior:

1. Add event handler for on_player_setup_blueprint.

2. Create a blueprint of an entity.

3. In the event handler, observe the following:
player.blueprint_to_setup.valid_for_read is true
player.cursor_stack.valid_for_read is false
player.blueprint_to_setup.is_blueprint is true
player.blueprint_to_setup.is_blueprint_setup() returns true
player.blueprint_to_setup.get_blueprint_entities() returns a table of 1 LuaEntity

4. In the BP GUI, click the "Select new contents for this blueprint" button, and select the same (or different) entity.

5. In the handler for on_player_setup_blueprint, observe the following are true:
player.blueprint_to_setup.valid_for_read is false
player.cursor_stack.valid_for_read is true
player.cursor_stack.is_blueprint is true
player.cursor_stack.is_blueprint_setup() returns false
player.cursor_stack.get_blueprint_entities() returns nil

Expected behavior:

In general, selecting new contents for a blueprint should have the same behavior during event handlers as when creating a brand-new blueprint.
In specific, there should be a way during the event handler to query the entities & tiles in the blueprint, and modify them.

Motivating use case:

https://github.com/mspielberg/factorio- ... #L299-L364

[Honktown]

Unless I'm mistaken, you should be using on_player_configured_blueprint. I might call it a bug that creating a new blueprint immediately sets the blueprint (the player did not confirm anything)*. Following behavior from an event like on_entity_died where the entity is (should be) valid while the event is raised, during on_player_setup_blueprint, I'd expect nothing would be stored about the new blueprint setup, while on_player_configured_blueprint is the event which lets one modify the blueprint data stored somewhere, which is about to be put into the blueprint.

When on_player_configured_blueprint is raised, the blueprint has stuff in it. Related to your code, direction and bar exist as values among bp.get_blueprint_entities()

For an unset blueprint, if you really wanted to set things yourself before the player configures anything (which sounds unsafe), use event.mapping.get() instead. No need to find entities. Tiles aren't as easily accessible during setup.

*The cursor immediately being set seems like it should be restricted to copying... the player never confirms but a blueprint is created and filled. It is a bit conflicting behavior versus setting up a blueprint, but it is what it is.

testing stuff

Code: Select all

local function dump_blueprint(event)
	local player = game.players[event.player_index]
	local mapping = (event.mapping and event.mapping.get()) or {}
	local bp = player.blueprint_to_setup
	if bp.valid_for_read == false then
		log("player.blueprint_to_setup valid for read = false")
		local cursor = player.cursor_stack
		--if cursor and cursor.valid_for_read and cursor.name == "blueprint" then
		if cursor and cursor.valid_for_read then
			log("using blueprint in cursor")
			bp = cursor
		else
			log("cursor stack was not valid for reading")
		end
	else
		log("player.blueprint_to_setup is valid")
	end
--[[
	if bp == nil or bp.valid_for_read == false then
		return
	end
--]]

	if bp ~= nil and bp.valid_for_read == true then
		log("serpent of blueprint:"..serpent.block(bp.get_blueprint_entities()))
	else
		log("could not check blueprint entities")
	end

	for index, entity in pairs(mapping) do
		if entity.valid then
			log("mapping entity: "..entity.name)
		else
			log("mapping entity invalid")
		end
	end
end

local function on_setup(event)
  log("on_setup")
  dump_blueprint(event)
end

local function on_configure(event)
  log("on_configure")
  dump_blueprint(event)
end

script.on_event(defines.events.on_player_setup_blueprint, on_setup)
script.on_event(defines.events.on_player_configured_blueprint, on_configure)

[Therax]

Unless I'm mistaken, you should be using on_player_configured_blueprint. I might call it a bug that creating a new blueprint immediately sets the blueprint (the player did not confirm anything)*.

I believe you are mistaken. on_player_configured_blueprint fires when the player selects Confirm in the blueprint dialog. There are many use cases where the blueprint dialog never appears, such as when using the built-in cut/copy tools.

For my use case, compound entities, it is quite frequent that there are half a dozen entities in the same map tile that are conceptually to the user a single entity, and built with a single entity. It is valuable to be able to maintain that illusion in the blueprint confirmation dialog, which means having some way to affect what is seen in that dialog between the time the user selects an area with a blueprinting tool and the dialog appearing. This is exactly what on_player_setup_blueprint does. The conceptual model is:

a) player selects area with a blank blueprint tool
b) Factorio creates a blueprint of the selected area (on_player_setup_blueprint)
c) Factorio immediately opens the configuration dialog for that brand new blueprint
d) player adjusts blueprint settings (on_player_configured_blueprint)
e) Factorio places the blueprint in the player inventory

[Honktown]

Unless I'm mistaken, you should be using on_player_configured_blueprint. I might call it a bug that creating a new blueprint immediately sets the blueprint (the player did not confirm anything)*.

I believe you are mistaken. on_player_configured_blueprint fires when the player selects Confirm in the blueprint dialog. There are many use cases where the blueprint dialog never appears, such as when using the built-in cut/copy tools.

For my use case, compound entities, it is quite frequent that there are half a dozen entities in the same map tile that are conceptually to the user a single entity, and built with a single entity. It is valuable to be able to maintain that illusion in the blueprint confirmation dialog, which means having some way to affect what is seen in that dialog between the time the user selects an area with a blueprinting tool and the dialog appearing. This is exactly what on_player_setup_blueprint does. The conceptual model is:

a) player selects area with a blank blueprint tool
b) Factorio creates a blueprint of the selected area (on_player_setup_blueprint)
c) Factorio immediately opens the configuration dialog for that brand new blueprint
d) player adjusts blueprint settings (on_player_configured_blueprint)
e) Factorio places the blueprint in the player inventory

I think I better understand now, however, if an entity is not blueprintable (player-creation flag is not set), it won't be transferred for any blueprint or copy. In this example, what the player sees in a dialog is the real entity, but then we should be able to manipulate the data afterwards for the proxy placement.

Testing:
On setup:
Case 1. Copy produces false for player.blueprint_to_setup.valid_for_read, and the cursor is populated.
Case 2. An empty blueprint area selection produces true for player.blueprint_to_setup.valid_for_read.
Case 3. Select new contents produces false for player.blueprint_to_setup.valid for read and the cursor blueprint is empty, but exists.

On config:
Case 1. Copy raises no event.
Case 2. blueprint_to_setup is invalid for read. Cursor is immediately filled, and can be edited.
Case 3. blueprint_to_setup is invalid for read. Cursor has no blueprint.

This produces three weird cases, but each logically distinguishable. In addition, on setup has event.item = "blueprint", which doesn't exist on configuration (implying a single function could handle different cases).

In the bug sense, Case 3 should be the same as Case 2, for consistency sake. In Case 1 (copy) the blueprint can be edited in cursor on setup. In Case 2 we can have blueprint_to_setup edited on setup, or in cursor on configuration. In Case 3 the data can be manually assigned on setup, but we could expect the information to be overwritten once the blueprint is confirmed... there is no way to cause any desired changes during on setup to survive on configuration, nor is there a mapping of which blueprint was the source of selecting new contents. Crux of the bug yes/no? A problem is the blueprint for which we want to add new contents could have been one from the library, and as far as I am aware, there isn't a way to access nor modify a blueprint stored there. That is a significant difference from Case 1 and 2.

Edit: we want to add new contents -> we want to select new contents

[Rseding91]

Ok; I looked into this and figured out what's happening.

The blueprint in the cursor is a red-herring. It's purely used to do rendering and is just temporary garbage. The actual blueprint that gets re-assigned is somewhere in the players inventory.

The re-assign process requires you open the blueprint GUI which means it has to have already been created fully and put into your inventory.

I don't have any nice answer beyond that. The way it was implemented is kind of a giant hack in my opinion and I don't see it getting re-worked any time soon.

[Muppet9010]

This may be a silly question, but why doesn't the player.blueprint_to_setup object get reset to a readable state on the reselection of an area?
As an area of the map has been selected to load the blueprint from, is it not just some blueprint data like name, icons, includes(?) are pre-populated compared to a new blueprint?

[Rseding91]

This may be a silly question, but why doesn't the player.blueprint_to_setup object get reset to a readable state on the reselection of an area?
As an area of the map has been selected to load the blueprint from, is it not just some blueprint data like name, icons, includes(?) are pre-populated compared to a new blueprint?

The original blueprint that had the "select new contents" button clicked has the new contents.

[kovarex]

I looked in the code, and I believe that you should use the BlueprintSelectArea event.

[Muppet9010]

The issue is the difference between a new BP being made and an existing BP having its contents re-selected.

On a new BP being selected the on_player_setup_blueprint event can be traced through to the player.blueprint_to_setup.get_blueprint_entities() correctly. With player.blueprint_to_setup.valid_for_read being true.

However, when the an existing BP has its contents reselected the on_player_setup_blueprint event can't be followed through as the player.blueprint_to_setup.valid_for_read is false. Also reading the player cursor stack doesn't work as Therax listed in his original post.

Therax's original post has the full breakdown of states for the 2 scenarios when the event is triggered.

[Therax]

I looked in the code, and I believe that you should use the BlueprintSelectArea event.

This is exactly the event we are talking about. BlueprintSelectArea on the C++ side is translated to on_player_setup_blueprint. During the processing of this event, there is no reliable way to get access to the blueprint that is actually getting updated. As Rseding described above, the blueprint in the cursor stack is a dummy, and the blueprint being updated is in some inventory slot somewhere, and might possibly even be in the blueprint library. This actual blueprint that is being modified should be accessible somehow, preferably by putting it in LuaPlayer::blueprint_to_setup.

[mrvn]

Unless I'm mistaken, you should be using on_player_configured_blueprint.

This would leave the user with this blueprint dialog where the proxy entity isn't shown in the blueprint dialog but after the on_player_configured_blueprint it would suddenly be there: viewtopic.php?f=29&t=88793

Would also be problematic with the user removing parts of a compound entity while leaving others. The on_player_configured_blueprint might then not have all the data to create the proxy object properly.

[mrvn]

So what is the solution or work around for this then? Any ideas?

Should mods leave all hidden entities blueprintable and included in the blueprint and not have any proxy objects at all? There seems to be no way to convert placed entities into proxy objects and preserve their data when updating a blueprint. Only when making a new one.

[Honktown]

So what is the solution or work around for this then? Any ideas?

Should mods leave all hidden entities blueprintable and included in the blueprint and not have any proxy objects at all? There seems to be no way to convert placed entities into proxy objects and preserve their data when updating a blueprint. Only when making a new one.

There is one workaround... disabling the permission to update blueprint contents, lol: viewtopic.php?p=553118#p553118

[mrvn]

But that looses me functionality. I've been creating new blueprints instead of updating now for a while and it's tedious. You loose the name and icons and setting them again over and over is a pain.

Why can updating the blueprint call the same function as creating a new one. Copy over the name and icons before the confirm dialog and event. Then after confirm replace the original blueprint with the new one. That can't be that hard.

What's the point of modifying the original blueprint object instead of replacing it code wise?

[Sopel]

This appears to be the best possible solution to this bug right now.

tmp.PNG (591.81 KiB) Viewed 7141 times

[Janzert]

To make it clear, as therax discovered since I got this from his mod, you can work around this when the blueprint being updated is stored in the player's inventory. The on_gui_closed event that is fired then has a type of gui_type.item and the blueprint is in event.item. Unfortunately the event fired if the blueprint is stored in the blueprint library, an event of type gui_type.blueprint_library, doesn't give any way to get at the blueprint.

So while it would be really nice to get the player.blueprint_to_setup field filled in all cases before firing the on_setup_blueprint event, just filling in event.item with the blueprint for gui_type.blueprint_library on_gui_closed events would also allow a workaround.

[Deadlock989]

I've just now run into this issue myself. As others have stated above, when a blueprint has its contents overwritten by using the "Select new contents" button, player.blueprint_to_setup has no contents and returns false for is_blueprint_setup(), and you can't get the blueprint from the player's cursor stack either. Functionally this should behave exactly as if you had area-selected with a fresh blueprint, but it doesn't, so things break.

[Rseding91]

In 2.0 there's a new parameter "stack" which is the blueprint that was re-configured. I believe Raiguard is planning additional improvements but if that doesn't happen this parameter will at least always be the item stack containing the blueprint in this event.

The issue was/is: the stack that contains the blueprint that was re-assigned is not in the cursor and not in the blueprint-to-be-setup. It is wherever it happened to be at the time the player actually re-selected the contents. It could be the players inventory - it could be in the trash slots - it could be in a robot - a chest - on the ground - on a belt - anywhere.

[Kuxynator]

struggling over the same bug. I have to assign tags to the bluprint entities. i do this on_player_setup_blueprint. but this works only if this is a new blueprint. on update a cannot add tags because the blueprint_to_setup can't be read (why?).
so how to resolve the problem?

[Plop and run]

I think this is still not fixed in [2.0.10].
The stack is valid if the blueprint in an inventory or in a book, but it is nil if the blueprint is in a player's or game's library.