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

[Harag]

To rephrase Sopel's "solution":
This system of passing around additional settings through tags probably took some effort to implement but it's been useless the whole time because there's a situation where nothing can be stored in them. Leaving the player with a broken blueprint because it lacks necessary information is not really an option.

Could an additional event field maybe fix this?

record :: LuaRecord? The library blueprint that is updated

This should be writable no matter where it is.

[Honktown]

I keep coming back to "where's the barrier" when pushing a blueprint from game state into a library?
On the Lua side:
1) we get events for what was blueprinted
2) those things can have data attached, modified, removed, etc.
And this is critical:
3) A script inventory can be created
4) The blueprint data can be stored there, in an actual blueprint
5) The inventory can be exposed to a player, or require them to do something to get an item
6) They can put it in their library
Where is the breakdown where a player clicking an item and moving it to their library cannot be done engine side? Blueprint data being applied to their local state already happens, otherwise we wouldn't be here!

If all the updating was done directly to the library, without intervention, that would make sense, but at least something makes it through, because we can get an event that it happened, and the information relevant. It seems perfectly sensible (from the outside) for everyone to create and act on a temporary 'blueprint stack', and then everyone but the maker throws it out. The one who made it gets it transferred to their library.

[raiguard]

Four years later, I finally have a solution for this.

In all cases except for reassigning contents to a blueprint record, you can use the stack parameter of the event.
For reassigning blueprint record contents, there is a new record parameter that you can use to edit the record.

I apologize that this is bringing even more complexity to blueprint handling, but it's necessary complexity. Blueprint items and blueprint records are fundamentally different things in the engine.

Anyway, fixed for 2.0.34!