[Gro.Bi]

 Weter, on 11 September 2021 - 05:34 AM, said:

Good luck further!

Thanks!

[M-M]

 roeter, on 09 September 2021 - 11:53 PM, said:

There's nothing wrong with pool definition, I think the problem is somewhere else.
In the pool definition the maxunit is set to 2. This means that the 2nd train is set to join the 1st train on the first storage track. That's how pools work - the storage tracks are filled to capacity, starting at the first defined track, and only when that track is full will the 2nd storage track be used etc.
The access to the pool is protected by signals. It could well be that these signals do not support call-on. So the 2nd train cannot get to the pool because the signal will not allow it to move onto occupied track.
You can test this by setting maxunit to 1, this will force the second train to go to the (unoccupied) 2nd storage track.
If that works, you will need to look at the signal script and ensure it will allow a train to call-on into the siding.

Regards,
Rob Roeterdink

#maxunits working for each track separately

fo example just storage tracks

#storage;Rig_TTS01
#maxunits;1
#storage;Rig_TTS02
#maxunits;1
#storage;Rig_TTS03
#maxunits;1

Maybe this work and help you.

[Gro.Bi]

 M-M, on 18 November 2023 - 11:56 PM, said:

#maxunits working for each track separately

fo example just storage tracks

#storage;Rig_TTS01
#maxunits;1
#storage;Rig_TTS02
#maxunits;1
#storage;Rig_TTS03
#maxunits;1

Maybe this work and help you.

Hi,

I have looked into my pool and found already that it is similar to your suggestion. But it didn't work as expected when I tested it 2 years ago. Now it works exactly as you say!

Maybe it's the reason that I now use Open Rails 1.5.1 that not yet was available at that time.

Thanks & Regards
Gro.Bi