I’ve been creating little side plugins to mix in with a shooter that I was working on. Lately I felt the urge to recreate portals from Portal/Narbacular Drop. JMonkeyEngine made that very easy. (I can see through them too).
This is just layered onto what was the TestWalkingChar example. That had a simple PhysicsCollisionListener that just checked if ObjectA or ObjectB was a BombControl and then simulated its destruction. BombControl has listeners inside to do pushback and stuff that just check if it was connected. Anyway, since this is simply wired, this bomb will detonate on anything.
Which brings me back to the portal. On detection, it takes anything with a RigidBodyControl and relocates it with a new trajectory. I was able to work around the BombControl behavior by coding in exemptions on GhostObjects.
Anyway, I was curious if anyone knew other tricks or overrides so I can make my portals “generic” enough to work with other listeners without too many special cases.
One idea I had would be to get PortalState’s listener added first and try to clean() or refactor the PhysicsCollisonEvent after the portal does its magic.
CollisonGroupListeners could be used to outright filter out the collision entirely, but then it would require a different means of detection.
could you tell more what do you mean? other listeners should work fine, until they affect changing trajectory that you already do. I just dont understand the issue.
I really should rephrase it better. I’d like to intercept or prevent BombControl’s “If there’s a collision and I’m in it, simulate pushback and remove self” default behavior. I’ll try to come up with a better title.
Other listeners will definitely work in concert, I’d like to still trigger one but prevent another downstream.
In this case, teleporting the bomb on impact without setting it off.
edit: changed title to “Ways to make manage overlapping PhysicsCollisionListeners?”
Ok, I got a chance to test it. if you do event.clean(), it won’t make it downstream to the BombControl to self-destruct. A later collision showed it can still function normally afterwards. The only snag is the explosion effect from the WalkingTestChar example happens on both collisions, but that’s only because that listener was added before the portal listener.
I’ll try to cook up an “intercepter” listener to take precedence that can maybe call child listeners.
(If objectA or objectB is PortalControl, notify portalCollisionListener and then clean event).
That list of filters might need some organizing, but it could act as an adapter for reconciling multiple modules.
Otherwise, the effect could be accomplished by removing/adding collisionListeners in the correct order.
Sorry to waste time, that was bugging me all week and I didn’t get a chance to test that theory last night. I won’t have to make all projectiles “portal friendly” in advance.
What i understand, you want avoid “BombControl collision listener execution” when your listener apply for portal.
Well, you can always just have 1 listener(on physics space, not on per rigid body) and check everything there. (but it will be slower)
Other simple solution would be just check for each listener(also bomb one) if its portal or not/etc. since im also not sure which collision listener is “first” in order.
If you are sure about listeners order, then your thinking seem proper and some methods like “skip other listeners” seems fine then(but i also dont know which method to use in this case)
Yeah, that’s about the gist of it. Avoiding listener execution for BombControl but keeping PortalControl.
I could do either of those things, if I plan far enough ahead. (Make/mod BombControl to detect Portal or run it all through one big listener).
I’ll go with making a InterceptCollisionListener that just exists to relay collision events to child listeners, I’ll include the ability to rearrange the children if needed. Then I just have to add that listener first and I will be certain on the order. (Or rearrange it, as maybe I want a listener to add sound/particles when something hits the portal before the event.clean(); is called).
Thanks for the responses as they helped me confirm that monkeying with the listeners is the way to go.
I’ll call it “solved” later tonight, so they’ll have that window to call me a madman or cryptically warn of “Unforeseen Consequences”.
If I understand the premise correctly then another way to handle this might be some kind of type matrix.
Each object would have some kind of base type: bomb, portal, mob
…where ‘mob’ can be the default for things that don’t specify their type.
Then a 3x3 array indexed by type can call a different kind of listener/handler depending on the two types in the collision… with some elements of the array pointing to the same listener/handler.
From there you would know exactly what to do for bomb+bomb, bomb+portal, bomb+mob, mob+portal, etc.
My thoughts were drifting in that direction too, but weren’t as fleshed out yet. TypeMatrix will probably get added (by way of the “interceptor” listener that just forwards to child listeners). I’m 80% sure it will just be by way of comparing Control types.
Sorry, I should have come back and called it “solved” about a month ago. Getting a listener to do a bypass in first will work for now, and I can move to some kind of type matrix to refine it later.