[F8] What is run, how and when?

[Clownfish5]

I have done a little coding in AS2 now, so I should now this, but I need someone to clear things out for me.
I've only been writing code in the first frame of the main timeline, in classes and occasionally in movieclip frames. But as I realize that it's common to write in several frames of the main timeline, it makes me wonder about the order in which things are executed... I know it's not run top down, but on many sites in parallell, but still - confusing.

I tried making a stop() at the first frame, and move it over to frame 2 and stop by the press of a button. Cool. So, it seems like it would be able to start anew on a new frame, go on with you life, so to speak, or stay and pause the game, and then go back. BUT, then I put a onEnterFrame function in frame 1 and it seems that THAT is executed all the time, even when stopped on frame 2. I guess, so would movieclip code be...

So, what are the rules for how this works? What is linear and what isn't? If the onEnterFrame ALWAYS will happen, even when not in the frame where it's written, similar problems like the classic pause-problem must arise when you want to go back to menus, game over screens, info screens and such? (and must be solved by a couple of booleans?)

[Ray Beez]

pause state should be a flag like

var gamePaused:Boolean;
gamePaused = false;

And important stuff that runs continuously then should check that flag.

everything is linear though, except onEnterFrame because that is meant to run every frame in the timeline it exists on (if that makes sense). What I mean by that is that yes, in frame 2 it still works, but if you were to define a NEW onEnterFrame in frame 2, it would REPLACE the previous one. Can't have both.

However if you created a new onEnterFrame inside a movieclip, then both would be running because they aren't in the same "scope" (not sure if that's the right term or not).

[Clownfish5]

Thanx, that all makes sense!
The fact that a new onEnterFrame OVERRIDES the other one was good news!
So, if you wanna have different parts of your game, info screens, menus etc, is this how you do it?:
frame 1:

stop();
trace("here")
gothere_btn.onPress = function () {
	gotoAndStop (2);
}
onEnterFrame = function () {
	//here-stuff
}

and in frame 2:

trace("there!");
goback_btn.onPress = function () {
	gotoAndStop (1);
}
onEnterFrame = function () {
	//there-stuff
}

[renderhjs]

But as I realize that it's common to write in several frames of the main timeline, it makes me wonder about the order in which things are executed... I know it's not run top down, but on many sites in parallell, but still - confusing.

bad practice imo. reminds me of the cluttered director days (timeline action all the way). My suggestions is to use as less frames as possible and rather structure your logic in classes and functions, if possible

also regarding order
the way flash was invented it was meant to stream everything which means that just like a casette or old tape things get loaded linear and can be played back as soon as it´s downloaded (progressivly) on the client´s computer.
This means that even though your whole flash movie is not yet completely loaded you can already access those frames on the main timeline that are already loaded.
In actionscript you have the properties of ._framesloaded and ._totalframes (back from the old flash 2/3 days) with those you can check which parts of the main timeline have already been loaded.

In general the execution and loading order is:
- top to down - layer
- first to last frame on the main timeline

There was something about scenes - but all I can remember is that it was basicly all merged with the main timeline and by todays practice total garbage to use - so stay away from scenes.
With Flash 4 and 5 Actionscript became a far more important part and its became possible to write actionscript linked to movieClips and with Flash 6 even to the _root level - and now with AS3 to far more object types.
But what that means is that whenever you access something with _root for example it stands in relation with the _root level and not the frame you are on.
so if you say on frame 2

_root.favouriteFood = "sushi"; 

you can still read out that variable in any other frame that comes after that, like frame 99:

trace("food I like : "+favouriteFood); 

So, if you wanna have different parts of your game, info screens, menus etc, is this how you do it?:
frame 1:

make sup parts in your onEnterFrame function - why the xtra 2 onEnterframe events (if it were possible it would slow down the movie alot.
do it for example like this:

function frame1loop(){
    //here-stuff
}
function frame2loop(){
    //there-stuff
}
_root.onEnterFrame = function(){
    var f:Number = _root._currentframe;
    if (f==1){
        frame1loop();
    }else if(f==2){
        frame1loop();
    }
} 

[Clownfish5]

Thanx for explaining, renderhjs! The tape analogy helps me understand how I guess the preloader concept works (haven't dug into that yet).

I agree, your code for two frames look much neater than mine, even though mine works too. As Ray Beez said, if there is an onEnterFrame in the current frame, it overrides any other, so it would not necessarily slow down anything. But as I said, it looks cleaner your way.

You said code in several frames were bad practice. Even if you ONLY put code and no graphics in the frames? I know some people organize it like that for clarity, separating inits, main loop, certain functions etc. Or would you spread that over layers instead?

[Ray Beez]

I still organize code into seperate frames for stuff like menu, game engine, game over etc when it suits me.

Or I split those up into movieclips and then the entire flash movie is 1 frame...

[renderhjs]

I don't know about other flash devs, but I usually leave the first frame empty. The reason for this is to prevent the heap of the flash player getting blown by content that already consumes CPU. Like warming up a car-engine before using it to its fullest.
At least on flash lite this proved to be effective so that the system wouldn't get any hick ups at first - because it couldn't choke all the commands that came at first - or address the data to be processed.

Steps after that empty frame are usually loading dynamic content (textures, xml, sounds,...) and then a initialize stage where all important matters are prepared followed by a go for the engine loop.

[Squize]

A bit of a boring but true statement, you should always leave the first 5 frames blank.
Sometimes Flash will just choke with content on those frames ( I remember a lot of F5/6 sites would fail to load back in the day ). It's something I picked up from a Moock article years ago and have always stuck with it.

That's another reason why I put my preloader in it's own scene at the start, as with those blank frames and a frame here for your logo and a frame there for your attached assets, you don't want to be working from frame 8 or so when you can just shove it all in it's own scene out of the way and then your main code starts at scene 2 frame 1 ( It just feels neater to me, looking at what you actually need rather than everything ).

Squize.

[Clownfish5]

That sounds strange and hard to believe, but I guess I'll have to trust you gurus! Why is that really? I mean, would Flash choke because it's compiler engine and all needs CPU the same milisecond as it executes code? I would have assumed that if the frames are empty, the following code will be read in the next instant anyway.... but of course, it waits 1/fps s per frame....

[Squize]

It's just Flash being Flash.

I managed to find this:
http://www.moock.org/webdesign/flash/productiontips/
( Point 11 )

It's quite dated now, but a lot of it still holds true. I don't know where the more detailed "Leave blank frames" is that I read, it may even have been in one of his great books.

Squize.