[0.8.3] Cargo Alert improvement

[0ptera]

Problem: Player uses station designs with unfiltered inserters. The current way of only checking cargo when leaving a requester does not alert when a train unloaded incorrect cargo at a dumb requester station.

Solution:

• [x] check train cargo against loading list when trains leave provider and requester
• [x] rename leftover cargo to wrong or incorrect cargo
• [x] Cargo Alerts should remain visible until manually cancelled by a player

[eduran84]

check train cargo against loading list when trains leave provider and requester

Which loading list do you refer to? I can see how loading incorrect cargo would be detectable by comparing shipment and train content. But how would I know that incorrect cargo was unloaded?

[0ptera]

Sorry for the confusion, loading list = delivery.shipment. I say loading list when talking about what should be loaded in and out of a train and shipment when it's inside the train or reserved.

[eduran84]

Makes sense. I'll look into it tonight.

[eduran84]

Going down that route would force me into listening for train status changes and figure out when a train leaves a provider. Any chance you could add an on_train_left_provider event, similiar to on_delivery_completed?

[0ptera]

Sure, I could do that. I am handling that case anyway, so firing one more event shouldn't impact performance.

A lazy way would be to check if delivery shipment counts have changed. Though that will fail for deliveries loaded to max train capacity

[0ptera]

Do you want anything beside the data sent in on_delivery_completed?

[0ptera]

I just noticed there already is a flag to indicate when trains left a provider: delivery.pickupDone

A version of LTN with the event is available in the 1.10.3 branch. If you need the event I'll keep it in, but I'd prefer if you could use the flag already in on_dispatcher_updated.

[eduran84]

To use the flag I would have to check every delivery with pickupDone == true against a list of all deliveries with pickupDone == false from the previous update to notice the change. Which means storing an additional table and performing the check on every update. Possible, but inefficient.

[eduran84]

I've pushed my first attempt at this to the 0.9.3 branch. It relies on the on_delivery_pickup_complete_event. If it's inconvenient for you to keep that around, I could do without it, but having the event is preferable (see above). If you are worried about event creep, you could consolidate all delivery events into one on_delivery_updated event, including the current data and a failed = true/false flag.

[0ptera]

I'm fine with having dedicated events for different states of a delivery. Wouldn't consolidating them make discerning between finished and pickup complete more involved?

The names of my events rub me wrong a lot more. No idea why I added "get_" prefix and "_event" suffix.