Page 1 of 1
Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 11:37 am
by 92212
Hello all
I was editing a route last night after a day of working on it. Final save before going to bed. Upon pressing F2, the game crashed to desktop. Now said route will not load at all. I have narrowed it down to the Tracks.bin causing the CTD. Looking inside the .bin, everything looks normal. So, the question is, does anyone know of a way to track down where an error might be within the Track.bin file, or know of a knowledgebase where I could find the answer?? I have used DTG, but they haven't been able to help with this.
My previous version of the Track.bin loses all of yesterday's work, so I would really like to recover that if possible.
Thanks in advance for any help you may be able to give.
Kind Regards
Matt
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 5:26 pm
by brysonman46
Hi Matt
You have my sympathy, having been in this position myself. I assume that you can convert Tracks.bin to an xml (using serz), ie decompile. And can then read it in Notepad++ or equivalent. Are there no erroneous colour codings showing up? Will it convert back to a bin file (ie compile)? Did you do the editing in 64bit? Are you using the new version of serz? If the answers to all these questions is yes, then I do not know what you can do (apart from losing a day's work).
I now take great care with my Tracks.bin. I work in Windowed mode, with the route networks folder open on my desktop After every mod to the tracks/infrastructure, I make a zip of the current TrackTiles and Tracks.bin, giving it a date and letter (a,b,c,...). Takes but seconds, but when a crash happens, only a few minutes work lost. At the end of the session, if all is well, I keep just the last 2 versions (sometimes I may have second thoughts about the last mod, so easy enough to regress it)
hope all works out OK
regards
Nick
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 5:48 pm
by 92212
Hi Nick
Thank you for replying. I have compared the current corrupted Tracks.bin in .xml format against the old version in .xml. I have noticed something very interesting.
Here is the first part of the corrupted Tracks.bin:
Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<cRecordSet xmlns:d="http://www.kuju.com/TnT/2003/Delta" d:version="1.0" d:id="2096630176">
<Record>
<Network-cTrackNetwork d:id="2081758944">
<NetworkID>
<cGUID>
<UUID>
<e d:type="sUInt64">5743106815149506397</e>
<e d:type="sUInt64">6435675412336092071</e>
</UUID>
<DevString d:type="cDeltaString">581c7f5d-9d38-4fb3-a723-029ab01c5059</DevString>
</cGUID>
</NetworkID>
<RibbonContainer>
<Network-cRibbonContainerUnstreamed d:id="2081759072">
<Ribbon>
<Network-cTrackRibbon>
<_length d:type="sFloat32" d:alt_encoding="0000008097926540" d:precision="string">172.581</_length>
<RibbonID>
<cGUID>
<UUID>
<e d:type="sUInt64">5600138326040278804</e>
<e d:type="sUInt64">9855347869530546366</e>
</UUID>
<DevString d:type="cDeltaString">00ae7714-b023-4db7-be60-45e5ab3ac588</DevString>
</cGUID>
</RibbonID>
<Height>
<Network-iRibbon-cHeight d:id="1401320336">
<_position d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">1</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1401320348">
<_position d:type="sFloat32" d:alt_encoding="0000004040034040" d:precision="string">32.0254</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">1</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1401320360">
<_position d:type="sFloat32" d:alt_encoding="000000A0D6AC4E40" d:precision="string">61.3503</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1401320372">
<_position d:type="sFloat32" d:alt_encoding="0000004062C46240" d:precision="string">150.137</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1401320384">
<_position d:type="sFloat32" d:alt_encoding="0000008097926540" d:precision="string">172.581</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
</Height>
Now look at the same section in the old version that still works:
Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<cRecordSet xmlns:d="http://www.kuju.com/TnT/2003/Delta" d:version="1.0" d:id="2000332640">
<Record>
<Network-cTrackNetwork d:id="1985274704">
<NetworkID>
<cGUID>
<UUID>
<e d:type="sUInt64">5743106815149506397</e>
<e d:type="sUInt64">6435675412336092071</e>
</UUID>
<DevString d:type="cDeltaString">581c7f5d-9d38-4fb3-a723-029ab01c5059</DevString>
</cGUID>
</NetworkID>
<RibbonContainer>
<Network-cRibbonContainerUnstreamed d:id="1985274832">
<Ribbon>
<Network-cTrackRibbon d:id="1429581200">
<_length d:type="sFloat32" d:alt_encoding="0000008097926540" d:precision="string">172.581</_length>
<RibbonID>
<cGUID>
<UUID>
<e d:type="sUInt64">5600138326040278804</e>
<e d:type="sUInt64">9855347869530546366</e>
</UUID>
<DevString d:type="cDeltaString">00ae7714-b023-4db7-be60-45e5ab3ac588</DevString>
</cGUID>
</RibbonID>
<Height>
<Network-iRibbon-cHeight d:id="1413955680">
<_position d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">1</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1413955692">
<_position d:type="sFloat32" d:alt_encoding="0000004040034040" d:precision="string">32.0254</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">1</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1413955704">
<_position d:type="sFloat32" d:alt_encoding="000000A0D6AC4E40" d:precision="string">61.3503</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1413955716">
<_position d:type="sFloat32" d:alt_encoding="0000004062C46240" d:precision="string">150.137</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
<Network-iRibbon-cHeight d:id="1413955728">
<_position d:type="sFloat32" d:alt_encoding="0000008097926540" d:precision="string">172.581</_position>
<_height d:type="sFloat32" d:alt_encoding="000000E0814F5840" d:precision="string">97.2423</_height>
<_manual d:type="bool">0</_manual>
</Network-iRibbon-cHeight>
</Height>
The obvious difference is that the corrupted one in line 17
<Network-cTrackRibbon>, and this line appears regularly, right the way through the file. I guess those are the start of each track entry. Interestingly, the old working version has at line 17
<Network-cTrackRibbon d:id="1429581200"> before each track section entry. In each case the id number is different, but there are no id numbers in the corrupted one. I wonder if that could be the problem??
Regards
Matt
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 6:22 pm
by brysonman46
Matt
Yes, the Tracks bin is split into sections within a part <RibbonContainer> to </RibbonContainer> (containing several <Ribbon> to </Ribbon> and <Node> to </Node> parts) and a <AreaMarkers> to </AreaMarkers>
The lack of ID numbers may well be the problem. I am not sure, but I think that the ID number in the Tracks.bin has to sync with the same in the Track Tiles (how else would they tie up!). I will experiment with my test bed route to see.
I have often wondered why the need for these ID numbers in other than Track related matters (I am sure that Gary will put me right)
Nick
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 6:41 pm
by gptech
I would if I knew....
There's obviously some correlation between any ID number in Tracks.bin and the items referenced in the related tiles so all I've ever done is accept that rather than investigate it. The strategy of backing up regularly is the best one to get into the habit of, regardless of how any files are cross linked. Potentially losing a day's worth of edits is hard to take, but on the bright side it's a lot better than losing the whole lot.
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 6:47 pm
by brysonman46
Matt
Just done some research. The ID numbers do not correspond between Tiles.bin and and Track Tile. However, I did open up the Tracks bin and the Track Tile, and amended the ID numbers for the track I had laid, saved, cleared the cache, and opened up my test bed. The track (and junction) were still there. So perhaps you can take your corrupt tracks bin and put in ANY ID number at the relevant place. If the tracks bin is large, you may have to write a macro or similar command to do it automatically
Nick
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 9:33 pm
by AndiS
I would do a quick test by just doing search and replace to put the same ID everywhere. Maybe that is all that is needed.
There are three different cases/theories and at least two of them are know to be true in some cases:
1) The IDs are referred to. This is the case in signal links, iirc.
2) The IDs are useless. There are many that are not used referred to by anything. So they may well be something that the file saving routine puts in for all sorts of elements and only few types ever use this.
3) They have some influence on the memory management on reloading. One could postulate that these IDs are still used as unique IDs on reloading the file. But I saw several cases where duplicate numbers were used in default routes. So the game does not crash when these numbers are not unique. But maybe storage is less efficient then. (I am thinking of hashes with linked lists for the doubles.)
I never observed bad effects of duplicate numbers but I cannot say that I ran serious tests on mass duplication. I heard other people worry about such, but you never know way signals play up, even less on someone else's computer.
At any rate, be sure to use multiples of 8 for these numbers. I never saw an ID that was not one.
(This is one of the reasons to believe that they could have to do with memory locations. But it could also mean that they originally had to do with memory locations, in some other game. The whole "XML" business is an obvious reuse of code that was created when XML was very young.)
To be on the safe side, you could use multiples of 100, because that is any number with two zeros appended - much easier than multiples of 8.
In short, if the route loads after the above search and replace, but is noticeably slow, then it is time for unique IDs.
Re: Corrupt Tracks.bin file
Posted: Thu Nov 08, 2018 10:17 pm
by brysonman46
AndiS wrote:
At any rate, be sure to use multiples of 8 for these numbers. I never saw an ID that was not one.
On the contrary, there are many when they increase by 12. I have used them in RouteMarkers going upwards in steps of one.
I do agree that they probably do have some importance with signals, and as these are in tracks.bin there may be some problems
Re: Corrupt Tracks.bin file
Posted: Fri Nov 09, 2018 9:48 am
by AndiS
Thanks for the note. I vaguely remembered 12, too, but was too slow in thinking when typing.
Best go for multiples of 24 then.
The hint with multiples of 100 being multiples of 8 is rubbish, too. 100 is not a multiple of 8.
Re: Corrupt Tracks.bin file
Posted: Fri Nov 09, 2018 12:41 pm
by brysonman46
Just been through a tracks bin. Have seen multiples of 8, 12, 16, 24, 32, 36, 48. I guess it should just be even (so the binary number finishes 0).
In scenery and other tiles, I have seen odd numbers as well!
PS Also seen negative numbers as well!