Other than Patrol, how to make repeating series of actions
-
@Aidan-Oxley There's nothing else interrupting or otherwise engaging this object, or this message. It's a new type of object in the game (a flashing start and finish line) and the Start Message is fired for the timing mechanisms, so is both well placed and firing singularly, as required. The timing mechanism works like a charm. Except for that floating point rounding bug... which I used a string culling to get around.
-
@Deeeds The Value9 also isn’t taking any values at all from receive message right? That’s the last thing I can think of. If not, then I can’t help any more without having you wait ages for your project to upload. All I can do is suggest you just use box containers instead.
-
@Aidan-Oxley It's supposed to flash 0, 1, 2, 3, 4 times... and then set the Value9 to 0
But that's not the important part... it's the fact that Value9 isn't (seemingly) getting set to 0.
At this point, when I made this little test case (trying to find out what Value types are) I thought..."this should work, and prove to me that they're self contained (encapsulated) copies of their original, and unique to their object. These are inside spawned objects. The start line is made up of 5 tiles of a single graphic. Each one of these has this code inside of it.
What this shows me is that Value Behaviours are not Value Types in the way that we think about them in strict languages, where they'd be unique copies of the original value with their own storage location in memory.
This is a global of some "type".
-
@Aidan-Oxley For the (what... 10th time?) this isn't about the problem. I know of other ways to solve the problem.
THIS IS ABOUT UNDERSTANDING VALUE BEHAVIOURS !!!!!!!!!!!!!!!!!!!!!!!!
PLEASE UNDERSTAND THAT!!!
Nobody has been able to (seemingly) explain what a Value Behaviour actually is: not in programming terms, not in computer science terms, not in hyperPad terms.
And the documentation is so thin, so scarce and bare as to be an afterthought, or less.
And, you yourself, have admitted that you do not know what these are.
This is the only thing in hyperPad I can recall stumping you.
What is a Value Behaviour?
-
What is a Value Behaviour?
Please, not in the words akin to the "documentation".
Try to describe them as though talking to a child.
Then try to describe them as though talking in computer science terms.
Then try to describe them in terms of their capacities and ideals within hyperPad.
Given how much time you two spend thinking about hyperPad additions and alterations, I hardly think Value Behaviour is an afterthought or haphazard.
Please, sirs, what IS it?
-
@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.
