[Railcat]

Occurred in X3863.

In X3875 there seem to be an error correction: Incorrect calculation of remaining length after a train is stored in a pool.

But this problem still occurred in X3875.

Another problem is about the $triggers command. It seems to have taken no effect from X3863. The result is equal to $forms. Is this correct?:sign_thanks:

[roeter]

Engines send to a pool are stored quite close together - see picture.
I can't quite see in the picture above how far apart the engines are. If they are too close, it could also be a problem with the bounding box of one of the engines.
But that was not the problem, anyway - the problem occured on pools with multiple storage roads when a road was full and storage should switch to the next road.
As far as I know no changes were made relating to $trigger, but I'll check if anything went wrong somewhere.



Regards,
Rob Roeterdink

[QJ-6811]

When I look at the top picture, I see 2 DF7 locomotives (red). The blue HDX has been driven through the last locomotive.

[Railcat]

Thank you for the reply.

From the picture in the first post, you can see there are two "engines". Actually the second engine is not just one, it's seven! So my question is not focused on the gap between the two groups of the engines, actually my question is why there're seven trains gathered together in the second group. I have attached some pictures, maybe through them the problem can be seen clearly.

Figures of the two types of engines:



The ESD_Bounding_Box set of the two types of engines:
------------------------------------------------------------------
SIMISA@@@@@@@@@@JINX0t1t______

shape ( HXD_3C0190.s
ESD_Detail_Level ( 0 )
ESD_Software_DLev ( 2 )
ESD_Alternative_Texture ( 0 )
ESD_Bounding_Box ( -1.59 0 -10.0 1.59 4.268 10.0 )
)
------------------------------------------------------------------

My storage paths set, this pool has seven paths:


My pool file set:
-----------------------------
;#comment
#comment;pool
#name;Shanghai
#storage;p1
#access;p1_1
#access;p1_2
#storage;p2
#access;p2_1
#access;p2_2
#storage;p3
#access;p3_1
#access;p3_2
#storage;p4
#access;p4_1
#access;p4_2
#storage;p5
#access;p5_1
#access;p5_2
#storage;p6
#access;p6_1
#access;p6_2
#storage;p7
#access;p7_1
#access;p7_2
------------------------------------------

[ebnertra000]

So are these engines all supposed to be placed on separate tracks, or are they all based from the same path (and presumably, start point)?

On a side note, where did you get those engines, especially that diesel? They look quite good

[roeter]

ebnertra000, on 16 June 2017 - 07:47 AM, said:

So are these engines all supposed to be placed on separate tracks, or are they all based from the same path (and presumably, start point)?

The pool logic is supposed to work that out, that's the whole point of the pool mechanism.
What is supposed to happen is that engines are stored in the first defined track, and if that is full, they start using the next track etc.
Here's a picture of a properly filled out pool at the start of the day.

There are six trains stored in the pool, over 4 tracks, two different types of units.
Normally, you would have to work out carefully where to store which train and which to extract first etc.
That is now no longer necessary, you just request a train from the pool and something will show up.
And if no longer required at the end of the day, you send the train back to the pool and the pool logic will sort out where to store it.
And ofcourse you can send trains to the pool and request them back again during the day as needed, e.g. units required during the morning and evening rush-hours but not inbetween can be send to the pool at the end of the morning rush and requested back again in the afternoon.

Quote

Thank you for the reply.

From the picture in the first post, you can see there are two "engines". Actually the second engine is not just one, it's seven! So my question is not focused on the gap between the two groups of the engines, actually my question is why there're seven trains gathered together in the second group. I have attached some pictures, maybe through them the problem can be seen clearly.

Sorry - I did indeed miss that, I didn't know these engines and thought they were supposed to look like that.

This is indeed the problem I had, but in my test environment, that problem is now solved. So I'm a bit puzzled that it still occurs here.

Two questions :
First : does this problem occur at start, that is - are these engines created in the pool (for later use), or does this problem occur during (pre-)running, that is - are these engines send to the pool one by one?

If it is the first problem (engines created in the pool), can you test what happens if you send the engines to the pool one by one?

It is rather important to know this, as these are differents bits of code and I need to know if the problem occurs in either the one or the other or, indeed, both.

Second : you have two access paths for each storage path. Do you access the pool from both ends?
That does not work, and could explain what happens. A pool can only be accessed in one direction.

Regards,
Rob Roeterdink

[Railcat]

roeter, on 16 June 2017 - 08:59 AM, said:

Two questions :
First : does this problem occur at start, that is - are these engines created in the pool (for later use), or does this problem occur during (pre-)running, that is - are these engines send to the pool one by one?

If it is the first problem (engines created in the pool), can you test what happens if you send the engines to the pool one by one?

It is rather important to know this, as these are differents bits of code and I need to know if the problem occurs in either the one or the other or, indeed, both.

Second : you have two access paths for each storage path. Do you access the pool from both ends?
That does not work, and could explain what happens. A pool can only be accessed in one direction.

Regards,
Rob Roeterdink

Thank you for your reply.

Answers to your two questions:
First: The pool is full empty at the start of the timetable. All the engines you see in the picture are sent to the pool one by one during running. Since you mentioned this, I then made a test on creating one engine in the pool directly and then sent others to the pool one by one during running to observe the result. But the test couldn't be started. The information I got in the log was: Information: Invalid starttime $create /pool=Shanghai for train K1047:x, train not included. So I couldn't know the result of the test.

Second: Since you mentioned in the document: Only dead-end storage areas are supported. Though you see from the picture that my pool can be access from both ends but currently I use it as a dead-end pool, so my all access paths for each storage are in the same direction. I think it's not the reason to this problem.

Sincerely hope for your further help. :sign_thanks:

[roeter]

Attached here is a special test-version of the program which prints lots of information on what happens in pools to the log-window.
Can you please run this test-version and upload the resulting logfile?

 PoolTest.zip (5.3MB)
Number of downloads: 384

Regards,
Rob Roeterdink

[Railcat]

roeter, on 18 June 2017 - 11:51 PM, said:

Attached here is a special test-version of the program which prints lots of information on what happens in pools to the log-window.
Can you please run this test-version and upload the resulting logfile?

Regards,
Rob Roeterdink

Thank you for your help. Below is the log file. Please check.
Test began at 5 o'clock. Several trains were sent to the pool during pre-loading and two trains after loading complete, then I exited the test. I think there's enough data for you to analyze. :sign_thanks:

 OpenRailsLog.txt (71.63K)
Number of downloads: 363

[roeter]

Committed a patch in version 3880, that should sort this out.

As for placing engines in the pool at the start : there's a small typo in the document.
The command to place engines in the pool at the start is : $static /pool=<poolname> - not $create as was stated in the document.

I have checked the code and nothing has been changed w.r.t. the $trigger command. But admittedly I have not used it for a long time, so perhaps something was broken earlier. I'll have a look at it, but there are some other issues still hanging around so it may be a while before I get down to it.

Thanks for your help,
Rob Roeterdink

[Railcat]

roeter, on 19 June 2017 - 02:56 PM, said:

Committed a patch in version 3880, that should sort this out.

As for placing engines in the pool at the start : there's a small typo in the document.
The command to place engines in the pool at the start is : $static /pool=<poolname> - not $create as was stated in the document.

I have checked the code and nothing has been changed w.r.t. the $trigger command. But admittedly I have not used it for a long time, so perhaps something was broken earlier. I'll have a look at it, but there are some other issues still hanging around so it may be a while before I get down to it.

Thanks for your help,
Rob Roeterdink

What a fantastic function it is! Everything goes well now. Thank you very much. :sign_thanks:

[VicenteIR]

Please fix a problem whith the $triggers command. It works like $forms again.