Love2d and collisions

[Kevin Tillman]

Hello, I have been through the documentation on mini physics and I have expiramented with the code. But I have no clue where to begin when dealing with triggering events from collisions. I have set up two hampster balls from the mini physics documentation and I want a sound effect to play when a collision happenes between the two balls, but which functions of love2d do I use? Are they the contact functions for the shapes?
And also, how would I set that up through code? Could someone give me an example to go by please. 8-)

[steventrouble]

AHA! There's some pretty good physics and collision checking documentation here:
http://love2d.org/docs/love_physics.html

[Kevin Tillman]

AHA! There's some pretty good physics and collision checking documentation here:
http://love2d.org/docs/love_physics.html

Nothing is explained....granted the explanations on things in the tutorials are descent, but that only goes so far...

http://love2d.org/forum/viewtopic.php?f=3&t=853

my thoughts exactly.....

an engine is only as good as its documentation....

[bartbes]

But you might also know that documentation and open-source projects have a long-term bad relationship..
And I can argue that a coder is as good as his own code...

[Robin]

But you might also know that documentation and open-source projects have a long-term bad relationship..
And I can argue that a coder is as good as his own code...

And if a documenter is as good as his own documentation, we can infer we need good documenters.

Volunteers?

[kikito]

I've been thinking about this and I've got several suggestions:

Some random ideas:

• Making a forum thread for "documentation volunteers". There, people would say "I have created this tutorial / I have finished updating this potato stuff". I could create this thread myself, but I think it would get more attention if someone from the LÖVE core team did it - so it looked more "official".
• Maybe some sort of contest? eg: the person that documents more or better gets his feature requests on the issue tracker prioritized.
• Or a small/symbolic incentive system. Eg. those providing nice tutorials will get a "documentator bage" (like a small icon visible under their forum picture). See the badges system on stackoverflow.com. The vBulletin forum engine supports this kind of "awards". I don't know if the one used in LÖVE does. If not, a symbolic "documentator" role (not different from regular users except for the name of the role and maybe the link color) would be just fine, too.

I've also have several wiki-specific suggestions:

• We need a standarized way to differentiate between 0.5 and 0.6 stuff. For example, if someone adapts the callback tutorial to .6, we need to decide how should be the new tutorial named. Should we rename the 0.5 version, too?
• Or, we could have a completely separated 0.6 wiki,
• Or, some kind of "tag", "branch" or "subfolder" for the 0.6 stuff. I don't know if the current LÖVE wiki supports this stuff.
• Provided that we resolve the 0.5 vs 0.6 stuff, I think we should start linking to wiki articles from the potato doc. Maybe a :wiki tag? Otherwise we can just link using urls.

I can more or less document the Physics part (warning: it will take loooooong) . But I still haven't touched images or sound, and I've just started with the input system, so I hope there are better candidates for this.

[scirath]

Tongue-in-cheek suggestion for the documentation badge name: Uber-Ink God.

[pekka]

Please start a new thread about the documentation project. It needs more visibility. I'll answer the original quetsion here to encourage that, and hopefully help the guy who asked.

In Box2D and Löve we use callbacks that are triggered when collisions and related events occur. Here is what Löve docs have to say about setting callbacks:

http://love2d.org/docs/World_setCallbacks_1.html

Note the connection to Shape:setData. You set the data field in each shape to tell them apart and then write the callback to deal with this data appropriately. As it says in the setData docs, you can put table references there, but really anything is OK, as long as you can treat it usefully.

The final callback is briefly explained in Box2D documentation, in case you are curious. It has to do with constraint solving related to situations where (possibly many) objects collide. I have yet to need it for anything I've done with Löve, so you can probably ignore it for a while too.

Note that if you destroy or otherwise mess with you objects in the callback, it may lead to the whole program crashing. A better way is to set some flag the means the object will be destroyed before next update. In the words of the Box2D docs:

It is tempting to implement game logic that alters the physics world inside a contact callback. For example, you may have a collision that applies damage and try to destroy the associated actor and its rigid body. However, Box2D does not allow you to alter the physics world inside a callback because you might destroy objects that Box2D is currently processing, leading to orphaned pointers.

The recommended practice for processing contact points is to buffer all contact points that you care about and process them after the time step. You should always process the contact points immediately after the time step, otherwise some other client code might alter the physics world, invalidating the contact buffer. When you process the contact point buffer you can alter the physics world, but you still need to be careful that you don't orphan pointers stored in the contact point buffer. The testbed has example contact point processing that is safe from orphaned pointers.

(Box2D is of course the C++ library that Löve uses for physics simulation.)