Other than Patrol, how to make repeating series of actions
-
@Deeeds All I know about the Value behaviour is that it does the same thing as a Box Container, stores some text, except it does a few other things that I’m not sure about. Hopefully Murtaza or Hamed will help you (and me) understand exactly what they do.
-
Box containers can get data from multiple sources.
Eg. You can have Add value, multiply, and subtract behaviours all send their result to a single box container.And depending on your behaviour logic, the box container will store the last thing that updated it.
A value behaviour can only have one source at a time, and it will replace the source with your new one.
Eg.
If you have Add values, and output the sum to a VALUE behaviour.
Then later try to output the product of a multiply behaviour to the same value behaviour, it will replace the add value, and any logic dependant on that will no longer work.
Additionally, the value behaviour is an event and it will trigger a child behaviour once it is executed. (The event is only triggered with parent, and WILL NOT be executed if the value is updated).In reality, the value behaviour is a weird bandaid fix that was required in a rare situation that I don't remember now.
For most cases a box container is what you want and will act like a regular variable. -
@Murtaza said in Other than Patrol, how to make repeating series of actions:
Box containers can get data from multiple sources.
Eg. You can have Add value, multiply, and subtract behaviours all send their result to a single box container.
And depending on your behaviour logic, the box container will store the last thing that updated it.
A value behaviour can only have one source at a time, and it will replace the source with your new one.
Eg.
If you have Add values, and output the sum to a VALUE behaviour.
Then later try to output the product of a multiply behaviour to the same value behaviour, it will replace the add value, and any logic dependant on that will no longer work.
Additionally, the value behaviour is an event and it will trigger a child behaviour once it is executed. (The event is only triggered with parent, and WILL NOT be executed if the value is updated).
In reality, the value behaviour is a weird bandaid fix that was required in a rare situation that I don't remember now.
For most cases a box container is what you want and will act like a regular variable.How is this:
Eg. You can have Add value, multiply, and subtract behaviours all send their result to a single box container.
And depending on your behaviour logic, the box container will store the last thing that updated it.
Different from this?
If you have Add values, and output the sum to a VALUE behaviour.
Then later try to output the product of a multiply behaviour to the same value behaviour, it will replace the add value, and any logic dependant on that will no longer work.
Neither of them now have the same original value, they are both updated to the latest result. Neither of them provide access to their prior value.
They're operationally the same, from this description, as far as I can tell.
-
Additionally, the value behaviour is an event and it will trigger a child behaviour once it is executed. (The event is only triggered with parent, and WILL NOT be executed if the value is updated).
This seems like an opportunity missed.
-
Try it in the editor and you will visually see value behaviour replace what's in the input field, and the box container will add the other behaviour as an additional source.
The key difference is that.
While yes at any given time they both store 1 value, the difference box container can have multiple sources for that value. -
@Murtaza yes, I’ve seen this peculiarity in the editor.
But that’s not the question I’m asking, nor what I’m curious about.
If both replace prior states of their store, then what’s the difference?
-
@Murtaza the problem comes in terms of two things, I think...
Value Behaviours are Behaviours but aren’t a Value.
They seem to be global variables. But I can’t be sure.
-
@Deeeds said in Other than Patrol, how to make repeating series of actions:
Additionally, the value behaviour is an event and it will trigger a child behaviour once it is executed. (The event is only triggered with parent, and WILL NOT be executed if the value is updated).
This seems like an opportunity missed.
I actually made a mistake. The Value behaviour should only store the value once it's executed. Otherwise it's null.
As for executing when the value is changed, we actually have this in a different way. If you tap the icon beside any input field it will generate a "Change input field" behaviour.
This new behaviour is like a "Value" behaviour specifically for that input field. There is a toggle switch that says "Restart Behavior" this will execute the original behaivour as soon as the change value is executed. -
@Deeeds said in Other than Patrol, how to make repeating series of actions:
@Murtaza yes, I’ve seen this peculiarity in the editor.
But that’s not the question I’m asking, nor what I’m curious about.
If both replace prior states of their store, then what’s the difference?
That is the difference. It all depends on how your behaviours are set up.
Additionally the key component earlier (which was part of my last reply) is that a value behaviour will only store the value once it has been executed.
With a box container you never need to execute the box container it self to store a value. A value is immediately put there.@Deeeds said in Other than Patrol, how to make repeating series of actions:
@Murtaza the problem comes in terms of two things, I think...
Value Behaviours are Behaviours but aren’t a Value.
They seem to be global variables. But I can’t be sure.
Values are not global.
They are scoped within the object. -
@Murtaza said in Other than Patrol, how to make repeating series of actions:
That is the difference. It all depends on how your behaviours are set up.
Additionally the key component earlier (which was part of my last reply) is that a value behaviour will only store the value once it has been executed.Please look closely at the example that @Aidan-Oxley and I have been experimenting with.
It seems to disprove your "only stored when executed", since both his fully working example and mine are interacting with the Value Behaviour and getting updated values, despite not executing the behaviour in subsequent updates.
-
@Aidan-Oxley
Try this.
Using the same structure as before, use a messaging object to activate spawns.
Place the Value and its code for flashing its object in an.... object.
Now spawn a few of these onto your screen.
Make a button, one that sends a message to the spawns to operate their flashing. START, in my example.
This is the scenario where this is failing for me.
-
@Deeeds @Murtaza There is definitely something strange happening here. It only happens when you start to spawn more of these objects with the flash cycle behaviours.
Have a look in this project: http://bit.ly/E04bqD
Tap the green object to make the blue objects flash (5 times). After you see that work normally, maybe try it again, just in case. Then, tap on the blue objects to spawn duplicates of themselves to the right. Then tap the green box and watch the blue objects fail to cycle properly (specifically, the original ones act a little strange, but only for the first time, any other cycles after that work fine, and only after they spawn duplicates). Tap the green object again, the spawned blue objects will only flash once, while the originals do it all 5 times.
