It hasn't been changed to integers (and 99% won't, ever). All that is done, is that while dragging and nudging, position gets rounded. The position is still a real number, though, and you can manually set it to 123.46938628 if you so wish.
@Icebox1910 said:
change the X and Y positions from reals to integers.
I don't understand , wouldn't that effect constraining 2 actors position x and y ?
There is a common misunderstanding in the way attributes are handled/stored - real and integer only applies to the storing of values, it has no effect on that values use outside of 'storage'.
So, you can take an integer attribute - let's use 5 - and chop it in half and you will get 2.5 - for example, make an integer, set the value to 5, then use a Display Text behaviour to display attribute/2 and you will get 2.5.
It's only the storing of an integer that rounds it to the nearest whole number.
@Socks I just did that i place an actor with integer attribute , i placed a rule when touch is pressed change attribute integer - 1.5 , and i placed a display text , it changes like this 5,4,3,2,1.
@Icebox1910 said:
Socks I just did that i place an actor with integer attribute , i placed a rule when touch is pressed change attribute integer - 1.5 , and i placed a display text , it changes like this 5,4,3,2,1.
I'm not sure what you are describing here, is this a question ?
@Wyrmfire Thanks for the feedback! We're making things better. Let us know what else we can do to help out.
@GeorgeGS Is new to the GameSalad codebase but is really putting in the fixes and driving to make things better. Much love for George!
@BlackCloakGS Keeps asking me to give him some time to implement zoom too... I expect we'll bite that off before you know it.
Our primary focus these days is removing blockers from using the app. Crashes, login issues, etc. Followed up by quality of life fixes and features. We're turning the crank as fast as we can. Hopefully fast enough to help keep you as a customer!
@WebWarrior said:
Well, this seems like a good way to do things Glad we could find some (relatively) trivial improvements with a high impact!
They are far from trivial to me ! Like I say elsewhere this is the stuff of dreams ! After you've spent 5 years years opening and closing and opening and closing and closing and opening and closing and opening (...) thousands of numerical fields (perhaps tens of thousands?), being told that this has come to an end is far from trivial !!!
@Socks said:
So, you can take an integer attribute - let's use 5 - and chop it in half and you will get 2.5 - for example, make an integer, set the value to 5, then use a Display Text behaviour to display attribute/2 and you will get 2.5.
I'm sorry , I meant with what you said to do , I did it I made an actor with an integer attribute value of 5 and i chopped it in half , and i made a display text and I did not get a 2.5 , I got a 3 , so I was talking about that. This would be a problem if they changed position from real to int.
@Socks said:
They are far from trivial to me ! Like I say elsewhere this is the stuff of dreams ! After you've spent 5 years years opening and closing and opening and closing and closing and opening and closing and opening (...) thousands of numerical fields (perhaps tens of thousands?), being told that this has come to an end is far from trivial !!!
We've all had those features for 5+ years, You've just been given a different version of GS this whole time.
The goal was to drive you mad before you released something so epic, we all had to give up dev.
I would love to see the rounded X&Y values when dragging actors onto the scene, this will save me (and others) a lot of time. Although..... I spawn most of my actors in the beginning of the game, gives me insanely fast loading times:D
Another thing that would be awesome to see, is if we could edit an actors initial properties from the layers panel. Simple tweaks can be made much faster this way, like changing the actors position, size, and its private attributes for example. Going back and forth trough actors can be a pain in the hand sometimes. Anyway, I already said too much for today, lets focus on the real issues first!
@Icebox1910 said:
This would be a problem if they changed position from real to int.
Like I say, it wouldn't be an issue as once 'out of the box' a value (a number) doesn't retain a memory of what 'box' it came from (numerical homeopathy ?). In an equation or a constrain calculation - or anything like that - there is no difference between a 'real' 17 and an integer '17', numbers are numbers, split 17 in half and you will get 8.5 regardless of whether the number is an integer or a real value. Integer and Real only apply to the storing of a number, not its use.
@codewizard, any chance that actor assets could be collected and organized into folders (or something) in the actors palette falls into the 'quick fix' catagory?
@AlchimiaStudios said:
We've all had those features for 5+ years, You've just been given a different version of GS this whole time. The goal was to drive you mad before you released something so epic, we all had to give up dev.
Well, I'm hAppy to saY it's had aBsoluEly no effeCt on me . . .
@jamie_c said: @CodeWizard , any chance that actor assets could be collected and organized into folders (or something) in the actors palette falls into the 'quick fix' catagory?
You know, I've been thinking about this. And it doesn't even need to be true "folders" in the sense that they exist within the proj file on disk and are referenced there.
For actors, a system already exists, it's just not nicely put in the viewer. Actor tag groups should work fine for this purpose. They just need to create a menu for the viewing them from the scene building view by the group instead of all at once.
I'd imagine the images and sound assets could use something similar.
@Icebox1910 said:
Socks I thought thats what you said that integer/2 will be 2.5, so I replied that it wont be 2.5 it will be 3 , sorry , I misunderstood !
I'm not sure I understand, sorry !
Integer is a definition for storing values, it has no effect on the value's general use. So divide an integer value of 5 by 2 and the result will be 2.5
@Socks said:
there is no difference between a 'real' 17 and an integer '17', numbers are numbers, split 17 in half and you will get 8.5 regardless of whether the number is an integer or a real value. Integer and Real only apply to the storing of a number, not its use.
I did not know that ! integer 17 /2 will not give you an 8.5 ! try it yourself man im sure ! it will give you a 9 , real 17 and integer 17 is different. Put a display text and see for yourself , your confusing me
@Socks said:
That would be a disaster ! Shift already does this, but why would we want to limit movement to steps of 10 pixels !? For this to be viable we would need to be able to place actors into a scene with pixel perfect accuracy !?
Yea I didn't mean to change the nudging from 1 to 10, just that it increase the original value without rounding
@Icebox1910 said:
I did not know that ! integer 17 /2 will not give you an 8.5 ! try it yourself man im sure ! it will give you a 9 , real 17 and integer 17 is different.
Are you suggesting there are two sets of numbers in the world, if presented with the number 17 a process (identical in every other way) would produce two differing results !?
Honestly, there is only one 17.
Show me an example of some code where dividing 17 into two (regardless of the source, integer or real) would produce 9 and I will show you an example of code where you are storing the result of a calculation in an integer shaped box before displaying it.
@Approw said:
I would love to see the rounded X&Y values when dragging actors onto the scene, this will save me (and others) a lot of time. Although..... I spawn most of my actors in the beginning of the game, gives me insanely fast loading times:D
Another thing that would be awesome to see, is if we could edit an actors initial properties from the layers panel. Simple tweaks can be made much faster this way, like changing the actors position, size, and its private attributes for example. Going back and forth trough actors can be a pain in the hand sometimes. Anyway, I already said too much for today, lets focus on the real issues first!
+1
The possibilty to change the attributes of a selected actor without opening and closing it would speed up the whole working process by roughly over 9000. The PC Creator already has this feature and the difference is insane. We'd just need an extra tab besides Images, Behaviors, etc. for Attributes.
@Socks said:
Show me an example of some code where dividing 17 into two (regardless of the source, integer or real) would produce 9 and I will show you an example of code where you are storing the result of a calculation in an integer shaped box before displaying it.
make an actor with an integer attribute "number" and give it the value of 17
when touch is pressed change attribute self.number to self.number /2
put a display text
the result will be 9 it wouldnt be 8.5
but if it was a real attribute then the result would be 8.5 , I don't mean to argue but I'm just confused about what your saying.
@Icebox1910 said:
when touch is pressed change attribute self.number to self.number /2
Change attributestores a number.
There is an attribute called 'number', you are changing that storage location (variable) to a new value when you use Change attribute, that storage location is 'integer shaped' it will only except integers, once that value has been stored in the integer shaped box, you are then saying "ok, now I have squeezed my number into a box that will only accept whole numbers, let's take a look at it'.
Hope that makes sense . . . . don't make me do a drawing, because I will !
@Icebox1910 said:
I don't mean to argue but I'm just confused about what your saying.
Not sure how to respond to that, I've got no issue with people discussing ideas.
@Socks Couldn't explain it better myself. Did you knew integer shapes are square, real attributes are round, and booleans are triangles? It blew my mind
@Icebox1910 said:
Socks then why is the result different when I put a real attribute ?
Because a real attribute can store a non-interger value.
Let's return to your original question - would making an actor's X/Y value an integer value impact on things like constrain behaviours where the actor is being asked to move through sub-pixel (non-interger) values ? The answer is no as the origin of a value has no bearing on how it acts in a calculation - like I say an integer 17 and a real 17 are identical, double either and you will get 34, half either and you will get 8.5 . . . but if you halve the value - then store that value in a container that will not allow decimal points - then take it back out and then continue to work with it, it will of course be effected.
So . . . . your example code . . .
1) make an actor with an integer attribute "number" and give it the value of 17
Ok, this defines 'number' as the value 17.
2) when touch is pressed change attribute self.number to self.number /2
This takes that value and divides it into 2, and then stores this value (8.5) in a container (an integer attribute) that will only accept whole numbers, so the number is rounded to the nearest whole value (9).
3) put a display text the result will be 9 it wouldnt be 8.5
This displays the value of 'number' which is 9.
You code works exactly as expected, if you extract an integer, preform a calculation on it, and then force the result back into an integer shaped box the result will be, of course, an integer.
Real and integer only refer to the storing of values.
. . . . . . .
Try this, make an integer attribute, let's call it 'A' - make 'A' = 17 . . . . and display the following A/2 - what result do you get ?
Notice how once 'out of the box' numbers don't remember some additional information about their history, 17 is simply 17, if you ask an actor to move to an x value of 17/2 it will move to x=8.5 or if you ask an actor to move to an x value of A/2 it will also move to x=8.5, even though A is an integer value.
@Socks it does feel like you are intentionally trying to confuse him.
His question is quite clearly related to how numbers work in GameSalad and in that sense he is absolutely correct.
Even with the majority of programming languages, you need to explicitly type cast if you want a float to be the result of dividing two integers, for example.
The math itself is done with real number precision, so on both occasions, the result of the calculation is the same (8.5 in your case), but then when the software returns the result to you, in one case it converts the result to an integer, which is why it shows 9.
Comments
Yup.
It hasn't been changed to integers (and 99% won't, ever). All that is done, is that while dragging and nudging, position gets rounded. The position is still a real number, though, and you can manually set it to 123.46938628 if you so wish.
There is a common misunderstanding in the way attributes are handled/stored - real and integer only applies to the storing of values, it has no effect on that values use outside of 'storage'.
So, you can take an integer attribute - let's use 5 - and chop it in half and you will get 2.5 - for example, make an integer, set the value to 5, then use a Display Text behaviour to display attribute/2 and you will get 2.5.
It's only the storing of an integer that rounds it to the nearest whole number.
+1
@pHghost Oh now i get it thanks !
@Socks I just did that i place an actor with integer attribute , i placed a rule when touch is pressed change attribute integer - 1.5 , and i placed a display text , it changes like this 5,4,3,2,1.
Well, this seems like a good way to do things
Glad we could find some (relatively) trivial improvements with a high impact!
I'm not sure what you are describing here, is this a question ?
@Wyrmfire Thanks for the feedback! We're making things better. Let us know what else we can do to help out.
@GeorgeGS Is new to the GameSalad codebase but is really putting in the fixes and driving to make things better. Much love for George!
@BlackCloakGS Keeps asking me to give him some time to implement zoom too... I expect we'll bite that off before you know it.
Our primary focus these days is removing blockers from using the app. Crashes, login issues, etc. Followed up by quality of life fixes and features. We're turning the crank as fast as we can. Hopefully fast enough to help keep you as a customer!
They are far from trivial to me ! Like I say elsewhere this is the stuff of dreams ! After you've spent 5 years years opening and closing and opening and closing and closing and opening and closing and opening (...) thousands of numerical fields (perhaps tens of thousands?), being told that this has come to an end is far from trivial !!!
I'm sorry , I meant with what you said to do , I did it I made an actor with an integer attribute value of 5 and i chopped it in half , and i made a display text and I did not get a 2.5 , I got a 3 , so I was talking about that. This would be a problem if they changed position from real to int.
We've all had those features for 5+ years, You've just been given a different version of GS this whole time.
The goal was to drive you mad before you released something so epic, we all had to give up dev.
Follow us: Twitter - Website
I would love to see the rounded X&Y values when dragging actors onto the scene, this will save me (and others) a lot of time. Although..... I spawn most of my actors in the beginning of the game, gives me insanely fast loading times:D
Another thing that would be awesome to see, is if we could edit an actors initial properties from the layers panel. Simple tweaks can be made much faster this way, like changing the actors position, size, and its private attributes for example. Going back and forth trough actors can be a pain in the hand sometimes. Anyway, I already said too much for today, lets focus on the real issues first!
Like I say, it wouldn't be an issue as once 'out of the box' a value (a number) doesn't retain a memory of what 'box' it came from (numerical homeopathy ?). In an equation or a constrain calculation - or anything like that - there is no difference between a 'real' 17 and an integer '17', numbers are numbers, split 17 in half and you will get 8.5 regardless of whether the number is an integer or a real value. Integer and Real only apply to the storing of a number, not its use.
@codewizard, any chance that actor assets could be collected and organized into folders (or something) in the actors palette falls into the 'quick fix' catagory?
http://jamie-cross.net/posts/ ✮ Udemy: Introduction to Mobile Games Development ✮ Learn Mobile Game Development in One Day Using Gamesalad ✮ My Patreon Page
@Socks I thought thats what you said that integer/2 will be 2.5, so I replied that it wont be 2.5 it will be 3 , sorry , I misunderstood !
Well, I'm hAppy to saY it's had aBsoluEly no effeCt on me . . .
You know, I've been thinking about this. And it doesn't even need to be true "folders" in the sense that they exist within the proj file on disk and are referenced there.
For actors, a system already exists, it's just not nicely put in the viewer. Actor tag groups should work fine for this purpose. They just need to create a menu for the viewing them from the scene building view by the group instead of all at once.
I'd imagine the images and sound assets could use something similar.
Follow us: Twitter - Website
I'm not sure I understand, sorry !
Integer is a definition for storing values, it has no effect on the value's general use. So divide an integer value of 5 by 2 and the result will be 2.5
I did not know that ! integer 17 /2 will not give you an 8.5 ! try it yourself man im sure ! it will give you a 9 , real 17 and integer 17 is different. Put a display text and see for yourself , your confusing me
Yea I didn't mean to change the nudging from 1 to 10, just that it increase the original value without rounding
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Honestly, there is only one 17.
Show me an example of some code where dividing 17 into two (regardless of the source, integer or real) would produce 9 and I will show you an example of code where you are storing the result of a calculation in an integer shaped box before displaying it.
+1
The possibilty to change the attributes of a selected actor without opening and closing it would speed up the whole working process by roughly over 9000. The PC Creator already has this feature and the difference is insane. We'd just need an extra tab besides Images, Behaviors, etc. for Attributes.
Thank god ! I thought you'd finally cracked under pressure and gone mad, lol
make an actor with an integer attribute "number" and give it the value of 17
when touch is pressed change attribute self.number to self.number /2
put a display text
the result will be 9 it wouldnt be 8.5
but if it was a real attribute then the result would be 8.5 , I don't mean to argue but I'm just confused about what your saying.
Change attribute stores a number.
There is an attribute called 'number', you are changing that storage location (variable) to a new value when you use Change attribute, that storage location is 'integer shaped' it will only except integers, once that value has been stored in the integer shaped box, you are then saying "ok, now I have squeezed my number into a box that will only accept whole numbers, let's take a look at it'.
Hope that makes sense . . . . don't make me do a drawing, because I will !
Not sure how to respond to that, I've got no issue with people discussing ideas.
@Socks then why is the result different when I put a real attribute ?
@Socks Couldn't explain it better myself. Did you knew integer shapes are square, real attributes are round, and booleans are triangles? It blew my mind
I did not understand a thing ! xD
Because a real attribute can store a non-interger value.
Let's return to your original question - would making an actor's X/Y value an integer value impact on things like constrain behaviours where the actor is being asked to move through sub-pixel (non-interger) values ? The answer is no as the origin of a value has no bearing on how it acts in a calculation - like I say an integer 17 and a real 17 are identical, double either and you will get 34, half either and you will get 8.5 . . . but if you halve the value - then store that value in a container that will not allow decimal points - then take it back out and then continue to work with it, it will of course be effected.
So . . . . your example code . . .
1) make an actor with an integer attribute "number" and give it the value of 17
Ok, this defines 'number' as the value 17.
2) when touch is pressed change attribute self.number to self.number /2
This takes that value and divides it into 2, and then stores this value (8.5) in a container (an integer attribute) that will only accept whole numbers, so the number is rounded to the nearest whole value (9).
3) put a display text the result will be 9 it wouldnt be 8.5
This displays the value of 'number' which is 9.
You code works exactly as expected, if you extract an integer, preform a calculation on it, and then force the result back into an integer shaped box the result will be, of course, an integer.
Real and integer only refer to the storing of values.
. . . . . . .
Try this, make an integer attribute, let's call it 'A' - make 'A' = 17 . . . . and display the following A/2 - what result do you get ?
Notice how once 'out of the box' numbers don't remember some additional information about their history, 17 is simply 17, if you ask an actor to move to an x value of 17/2 it will move to x=8.5 or if you ask an actor to move to an x value of A/2 it will also move to x=8.5, even though A is an integer value.
Hope that makes sense !
@Socks it does feel like you are intentionally trying to confuse him.
His question is quite clearly related to how numbers work in GameSalad and in that sense he is absolutely correct.
Even with the majority of programming languages, you need to explicitly type cast if you want a float to be the result of dividing two integers, for example.
@Icebox1910
The math itself is done with real number precision, so on both occasions, the result of the calculation is the same (8.5 in your case), but then when the software returns the result to you, in one case it converts the result to an integer, which is why it shows 9.
Honestly pHghost, please !@#$% off and try someone else for your trolling if you are in a poor mood.
Nope, you are wrong.