The collisions routinely fail to change the bullets’ life variable, enemies life variable, and scenery life variables, they bounce off, they collide ON NOTHING.
Literally the most unreliable thing ever.
I have tried changing the exact events several times and it only goes from bad to worse.
With the “bullet” option set in the physics2 behavior it doesn’t work properly, without the “bullet” option it works even worse.
What drives me mad is that the collision actually happens, i.e. the little things bounce off stuff, it just doesn’t register properly for the purpose of changing object variables!
Seriously, I need some help here, or I’ll have to disable physics for bullets and make them use basic collision; because releasing even a demo for a shmup where bullets don’t work properly would be shameful.
Be more specific about when it registers collision and when it doesn’t. For instance, does the problem occur when shooting several bullets or even one is enough?
Any reason for using physics behavior for your bullets?
does the problem occur when shooting several bullets or even one is enough?
It occurs more when there are several bullets, but single bullets can fail too.
A single bullet might push an 1hp enemy (dynamic) away, but fail to diminish either the enemy’s HP value or even its own value.
A stream of bullets may start to rebound off a static scenery piece and for a good while that’s all they will do.
Bullets may get destroyed as soon as they’re created, as if they were colliding with something (they aren’t), when this happens, it happens for a good while too (several seconds)
Most of the time, it’s as if by the time the collision-triggered event is evaluated, the objects involved have already had their positions updated away from each other, and as such the condition doesn’t obtain and the event isn’t executed. (a false negative)
The “false positives”, when bullets are destroyed as soon as they’re created without an apparent collision, or when an enemy explodes in midair when a different enemy is hit, are even more puzzling.
Any reason for using physics behavior for your bullets?
Nothing that really makes me married to it, the only reason is that scenery pieces fly around and that way bullets push them slightly. Hmm, well, that and collision masks/layers.
I’m certainly finding all sorts of reason not to use physics for bullets.
Unless you need the physics, I’d recommend not using it as it needs more computing power than standard forces.
Your false positives tell me that you need to wrap your collision events inside “for each” events (which will add to the required computing power).
One thing I verified yesterday is that it does work on the scenery objects’ side.
If there’s a bullet floating around failing to be destroyed, and a scenery piece is loosened and comes in contact with it, the scenery piece does get damaged (apparently) properly.
It’s bullet destruction what’s the most unreliable, and then enemy damage somewhat unreliable. A bullet might reach -95 life and Mulch 1 without ever triggering the deletion event, but those 95 hits did kill a loose scenery piece.
I guess I’ll give it a few more tries to fix it as an exercise, then when I fail to do so OR see the slowdown I’ll make a standard forces version.
