Digital Workshop

Thanks, Mack.

Progress adapting the actions as script substitutes. Using 1 Simultaneous, with 2 loops, each with consecutive actions where needed.

But, cannot figure out how to substitute an action for the following 3 from the original script:

(1) Vector8.Scale(.5,.5, bar2*.3)

(2) Vector8.Scale(-.5,-.5, bar2*.6)

(3) if (breakLoop) break

Have put each into its own script object for now.

But, when previewing in Opus, am getting "fatal runtime error." (Oddly, the animation will still work, but the script window is showing the "fatal runtime error." Can't figure out what to change to prevent the error.) When I publish to Flash, no more publication conflicts in the log ("fork" and "wait" are no longer used). But, the published animation runs much too fast in the Flash player (player 10).

Kind Regards,

I have forgotten most of what I knew about standard actions
I do recall there was a variable changed Trigger.
Also, I remember playing with some animation actions in a way that did smaller, incremental movements -- repeated in the equivalent of a WHILE loop. The Loop terminates when count EQ a variable. Re-trigger action for reverse direction, the same way in a loop.

Fred posted a great example/how-to on using Select/CASE in std actions. viewtopic.php?f=6&t=2822&hilit=case or other posts.

- - - - - - -
And here's an off-the-wall alternative.
I have used one of the preset animations (eg, Bounce) at a fixed speed, and combined that with Collision Enter which effectively incremented a counter. Can stop animation when counter reached a certain value (or >= a variable's value). It acted like a metronome... beats per second.
A variation of this is to have Obj A moving in one direction only, and an Obj B that will intersect or collide -- simply Set Position or Move Obj B a variable Distance from the starting point. That changes the timing. Use the Collision detection trigger to restart, or perform some other action.

Where is bar1 declared?
Are you dividing by 'undefined'?


Hyperventilating? --Have them breath into a paper bag.

Hi Larry,

bar1 is a number representing breaths per minute and has a default value of 10, each taking 6 seconds. There is a text input box tied to bar1 so the user can alter the starting breaths per minute (the length of the exercise is also set at a default value of 15 minutes but can be altered by the user using another text input box).

With using mostly standard Opus actions in Flex, the preview in Opus of the animation runs at the correct speed. But published to Flash (player 10), the timing is off: faster in and out for breaths, demonstrated by a quickly expanding/contracting animation that doesn't reach full size when expanding.

Part of the challenges faced in trying to "translate" this from Pro to Flex, is that the breathe cycle needed is twice as fast in as out, with approximately 100 ms pause between in and out (formula is .3 to .6, with .1 between), and the cycle needs to slow, decrementing breathe per minute (bpm) by 1 until 6 is reached after which the exercise continues at 6 bpm until the time length of exercise is reached.

This works flawlessly in Pro using script, but "translating" this into Flex has been difficult. So far, it is not working adequately.

(I wanted to do this Flash conversion for one person who needs the exercise and would not be able to view it on a Windows computer, but would need to view in an Android platform thereby needing the exercise to be in Flash. Just may not be possible.)

Kind Regards,

RAOTFL You get an A+ for creativity. Of course, if you want an incremental counter, just add a ticker action. It's just not as much fun!

Mack

Hi ,

Can see if I can substitute a ticker to decrement.

Still not sure what is causing the difficulty when published in Flash. But that "fatal runtime error" in the script window when previewing in Opus must mean something.

Kind Regards,

Yeah, probably that you broke it

1. Add ticker with incrementing variable.
2. Add variable of fixed value for upper limit
3. Calculate different between 1&2.

The difference will decrease overtime.

Mack

Mack, how true. I think when I was playing with that back when, I had a drag/drop slider to give the User an analog control (played with both GetPosition to set-value, and the Collision detect). Probably can be adapted for sci-fi, to illustrate an accelerating runaway warp-core.

Stephen:
If you are sure you do not have naming problems or duplicate names with Objects and variables, also check as Case Insensitive (for Flex).
You can try putting Debug statements every few lines to see how far your script gets. Try the below. Just paste the same Debug.trace statement and it will count up for you.

You may have to open/view the Debug pane back inside the Opus editor.

Hi Larry,

I've checked and checked including naming, etc, but nothing is fixing that fatal runtime error or the timing in the published Flash version.

Since, I'm using standard actions, I no longer have a script page to run a debug script in, just a few small script objects where I couldn't devise a substitute action. Not sure if I can debug in these or how to do this?

I'm beginning to think that given the complexity of the original script, based on the complex requirements of the pub to mimic breathing, allow for user input to set the pace and exercise length and then pace to decrement and slow it down (but not below a certain level), there may be no way to re-create this in Flex and not throw errors.

This is a tough challenge.

Kind Regards,

Throw in a large Caf-Pow and Killer Wobot and we'd be labeled for life.

Now where did I put that sonic screwdriver?

Mack

Yeah Mack, 'special effects' today vs. yesterday are a different animal.

Maybe what you are saying is 'yes the animation can be created in standard actions for a Flex type' HOWEVER when published the timing is off in the Flex/Flash player? Maybe it would be possible to give the User a calibration or adjustment dial. Or create a more elaborate calibrating scheme to derive an adjustment factor off of a test against the system clock time.

Hi Larry,

Yes, maybe some mechanism could be created to let the user change the speed. But, I still haven't eliminated the "fatal runtime error."

In this case, using standard actions which theoretically should work, creates an overly complex and large set of simultaneous, looped and consecutive actions, which don't quite mesh.

In any event, other more pressing tasks have, for now, replaced this one.

Kind Regards,

Certainly adds more thoughts to the complexities, possibilities and requirements of developing within other frameworks that has been raised elsewhere on the forum.

Mack