Re: [Adonthell-devel] Jumping and sliding glitches

[Kai Sterker]

2011/8/15 Michał Kaliński <address@hidden>:

> Friction indeed could be useful. I think we might also add some
> "terrain un-slide-able" (well, some better name) property, which will
> omit the sliding motion calculations when updating movable objects
> located on that terrain.

I guess the simplest way to implement friction might be to add a
threshold, and if the resulting velocity (after a collision) is
smaller than the threshold, we simply discard it. The threshold could
be different for different terrain types, but maybe a constant would
work as well.

Completely disabling the collision response calculations might not be
a good idea, as it could lead to getting stuck in walls instead of
rebounding or scraping along.


> As for jumping, it doesn't actually check the velocity. Doing so would
> faultlessly prevent wall climbing, but also disable jumping when the
> character is sliding down even the most gentle slope. Not something we
> want. I added a check to only jump when the character's jumping speed
> (VSpeed) is 0 (ie. no jumping before you actually stop the previous
> jump) and it helped a lot but climbing walls still occasionally
> happens.

VSpeed was what I had in mind when I wrote vertical velocity. Too bad
it does not completely solve the issue :-(.

> I think the main problem that needs to be solved is that when you walk
> up to a wall, the engine thinks that you are standing in that wall
> (GroundPos is set to the wall's top, and though z coordinate is not
> changed, it enables a lot abuse, I think). For example, if you attempt
> to jump where two wall objects are atop one another (like the doorway
> in wastesedge map), wall jumping will surely occur because you
> legitimately "landed" on the bottom section for a frame.

This looks indeed as if it is broken. Maybe the bbox used in
moving::calculate_ground_pos() is either off, or it's simply too large
so that it catches adjacent wall objects when it shouldn't. Have you
tried shrinking it by a pixel?

I'm a bit reluctant about marking objects explicitly as non-surfaces,
if it's not absolutely necessary. It's another piece of data to set
wrong when creating a model, and makes the code less generic at that
point.

> I can't think of a trivial way of solving this (though I admit I
> didn't read the paper on the collision algorithm).

The groundpos is an addition of mine. The main purpose was to omit the
whole collision/moving calculation when a character was resting on the
ground (and otherwise standing still). So its calculation might not be
100% perfect yet.


> The above mentioned properties (friction, etc.) I think could be
> placed in placeable_model - it already hold the string with the
> Terrain name, but that one seems to be meant to be used by python
> side. We could also create a c++ class for terrain information
> relevant to the engine.

I thought the terrain is used by the path finding code, although
Python might be involved where each character (or creature) could have
individual speeds per terrain type.

Actually, I'm not so happy with the location in placeable_model
anymore, because a single placeable can consist of multiple
placeable_models and that leads to strange code as in
placeable::get_terrain(). Might be better to keep stuff like that
directly in placeable.

Kai