Object Overlap Condition Not Firing

As the title states.

I have two terrain items, Asteroid and Asterock, and I have a detector object called P2 LOS Checker (all on Layer 2). When I attempt to move an NPC active, it places two items at the mouse location - Move Marker and Move Rock Checker, on Layer 4 and 2 respectively. Then, to find out if the NPC has line of sight to the Move Marker, I set scale of the P2 LOS Checker to form a line between the NPC active and the Move Marker.

Now, when this line is drawn, it will detect an overlap for Asteroid objects, but not Asterock objects, which is obviously not what I want.

They (Asteroid/Asterock) are both on the same layer, so that shouldn't be the issue, same with LOS Checker. I have different events which test for collisions on both Asteroid/Asterock with a different object that works, both as separate objects and underneath a shared Qualifier. I've attempted to check for the LOS collision as separate objects and under the qualifier, with the same effect (works for one, not the other). I've attempted to change the order of the Overlap condition (x overlapping y, y overlapping x) to no avail.

Probably related is the Active Move Rock Checker, which is displaying the same behaviour. This works by being placed at the same location as Move Marker, but then being moved to Layer 2. It successfully tests for Overlap on Asteroid, but not Asterock. Does moving layers change the order of objects within that layer? And would the order affect Overlap conditions anyway if it's all on the same layer?

I'm positively stumped. I can't understand why it works for one object and not the other, doubly so since one is a clone of the other to begin with! Since the file is too large to upload, dropbox link provided for perusing eyes. Thanks in advance for any pointers.

https://www.dropbox.com/s/bxv92pjby8...pload.mfa?dl=0

Took some screenies that may help. Note these are from the current file, not the upload version linked above, but the same bug is prevalent in both.
Attachment 22438Attachment 22439Attachment 22440

Still cannot figure out why this is happening.

Nor why the uploader would choose to shrink my images.

HRRRNNNGGGGGG

i cant see, too small... put your overlap condition first, then the additions after that.

Checks for Overlap upon a Loop. So the events are

On Loop "P2 LOS Check"
+
"P2 LOS Checker" Active is Overlapping (Active Object/Qualifier Group)

and also

On Loop "P2 LOS Check"
+
"P2 LOS Checker" Active is NOT Overlapping (Active Object/Qualifier Group) (Negated event)

Works fine for all intents and purposes with the exception of this ONE Active Object type "Asterock". As stated previously, "Asteroid" conditions work fine.

Let's try this again.

Attachment 22444Attachment 22445Attachment 22446

So maybe squint. But the bottom of the second image is where the Events in question are contained.

new images are better.. the collisions all must be on same layer to register - check the objects not working is on the same layer - you are testing the overlap - perhaps it may not be.

100% all on the same layer. Layer 2.

EDIT- To Clarify, conditions not seen in the above pictures relevant to to convo are the creation of the Objects, both of which happen at the start of the frame. The game runs loops X times to create a random number of Asteroid/Asterock objects.

On Loop "Asteroid"
- Create "Asteroid" at -8,-8 At Layer 2
- Set X Pos to (random 4000)
- Set Y Pos to (random 4000)
- Set Alt Val A (random(5))
- Set Dir (random 32)

Same loop for both objects.

Update:

Swapped out the LOS Check object for another, and it displayed the exact same behaviour - Overlapped on Asteroids, not on Asterocks.

Then added a new Object similar to the Asteroid/Asterock objects - Same qualifiers, same spawn method, same alt vals and conditions etc., and the engine doesn't detect these collisions either.

Conclusion: Something about the code can only register one type of collision at this loop juncture. I've got plenty of other collision events that work with Asterock as well as Asteroid, but the overlap loop setup doesn't register Asterock regardless of what order I place the events, if I run overlap events on Qualifiers or Single Actives, etc etc.

Question: If I want an event to be On Loop "X" and X is Overlapping Y OR Z is Overlapping Y, would I need to write it as:

On Loop P2 LOS Check
+ "P2 Los Checker" is Overlapping Asteroid
OR
+ "P2 Los Checker" is Overlapping Asterock

Or should it be written as

On Loop P2 LOS Check
+ "P2 Los Checker" is Overlapping Asteroid
OR
On Loop P2 LOS Check
+ "P2 Los Checker" is Overlapping Asterock

Thanks guys.

2nd way.. and i would debug, cause i reckon you'll find the object not working is not on the layer you think it is

Sorry, but your code is very complex to figure out what to do when I run the frame. Can you simplify things, remove any flashy effects and upload a simplified version of your mfa? I basically get a sphere of light that appears to stall after about 5 seconds at which point a ton of node objects suddenly appear.

@Danjo - I inserted a line that set Alt Vals to current Layer, and all show up as layer 2. Trust me that Debugger has been getting a bashing.

@mobichan - All that's happening is the level is being setup. Move commands kick in at 10 seconds, so if you do nothing until that time, afterwards it's ready to go. At any rate, I've created an annotated version, with all the other frames removed, and the Node commands removed to stop the slight hang at T+0.07, and the light spheres are scaled up so the fog shouldn't get in the way. Every group is also clearly labelled as to what it does, and there's a quick description also if it's not clear.

https://www.dropbox.com/s/2xug26l82p...pload.mfa?dl=0

Basically, right click to move Player 1 (blue) around, press 1 on the keyboard to move Player 2 (red). What you'll find is that Player 2 won't move if it doesn't have direct line of sight to the Move Marker that is placed upon pressing 1, but only if that line of sight passes through one of the grey objects (Asteroid), whereas according to the code it shouldn't be moving if it passes through any of the grey or black (Asterock) ones.

I know conditions on both Overlap and Collision work. You can shoot a laser with the left mouse that collides and destroys with both Asteroid and Asterock objects. The detector loop that checks for overlapping for the mouse position also works via an active object overlap check (Onrock Detector active). But for whatever reason, the LOS Checker active object can only pick up overlap conditions on that one type of object.

Had a look to your previous file some days ago,
but then have been too busy to post a (probably not very useful XD) reply,
well... I'm puzzled.
I'm almost tempted to suggest you the bugbox route.

I've been trying to understand what that nasty Asterock had so different to escape overlap
watched that Los line sitting above the Asterock
(outside the loop, and in fixed position) for endless frames
without an overlap being detected

Have no previous experience of such an issue, even considering there might be something wrong with your objects, like something corrupted
(even tried substitute the asterock object with another brand new object with the "replace by another object", issue persists)

I still don't give up completely because I've not scrolled through your whole set of events and cleaned up everything else
(but I've disabled most relevant stuff I think and the issue still persists)

Best thing would probably be recreating "Just the los part with two objects" from scratch and see if the issue shows up.

Interested in any follow up to this (and / or if any finds the hidden mistake of course! :))

Haha thanks schrodinger! I get the busy part - all good.

And - it's weird, right? There shouldn't be anything in the other event groups interacting with the objects in question (LOS checker/Asterock) so I don't think that's where the issue is. And to make it weirder, as I've stated above, other interactions with Asterock and LOS Checker work (Asterock destroys lasers fired by Player 1, LOS Checker works with Asteroid objects).

So. Bloody. Confused.

Will probably spend some time today rebuilding it all and seeing what happens.

Totally weird imo.

One thing I was searching and I didn't find were quick position switching,
Fusion misses the overlap among A and B when B has been moved in that very frame (and was not under A in the previous frame)
so in case you were constantly repositioning those rocks this could have been an explanation
...but it doesn't really seem the case :o

Quote:

---

Will probably spend some time today rebuilding it all and seeing what happens.

---

I think it's our best bet to understand what's going on - good luck!
(Maybe start with the los and two types of asterocks so you can catch the issue right from the beginning...)

https://www.dropbox.com/s/etxmwq6hnd...sREDO.mfa?dl=0

Rebuilt from scratch.

Frame 1 (0.01) - Basic engine. Works fine. Overlap conditions fire and is all good.
Frame 2 (0.01.1) - Added in a second layer and a background active. Works fine, all good.
Frame 3 (0.01.2) - Added more layers, and included Fog/Lighting Effects
Frame 4 (0.01.2.5) - Amended one of the rock objects by using a 50% opacity brush and editing the picture. No change (came back and did this after the next frame)
Frame 5 (0.01.3) - Updated the Rock object pictures. Breaks the Overlap, on BOTH objects.

So, it's something to do with the active object's graphic. I updated the graphic by pasting in an image from paint from a rock texture I have, then cleaning it up with a transparent brush around the edges. For the second object I copied the animation, and then ran a 50% opacity brush over it all to darken it (thus frame 4's test).

So it's something to do with the graphic in the Active. But that doesn't explain why it doesn't work in the original mfa, since none of it was pasted from an outside source; the second rock was a cloned object with the opacity pass-over, but yet it works for one and not the other.

Also had a cloned frame, which I have since deleted, of the last one, where I went back and copied the animation from a non-bugged, non-updated rock object, and replaced the updated texture on a bugged object. Overlap won't detect. Seemingly, something in the process of updating the animation is what bugs it out, then afterwards it's irretrievable.

Buuut. Doesn't explain why, again, in the original MFA overlap conditions wouldn't work on any NEW actives created and set up in the same manner (ie, same qualifier group that detects for the overlap).

WHAT IS HAPPENING!?! XD

https://www.dropbox.com/s/2xug26l82p...pload.mfa?dl=0

(PS - old mfa, using the old level generate runtimes which are not exactly clean at the moment. Let the frame run - it will pause for a bit after 7 seconds as Node's are spawned in. Movement control is given after 10 seconds.)

UPDATE

Can't sleep, so trying to figure this out. AND I THINK I DID IT.

The above link contains the latest findings. Went back to the original MFA I was working on, and added a new cloned object of the Asteroid object, called it Flurock. Edited the animation via simply changing the colour via the fill tool, then tested. FLUROCK OVERLAP DETECTION WORKS.

Next frame, cloned another Asteroid, this time changed the colour via the square fill tool using a 60% opacity brush selection. THIS DOES NOT WORK.

Next frame, cloned another Asteroid, used fill only, called it Unbreakarock. DETECTION WORKS.

CONCLUSION:

Something to do with the opacity of the brush in the animation is what is causing the Overlap function not to trigger. This seems bloody odd. Thoughts?

If you are using the "Fine Detection" option, try turning it OFF. This will force the overlap to check the object's bounding box. This will definitely narrow the problem to the alpha channel. Seeing as how I never use anything besides 1 bit alpha, I wonder if that is the cause.

Certainly am, and it did indeed fix the Overlap condition! Unfortunately I want pretty precise collisions so want to keep it enabled as the objects are pretty misshapen, and it seems to screw with the LOS checker when the Player objects are close to the rocks. Handy to know though.

And in regards to Alpha channel - I am clueless. Couldn't even tell you what it means. My only interaction with it has been in this in MFA in creating the fog layer, and that's only because I merely recreated an example mfa I tore apart hah.

the alpha channel comes in 2 flavors:

1. 1bit This is a single color alpha channel. It mean a hard edge and no anti-aliasing.
2. 24bit alpha channel. This allows for grayscale alpha and produces a softer/smoother edge.

Since 1bit simply uses the pixels that are visible as the ones that are tested in collisions, you know what to expect. I have no clue what 24bit alpha channel uses to test collisions, although I would assume all pixels that are not 100% transparent.

ohh great you found the issue guys :D (it would seem)

I never used the opacity setting in the picture editor,
seems like it broke something - somewhat - somehow ?
it's probably a good idea NOT using it entirely and rely on the alpha channel editing
(maybe in external paint softwares as picture editor is not extremely comfortable for this)

though I tried recreating the issue with 2 objects in a blank mfa and failed so far :(

for alpha collisions: I can confirm from past testing
any alpha value >=1 (or <= 254 depending on the software) is detected in overlaps,
when editing the alpha in picture editor or importing from external sources
so only alpha 0 (or 255) is considered "transparent" >> no collision

Interesting reading! When I get a bit fancier with my lighting and such, I will no doubt have further questions.

As an aside, do you think this is worthy of reporting as a bug? I'll be avoiding the opacity setting in the meantime - don't want this affecting things because now I'm knee-deep in node-based pathfinding events and it all relies heavily on LOS via the scaled/angled Active object overlapping loop setup.

I think if you can recreate it in very clear and simple manner
(as you seemed to be able to if I read well enough?)
and clearly detail every step, it's worth posting in the bugbox

I think posting there a "confirmed/replicable" bug is always a good thing
...though perhaps since it's easily circumventable (>> not using the opacity feature - am I correct?)
and with F3 coming, unless it's very quick and easy to fix,
don't know how many chances there are it would be addressed
Clickteam guys are always working on such a lot of things :)


Good luck with node-based pathfinding!
Are you going to build something using Dijkstra's algorithm (which I seem to recall is quite costly?)
or going with the usual A* route but implementing it with nodes (which would strongly improve its performances)
?

The built-from-scratch example did indeed recreate the bug. Might investigate it later when my head isn't so full of numbers and nested loops!

As for pathfinding - Well. Basically, I have NPC objects that attempt to move toward markers that are placed on the game board. If they have LOS, then easy, they move toward the marker (this exact loop is what this thread was created for!)

If there's no LOS to the marker, it will pick the closest Node (which I call Node Zero) to the marker, and check for LOS against that Node. If no LOS is found, it will then begin a series of nested loops. Essentially, Node's within range and LOS of Node Zero are checked for LOS. If no LOS is found, check for LOS against Nodes that have LOS to Node Generation One, if no LOS is found, check for LOS against Nodes that have LOS to Node Generation Two, etc etc etc.

It seems like it will end up with a huge amount of steps, but by basing it on LOS between Nodes rather than just immediate neighbours I can shave a lot of node steps off, and also by excluding Nodes that have already been checked. Here's hoping, anyway. It's based on stuff I've read about the Theta* method, which is a slightly more natural-looking movement system than straight A* pathfinding.

Once I get it working, I'll be sure to post an example. Since terrain is mutable in my game, the map needs to be updated fairly regularly, thus I'm working on making it very robust and adaptable with a small memory footprint. I say small memory, but the system already involves ~8 active objects for LOS checking and marker placement hah!