[Paid Request] Physics Behaviour Collision Table

Hey there!

I have been intensely trying to work with the limitations of the Physics behaviour's collision system and have come to a point where I'm certain I need a little bit of extra functionality. I am offering £10 (or hopefully a little bit more) via PayPal as a donation for helping me out. Not sure if it's considered fair for the work required or even much money. I'd have waited for the Scirra store business, but, well, perhaps this takes a while to develop and I could purchase it from the store when it gets released )

[Below is a simplified hypothetical situation, not the actual situation I hope to use it for]

Say we have "Item" which is a Sprite with Physics behaviour on it. We have "Ground" which is a immovable physics sprite, and we have "Hole" which is a simple square sprite that goes on the ground. Now, if Item is overlapping "Hole", I want it to disable collisions between Item and the ground.

1st problem is a glitch that I have reported here and have been told that it can't be fixed. If the Physics object is close to a ground and becomes disabled to the ground, it won't take effect until the object moves a bit further. That's not the main problem though, I managed to create a strange workaround involving modifying the Physics behaviour's settings to allow assigning multiple Physics behaviour onto 1 Sprite. It works, but if this could be somehow worked around without needing a 2nd physics behaviour, that'd be awesome. ^^

So say we have done my workaround, this means my item will correctly collide with the hole and fall through it (sometimes the physics behaviour will react first in this scenario and will bounce off the ground rather than detect the hole first, is this fixable? Making the Behaviour behave AFTER the event sheet?). Problem is, if I had multiple instances of the Item, and one is overlapping the hole whilst another is about to land on the ground, then there's a problem. Turns out that all instances share the same "Ignore Collisions" rules (Even amongst multiple physics behaviours within the sprite like I'm doing, meaning if you disable the ground collision for "Phys1" behaviour, it will also disable it for "Phys2" behaviour. Hope I'm making sense here.), rather than having their each individual rules. The absolute main thing I need, is to allow each instance of a physics object to have it's own "Disable/Enable Collisions" table within the behaviours code, without sharing it across all instances.

Is this request unrealistic or unfeasible? Is this a possible thing but performance would be hit astronomically? I'd love to have any explainations and information. ^^

Many thanks!

I am sure i had something similar to this working. I have a feeling it only disabled collisions whilst overlaping the hole. Will see if i can find it..

Hey, thanks! I have made many different attempts with new capx files, sometimes I get the illusion it is working (like, 5 items are resting on the ground, then I spawn one above the hole and it will fall into the hole whilst the other 5 items actually stay on the ground, which is how it should work) but the only reason they were staying on the ground was because of the glitch I linked above (So, the 5 resting items need to move away from the ground to actually disable it's collisions according to the glitch). So yeah I fail

Do you want to spawn the hole beneath objects already on the ground ?. In my case the hole was placed at design time and not spawned dynamically.

Well the hole would be just sitting there, placed in the Layout editor, with no behaviours or anything, just a square shape that is overlapping the ground. So yes, in design time So you have something that actually works? :O *excitement intensifies*

By the way, I'd post diagrams + capx's but am currently unable to.

Jase00

Ha, well it worked fine for my purposes. I am not at home at the moment however when i find it i will probably need to clean it up a bit. Will post it as soon as i can

That's awesome! I hope I've been clear though, I've tried a lot to have multiple instances behave this way, and I mean I've tried a lot. It'd be awesome if I was making a stupid little mistake all along somehow but I feel pretty confident that there's a limitation to Physics. Hoping I am wrong though

Hmmm looks like you're right after all i am afraid. I checked out my old code and realised it was for a single instance at a time Seems to me though that this particular problem is with C2 and not the actual physics. The option to disable collisions with a specific object should do just that. It should allow individual instances to be enabled and disabled dictated by the object picked. As it stands physics collisions are either enabled or disabled totally ignoring the picking.

Sorry i couldnt help. I would have been surprised if you had missed something somehow

Ahh man, I really appreciate you taking the time to check it out.

I'm figuring the reason that multiple instances share the same collisions, is because of performance and efficiency issues, but man it's so important to my project, the hit may only be bad if there's like 100 objects at a time. But ehh... hopefully there's a solution.

Again, thanks spongehammer ^^

I'm still hoping there's a stupidly easy solution to this.

Jase00

Can't you just spawn another sprite with an identical image at the same location and do a completely different behaviour?

Like -

Object A is Overlapping hole - Spawn Object B

- Destroy Object A

For all intents and purposes, it's the same thing, and there's not reason you couldn't transfer instance variables etc between the two.

JohnnySix

You know, I've never thought of that before. You've put my mind on a good path, I think I can come up with a workaround. I could have a Parent object of the Item, with 2 different physics objects paired with it, and the Parent item can position to the appropriate one when it needs to. I guess the only downside would be that whenever I add a new item that is a different shape, I'd have to add the Item's image 3 times (or the two physics ones could just be an invisible polygon but still). But it just might work. I'll have to try that soon. Thanks for the inspiration!