BUG: "Overlap" is not detected in some cases [FIXED: works if actor is marked as MOVEABLE]
Hymloe
Member Posts: 1,653
BUG: "Overlap or Collide" is not detected if you spawn an actor within the same space as another?
I have had problems today, and in the past, where I cannot detect an "overlap" event, in some circumstances.
I find that, if you have two actors that aren't touching, and you move them into each other, then a collision event occurs, and "is overlapping or colliding" is "true".
But if you have one actor, and then spawn another one on top of it, there is no "overlapping or colliding" event (as they don't actually cross boundaries, they are simply overlapping".
In older versions of GS, this would make "overlapping or colliding" = true, at least in some cases.
Does anyone have a good workaround for this, or know some sort of trick?
I kind of wish the "is overlapping or colliding" drop-down was divided into "is colliding with" or "is overlapping", or "is overlapping or colliding", and that they would actually report truly on those states.
Currently, I feel the wording is a bit confusing, seeing as it won't report an "overlap" really, even if two objects are indeed overlapping onscreen, if they didn't first "collide" to get into that state.
I am making a game with procedurally generated levels, and I frequently want to give rules to thinks like trees to say, "If you are overlapping the Exit Zone, destroy yourself". But because they are both things I've spawned into the level, they do not realise they're overlapping each other, because they haven't collided, they're just taking up the same space!
Frustrating.
To summarise, it would be nice if one could detect OVERLAPPING and COLLISIONS separately, as they are actually logically different things.
I guess it's the equivalent of Unity C# features where you can get OnCollisionEnter (which detects something entering your collision shape), OR you can get Physics.OverlapSphere, where you can check against anything that is "overlapping OR INSIDE" your collision shape.
https://docs.unity3d.com/ScriptReference/Physics.OverlapSphere.html
I want to be able to check if something is inside my collision check space (even if it never collided with it from the outside).
The current GS behaviour says "overlaps or collides", so it should do what it says, no?
Comments
EUREKA!
OK, right after posting this, I thought I should build a simple demo project to really see when "overlap" was detected, and when it "wasn't"!
To my surprise, it was working fine in both cases!
I discovered that as long as the actor in question is marked as MOVEABLE in the Physics properties, it does indeed return "true" as overlapping, even if it's spawned on top of the other object, and doesn't "collide" with it, as such.
So I fixed the bug in my project straight away, realising that it was marked as non-moveable (seeing as that actor never actually moves in my project).
I guess older versions of GS (0.13.34) still detected "is overlapping" even if an object was not marked as moveable, so long as it was overlapping.
All sorted! As you were.
Collisions are a feature of the physics engine, switching 'movable' off takes the actor out of the physics engine calculation, at least one of the two actors involved in a collision needs to have 'movable' enabled.
Thanks @Socks
All makes sense now.
It's actually going to let me fix a whole bunch of other issues with my procedural level generation that I'd been stumped on! Awesome.
Lovely! Looking forward to playing your game! And great to see you back and active!
Awwww, that's nice!
Trying to knock it on the head!
You can check can sleep to help save resources in the physics engine for actors that need to be movable but don't have a big part in the game.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Ah, that might be a nice bonus on these actors, as they actually never move, so "can sleep" sounds perfect. I'll give that a try.
What do I do if I want to detect overlap, but absolutely don't want the buildings to move?
Currently, if the player, or monsters, bump into a building, it starts moving, even if set Density, Friction, Drag and Angular Drag to 10,000.
I'd keep them in place with constraints or doesn't that work for what you're trying to do?
Switch 'movable' off for the buildings.
Ah yes! I think the constrains approach works.
Don't know why I didn't think of that!
Thanks @Hoodloc!
120 instructions a second, every second (60 times a second constrain X / 60 times a second constrain constrain Y)
vs
Simply switching 'movable' off
Switching 'moveable' off is generally the way you would make something fixed (like a wall or obstacle), would this not work for your project ?
Yes, that would be nice! But my project is doing this...
I have MiscObjects, RescueTargets & Spawners.
They're all buildings that I don't want to move.
And they may all overlap at times due to my level generation process.
So I need them all set to move-able, so I can check for overlaps, but I don't want any of them to move.
And they all need to Collide with (block) certain actors in the world, such as the player, monsters, bullets, so they need to have Collide Rules on (therefore pushing them around if I don't pin them down).
I could possibly do some smarter coding, along the lines of... have them spawn an extra actor which demarcates that a certain building has been put in that position, and other objects test against that invisible marker actor... which can be set to "moveable" but have no actual collision rules, and there would (I guess) stay put!...
Or I could be smarter about how and where I place objects during level generation, to avoid overlaps in the first place, but the system I have is working, and quite complex already, and I don't really want to re-write it, or deal with making it smarter at this point... I could do something where I "shuffle actors around after placement, and retest if they're overlapping in multiple iterations until everything has "settled" somewhere legal... but it would take a lot of work, and debugging at this point.
The constrain approach works, and runs fine on my iPad Mini 2, so I think I'm gonna go with it, even if it's not the most performant!
But yes, I'm sure there's a better smarter way!
I might come back through and do another pass on it later, but I really just wanna get this game done!
I don't know how you have your project set up, but you could utilise the fact that actors can collide with each other to position those actors, then use the fact that actors can be taken out of the physics calculation to set them up how you want them set up.
For example (again, I don't know how you have your project set up, so this is guesswork), if I wanted actors to spawn randomly, collide and reposition themselves so no two actors occupy the same position (?) whilst having 'movable' switched off - I would spawn the actors with movable on, have them position themselves, then each actor would spawn a second copy of itself with 'movable' switched off.
Hope that makes sense !
Interesting idea!
Yeah, I could think about something like that if I go in for another pass on it all.
Good thinking!
Turns out the performance does get quite jerky in the later levels of the game, when the levels are larger with more buildings. Hmmm, guess I WILL have to do something smarter now.
I don't know how your game looks so of course constraining might not be the best idea.
An easy way to "shuffle actors around after placement" like you said is to let them collide with each other. If you turn on fixed rotation they will push themselves away from each other without going all mad with rotations.
Do the buildings all have a set size, or do they vary? If they are roughly the same size (within 10% difference) or exactly the same size, how about using one specific actor type, a "building spawner" to check the spacing and then spawn everything else?
Yeah, that could work.
But, I think I'll try an approach where (after mapping out exactly which objects need to clear away which objects, in which cases), I'll have them all marked as non-moveable, and have certain ones of those actors spawn other "moveable" (but invisible) temporary actors that are basically just "space clearers", and then certain actors will detect if they're colliding with those, and destroy themselves if they are.
For example...
In "Clear the Area" maps, spawners are mission objectives, so they will take precedent, and other actors overlapping them will be destroyed.
But in "Rescue the Survivor" missions, the rescue targets are mission objectives, so in that case, spawners are not critical, so I can have a few of those destroy themselves if they overlap a rescue target.
etc.
Someone stated above that only one of the actors needs to be "moveable" to detect the collision/overlap, so I'm hoping my plan works as outlined above! Then I can just destroy these invisible actors after 5 or 10 seconds, as the level will be set.
If I was really smart, I probably would have done something more like that.
My level is largely generated by a "Level Builder" which does basically move along in rows, placing things. But then I have a few other independent "other" builders, that do another pass making trees, and then the mission objectives are randomly plonked down within ranges on top of that! So it's a bit disorderly, hence my problems!
But I do like that they come out quite organically, and I think I can solve the remaining overlap issues. Fingers crossed!
I've certainly learnt some good things that I'd bare in mind if starting a new procedurally generated game!
Hehehe.
Attached how I'd do it if I wanted a quick and easy solution.
Edit: Oh! I think right now my solution really doesn't help. I totally forgot that you wanted them to be unmovable.
Something I forgot before: I would never simply constrain everything in my scene. What about a rule that only constrains them when they get out of position? So if their x or y changes from their starting position, constrain them to their starting position, that's it. Would that work for you?
A rule to just Change Attribute back to the saved StartX,Y it if it moves... that could be good.
If posX is not StartX, posX = StartX
If posY is not StartY, posY = StartY
Unfortunately change attribute doesn't work or at least it didn't when I tested it. If you push into that object the rule triggers once put fails after that. Give it a try - maybe I did something wrong but ultimately I had to use constrains. In the end that doesn't really matter much because these constrains are only active for a few frames and that's it.
The best solution of course would still be to set them to unmovable and let the spawning handle all the trouble.
Good tips! Playing around now with some possible solutions. Thanks for the great ideas!
Definitely got my mind working on things!
Here's an old project (from May 2015!!), it spawns a 'spacer', the spacer checks that it's not treading on another actor, when all is clear it spawns the actual actors (which have movable switched off).
New version, faster, to increase or decrease the minimum space between the actors simply change the size of the 'spacer' actor.
Yeah, I like the sounds of that approach, I might go for something like that...
Thanks! I'll check it out.