I\O ERROR Options

[AT RR]

Steve / Norman
When running AG on an updated template i'm working on when I compile the activity everything goes fine until the end and I get an I\O error. My question is what should I be looking for in the files that may cause this problem?

Thanks,
Peter

[AT RR]

Steve,
Thank you for the help. Is their a forum out on the net for route designers? It would be great if this info was out there that when the track numbers are consecutive or when you reuse the same track number it could cause problems with templates or activities generated for the route.

Peter

[sgdavis]

Steve,
Thank you for the help. Is their a forum out on the net for route designers? It would be great if this info was out there that when the track numbers are consecutive or when you reuse the same track number it could cause problems with templates or activities generated for the route.

Peter

Peter,

Yes there is a route design forum on www.train-sim.com. The track numbers WILL typically be consecutive and that is part of MSTS and shouldn't be an issue, especially once I release my minor upgrade. MSTS assigns the track numbers (actually "SidingItem" numbers, for each siding marker, of which there are always two).

However duplicate track names ARE a route design issue and at the very least cause confusion when users attempt to complete activities since there is no way to determine which "Yard 2" is meant in a work order (and setting out at the wrong one will result in an "unsuccessful completion" whether running a regular 'scripted activity' or an activity created by Activity Generator). So if I were to post I'd post about avoiding duplicate names not the numbering issue as they can't control that. And MSTS never assigns the same sidingitem number twice so that part is taken care of internally.

I take it the file I sent works ok then?

Thanks,

Steve

[AT RR]

Peter,

Yes there is a route design forum on www.train-sim.com. The track numbers WILL typically be consecutive and that is part of MSTS and shouldn't be an issue, especially once I release my minor upgrade. MSTS assigns the track numbers (actually "SidingItem" numbers, for each siding marker, of which there are always two).

However duplicate track names ARE a route design issue and at the very least cause confusion when users attempt to complete activities since there is no way to determine which "Yard 2" is meant in a work order (and setting out at the wrong one will result in an "unsuccessful completion" whether running a regular 'scripted activity' or an activity created by Activity Generator). So if I were to post I'd post about avoiding duplicate names not the numbering issue as they can't control that. And MSTS never assigns the same sidingitem number twice so that part is taken care of internally.

I take it the file I sent works ok then?

Thanks,

Steve

Steve,

I haven't tried the change yet, will do tonight and let you know.

I think there second reason for the problem. The secondary number for yard 2 LV Jersey city is the same as the

primary number for Claermont yard track 2. These tracks worked fine as long as the path started in another region

and these tracks were used as destination tracks. On my final path I was using Claermont yd as the path start and

finish and as source track causing the conflict. When using the other paths the program wasn't looking source cars

at these locations and ignored the conflicting location and only picked one that worked.


722 Yard 2 LV JERSEY CITY 1 10 A 291.5064 I A 1279
1279 Yard 2 CLAREMONT YD 2 8 A 240.6565 Y A 1389

Does this logic work?

thanks,
Peter

[sgdavis]

Steve,

I haven't tried the change yet, will do tonight and let you know.

I think there second reason for the problem. The secondary number for yard 2 LV Jersey city is the same as the

primary number for Claermont yard track 2. These tracks worked fine as long as the path started in another region

and these tracks were used as destination tracks. On my final path I was using Claermont yd as the path start and

finish and as source track causing the conflict. When using the other paths the program wasn't looking source cars

at these locations and ignored the conflicting location and only picked one that worked.


722 Yard 2 LV JERSEY CITY 1 10 A 291.5064 I A 1279
1279 Yard 2 CLAREMONT YD 2 8 A 240.6565 Y A 1389

Does this logic work?

thanks,
Peter

Peter,

Yes that makes perfect sense. I don't think MSTS can actually assign the same number to two different tracks though so in this case I fear Activity Generator incorrectly matched up these numbers based on the track names being the same, i.e. AG SHOULD HAVE matched 722 with 723 and 1389 with 1279 but it matched 1279 with both. This is what I will fix in 4.2.1. I think I "fixed" it by deleting track 722 completely. A better fix and you won't have to wait for the patch, would be to tie 723 with 722 and leave the pair 1389/1279 as is. At least I think that will work, please give it a try.

Thanks,

Steve