LTN 1.13.0 uses temporary stations to path to specific provider and requester without relying on stop names.
This seems to mess up your logic for when to jump to a new train and which train to jump to.

Hi! For some reason I didn't get a notification about your issue. It is probably fixed in mod version 0.18.5.

BTW, I would really like to have a signal from LTN mod that provides updated scedules when they are created, because now I just subscribe to ALL train schedule updates, including made by players, and filter only those that are made by script, etc etc. The problem was that deleting temporary station is also a schedule update. I didn't find any API for that in LTN mod, at least in version 1.12.x.

event.deliveries from on_dispatcher_updated already includes that information.

I've tested it, and it has deliveries field, but that field includes all the deliveries that are active now, and than I need to iterate through it looking for trains that are leaving the depot. It would have been nice to have an event that fires only when new deliveries are created and contains list of only new deliveries.

A list containing only deliveries created this update cycle is not going to happen. Such a list is useless to LTN itself only moving overhead from your mod into mine.

I could add on_delivery_created, raised for each created delivery.
In practice adding deliveries from that event would be just as quick as comparing event.deliveries with global.deliveries.

I could add on_delivery_created, raised for each created delivery.

That would have been nice.

In practice adding deliveries from that event would be just as quick as comparing event.deliveries with global.deliveries.

Sorry, didn't understand what you meant. Have global.deliveries variable with current deliveries, and on each update do (figuratively speaking) new_deliveries = event.deliveries - global.deliveries to get the list of new ones?

local function on_dispatcher_updated(event)  
  for train_id, delivery in pairs event.deliveries do
    if not global.deliveries[train_id] then 
      -- new delivery
    end
  end
  global.deliveries = event.deliveries  
end

With one event per delivery you'd also have to subscribe to on_dispatcher_updated just to have something telling you when all deliveries are created.
The more I think about it the less sense an event for on_delivery_created makes.

lua local function on_dispatcher_updated(event) for train_id, delivery in pairs event.deliveries do if not global.deliveries[train_id] then -- new delivery end end global.deliveries = event.deliveries end

That's what I had in mind, thanks. Will try it during the weekend.

With one event per delivery you'd also have to subscribe to on_dispatcher_updated just to have something telling you when all deliveries are created.
The more I think about it the less sense an event for on_delivery_created makes.

Yes, I understand that this won't be a popular API function. I just didn't want to iterate through all the deliveries because I thought it would be slow, but that's probably just premature optimization.

Used your code snippet in 0.18.6 version. It seem to work, should change nothing for users, but code is probably a bit cleaner. Thank you.