[SOLVED] Why this strange 'reset' to height when inclding a .Walk() command?

Started by bx83, Sun 09/02/2020 00:16:09

Previous topic - Next topic

bx83

I've noticed the following weird behaviour.

My sprite has a wide area under him:



...so to make him walk back and forth on the path set out, I need to either:
a) export, change, and re-import all the masks for every room (not happening, too complex, will take 3 months, plus I have to resize paths with continuous scaling, and just editing a mask .bmp is paint.net or paint.exe results in it saving wrong)
OR
b) make his z coords good for "lowering" him to the path

I've already come up with an equation which seems to work 100% of the time depending on his scaling:

cJulius.z = 0 - ( FloatToInt( (Z_FACT / 100.0) * IntToFloat(cJulius.Scaling), eRoundDown ) );

Where cJulius is my sprite
Z_FACT is a floating point constant of 72.0 (about the distance his feet are from the bottom of his frame, 72pixels)

The final result for cJulius.z is always a negative number.

I have a usual interact function: walk to object, face object, say something, pickup object (play an animation of him bending down to get it).
The pickup animation is the same size exactly as the standard walk animations; it goes seemlesly.

HOWEVER

When I have a .Walk() anywhere near to the .PickupUp() animation, it 'resets' itself after I've done this --  in other words, it seems to jump a random amount in height, for no known reason:
https://bluekeystudios.com/img/julius reset.webm

When I take out the walking line, no reset:
https://bluekeystudios.com/img/julius no reset.webm

The code is:

Code: ags

function oWallet_Interact()
{
cJulius.Walk(587, 396, eBlock, eWalkableAreas);    <-- THIS LINE CAUSES RESET; if I comment it out, no reset occurs.
cJulius.FaceObject(oWallet);
cJulius.SayBubble("My wallet! Something survived the time-travel. Oh... it's got all the money missing.");
cJulius.PickUp(eLow, iWallet, oWallet, false, 8, player.Room);
}



Also, here's the .PickUp() code:

Code: ags

function PickUp (this Character*, PickUpHeight height, InventoryItem *i, Object *o, bool visibility, int obj, int room)
{
 
int _loop_down=0;
int _loop_up=0;
 
if (height == eLow) {
_loop_down=138; //low
_loop_up=140;
}
... //other heights, this just sets the view number for the pickup down, pickup up views
 
int cur_loop=this.Loop;

this.LockView(_loop_down);
this.Animate(cur_loop, 1, eOnce, eBlock);
this.UnlockView();

this.AddInventory(i);
o.Visible = visibility;

this.LockView(_loop_up);
this.Animate(cur_loop, 1, eOnce, eBlock);
this.UnlockView();

}



Now - obvious questions:

Have you tried setting Julius' loop to the same each time, even when you don't include the .FaceObject() function call? Yes - still happens.
Have you tried peppering Wait(1); between each line of code, and the .PickUp animation code? Yes - still happens.
Have you created a new room, with all the same objects, paths, masks and scaling, and see if it does this still? Yes - still happens.
Have you tried making a generic room with only the Walk,Speak,Pickup code in it? Yes - still happens.
Have you tried deleting the line to do with the .FaceObject() function, so it's walk,speak,pickup; or for that matter walk,pickup; or walk/wait/speak/wait/pickup; or walk,wait,pickup; or...? Yes - still happens as long as .Walk() is there.
What about when Julius walks to an object by guidance of the mouse, not a Walk() command It works when I send him to a point, but not the command .Walk(). However, don't really see how I can get rid of this.
Is the .z variable the same before, after and during? Yes, tested thoroughly, but .z is miss-set when I pickup something, as opposed to the clone rooms. When set .z based on scaling alone eg. if .scaling=5 then .z=-16 or whatevs -- it sets the .z different to other rooms, and the 'reset' still happens. However, the .z it's set to is always the same mis-set number.
What's the function for the setting Julius' .z variable?

Code: ags

function repeatedly_execute()
{
cJulius.z = 0 - ( FloatToInt( (Z_FACT / 100.0) * IntToFloat(cJulius.Scaling), eRoundDown ) );
....
}


Have you tried writing it walk/say/nothing You mean leave out the PickUp() animation? Or the .SayBubble()? It still does the reset wherever there's a Walk() command.
Is it something to do with the .SpeechBubble() code? Perhaps - I've got 0.8 but made a few minor changes to integrate it. Anyone wanting to see it I'll PM it to.

Am I missing something here? Does walk always do this, reset graphics somehow? Does walk() do something which the standard code for getting a character to walk somewhere based on a mouse-click in eModeWalk doesn't?
Am I insane, or as usual overthinking?

Plz help :(

bx83

Is there anyone in here who can help?
I'm happy to post code if that helps find a solution?

bx83

I used ProcessClick to try and find a function other than Walk():

Room.ProcessClick(580, 404, eModeWalkto);

But Julius doesn't walk to these coordinates. Am I doing something wrong?

Gilbert

Quote from: bx83 on Sun 09/02/2020 03:14:58
Is there anyone in here who can help?
I'm happy to post code if that helps find a solution?
It's just the usual 'everyone has a life and may not concern much about virtual adventures at weekends' thing. Just be patient as this is a forum, not a chat. It's normal to have people answer to a thread only after hours have passed (not to mention they live in different time zones).

I could not help ATM as I'm not at home and writing this with my phone.

Please don't bump threads unless there really is some new things to add, and don't cross-post in different forums. If you think a thread was not started in the appropiate forum just notify a moderator for them to move it for you. I'll remove tge duplicated thread from the beginners' forum.

bx83

Okay. Was just kiling my game, gave it over night, still no replies. It's all good.

In fact if someone could just tell me the ProcessClick() syntax that would be good, currently it does nothing, no walking.

Snarky

I always thought z-coordinates were scaled along with the character by the engine.

bx83

I don't think so... having trouble finding answers on this. If it does scale, then it's all been for nothing :/

bx83

Doesn't appear to scale.
.z=-72 means its always 72 pixels below floor. If you go into a room where Julius is scaled to like 8% then he's suddenly a huge amount under the floor.

ManicMatt

The videos are not a fair test because the character is facing forwards when he picks it up in the second video.

I don't know if it's good practice or not but I never use commands like face object because I don't have full control over where the character will face. In this instance I would have used the code for facing left, and if you had done so, then when testing it without the walk command, it would be a fair test. How do we know he doesn't move upwards when facing left without walking when we only see him face forwards (down) in the second video? We don't.

bx83

I have a room where he can click objects in any direction, so I've tested extensively. It's just the walk() command; don't know if ProcessClick() because I can't get it to - he doesn't walk (and the coordinate he's walking to is on the walkable area).

TheManInBoots

I had some trouble using the z-layer as well.
But you can simply edit out the space below the character sprites in the original files and re-import the sprites by right clicking all the character sprites in the sprite folder and selecting import from source.
If you don't have a proper tool to cut out the empty space below the character sprites, you can use gimp, which is freeware. It has a plug in that you can look for and download separately which allows you to export layers. So you can add all images in one project file as different layers. Remove the lower space with the "Crop to Selection" tool.
Then export them.
And then import them into the game as described above.
If you know what you're doing this is done in an hour and your game is fixed.
If you do it this way and you have troubles on the way feel free to ask.

written with Android 4.0

ManicMatt

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

Cassiebsg

Okay, stupid question, but why exactly do you have so much empty space bellow the character? Is there a reason for it, or just because they were provided like that by your artist? I would suggest you cut all that space, so that your z is like -7 or -10 or so, to start with. Just make sure you cut exactly as many pixels in each sprite and don't cut any part of his feet while walking. Don't know if it'll fix your problem, but at least the gap will be less noticeable.
I never used anything but adjusting the z before, and never noticed I needed to. But maybe when you scaling him so much there's a limit...
There are those who believe that life here began out there...

TheManInBoots

Quote from: ManicMatt on Sun 09/02/2020 11:38:16
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.

Snarky

There are lots of reasons to have free space below the character. For example, if you want to draw a shadow under them, or if the down walkcycle has the feet going further down.

Quote from: bx83 on Sun 09/02/2020 08:56:50
Doesn't appear to scale .z=-72 means its always 72 pixels below floor. If you go into a room where Julius is scaled to like 8% then he's suddenly a huge amount under the floor.

This seems like a pretty big oversight/bug in AGS. We've been telling people for years to use Character.z to move the character baseline to line up with the character's feet, and if it doesn't take scale into consideration then that's not a suitable solution.

(Sorry, I can't really help with your problem.)

Arlann

Is this not a blocking function problem?
If z is relative to scaling, you should update z in a function repeatedly_execute_always or late_repeatedly_execute_always, because the scale changes as you walk.

Snarky

Yes, it should definitely go in late_repeatedly_execute_always(). In fact, that function was created for pretty much this exact purpose.

(And with Arlann pointing it out, I now see what the problem is, and why this would fix it.)

TheManInBoots

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.

ManicMatt

If that's the case Snarky, it's interesting to me how complex bx83 made things be, which made the issue seem really complicated and way too advanced for me, but it was something I am familiar with.

The more you know, the less you can see, or something?

What I'm trying to say is, did bx83 make this problem much worse for themselves by over complicating things? Assuming it is this solution.

Olleh19

Maybe a dumb question, but are you 100% sure the sprite images are cut exactly the same?
I know i did that mistake in the beginning, that's why i never cut images inside the actual AGS editor anymore, i just import it "correctly" from photoshop directly.
Just a food for thought.

Edit: What i mean is, is the pickup animation the same as the walking animation in height/width pixels and placementwise?

SMF spam blocked by CleanTalk