fix no-stop zone unnecessarily restricting rail throughput

currently reserved tracks block trains from moving there even if by the time train reach there the block will be free, causing no stop-zones to force 1 train length spacing between trains even though there are no incoming converging trains.

what you want to do is store time dimension on block reservations in code, so test the block free-ness at t time not just at current time. if train is able to move forward, it should release blocks at corresponding times.

this way no stop zones won't force 1 train length spacing between trains.

This works as intended. Storing extra time won't be able to guarantee that the next train allows enough space for the previous train to clear the no-stopping zone. If you don't want this behavior, remove the zone or adjust the track layout.

on a second thought, the current algorithm already does this on plain tracks, why can't we just have the algorithm probe extra spaces ahead for the no stopping zone?

storing timestamp on the reservation for clearance will guarantee the no-stop zones are cleared. probably have to add a handle to the reservation block for the train that is reserving it also (which you probably already have), and trigger extra probes ahead for the train infront (which will chain further probing for more trains ahead if required)

When reserving a no-stopping zone, train must find a free track beyond that zone. If that piece of track is occupied by another moving train, it would have to somehow estimate whether that train would move out in time, which is non-trivial because train may start braking at any time. This does not have to do with reservation timestamps.

it is not an estimation. is is determinate with recursive probing

"whether that train would move in time" is exactly we add another parameter in the reservation which stores the frame the current train reserving it would free it. probably make this parameter a list which stores all time reservations sequentially

with correct setup just have to upgrade reserve_track(x,y) to reserve_track(x,y,t)

with reserve_track(x,y,t), you would have to be able to predict future though

predicting the future sounds fancy but all it is is each track block reservation (i'm assuming you are tracking reservation tile by tile implied by the train ui) stores an extra field with list of each item being (handle to train, reserved until). if t is < than the last reserved until, then the train calling reserve_track will have to make adjustments to its acceleration to delay reaching that track (including stopping). when a train is able to reserve n tracks in front, it updates its trailing reservations (starting from the end of the train) to time it will leave that block.

if you understand recursion this is only few lines of code

when a train is stopped or going to be stopped (eg at a station) the reservation does not store the time leaving marking it as indefinite, then it would behave like how it is behaving now.

its just treating t dimension homogenous with x and y dimension

Right, but constantly updating all blocks with estimated times could add a significant overhead to the system, and we would have to support one block being reserved by multiple trains at different times which we don't support now.

arent you already tracking reservation tile by tile? or is that just ui and you are actually tracking reservation by track segment and length

adding a single field to already being tracked train tiles is hardly an overhead.. especially how cheap the train calculations are. real poor optimisation is in truck pathfinding

Trains are tracked by blocks. Keeping times updated would mean updating all reserved blocks of all trains every tick with non-linear time estimations. That is non trivial overhead.

Moreover, all blocks would have to support being reserved by more than one train, significantly increasing per-block memory requirements.

no, you already stored the frame the train is leaving that block once, you don't need to update it every tick

reserving a block by more than one train i already explained, you store the single field as a list that stores tuples (handle to train, frame reserved until)

If the train is accelerating or braking, or the rate of acceleration changes, all blocks have to be recomputed

Storing a list of trains per block is a big no no, lists have way too big memory overhead

you only have to update the reservation twice, once indefinately, once when the train is able to reserve track ahead

not every tick

You cannot predict when the train leaves a block without knowing its speed for the entire duration of reservation

well then store it as mutable array

you can predict it. when the train is able to reserve the track in front, you know what time that train will be reaching that block,. that same time is leaving the end block

cmon, i countered every single thing you said

But you are not right, you cannot predict it because speed constantly changes

And again, we cannot afford dynamically-allocated array or list per block, that is too slow

that is not slow, you don't even have to mutate the array other than rare occasions

how many trains are realistically going to reserve a block

we give our kids years of calculus training yet developers cannot think in derivatives : (

once a train perceives a block it cannot reserve it can calculate speeds and time reached at all points of reservation blocks in one tick, not every tick

problem is you are only thinking of instantaneous values

It's already the case that trains can advance into non-stop zones before there's enough space for its entire length.

The challenge is mostly that it has to be pessimistic. It has to work even if the train ahead applies max braking the next step all the way to a stop.