Messages

Thanks

Does anyone still have the file and can post it or share a link? The link here is outdated...

Hi dayowlron. Just letting you know that I'm super busy for the moment. It looks interesting what you wrote. So don't worry, I'll come back to you when things loosen up a bit for me time wise

Hi everyone.

I would like to let specific things happen depending on the mouse movement.

For example if I move the mouse cursor to the right, a character animates and moves in a certain way, if I move the mouse up, the character animates differently and maybe moves differently.

It happened multiple times that I would have liked to be able to do that, but all my attempts failed.

Does anyone have an idea how this can be done?

Hi ld-airgrafix,
Try eri0o's module
https://www.adventuregamestudio.co.uk/forums/index.php?topic=57489.msg636611488#msg636611488

And I think there are already some threads on smooth camera movement in the forum.

Thank you so much for this, it works really well and smooth. This engine continues to surprise me daily

You welcome

Hi ld-airgrafix,
Try eri0o's module
https://www.adventuregamestudio.co.uk/forums/index.php?topic=57489.msg636611488#msg636611488

And I think there are already some threads on smooth camera movement in the forum.

Wow, lorenzo, did you draw that yourself?

I just thought the main principle is evident in itself, that the lifted leg bends and the other one is rather straight...

But I guess we both made our point clear.

Snarky you can also see that in picture 7 the leg is still slightly bent in your series. And then it start stretching fully out again to push the body forward in picture 8.

Yes, you're right Snarky.
The bending I am talking about is a very fast bending.
It's visible in your photo series only on picture 3 and 4.
It happens very fast, it's almost a jitter that happens.

It just takes so much time to explain everything thoroughly so I didn't mention it

But without that bending/jitter it would look more stiff and rigid. Some people walk that stiffly. Also older people tend to do less of a bend/jitter, in case you want to animate old people walking...
Thanks for going more into detail Snarky and sharing this Series.

Glad we could help!

Here is an illustration of how the leg behaves that carries the weight of the body.
The rest of the body is just for context, but don't pay any attention to it.

123

So in image 1 you can see that the leg stretches out and is completely straight to reach far out.
Then in picture 2 it is bent. It bends, so that the center of gravity changes in the body, making it fall forwards over the knee, which creates the forward movement.
Then in picture 3 the leg is stretched out again. It tries to push the body as far forward as possible to make it move.

[Edit:]

I agree that it looks nice, it has a really nice flow to it!
I second that the legs are bent too much.

I would not agree that the torso is bent forwards.
When people are walking normally, calmly, confidently, the torso is straight. Only when people are hectic, have an urgent errand and are stressed, or walk very decisively, the torso is bent forwards.
Edit: You could actually add a little wavering of the the torso back and forth, on one step forward (while the torso already moves slightly forwards) the torso tilts slightly forward, on the other step forward the torso tilts slightly backwards. You really shouldn't overdo this, it's minimal, but I think you could create a realistic and quite characteristic effect with it. It makes the walk more alive and energetic.

All in all it already looks pretty good!

If you followed the tutorial you started a sierra game, which can be played as it is already.
It already starts with a character and a room.
So you changed some settings that you shouldn't have changed apparently.
Make sure that the character that starts in room 1 is set as the player character.
Also, can you show some screenshots of what you did, and of the settings? If you can show more and give more information that would make it easier for everyone to help you.

Nightmarer, it's actually quite easy to understand once you know that the number/value "-1" is used to basically turn something off.

So, as Cassiebsg suggested, you can for example get a side character (or non-player character) out of the game by simply writing

Code: ags

cSideCharacter.ChangeRoom(-1);

Now the side character is no room and you cannot find him in anywhere in the game anymore

The "-1" is used in many places to turn something off.

Here are a few examples so you can understand better:

If you write

Code: ags

cPlayer.BlinkView=-1;

you set that the player character has NO blinking view.

If you write

Code: ags

cPlayer.SpeechView=-1;

you disabled the players speech view, and he won't animate while talking.

Or for example you can set which gui (displaybox) is used for displaying Text:

Code: ags

SetTextWindowGUI (-1);

You set TextWindowGui to -1, so the program is not going to use a specific gui box, but use the default gui for displaying text.


So just remember, "-1" is not the same as "1", and it's used to turn things off

     
ps Sorry for colours, just to show where the frame begins and ends.

It's nice. Thanks for sharing.

Aha, but it's two different animations tho a side animation when it doesn't work, and the front pickup version when it does work.

Lol actually he had mentioned that before that he had the exact same results for all animation directions:

I have a room where he can click objects in any direction, so I've tested extensively. It's just the walk() command

I realised my character z code was in the game start function, so I moved it late repeatedly execute always and when the game loads, I visually see the character get moved down after fade in. Keeping it in on game start as well seems to fix that.

Although my character z code is just the basic version of the code for the z axis, not the above code that bx83 is using which I don't understand.

Both the late repeatedly execute always and repeatedly execute always start running only AFTER the very first room has loaded. Nobody seemed to have noticed that.
So of course you have to write it both in game start (or room before fade in) AND repeatedly execute always, if you have the constantly changing z-factor.

You saw the jump because when AGS fades in a room the game is blocked, and a room's RepExec function only runs while the game isn't blocked (this is why repeatedly_execute_always exists).

.
Again, that's not correct. Even repeatedly execute always (AND late rep. always )is blocked before the very first room is loaded.
After the first room is loaded the repeatedly always function works during fade ins for other rooms but NOT before the first room is loaded.

I believe, this must be remembered, and go into FAQ, that if you need some property, especially visual property, be to kept in sync with another built-in property

And if you add the FAQ it might be very useful to also explain exactly what you mean with "visual property" and "built-in property", because people who are new to AGS (which are the ones who have FAQs) won't understand it otherwise.

bx83, would you mind sharing a sprite frame of the "walk up animation" of your character? One where the leg is stretched down to the very bottom of the sprite?
Because the question came up several times and I believe not everyone understood why that space below the character was necessary in the first place. And it's just a brilliant example for efficient walk animation (by stretching limbs).

Olleh bx83 mentioned before that they are.

Also when the character does not walk, the animation transition goes seemlessly as you can see in the second video.

So true of course the block is causing it.
And I have to correct myself. I watched the animation on the phone before.
But on closer look, bx83 totally uses the empty space below for the feet of the walking animation.

I assumed they wanted to keep the space below for some kind of animations, otherwise why have such a big space?

Let's see what bx83 says but the way the character is animated they don't seem to be.
If there is one moment where the character reaches below I would still cut out the lower space for all sprites, and then find a separate solution for that one animation.
Just talking efficiency here.