Page 2 of 2
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 11:52 pm
by stam
bn wrote: Sun Jul 18, 2021 11:49 pm
The correction does not work because of a typo: botton instead of bottom
LOL - should have double checked
Would be nice if the IDE would issue warnings for things like this (not errors but warnings as in other IDEs... would save SO much time debugging
)
Re: A cactus in the backside
Posted: Sun Jul 18, 2021 11:57 pm
by bn
Would be nice if the IDE would issue warnings for things like this (
The IDE cannot warn you since for the IDE you set a custom property. And custom properties can perfectly be named "botton".
But many typos are caught if you turn strict compilaton mode on for the script editor. The downside is you have to declare your variables.
Kind regards
Bernd
Re: A cactus in the backside
Posted: Mon Jul 19, 2021 5:14 pm
by jiml
For a technique that uses a single image containing all the cels of your animation (like the image you posted above), see CEL ANIMATION in Sample Stacks.
Re: A cactus in the backside
Posted: Mon Jul 19, 2021 5:24 pm
by stam
jiml wrote: Mon Jul 19, 2021 5:14 pm
For a technique that uses a single image containing all the cels of your animation (like the image you posted above), see CEL ANIMATION in Sample Stacks.
I wasn't able to find a reference to CEL ANIMATION IN sample stacks (may well be due to my old age!) - can you link?
I did find an interesting stack called 'runner 2009 - basic animation'. Not quite the same thing but useful nevertheless...
Re: A cactus in the backside
Posted: Mon Jul 19, 2021 5:41 pm
by stam
bn wrote: Sun Jul 18, 2021 11:57 pm
The IDE cannot warn you since for the IDE you set a custom property. And custom properties can perfectly be named "botton".
But many typos are caught if you turn strict compilaton mode on for the script editor. The downside is you have to declare your variables.
Hi Bernd - i definitely
always have strict compilation on, having come from strongly typed environments that's a bit a safety i prefer. My right hand tends to touch type just a bit faster than my left(!) and it's not unusual that i misspell things (translocation of letters), so when it comes to variables i prefer this to be on.
Custom props are a bit different as these are not declared and I'll be honest i wouldn't really care to do that in spite of this, as i've gown accustomed to the 'liveCode' way. However, although not that frequent, issues like this occur frequently enough that quite a few hours of debugging have gone into identifying that 1 errant letter that was mis-typed.
Sadly 'warnings' (not errors) don't exist in the liveCode IDE, but it would be nice if it would if say what is perceived as custom property that was only 1-2 letters different from reserved keywords generated a cautionary warning that you could safely ignore/dismiss.
Maybe one day the IDE will cater for both warnings and errors! Until then, it's just me talking nonsense
Re: A cactus in the backside
Posted: Mon Jul 19, 2021 7:55 pm
by richmond62
Re: A cactus in the backside
Posted: Mon Jul 19, 2021 8:26 pm
by jacque
I thought it might be fun to make a universal handler. I agree with Stam that this shouldn't involve any repeat loops, sending a message is the way to go.
Code: Select all
local sFrame
on marchSprite pDirection
if the shiftkey is down then exit marchSprite
put char 1 of pDirection into tDir
-- check if we're moving out of range:
if sFrame > 0 and (the right of grc "ramka" < 0 or \
the left of grc "ramka" > the right of img "B4.png") then
put 0 into sFrame
-- reset position so next iteration will work:
if tDir = "R" then set the left of grc "ramka" to (the right of img "B4.png" - 1)
else set the left of grc "ramka" to 1
exit marchSprite
end if
put (sFrame + 1) wrap 6 into sFrame
if tDir = "L" then put -4 into tStep else put 4 into tStep
lock screen
set the width of grc "ramka" to the width of img (tDir & sFrame & ".png")
set the height of grc "ramka" to the height of img (tDir & sFrame & ".png")
set the backGroundPattern of grc "ramka" to the ID of img (tDir & sFrame & ".png")
unlock screen
move grc "ramka" relative tStep,0 in 12 ticks -- less than this looks jerky on my Mac
send "marchSprite tDir" to me in 0
end marchSprite
The shift key will stop the animation. It will also stop if the boy goes out of range. You can pass either the whole word "left" or "right" as the direction, or just the first letter.
Re: A cactus in the backside
Posted: Tue Jul 20, 2021 4:27 pm
by jiml
Re: A cactus in the backside
Posted: Tue Jul 20, 2021 4:37 pm
by jiml
This, though old, may also be helpful.
Code: Select all
go stack url "http://netrin.on-rev.com/animateimage/roach3.livecode"
Re: A cactus in the backside
Posted: Tue Jul 20, 2021 7:31 pm
by stam
Thank Jim - had a look, that's really very clever!
been looking at the behaviour script (keep in mind i still consider myself a newbie round these parts!)
I was mystified at your code regarding the custom prop "AnimationData"
Code: Select all
set the AnimationData of me to empty
yep, that makes sense
this i found weird - the
lAnimationData doesn't trigger an error with strict compilation on, suggesting it recognises this as a custom property and probably the
AnimationData of me at that.
Is prefixing the custom prop of self with an 'L' a shortcut? i.e. is
lAnimationData == the AnimationData of me in this case?
Re: A cactus in the backside
Posted: Wed Jul 21, 2021 7:58 pm
by jiml
Stam wrote:
the lAnimationData doesn't trigger an error with strict compilation on, suggesting it recognises this as a custom property and probably the AnimationData of me at that.
Is prefixing the custom prop of self with an 'L' a shortcut? i.e. is lAnimationData == the AnimationData of me in this case?
The ''L' just indicates that 'lAnimationData' is a local variable. Prepending an 'L' is just a variable naming convention and is not a requirement.
Also, the data in lAnimationData is script local to a particular instance of the behavior. 'It's the 'working' data, so to speak. The AnimationData of me, on the other hand, is a custom property of the particular animated GROUP. It contains the same data as lAnimationData, but by storing the animation data as a custom property of the group that data can then persist when one leaves the card and then returns. Upon returning one only needs to call "init" rather than recalling "setup". Also the animation data will persist when the stack closes (presuming the stack is saved.)
The beauty of behaviors and custom props allows one to have several animation groups on a card running simultaneously - each with their own independently controlled settings.
Re: A cactus in the backside
Posted: Wed Jul 21, 2021 8:12 pm
by stam
jiml wrote: Wed Jul 21, 2021 7:58 pm
The beauty of behaviors and custom props allows one to have several animation groups on a card running simultaneously - each with their own independently controlled settings.
Ok gotcha - thanks
Clever animation technique, will definitely be using that