[2.0.72] Interrupts based on *destination full* have delay on call

Don't know how to use a machine? Looking for efficient setups? Stuck in a mission?
MrGergoth
Inserter
Inserter
Posts: 36
Joined: Sat Jul 23, 2016 3:33 pm
Contact:

[2.0.72] Interrupts based on *destination full* have delay on call

Post by MrGergoth »

Video below

What did you do?
I trying to use train interrupt: if destination is full or no path to Load station - train going to Relax station*. I expect that Trains will wait at Relax station while they are no needed.

What happened?
- if train is green mean its mooving to Load station
- white trains are trains that interrupted by *destination is full* and mooving to depo
For unknown reason, i see delay on this interruption. On video 1, step by step:
1) Red train is empty and gonna look path to Load station
2) Train says *destination stop full* but still Red (mean its not interrupted yet - why?)
3) Relax station is not full so i expect interrupt instantly will be called
4) Interrupt is called and train becomes white. But... Interrupt has delay between 0-1.5 second.
Not happend always, but mostly times - interrupt is delayed (next part of this video shown this delay)

Video 2 - train have same error, but this time destination even not full (2 train of 3 possible), or maybe station was full 1 tick ago before i paused because train on destination just loaded (between 4 and 5 second on video). So, if i paused BEFORE station has 3\3 - why i dont get interrupt? Then i un-paused, its 2\3 and train got interrupt instead of mooving to empty station. I expected in this way: if station wasnt full - train becomes Green and moves to Load. Instead, train becomes White and goes to depo while station has 2\3 (mean NOT FULL). Mean, it was interrupted before pause while it was 3\3 but its interrupted after pause while station has 2\3 train (mean has one free train slot)

What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expect interruption works without any delay, or - if there are somethink like *interrupt check cooldown* - some calls are at least subscribed on events (c#, hi) like *got status destination is full? bro, its in ur interrupt - then check all other conditions*.

Does it happen always, once, or sometimes?
70% of time, both situations - delay and delay + ignored *train limit* while train 3 of 3 was at station (like on video 2)

Honestly, this 1 second in space age is pretty impactful while unloading too fast and its may break threshold between *player can unload full X belts with 240 items per second* and *player cant do this* (i have right now some such setups for tests where 0.5 second do full belts instead of not full just because 0.5 second).
Attachments
2.mp4
(13.78 MiB) Downloaded 11 times
1.mp4
(18.38 MiB) Downloaded 6 times
MrGergoth
Inserter
Inserter
Posts: 36
Joined: Sat Jul 23, 2016 3:33 pm
Contact:

Re: [2.0.72] Interrupts based on *destination full* have delay on call

Post by MrGergoth »

Upd: new video, same setup, but instead of interrupt *Cargo empty + Destination full* i use *Cargo empty + Circuit signal* where signal is limit train more than current train on destination. Result - no delay.
Looks like its not every interrupt delayed, its just *destination full* delayed. So, why interrupt *Destination full* not trigegred instantly if train icon literally says *Destination full*?
Attachments
4.mp4
(29.58 MiB) Downloaded 7 times
Post Reply

Return to “Gameplay Help”