[Bug] choose signals ignoring way constraints in some cases

[Mariculous]

I just found a bug.
Trains guided to an alternative platform by a choose signal will only consider constraints of the first vehicle of the convoy, other constraints will be ignored.

This resulted in class 91/Mk4 trains entering overhead DC electrified tracks at a terminal platform and getting stuck there after reversal.
Could not reproduce this without choose signals nor without a constraintless car in the front, thus I highly expect that only this combination is affected.

Sidenote: Shouldn't extended mainain constraints on a per-convoy level, as we never care about constraints of individual vehicles?

[jamespetts]

Thank you for the report. Are you able to upload a reproduction case for this? I should be most grateful.

[Mariculous]

Sure,
load the attached save, and watch train (1) moving.
Affter reversing it will move towards towards the choose signal, where it will chose a platform that it should not be able to use.

Note the same does not seem to apply to any other kind of constraint-like restrictions e.g. no electrification at all or axle loads.

[jamespetts]

Thank you for your report. I believe that I have now fixed this; I should be grateful if you could re-test with the next nightly build.

[freddyhayward]

The new version won't build on my machine nor on the server. I get the error:

Code Select Expand

simconvoi.cc:8412: undefined reference to `vehicle_t::check_way_constraints(weg_t const&) const'
And after checking the relevant code I don't have a clue what the issue is.

[Matthew]

The new version won't build on my machine nor on the server. I get the error:

Code Select Expand

simconvoi.cc:8412: undefined reference to `vehicle_t::check_way_constraints(weg_t const&) const'
And after checking the relevant code I don't have a clue what the issue is.

I can't build either, the error message is:

Code Select Expand

===> LD  build/default/simutrans-extended
build/default/simconvoi.o: In function `convoi_t::check_way_constraints_of_all_vehicles(weg_t const&) const':
simconvoi.cc:(.text+0x110fb): undefined reference to `vehicle_t::check_way_constraints(weg_t const&) const'
collect2: error: ld returned 1 exit status
common.mk:21: recipe for target 'build/default/simutrans-extended' failed
make: *** [build/default/simutrans-extended] Error 1

All part of the fun of daily improvements and nightly builds!

P.S. Here is a Linux build as of the nightly of 20-21 January (#6bf376a8b), in case anybody wants it for a single-player game. It says it's #bea6f77, but since it does compile, I don't think that can be right.

[jamespetts]

I think that the nightly server has managed to build the latest version, since the build date for the version available on the server is early this morning, and there is no logic in the automatic build scripts to revert to an earlier commit if the current build fails to compile.

Can I ask one of you to re-test this bug with the nightly binary from the server to confirm this?

I am afraid that the code appears to be entirely in order, suggesting that the problem may be with the compilers that you are using. May  I ask what versions of what compilers that you are each using?

Edit: I should note that the only slightly unusual thing about this method is its inline declaration. There are some compilers that do not like inline declaration for functions that are not defined, but only declared, in the header file; I suspect that the current "inline" modifier has no effect in any event. I will remove "inline"; I should be grateful if you could test whether that helps.

[Matthew]

I think that the nightly server has managed to build the latest version, since the build date for the version available on the server is early this morning, and there is no logic in the automatic build scripts to revert to an earlier commit if the current build fails to compile.

The build date that I see for both Linux and Windows builds on http://bridgewater-brunel.me.uk/downloads/nightly/ is early yesterday morning, 2020-01-21.

Can I ask one of you to re-test this bug with the nightly binary from the server to confirm this?

If I understand the bug correctly, then it is not fixed in that Bridgewater-Brunel build. Train 1 smoothly glides into a platform that does not have AC catenary, only Third Rail electrification.

I am afraid that the code appears to be entirely in order, suggesting that the problem may be with the compilers that you are using. May  I ask what versions of what compilers that you are each using?

I am using GCC (G++) 7.4.0.

Edit: I should note that the only slightly unusual thing about this method is its inline declaration. There are some compilers that do not like inline declaration for functions that are not defined, but only declared, in the header file; I suspect that the current "inline" modifier has no effect in any event. I will remove "inline"; I should be grateful if you could test whether that helps.

I will try to do this later today.

EDIT: When commit #fce367b is pulled, I can compile and run James' master branch. The bug also appears to be fixed: train 1 refuses to enter the platform without AC catenary.

[jamespetts]

Splendid, thank you for letting me know. I believe that I had misremembered to-day's date and thought that it was still the 21st; my apologies. Thank you for confirming both fixes.