Strange bug adding components about lovetoys

[raffomania]

Sorry we're being so slow. I'm now looking into it.

[Nukesor]

I'll close this.
Your "Bug" is wanted behaviour. Our ECS doesn't use entity ids for every component type entity, it uses Entity ids for internal management of Entitys in the engine. Every Entity gets a unique id and that's it.
It looks like you expect Entity ids to be linked with Systems, but it's just an Engine thing
You shouldn't encounter any bugs with this, as you shouldn't use the entity id for anything anyway.

Btw. I know about the behaviour of # and I exploit this behaviour to reuse Entity ids of deleted Entitys, as this is the fastest way to get the next free int in the Entity registry.

[Nukesor]

The Engine has a function Engine:getEntitiesWithComponent(component). This gives a list with all entities which have the named component.

Engine:getEntitiesWithComponent(component)

component (String) - Class name of the component
Returns a list with all entities that contain this particular component.

If the total amount of entities with a specific component is a thing that is often needed, we can implement a new helper function for this :).

[raffomania]

So, after a lot of confusion, to clear this up:

system.targets is not a list, and thus the # doesn't work as expected. We're using global entity ids to index entities in system.targets, making it a hashmap/dict. In general, this is not a "wrong" way to store ECS data. It is arguably more cache-friendly to iterate over lists, while hashmaps provide more convenient deletion and fast access via entity ids. Also see here.

We're currently thinking about implementing a __len metamethod to count the entries in system.targets, either on-the-fly or using a counter keeping track of modifications to the table.

Edit: It should be safe to use entity ids for checking the equality of entities.

[rosshadden]

Note that Position has nothing to do with it. This is true for any component, any system, and any entities. My own codebase has REALLY crazy problems stemming from this, as the problem gets a lot worse with more entities and more components. It seems like the entities that are defined later are adding their components to the ones that were defined earlier.

[rosshadden]

Also looping through the entities in the targets table of the system reveals that the duplicate targets are all nil. So in the first example, the foo entry is nil, and bar is the expected entity.

[mpicard]

What version of Lua are you using @rosshadden ? Similarly, what version of Lua is lovetoys developed for @raffomania ? (Out of curiosity mostly)

There seems to be a "bug" in the table length operator # that counts elements that are nil I believe. It seems as though the TestSystem.targets for some reason is picking up then nulling foo? The work around I use is to do pairs(self.targets) to filter out the nils:

function TestSystem:update(dt)
    local count = 0
    for k,v in pairs(self.targets) do count = count + 1 end
    print(("#self.targets = %d, count = %d"):format(#self.targets, count))
    love.event.quit()
end

Have you made any progress @raffomania ? I'd like to help so if you have any ideas let me know.

[rosshadden]

@mpicard I am using love2d, in which the latest version uses luajit 2.0.4.

In my own ECS, SECS, I store entities in arrays (numerically-indexed tables) on systems, rather than tables with keys. It is faster to enumerate numeric tables (ref 1, ref 2), and they do not suffer from this problem.

[raffomania]

@mpicard we develop against the version love2d is using, which is luajit 2.0.4 as @rosshadden mentioned. I'm running the tests with lua 5.3.3 though, mainly out of lazyness and because nothing has broken because of that yet ;)
Do you have any reference to a report regarding the # issue? I've not heard of that yet.

[mpicard]

I'm also using Love2d as the game engine and lua 5.3.3 for busted, I was just wondering if you were testing using luajit, I don't think that's the problem.

It's not a bug per se but I found this on the mailing lists with the related documentation on the length operator that says the following interesting behaviour...

Unless a __len metamethod is given, the length of a table t is only defined if the table is a sequence, that is, the set of its positive numeric keys is equal to {1..n} for some non-negative integer n. In that case, n is its length. Note that a table like

{10, 20, nil, 40}

is not a sequence, because it has the key 4 but does not have the key 3. (So, there is no n such that the set {1..n} is equal to the set of positive numeric keys of that table.) Note, however, that non-numeric keys do not interfere with whether a table is a sequence.

function love.load()
    targets = {}
    targets[1] = "instance of class Entity"
    targets[2] = "instance of class Entity"
    print(#targets)  -- prints 2
    targets[1] = nil
    print(#targets) -- prints 2
    targets[3] = "instance of class Entity"
    print(#targets)  -- prints 3
    targets[3] = nil
    print(#targets) -- prints 2
    targets[4] = "instance of class Entity"
    print(#targets) -- prints 4
end

🤔 not intuitive behaviour at all. Thanks for the links @rosshadden I'll have a read!

[raffomania]

Interesting. I recon we should stop using the # operator to find new entity IDs. I must have misread its exact semantics.

[mpicard]

Oh that's good to know! so use some other identifying component to do comparisons and then what about the length operator? What would be the best method to quickly work out the length of entities with a particular component? It's been a while since I worked on my lua game

…

On Sun 12 Mar 2017 at 7:43 p.m. Arne Beer ***@***.***> wrote: I'll close this. Your "Bug" is wanted behaviour. Our ECS doesn't use entity ids for every component, it uses entity ids for internal management of entities in the engine. Every Entity gets a unique id and that's it. You shouldn't encounter any bugs with this, as you shouldn't use the entity id for anything anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHHYRru9taK9CAHr0flLi8YuhIZu1bDSks5rlErPgaJpZM4J0v1o> .