SOLVED Force overlapping physics sensors to refresh?

[CruelBus]

Here's a scenario: (edited)

There is a log being pushed over the edge of a cliff.
The log has a single sensor fixture that covers its full length.
The cliff has a single sensor fixture that covers its edge.
The log may move or rotate while hanging over the cliff..
I want the point where the log crosses the cliff to constantly emit particles.

I know that when the sensors first collide, there is a single collision event that is fired and no further collision events will occur until the 2 sensors are no longer overlapping.
The collision event between 2 sensors does not contain any phy_collision_points.
I can test the overlapping as much as I want, to check if the overlap is still happening, but can not get an updated collision list.

Is there a better way to handle this interaction? Maybe spam the creation and destruction of sensors to force new collision events?

SOLVED: I made more cliff sensors of a smaller size to more accurately track the overlap using physics_test_overlap , and then used the x and y of those sensors as the spawn location for particles.

 

[CruelBus]

Did some experimenting.

Spam creating sensors doesn't work using sensors the size of the log, since again, the only thing that is registered is "a collision happened" and not where precisely it happened.
Changing the log sensor to a regular fixture also does not yield any collision locations versus a sensor.

I am thinking that I should create MANY much smaller cliff sensors and do a physics_test_overlap every 30 frames. then if "true," create the particles inside the cliff sensor at that tiny sensor's x and y, instead of the log sensor . That's going to be quite a bit of work since the cliff edge is procedurally generated at column widths of 60px, and now I'll do it about every 6px. All of that just to get "dirt" to fall from the cliff edge.

 

[Nocturne]

Can you give us more information about the project and your reasons for doing what you're doing? If you're using sensors then it would imply that the project is physics based, and if those objects with the sensors are moving then I have to ask if they have a fixture? If they have a fixture (and they should if it's a physics engine game) then why not use the regular physics collision event which will return contact point positions? I'm just wanting to know more general info about the game, as with the information supplied it's hard to suggest an alternative or a fix, since the information is VERY specific.

 

[CruelBus]

@Nocturne Hi, Nocturne.

So, the game has a procedurally drawn cliff edge using a tile system. Another procedure creates a "CLIFF1" cliff sensor object per cliff edge tile with an embedded fixture set as a sensor. "CLIFF1" is a child of "CLIFFS."

The "log" in this case has its main "hard" collision fixture, and several attached sensor object, that each have a sensor fixture bound to them, to handle things like rolling through a puddle, or falling over the cliff. The log cliff sensor has a collision event with "CLIFFS." When that sensor collides with the cliff edge sensor, I had particles emit from the (x,y) of the log's cliff sensor. That works okay, but some logs are longer than other, so the middle of the sensor is sometimes a ways back on land, and not really near the cliff.

So then I reversed the event, having the cliff edge's sensor emit the particles from its (x,y) and this made sure the particles were always at the cliff edge, but always at the middle of that sensor, and not necessarily exactly where the log crossed it.

The goal is to have a constant stream of particles falling off the edge of the cliff, very close to where the log is actually crossing the cliff. I can get the stream of particles by constantly by performing the physics_test_overlap, but again, the particles will only spawn precisely where I tell them to, and not at the actual precise location of the overlap, like using collision masks would. I also have no real way to get that precise location of the overlap using physics sensors, so I was hoping to find another way of achieving the effect.

I am currently in the process of making the cliff edge sensors 2px wide and will see if that chokes the whole system. At 2px wide, that will be plenty close using the physics_test_overlap to generate particles at the (x,y) of the cliff edge sensor.

It may be a little unnecessary to have this effect, but some beta testers have mentioned that it's hard to tell the cliff edge from the flat playing surface and I thought having some visual clues would help. Finalizing the graphics will too, but that's an issue for future me.

 

[Nocturne]

Ah, Okay I understand what you're doing now... Hmmm... Does the cliff also have a "regular" fixture? I imagine it must have. In this case then doesn't the collision event provide a list of collision points between the regular fixtures? EG: https://manual.yoyogames.com/#t=Gam...Physics/Physics_Variables/phy_collision_x.htm

I suspect that you're already aware of the above, but I mention it just in case... Other than that I think your proposed solution of multiple, tiny sensor fixtures may be the only way to achieve what you want. I have no idea what overhead having so many sensors would have, but I'd imagine it would be quite small due to them not actually interacting with the physics system. So, this may just be the best answer to your issue! If you try it, let us know how it goes... I use the physics system quite a lot for things, so I'm curious to know how using a lot of sensors affects performance.

 

[CruelBus]

@Nocturne Thank you!

I just completed the test for sensors every 2 pixels, so well over 600 sensors, and... it works great, with minimal overhead.

The cliff edges only have a sensor fixture because (I think) if I put a regular "hard" fixture there, everything will just bounce off of it instead of passing over it.

My problem now is that I have so many particles, due to the objects hitting multiple sensors at once, that I have to tone it down. It's basically a landslide right now.