[lua][feature] User defined data attached to lua entity

[Asynchron]

Hi,

Just wondering is it possible to add capability to attach mod data to the lua entity itself?
i.e. given a lua entity 'a':

Code: Select all

a.user_data = 'my fancy data'
print a.user_data // will print 'my fancy data'

Such functionality will allow storing arbitrary information on entity itself and will eliminate any need to do search of relevant mod data for entity in potentially huge tables that mod itself maintains.

Best regards,
Asynchron.

[FuryoftheStars]

First, I want to note that all of these modding feature request threads you've been making belong to the Modding Interface Requests subforum.

But, as for this particular request, you may want to give this related (and refused) modding feature request thread a read: viewtopic.php?f=221&t=53615

[Asynchron]

Thanks for help,

I wasn't sure if modding interface requests forum was appropriate, since it felt more like requests down to specific api enhancements and not more general topics.

If someone could move them to modding interface requests, that would be appreciated.

Now onto thread you've shared.
This one was about transferring data from data stage to control stage. The suggestion I made was purely for control stage.

Say you have a mod that needs to keep some info for a specific assembler in game (a non-persistent property). Currently you'd do this by keeping a table in the mod with all pairs for assemblers -> your configuration/property. Every time you'd need to know what property value this assembler has, you'd have to look into that global mod table, find your assembler and then read the property.

What I'm suggesting is that LuaEntity class should have a new field, let's call it user_table (better if it is user_defined_data) that is writable. Now having this field in each instance of LuaEntity (assembler from example), would allow the mod to persist these values in it, and upon next event that involves said assembler, retrieve it from that field. This circumvents any need of bookkeeping all assemblers that the mod is interested in a global mod table, and circumvents an unnecessary operation, improving performance a bit, and eliminating cumbersome need for modder to do all this bookkeeping.

I think and hope this shouldn't be a complex thing to implement, and somewhat worth feature to add.

Regards,
Asyncrhon

[FuryoftheStars]

Now onto thread you've shared.
This one was about transferring data from data stage to control stage. The suggestion I made was purely for control stage.

Ah, apologies, missed that.

[PFQNiet]

I'm fairly sure this would actually be worse for performance, since you'd be querying the game engine for the user data rather than using your local Lua environment for it. Interfacing between script and game are the biggest bottleneck for mod performance, and such round trips should be minimised.

But perhaps more importantly, this would be a nightmare for multiple mods trying to use this feature. They would have to take care not to clobber each other!

[Asynchron]

Hi, thx for info,

To clarify, does this mean that LuaEntity isn't a direct mapping to internal representation of said object, and upon querying a field or other, they might pull data from different objects in the engine?

In regards for multiple mods, indeed it would be a nightmare if implemented at minimum, I planned to suggest to have this field scoped to each mod, so they couldn't interfere with each other, if there weren't any other concerns.

[boskid]

Unfortunately based on how our scripting support looks right now, we try to keep arrows always [ Lua ] ==> [ Game ] (and events are notifications where Lua registered as a GameActionListener) - they are separate so much that Lua data goes to script.dat and Game data goes to level.dat inside of a save file. That means we try to never keep mod's specific data in game objects unless they are allowed to be touched by all mods. One example of such data is for example LuaEntity::tags available only for EntityGhosts which can be touched by any mod. We have quite high pressure on keeping entities small in memory so we do not have general support for tags because that would mean every entity (including resource entities and trees) would immediately become larger. There are also limitations related to type of data that can be stored on the game side (lua would not be able to put a metatable, a function or a LuaObject here and expect it will persist because those are all concepts from Lua and we do not want to keep LuaRefs in game since they would not persist correctly across save-load).

For now primary approach for extending entities with mod's custom data is to have some sort of table under `global.some_table` indexed by some unique value taken from entity itself. Most commonly used value is `unit_number` which is uint32_t but there are also other solutions like usage of unique registration id given by LuaBootstrap::register_on_entity_destroyed.

Usage of tables on mod side lets us not have to deal with mods extending lua objects at all and it is quite flexible on the mod side, because there you can have any amount of different custom tables, covering possibly same entities without any problems.