Prototype with custom Keys (stupid question)

[AenAllAin]

Sorry for the stupid question, but is it possible to add a custom/new key to an existing prototype's data table that propagates to the instancing entities?

For instance,

Code: Select all

data:extend({
 {
   type: "furnace",
   name: "bigfurnace",
   [i]foo: "bar",[/i]
    ...
 },
})"

control.lua:

Code: Select all

...
if event.entity and event.entity.name == "bigfurnace" then
   local myfoo = event.entity.bar
end
...

[Rseding91]

No.

[AenAllAin]

No.

Ah! good! ...I feel less stupid.

So building upon that paradigm, can I assume it would be good practice then to map any custom keys or values to instance entities using an association array (not an associative array; rather an array that tracks associations [although an associative array is used for this purpose]) stored in the "global" memory and a "grouping" algorithm?

And given also that the entity references are somewhat transient between script usage thus cannot be relied upon for indirect comparison or hash keying, and given that we do not have access to the underlying entity identifiers, would it then also be good practice to use a "hashing" algorithm of the exposed entity attributes to efficiently key the "grouping" algorithm.

...in other words, I hashed the entity.position coordinates and used the hash as a key to a grouping table, so I could associate two entities and treat them as one.

I just wanted to make sure I am on the correct track for mod implementation as intended. It sounds like from what you are saying, I am.

[Rseding91]

No.

Ah! good! ...I feel less stupid.

So building upon that paradigm, can I assume it would be good practice then to map any custom keys or values to instance entities using an association array (not an associative array; rather an array that tracks associations [although an associative array is used for this purpose]) stored in the "global" memory and a "grouping" algorithm?

And given also that the entity references are somewhat transient between script usage thus cannot be relied upon for indirect comparison or hash keying, and given that we do not have access to the underlying entity identifiers, would it then also be good practice to use a "hashing" algorithm of the exposed entity attributes to efficiently key the "grouping" algorithm.

...in other words, I hashed the entity.position coordinates and used the hash as a key to a grouping table, so I could associate two entities and treat them as one.

I just wanted to make sure I am on the correct track for mod implementation as intended. It sounds like from what you are saying, I am.

All of the entity/object references are comparable with the == operator in Lua which will tell you if the two references are pointing at the same underlying object. http://lua-api.factorio.com/

[AenAllAin]

No.

...

All of the entity/object references are comparable with the == operator in Lua which will tell you if the two references are pointing at the same underlying object. http://lua-api.factorio.com/

I found that, but it leaves you with only the "brute-force" method for finding the matching entity in any array you make to store the associated information (right?) ...you cannot hash the entity table reference and expect to find the "same" entity between event handler triggers; plus we don't have access to the underlying entity ID; so how can we efficiently find the correct entity? If everyone writing mods just goes out and uses the naive approach of just an '==' comparison, then eventually having mods will always tank your performance. We need an efficient way to look up this kind of association ...for custom items that have an invisible component, I just hashed the position coordinates and used that as an index.

For instance, that is how I created my "powered walls"; I have an item with two entities: a 'wall' entity and an 'electric-pole' entity. I made one of them invisible and the other unselectable, so they operate as a single entity. But I had to associate them somehow so they get destroyed together; and they are walls, so I didn't want a lot of overhead in doing a "brute-force" matching lookup every time, so I keyed/indexed them by their position hash.

I think there are many possible applications for doing this; if this isn't a violation of your intent for mods, could it be included in the basic utils package also? ...I have a working mod now to demonstrate if this still sounds like jibberish?

[Adil]

Well, data structures implemented in C might bring joy to a couple of meaningless performance maniacs out here.

I just hashed the position coordinates and used that as an index.

These days you might want to take into account the fact, that there might be more than one surface.
I'd make a guess that for overlapping entities you may even just use .surface.get_entity() if it is only needed when the position of the partner entity is known and the handling happens only rarely.

[AenAllAin]

Well, data structures implemented in C might bring joy to a couple of meaningless performance maniacs out here.

I just hashed the position coordinates and used that as an index.

These days you might want to take into account the fact, that there might be more than one surface.
I'd make a guess that for overlapping entities you may even just use .surface.get_entity() if it is only needed when the position of the partner entity is known and the handling happens only rarely.

Very good point. I should add the surface ID as well...