OK, so my game is almost finished. All I have to do is sort out some bugs. And one bug is something that's probably fairly obvious but I guess I'm missing.
So here is an example of what's going on (I'm not going to put in all the script details since they're not important :P)
cEgo.Walk(x,y);
cEgo.Animate(blablabla); // this makes the character bend over
iStick.Visible=false;
cEgo.Animate(blablabla2); // this makes him stand up again
So after this sequence I do not move the character, so he stays where he was when the animation ended. Then I for instance make the character look at a hotspot. He does not move over to the hotspot but rather looks at the player and says what he has to say. (it's just a simple cEgo.Say("whatever"); script and nothing folows it. So far so good but then after the character stops talking he should move back to his default position. But rather than do that he moves to the first frame of the "blablabla2" view. I don't have any idle or blinking views set for my character.
Thank you :).
cEgo.UnlockView should do the trick. After locking a view and animating it, UnlockView restores the "default" view as set in the character panel.
Well... That didn't work :P All it does is set the character in the first frame of the view right away (I don't have to look at another hotspot).
This is how I wrote it. Maybe I did it wrong:
cEgo.Walk(282, 356, eBlock);
cEgo.Say("Cool, some leftovers");
cEgo.Animate(8, 3, eOnce, eBlock);
palica2.Visible = false;
cEgo.Animate(12, 3, eOnce, eBlock);
cEgo.UnlockView();
cEgo.AddInventory(palica);
cEgo.SetView(#);
should do the trick then, you set the view back to the characters normal walking view after animating him.
Quote from: selmiak on Sun 16/02/2014 22:58:34
cEgo.SetView(#);
should do the trick then, you set the view back to the characters normal walking view after animating him.
Well.... character.SetView is not something AGS recognizes. At least for characters. It returns a rather lengthy error message.
Maybe I forgot to mention that the view I am ussing as the default view is the same as the view I'm using for the animations (just different loops).
It is Character.ChangeView ;).
ChangeView is a permanent change though. I double-checked the manual and the method it describes seems tailer-made for the situation.
The trick is using LockView, and viktor's code doesn't do that, so Unlock won't work (you can't unlock what is not locked).
player.LockView(VIEWNUMBER);
player.Animate(0, 5, eOnce, eBlock, eForwards);
player.UnlockView();
Substitute VIEWNUMBER with the number/handle of your view.
Quote from: Ghost on Sun 16/02/2014 23:10:35
ChangeView is a permanent change though. I double-checked the manual and the method it describes seems tailer-made for the situation. LockView remembers the "default view". ChangeView... changes it. So for an animation to quickly restore the normal view once it is done, this should be easier to use:
player.LockView(VIEWNUMBER);
player.Animate(0, 5, eOnce, eBlock, eForwards);
player.UnlockView();
Substitute VIEWNUMBER with the number/handle of your view.
But the view I am using as the default view is the same view that contains the loop for the animation. So how is locking and unlocking the same view going to help?
Quote from: viktor on Sun 16/02/2014 23:14:45
But the view I am using as the default view is the same view that contains the loop for the animation. So how is locking and unlocking the same view going to help?
Well, I didn't know that. True, in that case it won't do much.
Maybe it's best to post the whole code- it's usually easier to see what happens when you can read through the whole function.
So how can I fix this other than making tons of views and rewriting a bunch of code. Besides if I try to code the animations how would that work exactly? I would have to change the views for every animation wouldn't I? But that seems like an unnecessary hassle. All the animations work perfectly except for this bug. The only other solution is to make the character move a bit after the animation. That seems to set the loops back to default. But it would be rather strange for the character to walkabout every time he picks up an item :P.
EDIT: I posted the entire code a few posts back...
This is how it looks now:
cEgo.Walk(282, 356, eBlock);
cEgo.Say("Cool, some leftovers");
cEgo.Animate(8, 3, eOnce, eBlock);
palica2.Visible = false;
cEgo.Animate(12, 3, eOnce, eBlock);
cEgo.AddInventory(palica);
So if I read you correctly, you use loops/one loop in the player's "walking view" to animate him bending over? That could be the problem then.
There are some things that are rather basic but important:
- The first eight loops in a view are reserved for directions. The first four for Up/Left/Right/Down, the next four for UpLeft/UpRight etc. Using these loops for anything else is not recommended because AGS needs them to stick to the "rules".
- Basically, any action should have its own view. A Bend-Over animation would justify its own view, with the benefit that the direction is taken care of automatically.
Think of a VIEW as "one animation", for all directions, which are assigned automatically. I really think your bug is caused by AGS somehow staying in a view that's "not used as intended".
__
Edit: And this is not meant to sound harsh. I don't know your level of experience, so I just went for the basics. It MAY be something completely different going wrong, and me not seeing it.
Probably. I know that the first 8 loops are used for directions. But the 9th doesn't serve any specific purpose so I figured it (or a later loop) shouldn't be a problem using that one as the bending animation. So If I want the things to flow good I would have to set up a new view as the bending animation (let's say that's view 3). If the default View is 2 the code should basically look like:
cEgo.ChangeView(3); //change to the view with the bending animation
cEgo.Animate(0, 3, eOnce, eBlock);
cEgo.ChangeView(2); //change back to the normal view
It is definitely recommended not to use the normal/walk view for other animations.
The manual states that one should use LockView before the actual animation, which implies using a different view, although that should be mentioned explicitly I guess.
You can try to "cheat" and use LockView anyway but simply lock it to the normal view. Maybe this will fix the issue. The only other solution I can see is to copy the animation to a new view and use the proper way in every situation where this bug occurs.
This is also a good opportunity to mention that stuff like that should always be implemented with custom functions:
function PickUp(int x, int y, Object *obj, InventoryItem *item, String message) {
cEgo.Walk(x, y, eBlock);
cEgo.Say(message);
cEgo.LockView(BENDOVER);
cEgo.Animate(8, 3, eOnce, eBlock);
obj.Visible = false;
cEgo.Animate(12, 3, eOnce, eBlock);
cEgo.UnlockView();
cEgo.AddInventory(item);
}
PickUp(282, 356, palica2, palica, "Cool, some leftovers");
Now if you want to change something, you can do it in a single spot and it will affect the entire game.
I'd also recommend using names like oPalica and iPalica for the Object and InvItem respectively.
Edit: no, it's LockView and UnlockView, like it says in Ghost's posts and the manual.
ChangeView is for permanently changing the Normal/Walk View (like it said in Ghost's post).
Nope that cheat doesn't work. It just sets the sprite to the first frame of the last loop that was animated. But even if I lock the view how do I determine the view that the new animation has to use. As far as I know if you want to animate a character the first int is the loop. How do I determine the view that is suppose to be used? Pardon my ignorance but as far as I understand lockin and unlocking the view wont do that :P.
Quote from: viktor on Mon 17/02/2014 00:25:30
How do I determine the view that is suppose to be used?
As already said:
a) LockView(
Number Or Handle Of TheView You Want To Use)
b) Then, simply use Animate as you already did, setting a loop in the now locked view.
c) Then unlock, and have your character "reset" to his standing/walking view.
It can be a hassle to create separate views for everything, but it's quite convenient once you're used to it. It even allows composite animation.
Quote from: viktor on Mon 17/02/2014 00:25:30But even if I lock the view how do I determine the view that the new animation has to use.
Did you even bother to look up the command in the manual? I'm willing to pardon ignorance, but willful ignorance... :P
QuoteCharacter.LockView(int view)
Sets the character's view to VIEW. This can be used to perform animations with characters, for example bending down to pick something up, which don't use the default view.
I did bit I will admit that I looked it up only just before I wrote the post... I still don't really fully understand it. Usually I code on a trial and error basis because I'm not really a programmer. I try something and if it works I sort of understand what it does. Since this didn't work for me (at least not yet) I still don't fully get it but I'm getting there :P.
Here's an idea. Instead of making all new views now that the game is actually more or less finished, what if I just make a new walking view (less work than creating all the other views) and add the lock and unlock codes to the scripts?
EDIT: Yup! That did the trick. A new walking view and adding the lock and unlock codes before the animations. At least the one I tested works, so I'm guessing all the other should to :P
Hi
QuoteUsually I code on a trial and error basis
I think most of us do at the beginning, but we should always take in what the the experienced guys recommend and keep browsing the manual and forums.
After doing all the views for the walk, talk and idle I find it really useful to make new animations for stuff I wish my character to do in the game IE bending over, reaching up etc etc and have them LockView animations. It is time consuming but worth the time spent and can be used anytime.
LockView is a definate yes yes when it comes to extra character actions / animations ;)
After you are quite well versed you should be able to access the situation and what you want to achieve and in your head you should know 98% /100% of how you intend to do it.
Hope this helps ;)
I'm tempted to comment on the glaring contradiction between what you said you did and what your previous question was but will refrain from doing so for the sake of not being called dead inside again.