Physics object identity (possibly a bug in Löve)

[Rad3k]

Consider the following piece of code:

Code: Select all

world = love.physics.newWorld(0, 0)
shape = love.physics.newCircleShape(1)
body = love.physics.newBody(world, 0, 0, 'dynamic')
fixture = love.physics.newFixture(body, shape)
same_fixture = body:getFixtureList()[1]

print(fixture == same_fixture)
print(rawequal(fixture, same_fixture))

In my case, it outputs

Code: Select all

true
false

Same applies to fixtures passed to collision callbacks, bodies from Fixture:getBody(), and probably every other objects that can be accessed in a similar way. I discovered this when I tried to make an object keep track of fixtures it's touching, by using a table with fixtures as keys and numbers of contacts (with the particular fixtures) as values. Current behavior complicates this quite a bit.

It seems like somewhere in the code, same box2d objects are being wrapped in different lua values. I wonder whether this is a bug, or is there a good reason for it to work like that. Any thoughts?

[kikito]

What's rawequal? I haven't seen that one before.

EDIT: Ok, found it - rawequal . Hmm. The only option I can think about is using the Data of setData instead of trying to identify each body by its fixtures.

[Boolsheet]

Yeah, I stumbled over that one too. This is a side effect of the chosen implementation because LÖVE has to juggle 3 things at the same time: The LÖVE object instance, the Box2D object pointer, and the Lua userdata proxy.

I believe the userdata proxy stuff would have to be rewritten to get the userdata equality back.

[bartbes]

It is a necessary evil, we can't duplicate full userdata without recreating the proxy, unless we'd know exactly where each userdata is.
Now, you might be thinking, this is possible, and it is (albeit crappy), but not with threads.

[Rad3k]

What's rawequal? I haven't seen that one before.

EDIT: Ok, found it - rawequal . Hmm. The only option I can think about is using the Data of setData instead of trying to identify each body by its fixtures.

This is probably the way I'll go, though it requires that I assign unique data to all fixtures that I want to keep track of.
The other way would be to iterate over a table checking each element if it's the one I'm looking for, but it's a rather ugly hack.

It is a necessary evil, we can't duplicate full userdata without recreating the proxy, unless we'd know exactly where each userdata is.
Now, you might be thinking, this is possible, and it is (albeit crappy), but not with threads.

I guess I'll take your word for it