To determine if a vehicle is next to a junction node is well beyond the current simplicity of the mod, and would involve some level of path finding. I'm simply not sure how that would be done/determined in the first place, let alone checking it efficiently for hundreds (or thousands?) of vehicles.

An option could be to check average speed or some other data that may already be available via the API (or at least determine average based on current vehicle speeds). Any suggestions?

Do you remember that other thing I mentioned weeks ago about that "hack" to force the game to recalculate the line rate by moving the slider of max. wait time and if this behaviour could be triggered by a script?
That also could help avoiding that more and more vehicles are added to an already gridlocked line by resetting the rate calculation to the "vanilla conservative estimate" then and when.

Another idea, based on the above:
One vehicle (of hundred, so 10 for a thousand) is taken as a random sample and the time it needs to move the entire line and its average speed is measured - and compared to the "vanilla conservative estimate" to see how much the values differ.
The more they differ, the more likely it is that a line is gridlocked.
This means that line is locked for adding more vehicles to it, the script even will remove empty vehicles gradually until the above mentioned difference goes away.
But then it's not set to be "free" again to have the same issue occur again, it will be flagged as "potential gridlock affinity".

Indeed, I do remember. Unfortunately haven't had time to explore it. Once you dive into the API, it can be somewhat time consuming. From the top of my head, I'm still thinking it might be possible to sample average speed to determine whether a line is "working" i.e. not gridlocked (either because of the line itself or some other reason - poor infrastructure?).

For instance, if average speed for a truck line is less than 10% (arbitrary number) of the (average) max speed for the vehicles on the line, then pause the adding of further vehicles.

This could however have some odd side effects that are yet to be discovered...

"Poor infrastructure" is not easily to be fixed because of the lack of proper asymetric roads.
Roads with one lane in one direction and two lanes in the other direction - or 2 | 3 - that can be connected perfectly fitting to a "normal" road optically, for junctions.
And not only with tarmac and from 1980 upwards; already with sand roads in 1850.
There are none.
And they're needed.

For sure! What I meant is that if a station has been placed in a location, and connectivity, that is less than optimal (including consideration to surrounding infrastructure and traffic amount), then there will be issues.

The way to find individual vehicle speed is pretty straight-forward (using the non-documented "game.interface.getEntity(id)" functionality. For instance:
>> game.interface.getEntity(144368)
(Note: list reduced)
speed = 13.46692943573,


Getting the modelId can be done via the (documented getComponent):
>> api.engine.getComponent(144368, api.type.ComponentType.TRANSPORT_VEHICLE)
{
(Note: list reduced)
transportVehicleConfig = {
vehicles = {
[1] = {
part = {
modelId = 3762,


However, how can I obtain information for that modelId? There's no documentation for this.

It is expected that top speed should be possible to obtain via the modelId.

Another possible idea (rather than checking average speed vs top speed) is to check how many of the "EN_ROUTE" vehicles that are moving (speed > 0). If, say, more than 50% of "EN_ROUTE" vehicles are not moving, then that is probably a bad sign... i.e. possible congestion somewhere, and no further vehicles to be added.

I've managed to whip up a quick and dirty congestion check, it's basically:
A vehicle is considered to be standing still if speed =< 1 (m/s?)
If more than 33% of EN-ROUTE vehicles (i.e. not at a station or in depot) of a line are standing still, then don't add more vehicles.

Once this has been tested more, can expand it to count for how long the threshold (i.e. 33%) has been exceeded, and start removing vehicles if the counter has been increasing for more than, say, 10 updates in a row. However, this could lead to congestion being masked (and the mod to seem broken), and thus not rectified, so some level of congestion is probably acceptable.

Sounds good. Will it be on Github to test?

Just pushed the commit to github now (NOT live in the workshop), try it out! Note that you can adjust the congestion threshold in 'sampling.lua', look for (Line 28):

local CONGESTION_THRESHOLD = 0.33 -- If the ratio of (EN_ROUTE) vehicles with zero speed exceeds this, then the line is considered congested.

Edit: I'm considering to change the 'is_congested' data to be a moving average 'congestion_ratio' instead. Makes it a bit easier to debug and can more easily be used in 'rules.lua'.

Did you not test it yourself?

I guess it's a missing end in line 327

Edit:
yes, it is

Sorry, that was the quick and dirty test (i.e. silly errors may occur in odd places...). I've done substantially more during the day. Will push a different version shortly to Github. Will not be live on the workshop yet.

A completely revised implementation uploaded. Congestion control rules are hard-coded into the the standard rules, and a congestion warning will be displayed in the console when vehicle addition is inhibited for lines using any of the default C/P/R rules. The congestion control will also remove vehicles if certain thresholds are met, as well as expeditiously remove vehicles in case of extreme congestion. The rules and implementation should probably be tuned further, but should work reasonably well in its current form. There's no setting for enabling/disabling congestion control.

To follow-up, I will most certainly make "Congestion control" a general mod setting, enabled by default. In addition, the "congestion" data will be possible to include in rules as well. One time permits, I'll get on with this.

An updated version on GitHub now that seems to work quite well for all the scenarios I've tested. I've spent way to much time on this.... :-) Give it a try and let me know if you discover any issues. There will be messages generated in the console regardless of whether you have "Congestion control" enabled or not, giving an idea of what it detects. The manual will be updated in due time.