@LumpApps said:
Now it is almost a game (Sorry, can't help myself)
That's so funny. I'll sometimes find myself just playing with a new idea too and end up with a fun playable 'game thing' before it's all over with. I guess maybe that is a testament to how easy and fun Gamesalad can be...
A way around it is to put a timer with 0.0 run to completion on the change attribute. This is how i've worked around these issues for a while. My theory is that interpolate is working to a number by going 0.01 to 149.99999 like it does, and the rule is interpreting it logically as 150. Then once it really is a whole value of 150, it already made that true, no reason to do it again. A timer delays the calculation long enough for it to hit on the next logic iteration when the interpolate truly ends.
@RondoRocket said:
have u tried tossing a timer in the rule? After 0.01 secs change size.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
@BBEnk said:
I think it as something to do with timing if you put the change attribute in a timer and say after 0.01 seconds then change size to 100 it will work, or at least does in 11.1.2.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
@timolapre1998 said:
add a timer. after 0 seconds change width to 100 also works
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
@natzuur said:
A way around it is to put a timer with 0.0 run to completion on the change attribute.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
. . . .
This thread = "You could use a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "Maybe you could use a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "Have you thought of using a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "A timer should do it" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . .
@natzuur said:
Aha! But you haven't told us why it won't work with a timer of 0.
Lol, I think the first thing I tried was a 'after 0 seconds' timer - weirdly the results were inconsistent - basically it didn't solve the issue (all these tests were dragged back to 0.9.0 where there worked just fine).
Change Attribute: self.goal To: 300
Interpolate: self.size.Width To: self.goal
When self.size.Width > 299.5
Change Attribute: self.goal To: 100
I think that's one of the first workarounds I tried, to move the target size into an attribute, it still suffered the same problem if I remember correctly (?) . . . . but thanks for the input, appreciated, I'll give it a go right now . . . .
I saw it the first time I watched it. And I even kinda snickered a little bit.
Then I felt bad for snickering and decided to just send a demo and let it go. (No need to embarrass anybody when I had already got my jollies off of snickering.)
I saw it the first time I watched it. And I even kinda snickered a little bit.
Then I felt bad for snickering and decided to just send a demo and let it go. (No need to embarrass anybody when I had already got my jollies off of snickering.)
Lets see if others can find the 'mistake'.
Let the contest begin!
It actually took opening up your project alongside the one I made for the video and looking at them side by side before it finally registered !
Anyhow, thanks for the input, hopefully GS can get this bug sorted out at some stage.
@RThurman said:
You are welcome. Will it work for your project?
No, lol Well actually it would work but would involve me redoing a lot of things, I'm going to take an entirely different route involving animation now, but I appreciate everyone's input - the issue brought me to a stand still, at least we now know it seems to be a bug rather than poor logic.
I wonder in how many other circumstances this particular glitch causes issues, for example I often get rid of spawned objects by fading (interpolating) them to alpha.0 and then use a rule that checks for alpha.0 and if true then the actor is destroyed, for all I know this glitch might mean they are not actually being destroyed, which would, over time, mean you have lots of unused actors still being handled by the processor (which you wouldn't be aware of as they are not visible) which would lead to a decrease in performance - might have to do some tests when I am back at my computer . . .
Bummer! I was hoping it would be a simple work-around for your project.
In terms of testing alpha.0 actors to see if they are actually destroyed -- you can put a display text behavior on them. Text shows even when an actor's self.color.alpha is set to zero. (I'm sure you know this. But subsequent readers may not be aware of this subtle 'feature' and how it can be used for testing.)
@Socks I think your problem was that you made GOAL capitalised which made you super-excited to use it.
I'd recommend using a timer, it should solve your problem.
In all seriousness, I'm curious as to why @jamie_c's suggestion of using a constrain attribute isn't any use. In practice it's doing the exact same thing in exactly the same way. Maybe I missed your explanation in the thread, but I'm assuming there are other considerations?
Whatever the case, definitely looks like a bug to me. I experimented a bit and it definitely seemed to be that the interpolate was over-ruling the attribute change. It'll allow the height to be changed in that rule without problem, so it's not that it can't tell when it reaches 300, or that the interpolate isn't "finishing". It just seems to be come super-attached to the attribute it changes and the size it changes it to. Putting the interpolate in a rule that disables it once the desire size is reached doesn't help either. Will be very interested to see what the GS say about the cause Wonder if it's a simple or horrendously complicated problem to fix.
@RThurman said:
In terms of testing alpha.0 actors to see if they are actually destroyed -- you can put a display text behavior on them. Text shows even when an actor's self.color.alpha is set to zero. (I'm sure you know this. But subsequent readers may not be aware of this subtle 'feature' and how it can be used for testing.)
Yeah, I did a test earlier and used exactly this method, and I can report all is well - the actors are destroyed.
I also learned that the issue only effects attempts to modify an attribute that has just been interpolated . . .
So - as we know - if you interpolate size, then when the actor arrives at the target size you use this to trigger a change attribute which changes the same attribute (size) it will fail . . . it's the same deal if you were to interpolate the alpha channel to 0 - if you try to use a rule that looks for alpha equalling 0 to trigger a change to the alpha channel it will also fail . . . .
Which would explain why interpolating the alpha channel to 0 - and then looking for alpha equalling 0 to destroy an actor works just fine.
Interpolate A - target value reached triggers a change to A = fails.
Interpolate A - target value reached triggers a change to B = works.
@Armelline said:
Socks I think your problem was that you made GOAL capitalised which made you super-excited to use it.
I thought that might the case too so I drank 2 bottles of red wine to calm me down, it didn't seem to help.
@Armelline said:
I'd recommend using a timer, it should solve your problem.
. . . 3 bottles of wine . . .
@Armelline said:
In all seriousness, I'm curious as to why jamie_c's suggestion of using a constrain attribute isn't any use. In practice it's doing the exact same thing in exactly the same way. Maybe I missed your explanation in the thread, but I'm assuming there are other considerations?
There are other considerations, I could tell you what they are but then I'd have to hunt you down and kill you, which I have neither the time nor budget for right now.
@Armelline said:
Whatever the case, definitely looks like a bug to me. I experimented a bit and it definitely seemed to be that the interpolate was over-ruling the attribute change. It'll allow the height to be changed in that rule without problem
Yep, the problem only occurs when trying to change the same attribute you have just interpolated.
@Armelline said:
Attached is a project commemorating this thread.
Comments
Not at my Mac right now, but I'll take a look later, cheers for your input (and to everyone else as well) - appreciated (and awesomed !).
I've stuck it in the Public Bug Database.
Now it is almost a game
(Sorry, can't help myself)
Lump Apps and My Assets
That's so funny. I'll sometimes find myself just playing with a new idea too and end up with a fun playable 'game thing' before it's all over with. I guess maybe that is a testament to how easy and fun Gamesalad can be...
http://jamie-cross.net/posts/ ✮ Udemy: Introduction to Mobile Games Development ✮ Learn Mobile Game Development in One Day Using Gamesalad ✮ My Patreon Page
Agreed
Lump Apps and My Assets
A way around it is to put a timer with 0.0 run to completion on the change attribute. This is how i've worked around these issues for a while. My theory is that interpolate is working to a number by going 0.01 to 149.99999 like it does, and the rule is interpreting it logically as 150. Then once it really is a whole value of 150, it already made that true, no reason to do it again. A timer delays the calculation long enough for it to hit on the next logic iteration when the interpolate truly ends.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
Cheers for the input, I'm sure there are numerous workarounds, but unfortunately the way my project is set up I need it to work as shown in the video.
. . . .
This thread = "You could use a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "Maybe you could use a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "Have you thought of using a timer" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . . "A timer should do it" - "Unfortunately the way I have it set up wouldn't allow a timer like this" . . .
Lol !
[runs out and registers FlappyBlocks as a trademark]
Aha! But you haven't told us why it won't work with a timer of 0.
So... Have ...you.. tried .. using a timer?
(Runs and hides and waits to see if Socks finally cracks)
That's a good idea @StormyStudio
@Socks, have you tried this?
It's ok, I've been on a 50%/50% alcohol/chicken-soup intravenous drip since around 7.30pm.
Do I at least get credit for being the first to suggest the timer idea?
Twitter:rondorocket
Web: rondorocket.com
. . . . slowly edges the chicken/alcohol ratio dial away from chicken . . .
That sounds like a maybe to me!
Twitter:rondorocket
Web: rondorocket.com
Here is yet another workaround:
I think that's one of the first workarounds I tried, to move the target size into an attribute, it still suffered the same problem if I remember correctly (?) . . . . but thanks for the input, appreciated, I'll give it a go right now . . . .
I can't get it to work !?![:\](http://forums.gamesalad.com/plugins/emojiextender/emoji/twitter/confused.png ":\")
Maybe I am doing something wrong, I'll make a video . . .
@RThurman
Here you go, I'm not able to reproduce your code (and make it work).
Works for me!
Whoops, check out my video, see if you can see my obvious mistake !
Yes, your version works fine, thanks for the upload.
Yes, yes
I saw it the first time I watched it. And I even kinda snickered a little bit.
Then I felt bad for snickering and decided to just send a demo and let it go. (No need to embarrass anybody when I had already got my jollies off of snickering.)
Lets see if others can find the 'mistake'.
Let the contest begin!
It actually took opening up your project alongside the one I made for the video and looking at them side by side before it finally registered !
Anyhow, thanks for the input, hopefully GS can get this bug sorted out at some stage.
You are welcome. Will it work for your project? Or do we continue to search for a solution that works for you?
No, lol
Well actually it would work but would involve me redoing a lot of things, I'm going to take an entirely different route involving animation now, but I appreciate everyone's input - the issue brought me to a stand still, at least we now know it seems to be a bug rather than poor logic.
I wonder in how many other circumstances this particular glitch causes issues, for example I often get rid of spawned objects by fading (interpolating) them to alpha.0 and then use a rule that checks for alpha.0 and if true then the actor is destroyed, for all I know this glitch might mean they are not actually being destroyed, which would, over time, mean you have lots of unused actors still being handled by the processor (which you wouldn't be aware of as they are not visible) which would lead to a decrease in performance - might have to do some tests when I am back at my computer . . .
Bummer! I was hoping it would be a simple work-around for your project.
In terms of testing alpha.0 actors to see if they are actually destroyed -- you can put a display text behavior on them. Text shows even when an actor's self.color.alpha is set to zero. (I'm sure you know this. But subsequent readers may not be aware of this subtle 'feature' and how it can be used for testing.)
@Socks I think your problem was that you made GOAL capitalised which made you super-excited to use it.
I'd recommend using a timer, it should solve your problem.
In all seriousness, I'm curious as to why @jamie_c's suggestion of using a constrain attribute isn't any use. In practice it's doing the exact same thing in exactly the same way. Maybe I missed your explanation in the thread, but I'm assuming there are other considerations?
Whatever the case, definitely looks like a bug to me. I experimented a bit and it definitely seemed to be that the interpolate was over-ruling the attribute change. It'll allow the height to be changed in that rule without problem, so it's not that it can't tell when it reaches 300, or that the interpolate isn't "finishing". It just seems to be come super-attached to the attribute it changes and the size it changes it to. Putting the interpolate in a rule that disables it once the desire size is reached doesn't help either. Will be very interested to see what the GS say about the cause
Wonder if it's a simple or horrendously complicated problem to fix.
Attached is a project commemorating this thread.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yeah, I did a test earlier and used exactly this method, and I can report all is well - the actors are destroyed.
I also learned that the issue only effects attempts to modify an attribute that has just been interpolated . . .
So - as we know - if you interpolate size, then when the actor arrives at the target size you use this to trigger a change attribute which changes the same attribute (size) it will fail . . . it's the same deal if you were to interpolate the alpha channel to 0 - if you try to use a rule that looks for alpha equalling 0 to trigger a change to the alpha channel it will also fail . . . .
Which would explain why interpolating the alpha channel to 0 - and then looking for alpha equalling 0 to destroy an actor works just fine.
Interpolate A - target value reached triggers a change to A = fails.
Interpolate A - target value reached triggers a change to B = works.
I thought that might the case too so I drank 2 bottles of red wine to calm me down, it didn't seem to help.
. . . 3 bottles of wine . . .
There are other considerations, I could tell you what they are but then I'd have to hunt you down and kill you, which I have neither the time nor budget for right now.
Yep, the problem only occurs when trying to change the same attribute you have just interpolated.
Lol ! Excellent