Adventure Game Studio

I don't know if this is intentional, but when I use the Unlock command it unlocks but it doesn't go to its normal loop.

EDIT:

For example:
I have a character: cChar, its normal view has 4 loops for walking and other 4 for other animations
So if I do this:

cChar.LockView(4);
cChar.Animate(9,6,...);
cChar.UnlockView();

And after that I move the character in the direction he's facing, then it uses the loop 9 of its normal view...

The manual doesn't explicitly state that the loop should be restored, so it's possible it's intentional. And it's highly likely that this is something which would be marked as "fixing would break backwards compatibility"/"some people might rely on this behavior"...

Yeah, with hindsight this is how UnlockView should have worked, but there's really no way it can be changed now without breaking tons of people's scripts.

You can use Extender Functions to implement your own version of LockView and UnlockView which remembers the loop number and restores it.

Ok let's do it :)

Joe, I'm not clear if you're asking for help or not...in any case, you could do it like this:

// GlobalScript.asc - or other script.asc file
int char_lock_loop[];

function game_start() {
 char_lock_loop = new int[Game.CharacterCount];
}

function LockViewEx(this Character*, int view) {
 if ((view <= 0) || (view > Game.ViewCount)) return;
 char_lock_loop[this.ID] = this.Loop;
 this.LockView(view);
}

function UnlockViewEx(this Character*) {
 this.UnlockView();
 this.Loop = char_lock_loop[this.ID];
}

// GlobalScript.ash - or other script.ash file

import function LockViewEx(this Character*, int view);
import function UnlockViewEx(this Character*);

// wherever
player.Loop = 5;
player.LockViewEx(4);
player.Animate(9,6,...);
player.UnlockViewEx(); // player.Loop is restored to 5

EDIT: As far as it being changed Chris, couldn't both functions have an optional bool preserveLoop=false added to the parameter list? That would preserve backwards compatibility and provide the requested functionality for future versions...

Ok thanks, I was't asking for help, buy anyway thanks, so I don't have to do it ;)

Ya that Lockview thing really bothered me as well when I started out 2 years ago (I even had a post about it because I was so confused).

If that's seriously not an option, I'd be perfectly happy with a new Lockview command.
I suggest:  LockViewLikeItShould
lol  All jokes aside... I really can't think of a different name for it.  But it would be a great feature to have for all newcomers to AGS and even people like Meee! :P

Something else to consider if you're not obsessed with splitting up views for every action is that you could just use the infinite loops in your character's walk view for custom animations and not bother with locking at all.  I've been doing this ever since CJ lifted the loop limit because it's far easier to work with, especially for background animations.

Yeah the infinite loops, I realized that yesterday

Wouldn't the animations placed in the diagonal views be used in the walk cycle? Or would you just have to not insert a frame to the diagonal loops and use the loops after those (hoping those blank loops wouldn't be part of the walk cycle)?  Curious...

Quote from: monkey_05_06 on Wed 12/08/2009 19:04:17
As far as it being changed Chris, couldn't both functions have an optional bool preserveLoop=false added to the parameter list? That would preserve backwards compatibility and provide the requested functionality for future versions...

That's a good idea, it's probably worth adding something like that to a future version. For now the workaround that you've posted should do a good job.

If the use diagonal loops option is off it won't use the those loop positions automatically.  If you do plan on having diagonal loops, though, you can just skip to loop 8 and go from there.

Quote from: Pumaman on Sat 15/08/2009 14:20:10

Quote from: monkey_05_06 on Wed 12/08/2009 19:04:17As far as it being changed Chris, couldn't both functions have an optional bool preserveLoop=false added to the parameter list? That would preserve backwards compatibility and provide the requested functionality for future versions...

That's a good idea, it's probably worth adding something like that to a future version. For now the workaround that you've posted should do a good job.

Actually retrospectively it might be silly having the parameter on both functions. Just having it on LockView might make the most sense because that would tell the engine whether it needed to store the information.