Rails on slopes are displayed weird
alexey-lukyanenko opened this issue · comments
Behavior of train on such slope tile is unpredictable.
On the last image the rail is straight and train goes ahead regardless of displayed rail shape.
This basically means that error is in the display part, not rail state as such...
Repeated it
Can it be related to #52? Something is wrong with tile state display in both cases.
type = 1 - ok, rail
height = 1 - this one is the only candidate to be wrong? Also there's extra field which is not printed here
m1 = 0 - ok, owner
m2 = c - ok, on desert
m3 = 0 - ok, conventional rails
m4 = 0 - pbs reserve, irrelevant
m5 = 2 - ok, track in Y direction
dbg: type = 1
dbg: height = 1
dbg: m1 = 0
dbg: m2 = c
dbg: m3 = 0
dbg: m4 = 0
dbg: m5 = 2
dbg: extra = 1
dbg: slope/h = 4/8
Slope type 4 according to tileh.png is just is what we see. It means that there's not a display error, but rail building terraform error
The train can go there without obstacles, so maybe this is the incorrect bits placed...
As far as I see train does not check tile form at all, just connection of rails. :) And internally rails are connected ok for such places.
in CmdBuildSingleRail():
CheckRailSlope seems to be ok, returns terraform price, so terraforming is assumed
Cmd.CMD_LANDSCAPE_CLEAR does not terraform - just removes trees
I don't see actual terraforming code during rail building. Cost is assumed, but no land changing.
Will debug DrawTile_Track...
Current suspect is DrawTrackBits(), for it was rewritten (not identical to C version).
- No real terraforming is done. Tile is 'dinamically terraformed' during painting.
- Fence shows how tile should be painted, but it does not.
- Error must be in DrawTrackBits(), but rewritten part seems to be correct, at least for this case (tileh == 14)
- Current suspect is GetRailFoundation()
Fixed part of error in GetRailFoundation()
if(bits == TRACK_BIT_DIAG1) return 15+i;
if(bits == TRACK_BIT_DIAG2) return 15+i+1;
This case is painted better:
OMG, I DID IT! :)
Wow!
One char fix. :)