[2.0.38] changing train schedule at current stop does not work

[hgschmie]

WIth 2.0.38:

Scenario:

Train sits at a station (just arrived)
Schedule was cleaned (all records removed)
Re-adding a new stop at index 1

This works:

Code: Select all

train_schedule.add_record {
    station = stop.entity.backer_name,
    rail_direction = stop.entity.connected_rail_direction,
    temporary = false,
    allows_unloading = true,
}

local record_position = { schedule_index = 1 }
train_schedule.add_wait_condition(record_position, 1, 'inactivity') 
train_schedule.change_wait_condition(record_position, 1, {
    type = 'inactivity',
    ticks = 300,
})

The green bar extends left to right, then the train waits for any change in schedule.

this does not:

Code: Select all

train_schedule.add_record {
    station = stop.entity.backer_name,
    rail_direction = stop.entity.connected_rail_direction,
    temporary = false,
    allows_unloading = true,
    wait_conditions = {
        {
            type = 'inactivity',
            ticks = 300,
        }
    }
}

Screenshot 2025-03-04 at 19.24.10.png (19.84 KiB) Viewed 274 times

So the inactivity timer never triggers.

Using a debugger, the train itself reports state == 1 (no_schedule).

[hgschmie]

I can not really make sense of this. I have trains with schedules that look like this:

Screenshot 2025-03-04 at 20.16.04.png (60.49 KiB) Viewed 258 times

which got added with a single add_record call (to the end of the schedule) and here both the "time" and "inactivity" wait condition work just fine.

[Rseding91]

Can you please post a save file and example mod showing this issue?

[hgschmie]

I want to say that this seems to be fixed with 2.0.39 but I am at an airport right now. Will verify when I get back home and post a save if needed.

[hgschmie]

I can reproduce the issue with 2.0.38 and confirm that it is gone in 2.0.39. So some change there made it go away.

The attached map, when loaded with 2.0.38, needs either the attached LTN 2.2.5 or 2.2.6 installed locally (sorry, can't download that from the portal).

2.2.5 uses the add_wait_condition/change_wait_condition code which works with 2.0.38, 2.2.6 uses adding wait_conditions directly with add_record.

2.2.5 works with 2.0.38. 2.2.6 shows the described behavior.