Mutliple object repositioning when overlaping other multiple objects.

Hello again. This time I spend more than a day trying to figure this one out myself. I know I should probably be able to fix this myself by now. But I can't seem to remember how if so.

In any case, I have about 20 enemies in my frame that all share the same movement system. Which is basicly
If direction (south) then every "movementspeed1" set ypos of enemy to ypos of enemy +movementspeed2

Nothing too complex. They use 4 directions in total.

When they reach any edge of the frame they will change direction and also get re-positioned by 3 pixels in the opposite direction.

When they overlap a neutral object (something meant to stop them climbing trees and walking through walls etc), I will check where the neutral object is, and where the enemy is with coordinates. To give an example, if enemy xpos
<= to xpos of Neutral. Set xpos of enemy to expos of enemy-2 and change direction to west.

It almost looks good to me. I want to believe that overlaping objects make the instance unique, and it will only use the objects overlaping to compare with.. This work good, well, with only 30 enemies atleast...
Untill an enemy somehow manages to get stuck between 2 neutral objects. when this happens. All enemies will start to get pushed into a corner. Well, they will actually be re-positioned with the current code used, because they think they are still overlaping a neutral object and has to be moved, just because 1 guy got stuck...

I have an example file where I have put an enemy inside the mountain to the northwest. To show the effect of what happens when 1 get stuck. If you want to wait for the "natural" bug you can move it outside again and just wait, there's usually one getting stuck southeast between 2 boulders.

In any case, This code might be usable, IF ONLY one wouldn't get stuck - which I don't even know how it can happen.

If someone would try to help me solve this, I'd appreciate it!

Edit:somehow I managed to paste away this part:
The obstacle collision is in the group Enemies-Obstacles-Original
The enemy movement is under Enemie group - Enemy name- "name" Movement

WASD to move around
http://www.filedropper.com/rpgorb43faaaaail

Update:

So, I've been at it for another day. I tried using alt values for directions instead of directions, didn't matter. I tried the ForEach as seen in the mfa(wrongly I assume, because ForEach isn't really making them unique in the way I want).

And just now I tried to use alt values to keep track of the enemies coordinates, because I thought that atleast now they won't mess up other's values but.. Nah, it didn't work since they will still compare with the other enemy also overlaping an obstacle, and for some reason the enemy will think he's stuck.


In any case, I think I start to understand why they will all start to get sent away. I searched the forums and found that usually one ought to set a "spread value" to make them unique. However I can't seem to wrap my head around how I would compare their value on each instance.

The other problem is how they can get "traped" in the first place. thye should be pushed out long before they get stuck. Maybe when several enemies overlaps at different palces? Those cordinatioon will take priority and keep pushing it.. I don't know.

Edit: I also now changed the action to set alt values instead of positions. Didn't fix..

There are many ways to do instance selection in Fusion, depending on your exact needs.

Actually, I find spread value to be generally a little superseeded (by foreach loops)
or little useful (because of fixed values already existing or dynamic IDs attribution under a custom logic)
in short - I never use it XD but it's just a matter of habit.

If you can isolate your issue in maybe just a specific group
(possibly you've already done it? Sorry - maybe I just didn't read correctly your post!)
or still better a single mfa portraying the issue alone,
forum users could have easier times trying to check this out
(and maybe "deconstructing" the code could be useful for you to solve it as well)

Here it is reproduced, with minimal code.

Just start it and watch. I added quite some enemies to make the wait shorter..

Oh, I see
nice example :D

I don't think this is a scoping issue,
I think overlapping condition are "too late" for bounce-collision type checks
in the sense that overlapping occurs while object already overlaps (is over) the other
in this condition, "phasing" may occur: object being pushed sideways may be "phased" inside another obstacle if the other obstacle is near enough,
and so start to trigger all the overlapping conditions you coded at the same time, resulting in huge mess!

If you switch overlapping to "on collision" events, things already get better (no objects phasing inside obstacles)
but you'll have to add some randomness (or additional checks) to avoid "stuck" situations where spiders keep bouncing between same obstacles

The bouncing between same obstacles? do you mean when it changes direction in very short span of time due the 2 obstacles being close to eachother? Or do you mean "stuck" as inside an obstacle?

The first mentioned is atleast logical, and is more of a design flaw than code flaw.

I am not sure why Overlaping wouldn't work. Collisions can also happen at the same time, more foten when there's more instances.
In any case I thought I tried collision alredy, I might've changed the hurt system a bit since, and that may have helped. But now it ran smoothly for 5 minutes atleast, thanks alot for that help!

Now I have to decide wether or not to use fine detection I suppose. I made the 4 direction movement to keep things simple, heh, I fooled myself apparently:P

Yeah I was meaning the first one,
and yes I agree it could be avoided with some different design choice.

Overlapping sounds as being "too late" in this situation to me: when an object overlaps another, it's already phased inside,
you can push it back yes... but (unless you do it 1 px at time and testing, like on a loop)
what if the object phased inside too much and your pushback distance is not enough,
maybe due to the object moving too fast, or maybe an instant direction change making just a bit of object still overlapping
or what if in your pushback you make it "phase" inside some other obstacle, triggering other pushbacks at same time, etc.
A little messy.

>>> btw, maybe using a separate "collision mask" would also save from this problem, making for a much smaller collision area (no legs) and thus lesser chances of "phasing"

While collision events somewhat "prevents" objects from phasing, are more solid for simple bounces
(I seem to remember collision events trigger when the first pixel phases inside the second object)

There are many examples around for pixel-perfect collisions though, don't know if you're interested in this,
or you're anyway up to a "lighter" approach.

Yep, I don't know why but no matter what, with movements and collisions,
as long as you can simplify, things always slip through your hands somewhere XD

Well. I understand now. If the pixel speed is higher than the pushback, it can get deeper than the push out.

By the way, I activated my other enemies, and they buged out, even though they use the same movement system, and are slower than the enemy I was doing the testing with. And the bug is probably what I experienced the first time i tried on collision, and is why I left it at once..

I now tried it with the file I uploaded 2nd here, to test it for real, and well. It's not solid yet, they can still get past objects even with onCollision. I guess they are "phasing" over it. And this can be understandable if what you said is true, they will keep on doing their movement thingy instead of being pushed out. However, even if I fix that, for some reason my other 2 eemies are buging out, which is weird since I copied the movements from the 1st enemy on to the one I was testing with. I thought I had moved past this problem but nooope :P Even if I add the pushout to 5 pixels (which is higher than any enemy speed) The new bug will remain.

I just realized, the pushout is the same as the speed so it shouldn't be able to move any further inside an object, especially since there's a delay on the movement, and not the pushout.

I have reproduced, er.. nevermind. this is different. On my main file they will walk left and right by the right edge. here, the other enemy will, well. u'll see.

I'm starting loving that crazy spiders - why not leave them rolling? XDXD

Just a quick question to avoid breaking our heads against something that has already been solved:
have you tried bouncing ball with just 4 directions
and/or direction "correction"?

It's pretty solid and gives similar results (non-buggy XD) even at high speeds

i.e.
Attachment 19232

Well. The example you showed got spiders stuck in the trees..

To expand on the ball movement.. I have used ball movement as a first go-to in all my applications, however, sooner or later they will make hell for me. I spent over a month trying to fix a certain enemy in my Tower Defence, and then droped the project for weeks- to later re-make the movement system (not using any ball movement).

Ball movement have been nice to me, in early development, but usually wrecks havoc later on.. This is probably the first time I did not use ball movement from the start.

More about selection of movement types. I like to try and keep things so I can understand them. I don't understand the ball movement. The movement system I have here, I can see it, i know what it does. Well, let's just say I can see what it does (or should do). I tried the safe move object2 today, but it didn't work and I didn't understand it.

So for the sake of developement(personal aswell) I would like to understand. Just as I understood that the movement can't be faster than the pushback, it makes sense. But then again, the movement have timer and the pushback doesen't so it should be faster anyways. But I think you get my point, if I can understand it, it's going to be easier making applications


Edit: I am open to suggestions if there's a simpler code than this.

As for the bouncing ball getting stuck, there's a quick fix you could use:

Attachment 19234

cheating a little: "always" events are used to "ungreen" collision events, making them somewhat "controllable" inside the event flow
(green events trigger immediately regardless of code order, thus being difficult to control in some situations)


but I'm not advocating the use of bouncing ball if it doesn't suit your needs,

if you want to be 100% sure not getting stuck and want full control, you'll probably have to use some looping

this is a recent example of a custom 8 dir movement:

Attachment 19235

this uses different things from what you need, but just to say the basic principles of loop movement:
you move things 1 pixel at time, check if they overlap something, if so, push back 1 pixel.
That's all (if you don't have moving obstacles)
Will give you very clean results in collisions, but is more processor intensive.

I can maybe make a quick example of this approach for your spiders if you would need/ be interested.

Just made a quick example:

Attachment 19237

You can change spider speed in "move2" value

other modifications:
added an extra object for storing instances (not to use global values)
and _DIRECTION value in spiders

There are currently pushable boulders in my application. I thought my code was simple and good but oh well. I will take a look at these 3 tomorrow. Thanks for taking your time and trying to help, I really appriciate it.

Well. I took a look at the ball move fix first, they will phase out eventually though.

I then took a look at 8 direction move block and it confused me alot. It says always(no other conditions) set x, and then on other conditions(keypress) it was to set x=90etc (we're talking bout angle) to something else, this makes no sense to me.

the angle would just flip around I feel. Ofcourse you can put in a statement on the always-if not key is pressed. would make sense. But for some reason it works.


In any case, on line 23 and 24 it want to move 0 - 305 pixels in x and ypos? Depending on which key is pressed.
Line 28 and 31 seems to be what I am after, the actual collision. And it seems as if they are simply just adding or subracting the movment speed on collision. Not different from a pushout. Ofcourse, it also stops the loop to move, but then again it could also be implemeted on the original code.

I have no idea what cos and sin is

Then we have the spiders with this movement object. I am guessing it is helping to make them unique instances.
I can see that the __DIRECTION is the speed, direction, both I suppose. But I don't understand the math here. Also again 2 equal conditions "on loop move spider loop" fixed valule of spider = fixed value of move obj. There's 2 with same condition. One which aparently is always setting the __DIRECTION to /11.25.

So I can read what it says but I have no idea what is going on really, or how to manipulate it. It seems more complicated than my original code - but probably just because I don't understand it:P

Swiff, if you find comfortable with your previous code - of course go for it! :D

I was under the impression you had problems in collision "phasing",
which I think doesn't happen in the example above, even in extreme situations (long time, fast speed).

If instead you could find something useful in the examples, and need some clarifications - just drop a line!

I was comfortable with it, but then weird things happend and I wanted to know if someone could help me with it. But before we dove into it you wanted me to take a look at ball movement, which will also phase out, and then wanted me to try another code, which, I can see but I don't understand.. I could try to learn this. But if it will help me develop the features I may want I don't know untill I'm there I suppose.

I guess I have a few questions about the loop movement then.

Let's start with what is cos and sin? In the movement loop you want it to add cos and sub sin the value of the __DIRECTION. If the index value is equal to selected_instance.
To me the cos and sin seems to be x and y pos, since the cos always handles the xpos and sin handles the ypos. But I don't see how, because the __DIRECTION can be as high as 24.

Also you have 2 equal conditions, and 2 equal actions that can be in the same event?

Maybe the first step is to understand what cos and sin is?

Well, I proposed increasingly "customized" solutions to try approach the argument without filing in too many deviations from the standard
(btw, latest "bouncing ball" solution is decently solid, with an apt level design could probably work enough?)

but the loop approach is the most solid (among the ones I proposed), if you need this kind of reliability

_DIRECTION is nothing more than the object's direction "angle" (0-360)

this example uses basic principles of trigonometry,
you may want to take a look at this picture:

Attachment 19246

You can spot Sin and Cos there.

The most direct advantage is not having to hard-code single directions (right: +x, down:+y etc.)
because in that single movement event you can also handle any direction in the range of 0-360 degrees. This will make your code far shorter and easy to inspect / modify.

"xpos" and "ypos" values would be not strictly needed in a 4-direction movement
(since sin/cos at 90° only range in values -1/0/1 and doesn't need floating point precision)
but they are needed if you want to use more directions (i.e. 8) because they will store floating point values < sin(45)=0.7... > differently from X,Y object coordinate, thus allowing you to calculate very precise objects positions and make smooth custom movements.

Trigonometry is very useful in gaming: will save you tons of lines, and give you tons of chances more. You'll find tons of references online if interested in the matter.

The other thing you need to be comfortable with is eventflow in Fusion: fastloops will be executed immediately and you can put in there whatever test and modification you need to do with your movement prior to "outputting" it to the screen.
The code in the example tries to move the object 1 pixel at time, than if the object is detected inside an obstacle, it reverts to previous "non overlapping" position and switches its direction angle. Thus, since we are moving 1 pixel at time, we won't see phasing happen, and we won't anyway see all these collision testing because the final output on screen will only represent the final result of our loop testing.

Hope this makes sense!

Well. I will tell you right now, I don't understand trigonometry. But then again I didn't put much effort into it today. I only watched that picture a few times:P

The bouncing ball got phased out after less than 2 minutse on the newest version.

I might try to learn trigonometry tomorrow. But most preferable would be to use something more simple.

Oh right I forgot. I tried to use the code evne though I don't udnerstand it, and well. You know what happens when you do things you don't udnerstand:

There are a couple of things to consider when detecting collisions and flipping direction:
if when flipping to other directions the object's "bounding box" changes shape
you can end up overlapping an obstacle --> phasing inside
and differently from previous example, you enabled "fine detection" (collision is detected only on non-transparent pixels)
so this happens much more because the collision shape is concave in one side (spider's "arms" >> think at a stone getting inbetween)
and convex in the other (spider's back >> stone will end up overlapping the spider when he flips to the opposite side)

One way to solve can be using additional looping ("pushout" loops) to ensure the object gets pushed out from obstacles
but can become laggy and potentially harmful if not 100% solid (endless loops can result in crashing)

You can take different routes still,
but since we want something simple and short (I guess)
in the example below I use a collision detector embedded in spiders
so you could theorically draw spiders in any way you want because collision will be tested against the "detector" animation

Attachment 19249

but I've also drawn the spiders in a "collision friendly" way (for this example's change-direction purposes):
they are made using odd pixel size: this makes for a perfectly centered hot spot (flipping direction will result in same bounding box position)
this means that you could obtain same result by disabling fine collisions, and removing the additional "change animations" code used for the detector