@Socks Ohhhh ! now I get what you mean ! but that only works in a display text man , but if you were to put an integer value in a change attribute that would be different , this is why I was saying changing position from real to integer would be a problem ! I got you now but I was referring to constraining and changing attributes.
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
@Socks said:
These kinds of changes, the default text colour, having to make two corrections for every actor you place in a scene, are the stuff of dreams ! Your interest in this stuff is genuinely appreciated !
I have to add my $0.02 here. It's wonderful to see such quick revisions to the software based on user needs. And it's unusual. Many of these things have been requested repeatedly for years with no response or "we can't do that." It's great to see that that's no longer the attitude. I agree that it makes a huge difference to have these "little" fixes. In one day of using GameSalad, I might click a few thousand times because of windows not remembering their position and size, default font color being white, lack of actor/asset folders, etc. It adds up quickly and gets tedious quickly.
I know I'm not saying anything that hasn't been said a bunch already in this thread but... THANK YOU. Great to see progress being made!
So, the changes made to the position values and such are editor changes only. There won't be any difference to anything you do at runtime. If it worked before it'll work after the new version.
@Icebox1910 said:
socks Ohhhh ! now I get what you mean !
Good !
@Icebox1910 said:
but that only works in a display text man . . .
Not at all ! It works with everything except for the storing of values (so writing a value into an attribute or table).
@Icebox1910 said:
. . . but if you were to put an integer value in a change attribute that would be different
Change attribute changes an attribute !! You are storing a value !
Imagine a star shaped plastic box and some Play-Doh . . . I am saying you can make the Play-Doh into any shape you like, but you are saying 'every time I squeeze the Play-Doh into my star shaped box it comes out looking like a star ?' . . . of course !
Change attribute moves the defined value into that attribute, if that attribute is an integer this will round the number.
@Icebox1910 said:
this is why I was saying changing position from real to integer would be a problem !
It wouldn't be a problem at all !
@Icebox1910 said:
I got you now but I was referring to constraining and changing attributes.
Constraining an actor's Y position to, for example, a sine wave (even if the sine wave's changing values passed through non-interger values) and even if the actor's position is defined as an integer value - would not be a problem at all.
@Socks I see , I understand now , but why most of the tutorials on gamesalad and other game engines always use float ( decimals / real) instead of integer when they are playing with position if it is not a problem , they say it affects precision and movement becomes less smooth if it was an integer, if the actor is not moveable they use integer but if its moveable they use real or float. Now based upon that , I was worried when I read that position would change into integer, this is the reason that made me discuss this.
@Icebox1910 said:
pHghost yea this is what I mean the return result , that is why I was confused with what Socks is saying , i might have explained it wrong
I was extracting a value (regardless of real or integer) and performing a process on that value, and using that result . . . . you were extracting a value, performing a process and then storing that value (in a container that couldn't accommodate it) and then re-extracting that value and using the result (with the result being effected by you first moving (modifying) the value).
Try this . . .
Make an iPad landscape project.
Make an actor with an integer attribute, let's call it AAA.
Now give this actor an Interpolate behaviour.
Interpolate AAA from 0 to 1024 over 100 seconds.
Now give this actor a Constrain behaviour.
Constrain the actor's X position to AAA
Also give this actor a Display Text behaviour, display AAA.
. . . . . . .
Notice that the integer attribute called 'AAA' happily displays sub-pixel (non integer) values, this directly relates to your original question, attribute definitions only relate to stored values, the Interpolate behaviour doesn't 'know' that it is interpolating an integer or a real value.
It's great that GeorgeGS is being let loose to address the issues brought up in this thread... In the space of a few days tinkering on small changes the software is going to have made bigger advancements in useability and productivity than in it has in ages...
Thankyou @GeorgeGS for being the new guy that's brave enough to tackle things... and thankyou to @Codewizard and the rest of the team for letting him, and helping him.
It's a big win for everyone, and although it might have seemed a bit heated and confrontational at times, I hope that everyone understands that it's just because we're passionate about using the software and seeing it, the team, and us the users succeed.
But yup.. For me personally, I feel like we've turned a corner... Longstanding issues have finally been acknowledged, and were heading in a better direction together.
It's a team effort, and everyone deserves a pat on the back... but I think GeorgeGS might be on his way to earning himself a bit of a fan club....
@Chunkpixels wisely and correctly proclaimed with the complete and enthusiastic agreement of @Armelline:
It's great that GeorgeGS is being let loose to address the issues brought up in this thread... In the space of a few days tinkering on small changes the software is going to have made bigger advancements in useability and productivity than in it has in ages...
Thankyou @GeorgeGS for being the new guy, that's brave enough to tackle things... and thankyou to @Codewizard and the rest of the team for letting him, and helping him.
@Icebox1910 said:
pHghost yea this is what I mean the return result , that is why I was confused with what @Socks is saying , i might have explained it wrong
No, you explained it clearly enough, don't beat yourself up about it. Socks usually explains everything to the most minute detail, which is often great and that's why his input is often the best out there. But sometimes people just want a simple, straightforward answer and get confused by the amount of his words instead.
@JohnRuskin (1819 - 1900) said:
Say all you have to say in the fewest possible words, or your reader will be sure to skip them; and in the plainest possible words or he will certainly misunderstand them.
What @Icebox1910 is referring to was his understanding of a position system which would be purely integer based. If that was the case, and no float positions were possible, it could truly create jerky movements.
@Chunkypixels said:
In the space of a few days tinkering on small changes the software is going to have made bigger advancements in useability and productivity than in it has in ages...
@Socks said:
Is there an example of someone making this case that I could take a look at ?
I searched this issue on another forum with a different engine im not sure if it would be alright to put the link here, but there is a tutorial on youtube by @The_Gamesalad_Guru that explains how locking two actors position using integers instead of real would be a problem. its in minute 10:42
this made me think that there would be a problem if it was integer instead of real ! This is why I wanted explanation
@pHghost said:
No, you explained it clearly enough, don't beat yourself up about it. Socks usually explains everything to the most minute detail, which is often great and that's why his input is often the best out there. But sometimes people just want a simple, straightforward answer and get confused by the amount of his words instead. (Quotes Ruskin !!]
A generally applicable piece of advice would be to make the conversation about the subject/the question, rather than the person, no one (perhaps besides you and me and my dear old mum) are interested in what you think about my approach to answering questions (as good or as bad as it can be at times), you can't really go wrong with sticking to the subject matter instead of attempting to politicise questions as a personal issue. Quoting Ruskin too ! lol.
What Icebox1910 is referring to was his understanding of a position system which would be purely integer based. If that was the case, and no float positions were possible, it could truly create jerky movements.
yea float position is possible because float is known in gamesalad as real ! now by eliminating real from position and changing it into an integer that would make float impossible right ?
@Icebox1910 said:
. . . there is a tutorial on youtube by @The_Gamesalad_Guru that explains how locking two actors position using integers instead of real would be a problem.
I give up ! lol
Sorry I was not able to explain myself better, but with lofty judgemental quote mining from Ruskin (not from you!) I'm outta this thread, try some of the experiments I suggest above, hopefully that will give you a better understanding of the underlying issues at play here, but the bottom line is that if (even accepting it's vanishingly unlikely to happen) actor poisons were stored as integer values it would have zero effect on how those values are processed.
Which of his works was that one in? I have trouble locating it.
@Socks said:
In GameSalad 'float' positions are possible.
Yes, we all know that. @Icebox1910 was referring to a hypothetical situation mentioned, and expressed valid concern.
Here is are the statements that likely set the stone in motion; for your reference:
@GeorgeGS said:
Changing from real to integer is a big change and unlikely to happen in the short term, but rounding the coordinates when you drag actors and images into the scene seems like it would get you most of the way there.
and:
@jonmulcahy said:
awesome! Next on the list is to change the X and Y positions from reals to integers. I can't think of any reason people would want decimal places when positioning actors.
@pHghost said:
Here is are the statements that likely set the stone in motion; for your reference:
Here is the actual question:
"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 ? if it was integer instead of real ?
@pHghost said:
Which is why his question was entirely valid.
Ok . . . . . but . . . . ?
Has anyone in this thread, or anywhere else, said his question was not valid ? As you were busying yourself attempting to introduce a personal dimension into this thread, making me (and your own personal views about my presentation style) a point of conversation (as well as inanely posting comically judgemental Ruskin quotes) I was happily engaging him in his question, it's clear we've had a disagreement in the past, attempts to drag it into other areas are pointless, give it up.
I'm not interested in another off-topic conversation where you twist other people's words.
I only pointed out that you were confusing him more than anything else, which you can read back and see, it got to the point where he was doubting whether he was asking correctly. I (likely unsuccessfully) tried to make a joke by saying you are doing it (confusing him) intentionally, thinking it might resonate with your British sense of humor. Sorry, my mistake.
Your reaction to that was telling me to f-off. And now you say I'm being personal?
Anyway, I'm not discussing this further and derailing another thread. We've had a disagreement in the past, and if you cannot let bygones be bygones, I'm really sorry.
@pHghost said:
Your reaction to that was telling me to f-off. And now you say I'm being personal?
Yes, please !@#$% off and stop trying to pursue an old argument and yes you needlessly made this conversation personal (again).
"I'm being personal?"
Yes, absolutely, unambiguously, we've recently had a (forum) falling out, so (presumably) we are both alive to the particular tension that causes . . . . . so you make your opening gambit to me in this thread: '@Socks it does feel like you are intentionally trying to confuse him'.
Lol, seriously, you start a conversation up, having come from a previous argument, with another of your silly admonishments . . . and then struggle to see the personal nature of this ?
So, yes, me and you have had a disagreement in the recent past, you have let it bother you to the extent where you feel the need to find an opening to resolve some still-held tensions (all amateur online psychology on my part, admittedly), so that's all quite understandable, we're all human, I do it myself, but let's not make Icebox1910's question the battle ground and leave it there shall we ?
If you still feel you need to get stuff off your chest then PM me.
I don't think you should change position to integers. As when you have an accelerating actor at a very slow acceleration that makes it's velocity fractions of a pixel, you want the position accumulate these decimals over time so that actor actually moves.
for example if
your position x is 20.0 and linear.velocity is only 0.3 you want position to accumulate to 20.3 and then 20.6 and 20.9 and so on...you don't want it to have no effect on position.
If this were to change to integer, your position x will not change as 20 + 0.3 converted to integer will still be 20 so it'll never actually move.
I know 7 people agreed to the above change but really think about what's going to happen, if positions are integers, then velocities will be pointless being reals so they have to be integers too..since new position is calculated by current position + velocity.
Would you really want that? movements won't be as smooth.
@tintran the positions are only snapping to an integer when you place them on the screen. When they move in the game they will still move the same. Acceleration will still work the same objects will move fluidly through decimal points.
When dragging a object on to the screen in editor it is nice to have them snap to an integer. So you can line things up nicely when doing level design.
@RossmanBrothersGames said:
tintran the positions are only snapping to an integer when you place them on the screen. When they move in the game they will still move the same. Acceleration will still work the same objects will move fluidly through decimal points.
When dragging a object on to the screen in editor it is nice to have them snap to an integer. So you can line things up nicely when doing level design.
So you're asking for GUI snapping to whole numbers for example rounded to the nearest integer, and for example if you hold down control and drag then they snap to nearest 10 or increments of 10 from original position..
I am all for that.
Just not actually changing the type of position.x and position.y to integers because that will break it because then velocities will also turn into whole integer pixels and so will acceleration and that would be really bad.
@Icebox1910 said:
Socks Ohhhh ! now I get what you mean ! but that only works in a display text man , but if you were to put an integer value in a change attribute that would be different , this is why I was saying changing position from real to integer would be a problem ! I got you now but I was referring to constraining and changing attributes.
You could always have a real number as the variable type, which stores an integer and a setting for the designer to set with a choice of "Display XY Coordinates as Real or Integer?" Radio 1 = Real, Radio 2 = Integer.
It would make it an option based on how people want to work rather than locking people into a specific style they don't necessarily like.
Comments
@Socks Ohhhh ! now I get what you mean ! but that only works in a display text man , but if you were to put an integer value in a change attribute that would be different , this is why I was saying changing position from real to integer would be a problem ! I got you now but I was referring to constraining and changing attributes.
I have to add my $0.02 here. It's wonderful to see such quick revisions to the software based on user needs. And it's unusual. Many of these things have been requested repeatedly for years with no response or "we can't do that." It's great to see that that's no longer the attitude. I agree that it makes a huge difference to have these "little" fixes. In one day of using GameSalad, I might click a few thousand times because of windows not remembering their position and size, default font color being white, lack of actor/asset folders, etc. It adds up quickly and gets tedious quickly.
I know I'm not saying anything that hasn't been said a bunch already in this thread but... THANK YOU. Great to see progress being made!
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
@pHghost yea this is what I mean the return result , that is why I was confused with what @Socks is saying , i might have explained it wrong
So, the changes made to the position values and such are editor changes only. There won't be any difference to anything you do at runtime. If it worked before it'll work after the new version.
Good !
Not at all ! It works with everything except for the storing of values (so writing a value into an attribute or table).
Change attribute changes an attribute !! You are storing a value !
Imagine a star shaped plastic box and some Play-Doh . . . I am saying you can make the Play-Doh into any shape you like, but you are saying 'every time I squeeze the Play-Doh into my star shaped box it comes out looking like a star ?' . . . of course !
Change attribute moves the defined value into that attribute, if that attribute is an integer this will round the number.
It wouldn't be a problem at all !
Constraining an actor's Y position to, for example, a sine wave (even if the sine wave's changing values passed through non-interger values) and even if the actor's position is defined as an integer value - would not be a problem at all.
@Socks I see , I understand now , but why most of the tutorials on gamesalad and other game engines always use float ( decimals / real) instead of integer when they are playing with position if it is not a problem , they say it affects precision and movement becomes less smooth if it was an integer, if the actor is not moveable they use integer but if its moveable they use real or float. Now based upon that , I was worried when I read that position would change into integer, this is the reason that made me discuss this.
I was extracting a value (regardless of real or integer) and performing a process on that value, and using that result . . . . you were extracting a value, performing a process and then storing that value (in a container that couldn't accommodate it) and then re-extracting that value and using the result (with the result being effected by you first moving (modifying) the value).
Try this . . .
Make an iPad landscape project.
Make an actor with an integer attribute, let's call it AAA.
Now give this actor an Interpolate behaviour.
Interpolate AAA from 0 to 1024 over 100 seconds.
Now give this actor a Constrain behaviour.
Constrain the actor's X position to AAA
Also give this actor a Display Text behaviour, display AAA.
. . . . . . .
Notice that the integer attribute called 'AAA' happily displays sub-pixel (non integer) values, this directly relates to your original question, attribute definitions only relate to stored values, the Interpolate behaviour doesn't 'know' that it is interpolating an integer or a real value.
It's great that GeorgeGS is being let loose to address the issues brought up in this thread... In the space of a few days tinkering on small changes the software is going to have made bigger advancements in useability and productivity than in it has in ages...
Thankyou @GeorgeGS for being the new guy that's brave enough to tackle things... and thankyou to @Codewizard and the rest of the team for letting him, and helping him.
It's a big win for everyone, and although it might have seemed a bit heated and confrontational at times, I hope that everyone understands that it's just because we're passionate about using the software and seeing it, the team, and us the users succeed.
But yup.. For me personally, I feel like we've turned a corner... Longstanding issues have finally been acknowledged, and were heading in a better direction together.
It's a team effort, and everyone deserves a pat on the back... but I think GeorgeGS might be on his way to earning himself a bit of a fan club....
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
No, you explained it clearly enough, don't beat yourself up about it. Socks usually explains everything to the most minute detail, which is often great and that's why his input is often the best out there. But sometimes people just want a simple, straightforward answer and get confused by the amount of his words instead.
Is there an example of someone making this case that I could take a look at ?
@Socks
What @Icebox1910 is referring to was his understanding of a position system which would be purely integer based. If that was the case, and no float positions were possible, it could truly create jerky movements.
+1
I searched this issue on another forum with a different engine im not sure if it would be alright to put the link here, but there is a tutorial on youtube by @The_Gamesalad_Guru that explains how locking two actors position using integers instead of real would be a problem. its in minute 10:42
this made me think that there would be a problem if it was integer instead of real ! This is why I wanted explanation
because in my game it is a platformer and im constraining feet actor to the player actor, so if it was integer it would lag based on what I understand
"pHghost, honestly !@#$% off" Ruskin
A generally applicable piece of advice would be to make the conversation about the subject/the question, rather than the person, no one (perhaps besides you and me and my dear old mum) are interested in what you think about my approach to answering questions (as good or as bad as it can be at times), you can't really go wrong with sticking to the subject matter instead of attempting to politicise questions as a personal issue. Quoting Ruskin too ! lol.
In GameSalad 'float' positions are possible.
yea float position is possible because float is known in gamesalad as real ! now by eliminating real from position and changing it into an integer that would make float impossible right ?
I give up ! lol
Sorry I was not able to explain myself better, but with lofty judgemental quote mining from Ruskin (not from you!) I'm outta this thread, try some of the experiments I suggest above, hopefully that will give you a better understanding of the underlying issues at play here, but the bottom line is that if (even accepting it's vanishingly unlikely to happen) actor poisons were stored as integer values it would have zero effect on how those values are processed.
Which of his works was that one in? I have trouble locating it.
Yes, we all know that. @Icebox1910 was referring to a hypothetical situation mentioned, and expressed valid concern.
Here is are the statements that likely set the stone in motion; for your reference:
and:
Here is the actual question:
"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 ? if it was integer instead of real ?
@Socks
Yes, correct. And the first part of his question directly quotes the post of @jonmulcahy so that's ultimately the root reference (and the context).
Which is why his question was entirely valid. If the position system truly were all-integer, his worries would come to life.
Ok . . . . . but . . . . ?
Has anyone in this thread, or anywhere else, said his question was not valid ? As you were busying yourself attempting to introduce a personal dimension into this thread, making me (and your own personal views about my presentation style) a point of conversation (as well as inanely posting comically judgemental Ruskin quotes) I was happily engaging him in his question, it's clear we've had a disagreement in the past, attempts to drag it into other areas are pointless, give it up.
@Socks
I'm not interested in another off-topic conversation where you twist other people's words.
I only pointed out that you were confusing him more than anything else, which you can read back and see, it got to the point where he was doubting whether he was asking correctly. I (likely unsuccessfully) tried to make a joke by saying you are doing it (confusing him) intentionally, thinking it might resonate with your British sense of humor. Sorry, my mistake.
Your reaction to that was telling me to f-off. And now you say I'm being personal?
Anyway, I'm not discussing this further and derailing another thread. We've had a disagreement in the past, and if you cannot let bygones be bygones, I'm really sorry.
Yes, please !@#$% off and stop trying to pursue an old argument and yes you needlessly made this conversation personal (again).
"I'm being personal?"
Yes, absolutely, unambiguously, we've recently had a (forum) falling out, so (presumably) we are both alive to the particular tension that causes . . . . . so you make your opening gambit to me in this thread: '@Socks it does feel like you are intentionally trying to confuse him'.
Lol, seriously, you start a conversation up, having come from a previous argument, with another of your silly admonishments . . . and then struggle to see the personal nature of this ?
So, yes, me and you have had a disagreement in the recent past, you have let it bother you to the extent where you feel the need to find an opening to resolve some still-held tensions (all amateur online psychology on my part, admittedly), so that's all quite understandable, we're all human, I do it myself, but let's not make Icebox1910's question the battle ground and leave it there shall we ?
If you still feel you need to get stuff off your chest then PM me.
I don't think you should change position to integers. As when you have an accelerating actor at a very slow acceleration that makes it's velocity fractions of a pixel, you want the position accumulate these decimals over time so that actor actually moves.
for example if
your position x is 20.0 and linear.velocity is only 0.3 you want position to accumulate to 20.3 and then 20.6 and 20.9 and so on...you don't want it to have no effect on position.
If this were to change to integer, your position x will not change as 20 + 0.3 converted to integer will still be 20 so it'll never actually move.
I know 7 people agreed to the above change but really think about what's going to happen, if positions are integers, then velocities will be pointless being reals so they have to be integers too..since new position is calculated by current position + velocity.
Would you really want that? movements won't be as smooth.
@tintran the positions are only snapping to an integer when you place them on the screen. When they move in the game they will still move the same. Acceleration will still work the same objects will move fluidly through decimal points.
When dragging a object on to the screen in editor it is nice to have them snap to an integer. So you can line things up nicely when doing level design.
www.rossmanbrosgames.com
So you're asking for GUI snapping to whole numbers for example rounded to the nearest integer, and for example if you hold down control and drag then they snap to nearest 10 or increments of 10 from original position..
I am all for that.
Just not actually changing the type of position.x and position.y to integers because that will break it because then velocities will also turn into whole integer pixels and so will acceleration and that would be really bad.
@tintran correct, it only affects placing actors into a scene in the editor. Gameplay won't change at all.
www.rossmanbrosgames.com
You could always have a real number as the variable type, which stores an integer and a setting for the designer to set with a choice of "Display XY Coordinates as Real or Integer?" Radio 1 = Real, Radio 2 = Integer.
It would make it an option based on how people want to work rather than locking people into a specific style they don't necessarily like.