Feature Request: Getters for all Setters
-
Set Bounce, Set Friction are two jumping out at me, right now.
I could really use a "Get Friction" for debugging, right about now. I don't know where/how I'm setting it, or to what.
But, other than that, in general, I think all getters and setters should be merged into single blocks, with a switch, that determines whether they're a getter or setter.
So there's behaviours:
Get/Set Friction
Get/Set Bounce
Get/Set Massetc.
And the user taps the switch to make each block either a getter or setter.
Less blocks good, I say.
Similarly, while I'm on the subject of minimisation:
Arithmetic can be one block with a pair of inputs and an operator in the middle, to be chosen from add, subtract, multiply, divide, square and exponent.Further, right below the pair and operator can be an option to add another operator and another input, ad infinitum.
I like spreadsheets, too.
-
Set Bounce, Set Friction are two jumping out at me, right now.
I could really use a "Get Friction" for debugging, right about now. I don't know where/how I'm setting it, or to what.
But, other than that, in general, I think all getters and setters should be merged into single blocks, with a switch, that determines whether they're a getter or setter.
So there's behaviours:
Get/Set Friction
Get/Set Bounce
Get/Set Massetc.
And the user taps the switch to make each block either a getter or setter.
Less blocks good, I say.
Similarly, while I'm on the subject of minimisation:
Arithmetic can be one block with a pair of inputs and an operator in the middle, to be chosen from add, subtract, multiply, divide, square and exponent.Further, right below the pair and operator can be an option to add another operator and another input, ad infinitum.
I like spreadsheets, too.
I've decided the only thing needed is a single block for ALL getters and setters.
Get/Set
The first field is the entity that's going to be gotten from or set to.
The next field(s) are where the user picks what to get and/or set.
Simple. Universal. Elegant. Easily understood and articulated, incredibly powerful, yet elegant.
Time for a beer.
-
I've decided the only thing needed is a single block for ALL getters and setters.
Get/Set
The first field is the entity that's going to be gotten from or set to.
The next field(s) are where the user picks what to get and/or set.
Simple. Universal. Elegant. Easily understood and articulated, incredibly powerful, yet elegant.
Time for a beer.
@Deeeds Kinda like how they have only the 1 behaviour for all trig functions? (Math function)
-
@Deeeds Kinda like how they have only the 1 behaviour for all trig functions? (Math function)
@Aidan-Oxley Yes, and all math functions should have their own little box, too.
No need for different ones for
+
–
x
÷
^
√Put them in all in a single "Calculate" box, and enable the user to pick the operator in between values, and then let them add more operators and values as they require.
-
@Aidan-Oxley Yes, and all math functions should have their own little box, too.
No need for different ones for
+
–
x
÷
^
√Put them in all in a single "Calculate" box, and enable the user to pick the operator in between values, and then let them add more operators and values as they require.
@Deeeds I think this could be useful. The amount of times I’ve made a huge amount of maths logic, just to realise that one box is addition rather than subtraction by mistake. Have to disconnect all the behaviours, delete the addition, replace it with subtraction then connect it all back up. To be able to just go and change a sign between two values would be awesome.
-
The getters/setters is actually a planned change. Also same with the math functions! We want to have a "calculator" type behaviour that can handle all the calculations in a single place.
@Murtaza Can you add "Observers" to this planning?
By this I mean having things that observe changes to a property.
There's two modes of operation for an observer for ideal use and design:
willSet (knows it's about to change so does something with the existing value and considers how to use the incoming value)
didSet (knows the value has changed and has access to both the prior value and new value to do as it pleases)
These are incredibly simple activation switches for objects, and absolutely ideal for game design and production conceptualisation. Saves on messaging, too, enormously.
-
@Murtaza Can you add "Observers" to this planning?
By this I mean having things that observe changes to a property.
There's two modes of operation for an observer for ideal use and design:
willSet (knows it's about to change so does something with the existing value and considers how to use the incoming value)
didSet (knows the value has changed and has access to both the prior value and new value to do as it pleases)
These are incredibly simple activation switches for objects, and absolutely ideal for game design and production conceptualisation. Saves on messaging, too, enormously.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login