Collisions / Overlapping not detected if detecting actor is on lower layer than target

Agent Argyle

Recently I have noticed that rules with overlapping/collision detection don't work unless they are in actors that are higher in layers than the actors they are overlapping or colliding with.

For example if I have an actor with a rule "When Actor receives event Overlaps or Collides with Actor of Type" that is in a higher layer than its target actor, then it works. If it is below, it does not.

Previously this only seemed to be an issue if an attribute was being constrained but now it seems to just happen when an actor is merely on a lower layer. There is a bug report to that effect here: http://bugs.gamesalad.com/show_bug.cgi?id=926

I'm using GS 13.36 on OS X 10.10.5.

Anyone else experiencing this?

Socks

This is not a bug, this is how GS scans code, it will either be top down or bottom up, in the case of GS it is bottom up.

Agent Argyle

Thanks @Socks.

So what you are saying is that the only way an actor can interact with another actor is if it is on a higher layer because its code is parsed later than the lower actor so it can be aware of the lower actor which, once parsed is now in memory? But that the lower actor cannot be aware of the higher actor because its code was parsed before the higher actor's object was instantiated?

In that case how do you deal with the situation where you want an actor to detect collisions with actors on higher layers?

Thanks again.

Socks

@Agent Argyle said:
So what you are saying is that the only way an actor can interact with another actor is if it is on a higher layer because its code is parsed later than the lower actor so it can be aware of the lower actor which, once parsed is now in memory?

No, sorry, in hindsight my comment is a bit confusing / doesn't directly address your issue.

Actors can collide with actors on any layer, above or below. But the way code is scanned can sometimes produce anomalies like the one you mention in your original post, this is usually an interaction between the particular code the actor has the way code is scanned, there is usually a way to fix these things, the fix would depend on the particulars of the project.

Agent Argyle

Thanks @Socks. I didn't think that sounded likely, but I am unfamiliar with LUA. I did a test and layer order does not in and of itself seem to be an issue so I'll have to dig deeper. Thanks again.

Lovejoy

@Agent Argyle said:
Thanks Socks. I didn't think that sounded likely, but I am unfamiliar with LUA. I did a test and layer order does not in and of itself seem to be an issue so I'll have to dig deeper. Thanks again.

Make sure you have moveable turned on on the actors doing the overlapping/collision.

Agent Argyle

Hey @Socks.

So, turns out that the problem occurs when an actor on an un-scrollable layer collides with an actor on a scrollable one. I have attached a test project where an actor called detector displays the text "COLLIDING" when overlapping or colliding with an actor called Detectee. I have placed the Detectee actor on both scrollable and unscrollable layers. It detects collisions fine when the layers are scrollable, but doesn't work properly with actors on un-scrollable layers. The detection occurs only at the original coordinates of the actor on the un-scrollable layer.

So for example, if you have a HUD and want to disable buttons on scrollable layers when they are under the HUD, you cannot accurately detect when your scrollable actor is under the un-scrollable HUD.

Collision detected with actor on scrollable layer.

--

No collision detected with actor on non-scrollable layer:

--

Collision detected despite no visible collision occurring. Detection appears to be at original coordinates for non-scrollable actor ( the HUD).

I suspect this is just how GS works and is not a bug per se. But it is not the behavior I would expect.

Agent Argyle

thanks @Lovejoy

Make sure you have moveable turned on on the actors doing the overlapping/collision.

I tried making the detectees moveable and the detector is already moveable. No dice.

Socks

@Agent Argyle said:
Hey Socks.

detectee + detector + detection + collides + overlapping or colliding + collisions = my mind gets lost in paragraphs like this, I'm all for clarity of communication : ) - Whatever happened to naming actors 'A' and 'B' !

I really didn't understand all that, too confusing for me, sorry . . .

Are you able to say what it is you are trying to do a little more clearly.

The only thing I could work out (I might be wrong) was that you wanted to have a movable actor collide with a second actor . . . when the second actor is off screen and on a non-scrollable layer ? In which case you would never see it or never be able to reach it ?

Socks

@Agent Argyle said:
No collision detected with actor on non-scrollable layer:

How are you moving the actor on to the second (green) actor in this image ?

How would actor A be able to collide with actor B . . . when B is on a non-scollable layer, so A could never move towards it (in your set up where the camera tracking area is closed down) ?

Agent Argyle

Sorry @Socks - check out the pics I posted and the sample project if necessary. They should tell the whole story.

But In other words, actor A, the Hero, is on a scrollable layer and trying to detect collisions with Actor B. If Actor B is also on a scrollable layer everything is fine. But if Actor B is on a non-scrollable layer, Actor A will not detect collisions with it in the right location. It will detect a collision where there is no visible collision, and not detect a collision when there visibly is one.

In this case, both actors are always on screen- Actor A, the Hero, moves around and Actor B, the HUD stays in place. For example, say you have a vertical game which is 1000 pixels high with the standard camera size with a height of 320 and you place your HUD at the top of the screen. (This is how I set it up in my example pics and project by the way)
If Actor A moves up the screen it will detect collisions only at Actor B's location relative to Actor B's own layer (around Y coordinates 300px depending on the height of the HUD). But the HUD is not visibly there. It stays at the top of the screen because it is on a non-scrollable layer. So on its own layer it may well still be at 320 but in relation to everything else, it is now higher. And when Actor A gets to the very top of the scene and finally collides with Actor B because the scrolling comes to a halt, it does not detect a collision.

Does that make more sense?

Socks

@Agent Argyle said:
In this case, both actors are always on screen- Actor A, the Hero, moves around and Actor B, the HUD stays in place. For example, say you have a vertical game which is 1000 pixels high with the standard camera size with a height of 320 and you place your HUD at the top of the screen. (This is how I set it up in my example pics and project by the way)
If Actor A moves up the screen it will detect collisions only at Actor B's location relative to Actor B's own layer (around Y coordinates 300px depending on the height of the HUD). But the HUD is not visibly there. It stays at the top of the screen because it is on a non-scrollable layer. So on its own layer it may well still be at 320 but in relation to everything else, it is now higher. And when Actor A gets to the very top of the scene and finally collides with Actor B because the scrolling comes to a halt, it does not detect a collision.

Does that make more sense?

Yes ! That last line was all I was after ! The rest of the stuff is just distraction, makes much more sense now !!

. . . . . . .

1) Make your HUD layer scrollable and move it so it is above Actor A.

2) Unlock the HUD element (the wide green bar) in the scene.

3) Place one constrain behaviour into the HUD element and set it to . . .

Constrain self.Y to scene.Camera.Origin.Y +( scene.Camera.Size.Height -( self.Size.Height /2))

. . . . . . .

Or you could simply the above with . . .

Constrain self.Y to scene.Camera.Origin.Y +297

Agent Argyle

Thanks @Socks. I appreciate your taking the time to help with this.

In general I am pretty loathe to unlock actors because then in order to make changes to the actor once it is used on multiple scenes means editing each and every instance of it rather than just editing the prototype. I realize this leaves me far fewer options and perhaps I just need to start working on one big scene rather than multiple scenes to cut down on the number of instances.

But, getting back to the issue at hand, I believe this is a bug. My test clearly shows errant collision detection between actors on scrollable and non-scrollable layers with both false negatives and false positives. I've experienced this problem since I started using Game Salad, so perhaps it is considered a "feature" at this point. But, to me, it is a design flaw. I am going to file a bug report.

Socks

@Agent Argyle said:
But, getting back to the issue at hand, I believe this is a bug.

I wouldn't really call it a bug, a non-scrollable layer is primarily designed for HUD elements, so generally speaking (the overwhelming majority of cases) there would be no need for interaction between HUD elements and 'scene' elements, HUD elements are primarily for display and control (as I'm sure you know) and in those case where there is a need for interaction then there are other - fairly straightforward solutions.

I think you are trying to get a non-scrollable layer to do something it wasn't designed to do, so in that respect you are fighting a deliberate design decision (from GS), if the basic goal is to detect a collision with the top of a tall scene could you not simply place an actor at the top of the scene that detects collisions ? (it would be invisible of course, so not visually interfere with your HUD element) It seems odd to try and force the non-scrollable layer / HUD system to do a job it really isn't designed for.

@Agent Argyle said:
My test clearly shows errant collision detection between actors on scrollable and non-scrollable layers with both false negatives and false positives.

I wouldn't say this was the case, collisions are measured from 0,0, once you move the camera area off its origin you would also need to move the origin itself too to return the right result . . . to me this isn't a bug at all, it's just a very flexible way of working, I like the fact that you can decouple the scene origin and the camera origin, it allows you to do things that you couldn't do if this weren't the case.

Agent Argyle

@Socks said:

I wouldn't really call it a bug, a non-scrollable layer is primarily designed for HUD elements, so generally speaking (the overwhelming majority of cases) there would be no need for interaction between HUD elements and 'scene' elements, HUD elements are primarily for display and control (as I'm sure you know) and in those case where there is a need for interaction then there are other - fairly straightforward solutions.

I think you are trying to get a non-scrollable layer to do something it wasn't designed to do, so in that respect you are fighting a deliberate design decision (from GS), if the basic goal is to detect a collision with the top of a tall scene could you not simply place an actor at the top of the scene that detects collisions ? (it would be invisible of course, so not visually interfere with your HUD element) It seems odd to try and force the non-scrollable layer / HUD system to do a job it really isn't designed for.

I see your point but one cannot assume users will only use the software as the devs intended. The best practice here would be to ensure that the software produces consistent, intuitive and expected, documented results. Detecting collisions where there are clearly no visible collisions, while not detecting them where there are clearly visible collisions is unexpected and inconsistent with how collision detections normally work.

My goal is not to simply detect a collision at the top of a tall scene. I can do that a myriad of ways. While I really do appreciate your suggestions of workarounds, and will try them out in my production project, the actual goal of this thread was to point out a behavior that appears to be unexpected and see if anyone else has noticed the same thing. That's why I made the test project- to simply show the unexpected behavior in action.

@Agent Argyle said:
...clearly shows errant collision detection between actors on scrollable and non-scrollable layers with both false negatives and false positives.

@Socks said:

I wouldn't say this was the case, collisions are measured from 0,0, once you move the camera area off its origin you would also need to move the origin itself too to return the right result . . . to me this isn't a bug at all, it's just a very flexible way of working, I like the fact that you can decouple the scene origin and the camera origin, it allows you to do things that you couldn't do if this weren't the case.

Right, so when Actor A's area (measured from its current origin relative to the scene -its 0,0) overlaps visibly with Actor B's area (measured from its current origin relative to the scene), as long as they are both on scrollable layers the collision is detected.

The problem is that when Actor B is on a non-scrollable layer, Its origin stays static. So you are correct- you would also need to move the origin of Actor B itself to return the right result. On non-scrollable layers, Actors' coordinates should change relative to the scene despite being static relative to their layers. That is what I am arguing for.

What matters when detecting collisions is whether two actors are visibly overlapping or not. So, when two actors visibly collide then the default collision detection should produce a valid collision and not produce an invalid one when they are not visibly colliding.

While it may offer some more flexibility once you know the idiosyncrasy exists, the discrepancy doesn't appear to be documented. If this is intended as a design choice then it should be documented as such. The fact that it is not documented, that it is inconsistent, unexpected and unintuitive makes me call it a bug- or worse, a design flaw.

Agent Argyle

Maybe it is just easier to explain by playing the demo...

gsrca.de/133156

Socks

@Agent Argyle said:
I see your point but one cannot assume users will only use the software as the devs intended. The best practice here would be to ensure that the software produces consistent, intuitive and expected, documented results.

In respect of scrollable / non-scrollable layers - and the way collisions interacts with them, I'd say it does produce consistent and expected results (although I'd agree with you that it might not be intuitive).

@Agent Argyle said:
My goal is not to simply detect a collision at the top of a tall scene. I can do that a myriad of ways. While I really do appreciate your suggestions of workarounds, and will try them out in my production project, the actual goal of this thread was to point out a behavior that appears to be unexpected and see if anyone else has noticed the same thing. That's why I made the test project- to simply show the unexpected behavior in action.

Ah, I see, sorry, I thought that was a rough layout of an actual idea you were working on.

@Agent Argyle said:
Right, so when Actor A's area (measured from its current origin relative to the scene -its 0,0) overlaps visibly with Actor B's area (measured from its current origin relative to the scene), as long as they are both on scrollable layers the collision is detected.

Yes, agreed.

@Agent Argyle said:
The problem is that when Actor B is on a non-scrollable layer, Its origin stays static. So you are correct- you would also need to move the origin of Actor B itself to return the right result. On non-scrollable layers, Actors' coordinates should change relative to the scene despite being static relative to their layers. That is what I am arguing for.

Sounds like it would be useful, but I suspect only in a very small number of scenarios, like I say non-scrollable layers were most probably designed to meet the needs of static elements (scores, radars, buttons, lives . . etc) - the need for elements on a non-scrollable layer to collide with elements on a scrollable layer is probably something with very little demand.

I have a project I'm working on where just to have a button on screen I am needing to constrain it to . . .

x = ( scene.Camera.Size.Width * 0.475)cos ((- game.Camera Skew *sin ( game.Time * game.Camera Skew time ))-18)+ scene.Camera.Size.Width /2 y = ( scene.Camera.Size.Width * 0.475)sin ((- game.Camera Skew *sin ( game.Time * game.Camera Skew time ))-18)+ scene.Camera.Size.Height /2 r = - game.Camera Skew *sin( game.Time * game.Camera Skew time ) W= scene.Camera.Size.Width * 0.09765625 and H = self.Size.Width *1.72

. . . and this is a perfectly static, non animating button ! Of course there is a lot of other stuff going on with the camera, but the temptation would be to think 'why can't I just stick my button where I want it and GS work out I want it to stay there' . . but GS wasn't designed with my particular project needs in mind, and the same is probably true of your project (or at least that particular mechanic).

@Agent Argyle said:
What matters when detecting collisions is whether two actors are visibly overlapping or not. So, when two actors visibly collide then the default collision detection should produce a valid collision and not produce an invalid one when they are not visibly colliding

Yes, agreed (with all the usual caveats of any system - need to be using the physics engine, need to both be on scrollable layers, need time for the code to cycle before the collision is lost (on smaller objects) etc etc). You could also argue that what matters for a non-scrollable layer is that the elements always remain perfectly static (imagine how we would all complain and demand GS fix non-scrollable layers if they occasionally drifted in certain situations ! - and perhaps this need outweighed the need for in game elements to collide with elements on what was designed to be a static HUD ? Who knows ?

@Agent Argyle said:
While it may offer some more flexibility once you know the idiosyncrasy exists, the discrepancy doesn't appear to be documented.

Agreed, there is a lot about GameSalad that isn't documented, in this case I would return to the point that this kind of thing is most probably not part of its intended use, so it's not unreasonable that it's not addressed in the documentation - after all there are literally tens of millions of permutations of a system like this, they can't of course all be documented, you can produce a spectrum of colours using just a sine wave in GameSalad or orbit around a 3D isometric scene or have actors track the surface of sphere (etc etc), but none of these are documented, I'd say your particular case is a better candidate for documentation as it does occasionally come up (or a variation on it), but I'd still say it's outside of the intended use for that particular tool, and who documents things a tool cannot do nor was intended to do ? I can't load custom fonts, this is not mentioned once in the Cookbook

@Agent Argyle said:
If this is intended as a design choice then it should be documented as such.

I don't think interaction between scrollable and non-scrollable layer was a design choice, it was likely never even considered.

@Agent Argyle said:
The fact that it is not documented, that it is inconsistent, unexpected and unintuitive . . .

Not documented = agreed.
Inconsistent = disagree, it's incredibly consistent, I rely on it a lot, I've never seen any inconsistency !
Unexpected = that depends on whether you are aware of how the system works.
Unintuitive = agreed.

Agent Argyle

Thanks @Socks - I'm happy to get your opinion on this. I filed a bug report here: http://bugs.gamesalad.com/show_bug.cgi?id=1368 and we'll see if the devs think its a bug or not. I suspect they will go with your reasoning since it has been like this a long time. But you never know- they just might play my demo and see my point of view.

Cheers!

tmagames

I have been having this problem for a while on a game I am developing, for ages, I could not solve the problem, it was annoying because it was inconsistent across various scenes. Analysing every position of every actor in every scene I solved the problem simply: I do not know the logic behind it but, it made a difference where the offscreen actors controlling gameplay were, like change scene, game high score, reset scene etc. Moving them to the lowest level of the lowest layer, solved all my problems.