Understanding Sequence of Behaviours: In Search of Speed!

[Deeeds]

@Aidan-Oxley Good. In this situation that's definitely what appears to be happening and what I want happening.

Are there faster ways? Any concurrency on offer?

[Aidan_Fire]

@Deeeds I don’t really think any way of arranging behaviours is faster, it just depends on how you like it to look. I’m a little bit crazy, I let all my behaviours sit in a giant horizontal line under the event triggering them all. I’m also obsessed with double tapping event behaviours to make everything under them automatically neaten themselves.

[Deeeds]

@Aidan-Oxley If, as I'm suggesting and you're saying, it's down the branches then left to right, why does "Behaviour Bundle" exist?

It seems to do much the same thing.

[Aidan_Fire]

@Deeeds Behaviour bundle does nothing other than make behaviours look a bit neater while not affecting performance. My 3D project actually uses this because if I didn’t, my maths to calculate 3D points would be so long I wouldn’t be able to join them to the event even if I zoomed out to max.

[Deeeds]

@Aidan-Oxley Is there anywhere discussing the relative differences between:

Getting a Value Behaviours 'value'
Getting a Box Container's 'value'
Getting an Array's 'value' by index
Getting an Attribute's 'value'

And all the other means of getting (and setting/storing) values in terms of performance?

I'm assuming that Attribute value gets are slowest, then Box Containers, then it's probably close to a tie between Array elements and Values.

But I don't know. Just guessing.

[Aidan_Fire]

@Deeeds I think the fastest way to store and use a value is through Box Containers or maybe Values. I’ve never actually used the Value behaviour though. Attributes are for having a value easily accessible to other objects, arrays are for storing lots of values as one group of text.

[Deeeds]

@Aidan-Oxley said in Understanding Sequence of Behaviours: In Search of Speed!:

arrays are for storing lots of values as one group of text.

You keep saying this.

Arrays, in the rest of the world, aren't this.

They can have text, sure. But that's not their benefits/purpose/way.

Is this how they are, exclusively, in hyperPad?

The way @hamed optimises things, and makes a very concerted effort for efficiency and performance, I find it highly unlikely that he's doing this to real world Arrays when they offer SO many benefits in their real world way of being.

ie arrays of types based on the content type.

[Aidan_Fire]

@Deeeds An array (at least as I know it, in hyperPad) is a bunch of text that means something. Kinda like words. A bunch of text that stores as many values as you like in a specific format.

[Deeeds]

@Aidan-Oxley Again, this is a way of thinking about arrays, but it's not actually what they are, nor how they work.

Where do you get this idea from?

What you're describing is the use of a massive string with stored separators that would require some kind of index for the division of each element, or some other kind of separator. Which, again, isn't an array.

That's how CSV works, but they still need a type, too.

[Aidan_Fire]

@Deeeds I got this idea from the fact that I can display it as text, modify the text etc. The formatting uses symbols to separate values. Clearly I think about arrays (at least hyperPad version of arrays?) differently to you.

[Deeeds]

@Aidan-Oxley yes, like I've said before, this can be how an Array is represented to you, and can be thought of, but it's not what it actually is. You're being gifted a slightly abstracted view and experience with them.

[Jack8680]

I'm guessing array values are stored in separate memory addresses in a way that they can quickly be accessed by index, but they can be converted to and from plain text json for use in non-array operations (which I think most languages do). I might be completely wrong.

This would make accessing an array value the same as accessing a box container.

Running a modify array behaviour replacing an existing array should then also be the same as using set input field on a box container, but appending or prepending is probably less efficient.

I don't know how memory allocation would work for attributes, but because they can be accessed on spawned objects I expect they'd be least efficient.

Keep in mind I have no idea what I'm talking about and might be completely wrong, perhaps arrays store a list of memory addresses instead, which means accessing two addresses per reference.

[Deeeds]

@Jack8680 Can you explain what a Value container is, in words different from the docs?

I can't figure out what these are representative of, or... well, anything about them.

I thought I knew, then I tried a few things and couldn't work out what was going on.

Much like my cooking.

[Jack8680]

@Deeeds the value behaviour updates its output when it is run. You can for example get the value of the output of a while touching behaviour once, and then reference it in that state later after the output of the while touching behaviour has changed. It's basically declaring a new variable that takes the value of another variable but not as a pointer.

[Deeeds]

@Jack8680 said in Understanding Sequence of Behaviours: In Search of Speed!:

the value behaviour updates its output when it is run.

Sorry to be pedantic: Do you mean when its branch has completed running? Like a late update or willSet in Swift?

[Deeeds]

@Jack8680 The rest I don't understand what you're saying.

It's making a new variable? Not overwriting it later?

I'm more confused than before. Sorry!

[Jack8680]

@Deeeds the value behaviour is basically like saying

Var value = input

It's not a pointer, so if you reference the value elsewhere it will have the value of the input when the value behaviour is activated.

It is different to a box container because a box container is a pointer when you drag a behaviour output in, so referencing a box container will reference the value of what is selected in the box container.

You can't use set input field on a box container that has a behaviour output selected as its value, so there's no reason to use them this way as you can just reference the behaviour output directly.

Using set input field on a box container that isn't a reference to another behaviour output acts the same as using a value behaviour, but it can be set from multiple places.

[Deeeds]

@Jack8680 said in Understanding Sequence of Behaviours: In Search of Speed!:

It's not a pointer, so if you reference the value elsewhere it will have the value of the input when the value behaviour is activated.

Reading this I'm doubting I understand how behaviours actually work.

I'm missing something.

Can you give a concrete example of where and when you'd have to use a Value container for its benefits (and ways of being) versus somewhere a Box container could only provide the desired results?

[Jack8680]

@Deeeds I rarely use the value behaviour, but an example:

While Touching:
    {
    If(While Touching Y < 0):
        {
        Value = Value(While Touching X)
        }
    }

Stopped Touching:
    {
    Set label to Value
    }

When you stop touching the object it will set a label to the last x position you touched it in where the Y position was less than zero.

And an example of using a box container:

Box container A = 0
Started Touching:
    {
    If(While Touching X < 0):
        {
        Set input field of Box Container A to 1
        }
    If(While Touching Y < 0):
        {
        Set input field of Box Container A to 1
        }
    Set label to Box Container A.

This will set the label to 1 if X or Y is negative. Both of these can also be done using the other behaviour, so I guess there isn't a specific reason to use one over the other. There might be a use case I'm not aware of though.

[Deeeds]

@Jack8680 said in Understanding Sequence of Behaviours: In Search of Speed!:

Both of these can also be done using the other behaviour, so I guess there isn't a specific reason to use one over the other.

This is exactly the cognition problem I'm having.

Although I just accidentally dragged a different source into a box container and it took it, and left the old one there, too.

So maybe Box Containers are abstracted arrays posing as a variable and without the need to append, etc.