Oh, this report is from many months ago, well..maybe not exactly FARL that cause it.
But i can assure you it's still happening even as of last night, i disable this mod (plus many other) to test out a set of other mod.
When this mod get re-enabled, then i loaded a save. it doesn't work.
There's not even a script-update activity from this mod whatsoever.
This is also happening with your other mod "Train Skipped Fulfilled Station".
However, the solution is either the one i posted earlier (this mod were activated before FARL/everything else;usually a newly installed mod),
OR, and this a more reliable "fix":
After the save is loaded, i need to re-save it, then either reload the save file, or sometimes i even i completely exit the game / relaunch.
No, there's something that this mod can't do.
Well, actually it's not this mod fault with the functionality being offered.
I setup the rail like this
A (Load/outpost) -> B (waiting/supply) -> C (unload)
In B they're waiting a signal from C to depart (When C reach lower threshold, sent X number of train, stop sending above upper threshold)
The non TSM way (with only Train Concurrent) is i just sent the signal through circuit wire.
Problem is, let's say there's only 1 train demand, but there are 10 train waiting,
When the signal is received in B, all 10 train managed to depart, although 9 of them will goes to a loop because 1 already managed to lock the target by Train Concurrent.
During my test, it appear i need to delay about 10 ticks before Concurrent TrainStop mod recognize that there are train already depart.
It goes like this :
The very 1st B trainstop get signal instantly, while the next train stop only get them after 10 ticks delay, then the next one is also 10 ticks delay after the 2nd one, and so on.
Only with that approach that a correct number of train managed to depart.
Problem is, on huge demand, let's say 30 train demand = 30x10 ticks=300 ticks.
So the order took 5 seconds to finished.
This pose a problem because the late game plan setup will be much-much bigger than this.
That's where TSM comes in.
It took care of that timing. So no need for me to determined timing.
But, TSM didn't like if the unload station were given the same name.
So, a wrong amount of train can be arrived at wrong target station (usually the closest one)
While other station that also giving the order never received a train.
So the idea was to combine that two benefit. TSM will take care the timing problem and dispatched the amount of train needed, while the Train Restriction will took care the distribution of that train.
Basically it's not the way TSM is intended to use, but there is much bigger potential with combination of this two mod.
What's even greater is the way TSM and this mod counting/restrict the amount of needed train is exactly the same.
I don't even need to change the circuit setup in unload for this mod for TSM at all, it's exactly the same setup.
Just to be clear, i'm not forcing you to make it compatible with TSM, but if only...
TLDR, the benefit :
- Exactly the same circuit setup in Unload/requester. No need to change anything.
- No need to naming the target uniquely (TSM problem). Which in result is a neater naming.
Edit 1 :
Wait a minute, i just realize that if you can somehow fix the behaviour of train managed to departing on signal cue despite being restricted by Concurrent mod , then there's no need for me to use TSM at all.
Or is it can't be done ? Vanilla train signal took over priority ?
Edit 2 :
Just test it on small scale test world, only 9 train.
The "still departing due signal" behaviour didn't happen at all, a correct number of train is the only departing one.
The other were stay in the stop.
But i swear it happened from my last playthrough, reproducible, constant behaviour.
Thus why i have to resolve it using delay.
Perhaps a big number of train that this mod handle at that time prompt that behaviour ?
This is weird, but if this were fixed then i'm a very happy player 😁