QUOTE(AT RR @ Oct 15 2007, 08:15 AM)
Everyone,
Thank you for your input. Yes this route does have problems with duplicate track numbers that is why I use locations the SWLACT generates to verify the tracks on the SWLTDB. When I generate the final template I edit all the duplicate track numbers and add a discription IE: 1 YD S. Oak, 1 YD Weehawken Ect. I also have compiled a master list for this route with all the sidings, railroads Ect. to check for duplicate numbers in the SWLTDB. The problem is not with the duplicate track numbers as I can usualy ID the railroad / location from my seed list, the problem is numbers that don't match ANY number that is generated.
On other templates just changing the ID number up or down one digit so they would match the SWLACT worked, they also worked in this template. Back th the reason I regenerated the two data bases, When doing my final runs on all the sidings prior to releasing this template I started getting I/O errors and could not find a problem in the Debug data. My thought was the problem may be the adjusted location numbers so I regenerated the data in AG4.2
The new question is did I open up a new bag of worms and the adjusted numbers are OK?
Could the problem be related tho other factors in the template?
Steve, if I get a chance tonight I will send you the files that started this thread not the current ones that may mask the real probem. Please post you findings as we all may learn from this and it will be help for all in the future.
Thanks,
Peter
I figured out what the problem is here.
Basically it boils down to the duplicate name issue. As mentioned we did address the problem of dealing with two numbers for each siding, but, this is done by matching siding names. So when there are duplicate names AG can come up with the wrong match. One of our users (Eric) shared with me an idea for really fixing this rather than using names to match. For those who are interested in the details, take a look at these two "SidingItem" entries from the Usa_NJC.tdb track database file:
SidingItem (
TrItemId ( 1279 )
TrItemSData ( 41.9926 00000002 )
TrItemRData ( 192.293 8.153 145.872 -10971 14369 )
SidingTrItemData ( 00000000 1280 )
SidingName ( 2 )
)
SidingItem (
TrItemId ( 1280 )
TrItemSData ( 293.699 00000002 )
TrItemRData ( 127.309 11.6909 388.787 -10971 14369 )
SidingTrItemData ( ffff0000 1279 )
SidingName ( 2 )
Now if you are paying close attention you will see that there are two markers for the siding with the name '2', one is 1279 and the other is 1280. But in this case there are several sidings named 2 .... one is number 722 and 723. Anyway the fix, which I will implement in AG 4.2.1 which I'll release very soon, is to use the "SidingTrItemData" for the other number. Notice that the second number in SidingTrItemData for siding marker 1280, is 1279. And notice that likewise the SidingTrItemData for siding marker 1279 is 1280. So now instead of AG GUESSING, it will be able to DEFINITIVELY IDENTIFY THE SIDING ITEM PAIRS! This idea was suggested to me by a new user named Eric, my thanks to Eric for the idea.
Ok so what is wrong with this template? In this case, through no fault of your own, you picked the wrong " 2 " number to use (722). There is no car actually on track 722, although it is listed in both the SWLTDB and SWLACT files as having a car there. So what happens is AG can't find a "seed car" to use to place the car and fails. Now that is a BUG in AG4 which I am also fixing in 4.2.1: instead of failing with that unhelpful error, it will now say something useful, in this case "Unable to place car on track 722 because there is no 'seed car' there."
I removed track 722 from the SWLTDB file and was able to generate activities without problems. I will email the fixed SWLTDB file directly to you (it won't help other readers of this forum since they don't have this template yet ... though the information here might.)
So truly this is more an AG4 bug, but one that is only brought out when route designers name two sidings using the same name (in this case the name was simply '2' which you changed to 'Yard 2', which is of course fine).
I will get the patch posted this week. In the meantime though this template, with the entry for track 722 removed, works.
If you continue to have problems please wait for me to get the patch posted and then regenerate the numbers using 4.2.1. Thanks for pointing out the problem and sorry about the frustration I know it caused.
Cheers,
Steve