Thats stupid, change my mind
This is actually very important because a lot of the behaviors and behavior nodes such as spawning an object could become very unpredictable.
Heres an example… Back then when the spawn behavior first came out, the spawn slot was on top of the other two, so it would spawn the object first before actually updating the coordinates. (And a currently existing example is the emit and its angle value being in the wrong place)
I also believe this helps the engine run smoothly
@CrimsonBlackGames What youre seeing here is how the engine actually doesnt do multiple inputs simultaneously, but prioritizes the upper-left most input first…
Ok this is blowing my mind. Is this mentioned anywhere? Ive been developing an arrangement system while I build games to keep things organized, but have not taken this bug/function into account. Are there other hidden aspects that work like this? Is it as simple as top left input = 1st processed or is there more to it than that? Does this just apply to behaviors in a single object or between objects too? And what about bundled behavior placement or parent/child behaviors?
September 2017, on page 5 of my SB3 update log, I was having trouble with the mobile editions Dpads that used messages.
Grazer responded: [spoiler] Hey @jngthree - this took some head scratching, but I think I figured the D-Pad problems out. The issue is that the mailboxes were not sorting correctly. When you move quickly from one button to the next, two messages can get sent to the ship in the same frame: “Stop” and “Go”. When the ship checks its mailboxes, if it happened to check them in the right order then they worked, otherwise they didn’t. Shooting is the same issue.
I fixed the mailbox sorting, but you need to make a tweak to the logic: in the “Gun” object, you need to make sure that the “Stop” mailbox is to the left of the “Go” mailbox, so that “Stop” always gets checked first (all triggers fire from left to right and top to bottom). This way when the Gun has both a Stop and Go message at the same time, it will stop and then go again. [/spoiler]
wow, I never knew that before. I find it surprising that so many people seem to not know about it for how important that could be.
ya, it’s almost like grazer should tell us this stuff
I’ve added a section in the User Guide explaining the behavior blocks’ evaluation order:
https://flowlab.io/user_guide/#flowlab-user-guide-behaviors-evaluation-order
1 Like
oh did I mention this still happens too?
Let me just play this out.
be me making some code
add logic gates to the code
this dumb stuff happens
Me “oh ill just move every logic gate in the code”
My face when I have to disconnect every logic gate because I cant move it without moving EVERYTHING.
Picture Related
Thank you,
But its kinda still annoying having every logic gate in the corner
I didn’t realize you didn’t know about shift moving, that’s what I did when I said it was working for me.
Does the gates still have to be in the corners if you shift move them?
1 Like