onEnterFrame function null on frame c hange

[congruent2006]

this is going to sound lame but,
My movie clip when it is in "battle" goes to the second key frame which is the attacking frame,
but then the on EnterFrame function on keyframe one does not work anymore, he does not lose life, amung other things he is supposed to do. what is the way around this?

[Pazil]

You shouldn't put onEnterFrame's on keyframes inside other clips. It sort of defeats the purpose of writing code in a keyframe at all. It's better to do all coding on the root keyframes. That should also solve you're problem then...though technically from my experience, it should still work even after a keyframe change...weird...

[congruent2006]

If you cant put onenter on an MC how are you supposed to do things like have multiple mcs walk towards the Player MC via rotationmydegrees x y blah blah blah.

Oh well, Guess I will have to figure it out.

[ImprisonedPride]

If you cant put onenter on an MC how are you supposed to do things like have multiple mcs walk towards the Player MC via rotationmydegrees x y blah blah blah.

Oh well, Guess I will have to figure it out.

When you attach your player/bullet/tile mc, define it's onEnterFrame like so:

var char = _root.attachMovie("char", "char", _root.getNextHighestDepth());
char.onEnterframe = function() {
// anything in here is in scope of the char mc, not the _root
dx = this._x - _root.something._x;
dy = this._y - _root.something._y;
// do some math and move this thing towards something else
}

Note that the onEnterFrame of the char won't actually run until the NEXT frame.

[congruent2006]

Ok, that works, now how do you assign vars to each MC, giving them their own stats if you will,
like the way you have a var before the on enterframe. does that make sense?
so if i have a var that changes i dont have to say
if (switch==false){
stat = #}
if (switch ==true){
stat -= 1}

[Jephz]

Like pazil said, its always better to code on _root. as your code will be much cleaner and easier to find rather then surfing through hundreds of movieclips.

It is very possible to have "multiple mcs walk towards the Player MC" etc. code on _root.

[congruent2006]

Know any tutorials then?
All of the tutorials I have ever seen have onenter functions on the Mc,s
in fact when I asked about it last week noone even knew how to make multiples of an MC much less how to make them move, give them stats, and what not.

[ImprisonedPride]

The same way you target an mc's variable when you want to use it.

var char = _root.attachMovie("char", "char", _root.getNextHighestDepth());
char._x = 50;
char._y = 100;
//etc

[Pazil]

Or what you can do is add the MC's to an array, and then with a for loop you can cycle through the array each frame, and apply the same function to each. I think it saves memory, as well it's a lot easier to manage. For example, if you want to have bullets and enemies. When creating them, you of course give each the required properties, and then you can add each to it's respective arrays.
Then, you know that whenever you loop through the bullet array, they're all bullets in there, and that way you can organize the structure better...meh, that's my opinion.

[ImprisonedPride]

There wouldn't be a reason to use an array. Simply make the function on the _root and then point the onEnterFrame of the mc to the new function, without the () on the end.

function foo() {
// if you use "this" in this function, when it's applied to an mc it'll still work
trace(this._x);
}

var char = _root.attachMovie("char", "char", _root.getNextHighestDepth());
char._x = 50;
char._y = 100;
char.onEnterFrame = foo;

[Pazil]

But if you do that, cleaning up the mess the game makes gets a lot tougher. How do you plan to removeMovieClip() all of them? Using arrays, even if instance names get mixed up, you still have a reference to every single MC, and (for me) just seems a lot more organized.

[congruent2006]

come again Paz?
Not sure what you mean,
Why wouldnt char.name on enterframe function
this.removeMovieClip() not work?

Not quite sure what your saying.

[ImprisonedPride]

Exactly congruent. Pazil, you're only going to remove the clip under a certain circumstance, no? Add an if statement in there to check for game state. If the game is over, have it run this.removeMovieClip();.

[TOdorus]

that's just asking for trouble. I'd rather have every actory in my games go through the first fase in an update and then the next. This way they go through all the fases one by one. You'd be collision checking against stuff that already has a updated movement vector or a outdated movement vector. Pretty inaccurate, not to mention the brute force of having an event per actor.

function update(){
     updateAI()
     updateMovement()
     updateCollisions()
}

[Pazil]

And TOdorus also gave a perfect example of another problem : performing certain functions at certain times in a frame. It's a lot better for organization, and performance, since you can optimize a function because you'll know that when that function's running, at what point the process of all other objects are in...when running a hitCheck, you know that all objects have already moved (depending on your order)...

IDK, from my experience, it's been a lot easier to manage several for loops rather than chasing down Movieclips...

[congruent2006]

this coming from the same guy who was telling me there is no wrong way to do somethinig? :P ^_^

[TOdorus]

this coming from the same guy who was telling me there is no wrong way to do somethinig? :P ^_^

I love nitpicking like that, so here goes

Did he say that any of the mentioned methods was wrong then? I think he did say some methods were: less organized.

[congruent2006]

well something was obviously wrong with my original method BECAUSE MY CHAR WASNT STOPPING OR TAKING DAMAGE because of the animation keyframe ^.^

[Squize]

If you're using multiple instances of anything, be it movieclips / sprites or objects, unless you're using a broadcaster approach to send messages you should store them in an array.
To expect something to tidy itself up is just pushing your luck.

Anyway, this is getting very o/t now.

Squize.

[Pazil]

Ha...weeell, I'm not saying it's wrong...just I find it easier. Also I was talking in more general terms when I said there's no wrong way of making a game...you'll be giving be hell about that every time now!