Re: [Adonthell-devel] Jumping and sliding glitches

[Kai Sterker]

On Tue, Aug 23, 2011 at 8:08 PM, StyxD <address@hidden> wrote:

> I had no time whatsoever during this weekend and I may not have much
> this week, but I tried to do something today.

No worries there. Had not that much time myself, so only halfway done
with the GUI event stuff I've started working on.


> Well, I added a check vz() == 0 in addition to GroundPos == 0 and it
> seems to be fine now.
>
> However, I can't notice that even if you can't stand on it, when you
> jump on the stairs the shadow is set on thin air when you pass the
> floor level. Just what object is there?

That one, I'd assume:
https://github.com/ksterker/wastesedge/blob/master/models/map/ground/inside/wood1-down.xml.

Could be a problem that at some points we work with the overall object
bbox instead of the individual cubes. In case of this object, the
collision code (which is more precise) knows there is nothing directly
above the stairs, but for the shadow rendering it appears that the
object does cover the stairs.

The problem is in shadow.cc around line 100, where we do not check on
individual cube level. OTOH, in this particular case, it would
probably be easier to break the model into 3 distinct sprites (and
thus 3 placeable_shapes) to avoid the issue altogether. Wouldn't worry
too much about this, however. There's already a new graphics set in
the making, which is much better tailored to the specific needs of the
renderer.


> I tried to compile adonthell-tools to see the map in editor, but
> autogen.sh doesn't even generate the configure script. Instead of
> trying to force autotools to work, wouldn't it be better to make cmake
> script for adonthell-tools? Is there a specific reason why it's not
> there? I might try setting one up, though I'll need to learn cmake
> first.

We originally introduced the cmake build to get stuff compiling on
Windows, using mingw. Building all the dlls with auto-tools didn#t
really work back then. (It does now, but I guess cmake is still the
better alternative). Anyway, the tools are much easier, so there
wasn't a real need to add a cmake build system. But if you want to
take the opportunity to learn more about cmake, feel free :-),


> Should the gravity effect even be governed by VSpeed? Even if we allow
> it to be negative, it means that a character will accumulate speed,
> while for example a crate pushed down from a roof will not. Will we
> allow players to push crates off thing?

Pushing objects around might be a possible addition for later. But I
assume such objects would be a special type different from ordinary
scenery and use special implementation (inheriting from moveable). So
it could also get the same acceleration effect that characters might
have. OTOH, I don't think there is that much worth in keeping the
acceleration, if it causes big problems. The main reason for having it
was as a way to tell how deep a character fell, to deal out damage
accordingly (so that long enough falls would effectively kill the
character), But there might be better ways to accomplish the same
effect.


> I found a new bug: if you stand on a left or upper ledge of something
> (the barrel is good for testing that), the character can't jump
> because the game think they're standing on the ground beneath (i.e.
> GroundPos is set to that), but collision detection (correctly)
> prevents the character from actually falling there. The offending line
> is src/world/moving.cc:367
[...]
> When standing on left or upper ledge, px or py are negative, which is
> correct but makes no sense, because the character still is mostly
> standing on the upper object. Moreover, when I commented out the if
> clause, it seemingly broke nothing and fixed the bug. What exactly is
> the point of that check?

I would assume that our change to the bbox for finding the objects
beneath the character may have made that check obsolete. But before
you could have gotten objects directly next to the character, but
higher or lower than the actual ground position. Especially the stairs
might have been a problem here.

So if removing the if clause does not show any ill effects, then it
should be gone.

Kai

P.S.: Btw., thanks for all the thorough testing. I guess that
collision stuff is an area where I thought that good enough is okay
instead of striving for perfection, But I'm very glad about all those
improvements :-).