[2.0.37] LuaSchedule::add_record adds temporary stops with a wait condition

[hgschmie]

Any temporary stop that is added with the add_record API looks like this:

Code: Select all

> for i = 1, train_schedule.get_record_count() do print(serpent.line(train_schedule.get_record{ schedule_index = i })) end
(nil)
> train_schedule.add_record { station = "test", temporary = true }
(nil)
> train_schedule.add_record { rail = rail, temporary = true }
(nil)
> for i = 1, train_schedule.get_record_count() do print(serpent.line(train_schedule.get_record{ schedule_index = i })) end
{allows_unloading = true, created_by_interrupt = false, station = "test", temporary = true, wait_conditions = {{compare_type = "and", ticks = 300, type = "time"}}}
{allows_unloading = true, created_by_interrupt = false, rail = "[LuaEntity: legacy-straight-rail at [gps=227.0,-1.0]]", temporary = true, wait_conditions = {{compare_type = "and", ticks = 300, type = "time"}}}
(nil)

If this wait condition is part of a temporary stop, it would be good to document it, otherwise adding wait conditions to a temporary stop is different than adding wait conditions to a permanent stop (as there already exists a wait condition with index 1).

[robot256]

The LuaSchedule interface right now replicates user input functions, so that's why it's making the wait condition automatically. There are some more updates to the API in the works to make things easier, not sure how this one will be handled.

[Rseding91]

Thanks for hte report. That's working as intended - although probably not super useful. For the next release I've added insert_record() which is probably what add_record should have been but oh well.

02-28-2025, 08-31-23.png (14.19 KiB) Viewed 1080 times

02-28-2025, 08-31-36.png (25.37 KiB) Viewed 1080 times

[Rseding91]

Small correction: it also supports 'temporary' but I forgot to include it when generating the doc files for the images.

[hgschmie]

Thanks, this sounds great! Can you make it return the actual index where the record was inserted? It would make subsequent modifications of the created record easier.

[curiosity]

which is probably what add_record should have been but oh well.

Better change it now while few mods use it and it's not in stable than wait till 3.0 and then leave it as is due to deadline.

[Rseding91]

Thanks, this sounds great! Can you make it return the actual index where the record was inserted? It would make subsequent modifications of the created record easier.

The index it’s added at is the one given or the end of none was given.

[hgschmie]

Understood. But now I have to call get_record_count if I added at the end unless I keep track of the schedule size.

[Viidi]

For some reason, temporary entries are inserted at the beginning of the schedule, and not at the end.

[Rseding91]

For some reason, temporary entries are inserted at the beginning of the schedule, and not at the end.

Yes, that’s how they work when a player does it in-game.

In the next release it will be changed so it just sticks it wherever you tell it to, or the end always if not told where.

[wiggleshark]

Is there any reason for this new behavior for temporary stops? Frequently I want to queue up stops in the order I select them.

Or I make a temporary stop, do something quick, hop back in, and select a new stop; my train goes there and (because the five seconds never completed at the first stop) five seconds later goes back to the original stop leaving me stranded.

[Rseding91]

Is there any reason for this new behavior for temporary stops? Frequently I want to queue up stops in the order I select them.

Or I make a temporary stop, do something quick, hop back in, and select a new stop; my train goes there and (because the five seconds never completed at the first stop) five seconds later goes back to the original stop leaving me stranded.

The behavior for temporary stops has not changed since they were added as a game mechanic years ago.

[wiggleshark]

Are you sure? It used to be [edit on 1.1.110] that when I created a temporary stop, it would either

1. Insert it before the current stop [edit and makes it active] or
2. If a temporary stop is active, append it to the sequence of temporary stops.

Now, regardless, it just inserts it before the current stop.

[curiosity]

Are you sure? It used to be [edit on 1.1.110] that when I created a temporary stop, it would either

1. Insert it before the current stop [edit and makes it active] or
2. If a temporary stop is active, append it to the sequence of temporary stops.

Now, regardless, it just inserts it before the current stop.

Can confirm it was always like that. Certainly on late 1.1. Download 1.1 or any other version and see for yourself if you don't believe.

[wiggleshark]

Alright, I did that. It has exactly the behavior I was describing. Now what? edit And no mods are enabled.

Maybe it's your turn? Download it and try. It has never had the behavior you describe. Unless you're misunderstanding...

The behavior I expect is that if I have 1 or more temporary stops, and one of them is active (in transit or stopped there), any new temporary stop is appended to the end of the sequence [edit of temporary stops]. But now when the new temporary stop is created, it is inserted before the currently active temporary stop.

[curiosity]

Maybe it's your turn? Download it and try. It has never had the behavior you describe. Unless you're misunderstanding...

1.1.109, 1.1.110:

• stop is added to the end
• active stop not changed

2.0.34, 2.0.39:

• stop is added to the end
• new stop made active

At no point have I observed what you describe, a temporary stop being added in front of the active temporary stop.

[wiggleshark]

Okay, so there was a bit of a miscommunication. I am seeing new stops added to the front before the active temporary stop. I'm running 2.0.36. This seemed to be what I saw in the message

For some reason, temporary entries are inserted at the beginning of the schedule, and not at the end.

I also saw other issues that were basically closed as 'not a bug'.

[wiggleshark]

Oh I think I see the confusion. It's the difference you noted:

active stop not changed

new stop made active

This is the thing that I feel is a regression. But not related to this issue and I'm sad I've thrown it off track.

[curiosity]

Okay, so there was a bit of a miscommunication. I am seeing new stops added to the front before the active temporary stop. I'm running 2.0.36.

Then why are you writing in a post-2.0.37 bugfix thread that can't possibly be the cause of your issue?

[Muche]

The issue described by wiggleshark has been reported in 118266 Train skips temporary train stop if new temporary stop is added, and was declared an intentional change in 2.0.