A cactus in the backside

[stam]

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 )

[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

[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.

[stam]

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...

[stam]

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

[richmond62]

-
Click anywhere on the stack . . .

https://www.dropbox.com/s/pi4e6zh2isebi ... e.zip?dl=0

[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.

[jiml]

Stam,

Here's the link to Cel Animation
http://livecodeshare.runrev.com/stack/857/Cel-Animation

JimL

[jiml]

This, though old, may also be helpful.

Code: Select all

go stack url "http://netrin.on-rev.com/animateimage/roach3.livecode"

[stam]

Stam,

Here's the link to Cel Animation
http://livecodeshare.runrev.com/stack/857/Cel-Animation

JimL

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

Code: Select all

 put "" into lAnimationData

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?

[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.

[stam]

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