On Tue, Aug 23, 2011 at 8:08 PM, StyxD <sty...@gmail.com> 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 :-). _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel