Hey @“Mhx Ar” - can you elaborate on the bugs that are blocking you on this game? I took a look and it wasn’t immediately obvious to me. I did notice that there it can get stuck in an infinite loop when you hit the right arrow:
There is a filter that checks for <1, and if the check passes, then it sets the Number to “1” and then sends the output back to the filter, etc, until it triggers an error.
The bug isn’t so much a bug as it is a lack of consistency.
1.) Objects that follow extracted coordinates are about a half second behind. This can also be found for mousemove.
2.) Proximity does not truly display the nearest object. If I select nearest x, and sit inside of 8 blocks in a square around me, it will point towards the bottom square as the nearest x. If I disable nearest x, it points towards the right block, but never the left block, no matter how much I tweak the slider.
This means, I can’t make a faux collision with proximity, and I can’t make one with following hip blocks. As far as I know, I believe collision was removed from attach blocks as well, although that wouldn’t help me with white blocks stopping on top of each other. Both CBG and I are finding it very difficult to make a game where objects move in grid chunks, instead of gliding, due to being unable to tell the objects when they can no longer move in a direction in an effective manner.
@“Mhx Ar” do you think we could have 2 objects on either side that detect blocks, then send the message saying that its there to disable the movement.
It would take the players position, add/subtract the X by 32 (depending on what side it needs to be on) and set it as its position, then prox check to see if a block overlaps it. Would that work?
Ima make a graph.
The red square with the P represents the player.
The blue squares represent the detector objects, with the size of the circle in them representing the proximity field, (can be no bigger than the square itself)
Thanks for the info - I’ll look into these. The proximity/nearest issue should be easy enough to test & fix I think. I don;t really understand the issue though, I think. If there are 8 blocks all surrounding a center block, they should all be equidistant from the center, which means that the result for the “nearest” block will be arbitrary, right? Maybe I misunderstand you.
The “half second behind issue” sounds a bit trickier. Is this to do with messages? Message timing can be tricky, since the order can depend on which objects (sender vs receiver) get run first in a given frame.
Can you point me to an example of where you see this issue? I’ll check it out and see if I can figure out a solution.
Also, maybe the issue is that you guys just need a different type of behavior block that would more specifically help solve the problem you’re working on?
I know the problem- the proximity can only handle one object at a time, maybe add a setting that allows up to the closest X objects- with multiple pairs of Xs and Ys
@“Mhx Ar” - I think I may see where the collision confusion might be happening. The Proximity trigger will detect the closest object, and output the x & y position of that object. It doesn’t detect the x and y proximity separately.
@grazer Would you be able to make a 4 way proximity? A separate check for up down left and right? This would allow one object to detect being surround ed by objects or enemies.
As for extract - position lag, yes I am using messages, but it happens if you connect mousemove directly to position as well. I guess I could manually set the extract within the hip boxes for the green box. There’s only one instance of it. Still can’t come up with a solution for making white boxes move on grid and stack. Maybe have each box move 1 grid down then 1px up, enable, collision below white, toggle off timer for movement, disable, so it locks in place and won’t be accidentally pushed by the player… but then how could I stand on it if collision disables? Hm…
@CrimsonBlackGames the hips blocks I already mentioned from the start. I have then at alpha 20. Check my game.
@“Mhx Ar” I got my game working fine and the blocks stack too…
@CrimsonBlackGames
Oh? If so, you’re even better at flowlab than I thought. I’ll have to try it out. Good job. You just keep pulling out new tricks I never even thought of.
The only thing I dont have down yet is the whole block next to you thing
@CrimsonBlackGames that’s what the hip boxes in my game do. That’s also what your drawing was, right? They have a tiny proximity and send a message to turn off x movement for that side.
Actually, btw @grazer @CrimsonBlackGames I may have finally solved the hitbox issue I have questioned for years. “How the heck would someone make Mortal Kombat or any other arcade fighter in flowlab? The hitboxes never change.”
It just hit me like a speeding train.
The player object has the collision of a thin rectangle, and plays full size body animations. There are 6 circle/rectangle objects with alpha 0. Head, left hand, right hand, left leg, right leg, and torso. Rotation changes collision, so check this out.
Every animation that plays sends a message to each 6 objects to go to a certain pixel distance from the player body rectangle. If I punch, the alpha 0 hand circle positions to match the sprite. If I kick, the alpha 0 leg rectangle rotates and positions for those frames. When attacking, the shapes play a red animation for that frame, and blue when not attacking. When blue, that box can be hit. When red, it can’t be hit, and causes damage to blue on collision. Each object upon being hit sends a message to the player spine to play a hurt animation. The ultimate hitbox skeleton map.
Oh, uh, collision won’t work with position right? Maybe use small proximity circles for the objects.
Ooooh…
that’s an interesting concept
Probably the first time in Flowlab that has physical fights
Yeah, thats what I sorta did, to avoid corner catching I cut the sides off, so they wouldnt collide, but played an animation so they still looked like a square