Here is some code I have for an object that is supposed to travel horizontally back and forth, and switch directions when it encounters a gray wall.
Here is the code I used:
And here is what happens:
As you can see, SOME of the red balls get out of sync from the rest. This boggles me, as they all have the exact same code. It seems to matter where each ball starts horizontally. If anyone has any feedback, PLEASE HELP! The game is https://flowlab.io/game/play/844156 if you would like to check the code. The object is called “Test green ball.”
Collisions don’t count when if it doesn’t “collide”. They get out of sync because they get stuck to each other and the collision doesn’t count.
What you should do is to use a raycast to detect when another object is next to it (make them short).
What do you mean they get stuck to each other?
I do use raycast for other similar objects, the problem is I think the constant checking is causing lag. I was wondering if I could get collision to work.
Raycasts shouldn’t cause lag,
proximity will cause lag though.
I knew about proximity lag. I will take another look and see if I can isolate the problem.
Also, could you expand on what you meant in your previous reply?
Using an Always on a Raycast shouldn’t cause lag.
Using any object with an Always block shouldn’t cause lag either.
- Why Proximity lags is because it checks any and all objects inside the proximity, so using a large proximity in a big level will create lag.
- With this same idea, this can also be why large levels lag is because every object has a hitbox, so making a large game with 32x32 blocks can also cause lag.
- These are the main reason/issue with lag in Flowlab. Outside of this, I actually recommend testing and pushing the Flowlab engine.
What about the collisions not counting thing
Collision counts on a “collision”, or “impact”, between objects.
So they will have to collide again to output.
Think of it like a hug, the collision would output when you contact the other person/object.
But it won’t output again until you let go (unless you hit a wall or another object during the hug lol).
Ok, I understand that much. But how does that cause the behavior seen in the gif I posted? The red ball hits the wall, and outputs, thus reversing the velocity. The red ball now is no longer in contact with the wall. Then, it hits the other side wall, ouputs, and reverses the velocity again. The problem is some of the balls seem to “collide” a frame later than they should. So they travel ever so slightly farther than the others, getting out of sync.
Yes but also its the lag between the balls, cause every collision takes a frame, making other balls that haven’t collided be ahead by a frame. Then the chain reaction will cause the delay to “hug” each other.
I figured each ball should register collisions separately. Do you mean just general lag is causing the collisions not to register at the right time?
Oh no, they do register separately. That’s what I meant by chain reactions.
But also the delay is all the same for all objects, so other objects who haven’t “collided” don’t have this delay.
Hey @johnpost - I think you’re correct that they get out of sync due to frame timing issues. If they need to stay perfectly in sync you will probably need to move them explicitly (using x position) and maybe use timing to swap the directions instead of collision triggers.
I still think the best solution is using Raycasting to flip on first hit.
It makes an easy solution and works anywhere in the level.
Raycasts has never been a lag issue, right? (just double checking)
If they do for some reason, a solution with enable behavior could be used.
You could be right, it really all depends on how perfectly sychronized they need to stay. There is no real performance impact from that few rays.
I have been using raycast. The sync part seems to work fine with that and as @JR01 said, it makes them more versatile.
I had a question for grazer, would the performance impact increase as I add more of the object though? I have been testing different strategies and it seems as though a “level” with say, 15, of the objects raycasting in this way has substantially more lag than a “level” with none of the objects. I should clarify, the game is one big level, so I have a checker that disables the raycast and ball movement unless the “level” the object is in is the one that is currently selected.
And a question for JR_01, how would the solution with the enable behavior you mentioned work?
@johnpost Raycast has some performance impact, but I’m surprised to hear that it is noticeable without having a lot of them running per frame. How can I reproduce this lag myself to see what might be causing it?
I will see if I can make some examples. I’m having some difficulty isolating the exact cause of the lag, but I’ve got it down somewhat. I’ll set something up then link it here
Because all your objects are on one large level, you can disable the objects that are not on the level your on.
Best way to do this is to get the camera x and y outputs in a global variable. And for every object, use those numbers to see if its on screen.
If its on screen, use True into enable.
If its off screen, use False into enable.