setRadius()

[Xcmd]

Is there any way to change the radius of a physics shape? Because right now the only way I can figure to do it is to destroy the old body and create a new one. And that just wreaks havoc on the collision engine, which suddenly no-longer recognizes the new shape, even though I use setData to make the name of it identical. I've got two games in mind that I'd use this for if I could, but they're not going any further without this ability.

[bartbes]

Not as far as I know, about destroying them, you might want to do that explicitly and let the lua gc clean up before you continue. (might create huge lag though)

[Xcmd]

I'm just going to have to figure out genius hacks to get this done. That or abandon the project.

Oh well. I've got other projects.

[Zorbatron]

Not as far as I know, about destroying them, you might want to do that explicitly and let the lua gc clean up before you continue. (might create huge lag though)

You want him to force a garbage collection cycle after he explicitly removes the body and sets any reference to it to nil? Why is this?

[bartbes]

Because it takes a while for it to catch up, yes you might be able to explicitly destroy anything, but there are enough examples where simply calling destroy still leaves behind something in the physics world until it is garbage collected. However, it might be that if you destroy each and every part of what needs to be destroyed this might not be the case, in any way, this has never been tested, and it's always better to be safe than sorry, I never said it was a good solution.

Why this might fail can has several reasons, almost all of them have something to do with a reference in C++. Hopefully, these problems won't occur in 0.6.0 as there wrappers are custom made, and so are the data objects.

EDIT: WAIT! I don't want it to sound agitated, I just am at the moment of writing. No offense to anyone.

[Zorbatron]

No you didn't seem agitated.

I agree with avoiding creating and destroying userdata frequently, however, forcing a GC cycle I was told should only happen when you're outside of any major loops.

[bartbes]

Which never happens in LÖVE, it's all one big loop. And in any case running a collection cycle is performance-wise not smart to do, however, when it comes to accuracy, or even just correctness it might just be a necessity. It might be possible (but unreliable) to get away with a single garbage collection step, instead of a full cycle, anyway, there is no good way to do this, let's wrap this up.

EDIT: Of course I am open to suggestions, as I imagine Xcmd is too.

[Xcmd]

So far my super-awesome trickery has come up with the following:

Create an array of objects that are all the size that the player could potentially be and update ONLY the active object. Thus the object already exists.

Down-shot of this is if I have too many potential sizes... well... you get the drift.

[Zorbatron]

So far my super-awesome trickery has come up with the following:

Create an array of objects that are all the size that the player could potentially be and update ONLY the active object. Thus the object already exists.

Down-shot of this is if I have too many potential sizes... well... you get the drift.

Good work around, how do you choose which ones to update? Don't they all have to be updated at the same time? (world:update())

[Xcmd]

What you do is put the objects to sleep and put them off-camera somewhere. Wake up the objects as the player increases sizes and move the previous object off-camera and put it to sleep. Or explicitly destroy it if the player cannot shrink in size.