majoca wrote: Mon May 12, 2025 2:38 pm

Added LuaGuiElement::quality read/write for "sprite-button" type.

If this is what I think it is, THANK YOU! This was so annoying to implement with negative margins and such.

Seconded. Way to sneak that huge change casually into the change log.

Contrary to the FFF where landfill is described as removable, when loading a 1.1 save and migrating it to 2.0, the landfill that was placed with the 1.1 version of the game can not be removed.

Screenshot 2025-03-19 at 20.31.49.png

(I marked all the landfill for deletion but only the landfill ...

There are "pre" events for all "mining" ways in which an entity can be removed:

- on_pre_player_mined_item -> on_player_mined_entity
- on_robot_pre_mined -> on_robot_mined_entity
- on_space_platform_pre_mined -> on_space_platform_mined_entity

However, there is no pre-event for on_entity_died. So ...

Works for me. It is more a curious corner case than anything else.

- Create a new game without space age. Create a rocket silo. Start building rockets until both green bars are full (one rocket on the launch pad, one "in the silo").
- Save the game.
- Enable space age
- Load the game.

The silo still contains a rocket on the launch pad. But "in the silo" are now ...

Thanks for adding that explanation. I will update my code accordingly.

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 ...

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.

Hi,

With the release of the LuaSchedule API in 2.0.36 (and its various iterations until currently 2.0.39), it is now possible to influence train schedules much more than with the limited 1.1 (and the previous 2.0 API).

I have put together a number of things for the 2.3.0 release of LTN that will ...

I can not really make sense of this. I have trains with schedules that look like this:
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.

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:

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

AddRecordData uses "RailDirection?" as the attribute definition, this should probably be defines.rail_direction as e.g. https://lua-api.factorio.com/latest/cla ... _direction

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

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.

It seems slightly more complicated. If the first stop is a temporary stop, then the new stop is put *behind* that temporary stop but *before* the first permanent stop:


> for i = 1, train_schedule.get_record_count() do print(serpent.line(train_schedule.get_record{ schedule_index = i })) end
(nil ...

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


> 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 ...

(not sure if this is a bug or an API limitation)

Adding a temporary rail stop:

> 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 { rail = rail, temporary = true }
(nil)
> for i = 1, train ...

( this is a debugging session with an actual train and schedule )

> 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 = 'zzz_first' }
> train_schedule.add_record { station = 'aaa ...

The (old?) train schedule API allows setting the rail direction (see https://lua-api.factorio.com/latest/concepts/ScheduleRecord.html)

The new LuaSchedule API offers AddRecordData for adding a record: https://lua-api.factorio.com/latest/concepts/AddRecordData.html which does not contain the rail ...

Thank you for adding this to Factorio!

A few comments:

- LuaSchedule::add_record should either return the index at which the record was inserted *or* have a parameter that allows defining where the record goes in the schedule. Currently I do

schedule.add_record { ... }
local index = schedule.get ...