Anyway, given your code (using experimental version 2) I would have expected that a basher falling down has its falling distance reduced by 3, because it got moved down already 3 pixels during the basher function. However experiments show that being a basher doesn't matter whether a lemmig splats or not. Where is my mistake?
if (aAction = baFalling) then
begin
LemFallen := -2;
if LemAction in [baWalking] then LemFallen := 0;
if LemAction in [baBashing] then LemFallen := -1;
if LemAction in [baMining, baDigging] then LemFallen := -3;
end;
This code handles setting the initial fall distance. I couldn't tell you off-hand
why these values work - they were derived a very long time ago, by trial-and-error rather than by analysing code. However, just in case, I tested it now and can confirm - both a walker or a basher, falling from a 64 pixel height, will splat. Either one falling from a 63 pixel height will not. So while the code may be a bit strange here, there is no inconsistency in the end result.
Still if the basher is a floater, he opens the parachute one pixel higher than usual lemmings falling down. So there is something not completely right with the faller transition.
This (which probably should be fixed) is because a walker is moved downwards by one pixel more than a basher is, before transitioning to a faller. Although the splat distance is, unlike L1, checked on a pixel-perfect basis; the timing of pulling out a floater is unchanged from L1. For a floater this generally won't make a huge difference (in some cases it may mean a walker arrives at the ground one frame sooner than a basher, even if both begun falling at the same time - this also holds true for regular fallers as well), but I could see this being significant when it comes to Gliders.
Do we even need the steel check on assignment at all, if we use the new checks during the basher animation?
I was wondering the same thing myself. However, as far as I recall, no one suggests changing the check-on-assign for the digger. People also seem to want the check-on-assign for miners to be made more strict. In light of this, making the basher check
less strict seems a bit strange.
Just looked a bit more at the experimental code and found some more bugs:
- Bashers can now climb much steeper inclines (about three times as steep)
- If a basher moved up or down, the steel checks are at the wrong height
The first one might be desirable for consistency (and at any rate, is a very unusual setup, though it might occur in the Sky set or by very well-timed use of Stoners, or perhaps even Stackers). The only reason the lemming couldn't do so before is because the steel check caused him to revert to a walker. In the absence of this - perhaps if the aforementioned stoner / stacker timing setup was used to create such a layout - the basher would have been able to do this too, I believe.
The second one I'll look into.
Finally I noticed the following: If the lowest 5 pixels are air and from pixel 6 on there is steel, then the lemming will happily continue bashing forward without removing any terrain pixel at all. Do we want to keep this behavior?
No, we do not. We should compare this to a digger - although steel (other than right underneath the lemming) won't
stop the lemming, they don't count as solid pixels for the terrain check.
In regards to your proposed code - I'm planning to overhaul the way the code is written in the near future, so I don't want to worry too much about improving the way the current code is laid out. Rather, my intention is - decide on and implement new physics by adjusting the current code, then when that's done, do the overhaul, at which point the improved-readability etc changes would also be made.
FWIW though, as far as I can (without actually testing it) tell that code is mostly fine, except for "Return :=" rather than "Result :=" in the first snippet. Although the new functions should probably be defined as private functions of TLemmingGame, rather than standalone ones.
