muddle by catenary with curves and diagonals

[makie]

Pak128.german
oldtrak 90km/h --> has curves --> is ok
single powerrail 80km/h --> has curves --> I have changed the color to red for better visibility

Look at red arrows this are graphics of curves
That only happens if you drag the power rail fresh from top to bottom and the right one first
or from left to right and the upper line first.
If you drag vom right to left and bottom up all is fine until you change the order which one first.
It is possible to rotate nothing change.
if you save and reload all is fine.

The blue arrows this are diagonals where the rail has curves.
I think rail and catenary should work equal.


just a funny thing, but i want to mention it

[victor_18993]

Thanks makie for the very detailed report - the "reload fixes it, so the saved data
is fine but the drawing is not" observation is the key, and it points straight at the
engine rather than at pak128.german.

What seems to happen

The connectivity that gets saved looks correct; what can go wrong is the cached image.
A way-object at a bend (like the power rail) chooses between its curve and diagonal
image from the direction of its neighbours. When you drag a line the tiles are built
one after another, so a bend can have its image computed before the neighbour that
determines which image it needs has been built. The drag tool does not perform a final
recalculation after the whole route has been completed. Loading does: it recomputes
every way-object after the full map is present
(wayobj_t::finish_rd), which is why a save/reload repairs the picture without changing
any saved data, and why the result depends on drag direction and on which parallel line
is built first.

Candidate patch

One file (tool/simtool.cc, +12 lines). After the drag is finished, it recomputes the
way-object image on each tile of the route, so the drawn image ends up the same as it
would be after a save/reload. It is deliberately the same post-build recalc the way
builder already does for diagonal ways (way_builder_t::build_track), just applied to
the way-objects; it reuses the object's own image routine, so it is a no-op wherever
the image is already correct. No pakset change and no new translation are needed, and
it does not touch the savegame format.

@prissi - I kept it as a small along-the-route pass in do_work, mirroring the way
builder, rather than trying to push it into extend_wayobj (which runs per tile, before
the route is complete, so it cannot see the final geometry). Happy to reshape it if you
would prefer it elsewhere.

Honest status

I have to be careful here: on current trunk (r12100, which already has the recent
close-diagonal fixes for ways) with pak128.german and the old track plus power_rail_80,
I could not actually reproduce the wrong sprites in my own headless tests - single
diagonals and two parallel close diagonals built in every order all came out correct
for me. The build is clean and the full automated test suite still passes (201/201,
no regressions). I believe this is the missing invalidation step, but since I have not
reproduced the visible failure locally, I am attaching it as a candidate fix rather
than claiming the bug is solved.

To confirm it, could you attach a savegame from just before the build that goes wrong,
and tell me:
- the exact Simutrans version and pak128.german version you use,
- the two tile coordinates and the drag direction,
- the order in which you built the lines?

With that I can reproduce it, check that the patch removes the difference, and add a
regression test. I would rather send a confirmed fix than a plausible one.

[prissi]

This was more complex than thought as also the ways need some fixing. The recaluclation after buildign was only a part of it, the diagonal calculation routines differed between ways and wayobj.

r12101 shoudl fix all those and do even less meaningless recalculations.

[makie]

Very nice, thank you very much.