Question regarding Blocking and NoBlocking animations... (eNoBlockBackground?)

Started by Snake, Tue 23/10/2007 20:27:19

Previous topic - Next topic

Snake

Is there an "in between" with eBlock and eNoBlock?

Blocking stops executing code until the animation is finished.
No blocking runs the animation and continues with the code.

The problem I've found with eNoBlock is that the animation is cut short when the script continues. This way you are forced to use Wait(1).
Even when using the Wait commands you are still cutting the animation short unless you "up" the wait time - ie; Wait(10);. This of course also posses a problem. While this animation is running (with Wait still waiting until it's done) the player character is "frozen" or sliding until the Wait command is finished.

Here's an example to help explain: I'm using the module for 8 direction movement - hold arrows key(s) to move and let go to stop.
While the player is moving around and a specific animation for a different character (in the case below, it's an object) is to be played - let's say that the player is running as the animation is executed - the player "slides" until this animation is complete. It's quite an annoying and unpolished feel.
Did that make sence?

Here's an example of a code:
Code: ags
if ((object[4].Moving==0)&&(fireball==1)){/////RESET FIREBALL 1
  object[4].Animate(2, 0, eOnce, eNoBlock,eForwards);
  Wait(8);
  object[4].X=character[2].x;
  object[4].Y=character[2].y;
  SetGlobalInt(0,0);
  object[4].Visible=0;
  SetTimer(1,1);
  fireball=0;
  }  

Notice how WAIT is at 8. This allows for the animation to complete (almost all of the way, but good enough for my liking) without being cut off, but of course you can still tell there's a little delay before you can move again or for the player to stop moving.

My initial question here is that is there a code that I'm missing that animates in the background and allows the code to still run without these annoying delays? Could it be a problem with using the 8 direction movement module? Should I temporarily shut it off while these animation are run and then turn it back on?

An eNoBlockBackground would be the best thing ever.

Thanks in advance,


--Snake
Grim: "You're making me want to quit smoking... stop it!;)"
miguel: "I second Grim, stop this nonsense! I love my cigarettes!"

Radiant


Snake

No, I haven't.

I don't want to sound stupid, trust me because I feel stupid, but what is that? I've always just used repeatedly execute... that's all I thought there was :-[


--Snake
Grim: "You're making me want to quit smoking... stop it!;)"
miguel: "I second Grim, stop this nonsense! I love my cigarettes!"

Ashen

Try reading the manual.
Quote
repeatedly_execute_always()
Called every game cycle, even when a blocking routine (eg. speech/cutscene) is in progress. You cannot call any blocking functions from this event handler. You can have a repeatedly_execute_always function in both your global script and in any room scripts where you require it.

So it'd run in the background, even while the game was blocked by the Wait command. (Which you wouldn't be able to CALL from rep_ex_always, so you'd need to split your code in two.) I'm not sure if that'd help here, though.

What's the problem? The player freezes on the spot (but still animates) while another blocking animation happens? Try calling player.UnlockView before the animation - that should stop them animating. And, I guess they still won't be moving - this probably IS a consequence of how the movement module works; as the game is blocked, rep_ex doesn't run to update their position, however it also can't stop their animation as it should. (Actually, you might be able to make the MOVEMENT code run in rep_ex_always, which would solve the problem. But, I'm not sure if that's possible, not knowing the module.)

Incidentally, why are you using a non-blocking animaton, followed by Wait? As you've discovered, the effect is the same except that - unless you get the length of the wait right - part of the animation will be cut off. Depending on the effect you want, you might be able to rearrange the code a little, and eliminate the need for it to block at all, e.g add another variable to say whether the animation had run:
Code: ags

if ((object[4].Moving==0)&&(fireball==1)&&(object[4].Animating==false)){/////RESET FIREBALL 1
  if (hasanimated == 0) {
    object[4].Animate(2, 0, eOnce, eNoBlock,eForwards);
    hasanimated = 1;
  }
  else {
    // WIl run after animation has ended
    object[4].X=character[2].x;
    object[4].Y=character[2].y;
    SetGlobalInt(0,0);
    object[4].Visible=0;
    SetTimer(1,1);
    fireball=0;
    hasanimated = 0;
  }  
}

(Untested)
I know what you're thinking ... Don't think that.

Snake

No no. The player character animations are fine. It's when another character needs to animate that this "freezing" thing happens.

I'll try to explain better:
In this room and others, there is a dragon that spits fireballs. When these fireballs hit the ground an animation is run - fireball "blowing up". It's when this "blowing up" animation is played that there is a slight delay because of the Wait( 8 ); command. So what happens to the player character depends on if the player is holding the arrow key - keeps walking until Wait hits 0. Or the player can't move the character if he pushes an arrow key during the Wait. Did I explain better this time?

If there's no Wait then everything is dandy except that the animation is cut off.
I think what I need to do is do something like what you've given an example of. Make a variable that is tested to see if the animation is done yet. What it's doing is putting the fireball back at the Dragon's x,y coordinates before finishing the animation, hence, cutting it short.

I'll print off the manual and bring it to bed with me tonight and read it. I keep meaning to do that.


--Snake
Grim: "You're making me want to quit smoking... stop it!;)"
miguel: "I second Grim, stop this nonsense! I love my cigarettes!"

Ashen

Quote
So what happens to the player character depends on if the player is holding the arrow key - keeps walking until Wait hits 0. Or the player can't move the character if he pushes an arrow key during the Wait. Did I explain better this time?

So 'sliding' just meant moving (with animation) when they weren't supposed to - like they couldn't stop moving along the same path while the script was blocked, even when they should stop?
Just to clarify, that bit (quoted) is what does happen, and you want to avoid it? Using the variable will probably stop the 'sliding', and should let movement work as normal (the player character can stop if they're supposed to, and can start if they're supposed to). I think I had the cause right, even if I was off on the symptoms - because rep_ex is blocked, the movement module doesn't realise the arrow key has been released, and the characetr should stop moving now (or conversely, that the arrow key has been pressed, and they should start. Making the movement code rep_ex_always probably isn't the answer - there'll almost certainly be times when you WILL want to block keyboard interactions along with everything else.

One more question (I feel like Columbo now) which module are you using - I'd guess Bernie's 8-direction movement one, right? If the variable method works, it probbaly doesn't matter. Just curious...
I know what you're thinking ... Don't think that.

Snake

Yes, Columbo, I'm using Bernie's ;) It's an awesome module and just about pissed my pants when he released it :=

I've just finished the variable idea and it works flawlessly. Now after doing that there's something very wierd happening that I have to figure out and fix ;) If it's not one thing, it's another. I'm sure it's just something simple, like another variable I've forgotten to add when cutting my code in half... <--fixed


--Snake
Grim: "You're making me want to quit smoking... stop it!;)"
miguel: "I second Grim, stop this nonsense! I love my cigarettes!"

SMF spam blocked by CleanTalk