[Fixed] Ship teleportation?!?

[neroden]

OK, this is a bug in -devel which I found using my slightly altered pak.
- in the current repo for pak128.Britain.experimental, the Dogger "MUST USE: Waterway", which means it can't be used for fishing at all.  Oh dear.
- So I modified it to remove that constraint.  It "MAY USE Small Waterway", but it doesn't have to use a waterway at all.

- Then I started playing a map with a route where the fishing boat had to go from one ocean basin to another, via a canal, in order to get from the Fishery to the Fish Port.  The boat first found "no route".  After I gave it waypoints, it started teleporting.  I then removed the waypoints and it continues to teleport.

So there are some funny problems with the route finder in this circumstance.  Teleporting boats is a new one on me, though.

The game:
http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/BT0knyrqNr/teleport-game.zip

The pak files which might be different from yours (I couldn't upload the whole pak):
http://files.[ simutrans [dot] us (site down, do not visit) ]/files/get/3YzpEh19yz/pak.zip

[jamespetts]

Neroden,

thank you for this report. The issue seems to be connected to some of DoR's reports. The problem seems to occur in bool route_t::intern_calc_route(karte_t *welt, const koord3d ziel, const koord3d start, fahrer_t *fahr, const uint32 max_speed, const uint32 max_cost, const uint32 weight) somewhere, I think, but I don't have time to track down exactly what's going on at present. Oddly, this is not a method that I have altered much for Experimental, and not since the last release. The problem does not, however, appear to be related to way constraints. I shall have to look into this in more detail when I get a little more time. Thank you again for the report!

[prissi]

Well, this function calls ultimatively calc_route_intern, which calls ist_befahrbar() and all other fahrer functions ... Thus here is a good chance something may be still wrong in the experimental part.

[jamespetts]

Prissi,

thank you for taking a look at this. My preliminary investigations revealed that what appeared to be happening was that the queue of tiles was being exhausted before the destination was found: on a queue of four tiles (on a four tile canal, the depot at one end and the destination waypoint at the other), the tile pushing and popping routines were executed four times, and then the end of the loop reached without a destination being found. The check way constraints method returned a positive result (meaning that the way constraints check passed, and the way constraints did not block the progress of the vehicle).

Further investigation is needed, I think.

[jamespetts]

Hmm, this is a very odd one. I have confirmed that the "ship teleportation" occurs only with Simutrans-Experimental, and not with Simutrans-Standard, but I am having trouble finding exactly where it's occurring. If anyone has any ideas, I'd be most grateful!

[jamespetts]

I have now found the problem, and it is fixed on the -devel branch. Thank you for the report!

[neroden]

I have now found the problem, and it is fixed on the -devel branch. Thank you for the report!

What was the fix?  I can't find anything which looks likely to have been the fix with 'git show 8dbe78765bda12b36dc6b25c295dcf87ea4bb875', which is the commit with the log message saying it's fixed.

[jamespetts]

Neroden,

it was a very subtle problem: on open water, there is no speed limit, so the method for returning the speed limit was set to "UINT_MAX" for a 32-bit unsigned integer. For some reason, however, the speed limit of the way was put into a 32-bit signed local variable in the method. The minimum of all the various possibly applicable speed limits was set, so that the actual speed limit was set to a negative number. That then meant that the actual speed was set to a negative number (as there is an algorithm that sets the actual speed to the minimum of the current speed and the speed limit), which resulted (for reasons that I did not investigate) in an effectively infinite speed: hence apparent teleportation. I fixed it by changing the local variable to an unsigned integer.

[neroden]

Neroden,

it was a very subtle problem: on open water, there is no speed limit, so the method for returning the speed limit was set to "UINT_MAX" for a 32-bit unsigned integer. For some reason, however, the speed limit of the way was put into a 32-bit signed local variable in the method.

Sigh.  I guess my plan to clean up signed-unsigned conversions was a good one -- I hope I can get back to it.