Shape object ideas

[Nexion]

Could you maybe add a little bit more functionality w/ shapes and bodies?
Having to switch between the two is a pain without built in functions for it.
The main thing I'm thinking of is something like shape:getBody() that would simply return the body that the shape is attached to.

[rude]

I've added this to the task list. 8-)

[Nexion]

Awesome.

I had another question rude, but I don't think it really calls for another thread.
Are body:destroy() and shape:destroy() depreciated? Whenever I try to use them LOVE errors and doesn't remove the shape or object.

[rude]

The object will only be destroyed if it really is the last reference. Shapes and joints keep internal references to their bodies, so if you destroy a body without destroying its joints and shapes, nothing will be destroyed. Order is unimportant, but everything associated with a body must be destroyed for the body itself to be freed.

Yes, yes, docs, I know.

[Nexion]

OK, I don't have my code in front of me but that's probably where I went wrong.

Do you think it would be possible to put a variable in the config file to tell LOVE what quadrant to be in? It would be handy to have the origin be at the bottom left in some cases instead of the top left. Just have it be an ENUM for what quadrant

Also - you and mike should just take a day and improve the docs as much as you can.

[rude]

You'll be able to set the viewport in a future LÖVE version. Then you can have the origin wherever you like.

[MHD]

I think it would be really nice that the body was the top of an entity tree (being the GarrysMod programmer I am), thus if you destroy the body, all shapes and joints will be destroyed too. It doesn't need to be :destroy() but maybe a new function called :destroytree() or similar.

Also a body:getShapes() would be nice.

[rude]

That is possible, but it would mean death and pain for those who try to access implicitly destroyed joints and shapes. If you try to access something destroyed now, you get an error at least. With something like destroytree(), you could end up getting something closer to a segfault. Not sure I want that.

Body:getShapes() should be possible without problems, though.

[MHD]

Also, how about world:getBodies() and world:getShapes() ?

[rude]

The reason I didn't implement all these "get" functions in the first place is because of boost::shared_ptr, and somewhat shabby access to the SWIG runtime.

Next version will use raw pointers, and a custom typesystem, so things will be much more flexible.