[1830] I bought 3T while 2Ts are still available about 18xx HOT 6 CLOSED

At https://18xx.games/game/133915?action=95 the displayed available trains look correct (ie just the 2-trains from the depot and other corporations), but when processing the buy train action it should probably enforce that the bought train is a legitimate one--that'll likely be the fix for this bug.

Not sure how this could have happened, one way is you could probably make a POST request with the right data but it doesn't sound like that was the cause here.

from 18xx.

@Ticketautomat1 you should undo to right before you bought the 3-train, and then you can proceed with the game like normal. If you don't undo and remove that illegal action from history, your game will break when the fix is deployed.

saved the game JSON here - https://gist.github.com/michaeljb/5a8cffb8d2d47ae25df331befec4db40

from 18xx.

I tried a simple approach in michaeljb@30e7f33

It broke 6 fixtures

• 18Ireland (39547 and hs_ljvktyhv_38235) - twice a 4H train was bought while one more 2H train was available, in the UI it looks like the 4H should not have been available, just like in the 1830 game here
• 1880 (1) and 18EU (74045) - in each of these a train of the correct rank was bought, but not the next one on the stack, ie in 1880 they were on the 6-trains and 6-4 was bought instead of 6-3
• 18Mag (76622) and Harzbahn 1873 (hs_gwlftpex_33770) look like this change actually breaks them when it shouldn't

from 18xx.

Here's a weird one, one 5T left while all 6Ts are gone (currently only in my local env). https://gist.github.com/michaeljb/a4e4a477d2926ab8cd44b78362cda6f0

This is because of #10609 and it's only getting into that exact state because of my local testing a fix (note: because of this fix, checking out this game in the future may require checking out commit 905dbbe or another master commit around this time), but if this train availability issue were fixed, then that game would break as soon as someone tried to buy a 6T instead of a 5T, which would be ideal.

from 18xx.

A fix that might be more backward compatible would be to enforce that the train being bought has the same name as the first in the depot, even if it’s not the same train by ID. OTOH this probably leaves a vulnerability for events that happen on a train other than the first of its type, eg 18NY or 18RoyalGorge

from 18xx.

Copying a note from @crericha in case it is useful for working on the underlying issue after #10889 is merged:

The potential ordering bug is then that we assume depot.available_upcoming_trains() is sorted lowest index train first. I don't see any explicit sorting, so maybe that's how the ordering is getting messed up?
@upcoming.group_by(&:name).values().map {|group| group.min_by(&:index)}.select { |t| t.name == @upcoming.first.name || @game.phase_available?(t.available_on) }

from 18xx.