Is the Theory About .ap Files Correct?

[latimers]

I understand that the theory is that some default DLC files have been moved to .ap files, and that one of the consequences of this is that a file verify will update only the .ap files. That way, modifications can be put in the old file structure, will take precedence over the files in the .ap files and won't be updated with a file verify.

One of the folders that has been "processed" as part of the TS2014 upgrade is the Assets\Kuju\RailSimulatorUS folder.

I have just run a file verify on my DLC-only machine and have received an update to some files in the Assets\Kuju\RailSimulatorUS\Railvehicles\Diesel\ES44AC and Assets\Kuju\RailSimulatorUS\Railvehicles\Diesel\SD40-2 folders.

I have checked my pre-latest-update machine and found that the above modified folders contain no files and that the files that are subject to this upgrade are in the RailSimulatorUS.ap file.

My conclusion is that if I had subscribed to the theory about .ap files and put modifications to those files in the old folder structure, the modifications would just have been overwritten by the update. Bugger!

It appears that either the theory is incorrect or RSC made a mistake in adding files to the old folder structure when it should have modified the .ap file.

Bob.

[Bananarama]

My conclusion is that if I had subscribed to the theory about .ap files and put modifications to those files in the old folder structure, the modifications would just have been overwritten by the update. Bugger!

It appears that either the theory is incorrect or RSC made a mistake in adding files to the old folder structure when it should have modified the .ap file.

Hi Bob,

Easy way to check. Add modified files into that folder as a test, rename the RailsimulatorUSAssets.ap, and then do a file verify. Only then will you know for sure.

[Ericmopar]

Having the .ap files and the external folder structure does not appear to protect us in all ways from a file verification.

I felt like being a guinea pig and did a Cache Verify just to see what would happen and I lost a lot of my sound, track and scenario mods that I had just added back into TS 2014 using the "external" folders.

[mikesimpson]

Hi Bob,

These .ap files have rendered much of the use of RW_Tools useless.

You can't
Check Routes
Check Scenarios
Clone Routes
Edit Scenarios to substitute rolling stock you have for items in the scenarios.
Reskin models

etc. etc.

I have added an option to RW_Tools to unpack the .ap files into their correct folders, and this works OK for routes as you can then clone the route using RW_Tools and run the cloned version of the route as before. However, if as you say, updates to Kuju\RailSimulatorUS empties any external folders, I don't know how to get around that one.

All I can assume from this change is the .ap files have been introduced to lock the game down as RSC think it should be and to stop things like rolling-stock substitution to force users to purchase missing stock.

Mike

[buzz456]

Let's hope they come up with a more acceptable explanation but at this moment I remain a very unhappy camper.

[Ericmopar]

You can get into the .bin files inside the .ap files, using RW Tools.
I opened the .ap files with 7-Zip first and then could open the .bin files inside the 7-Zip window using RW Tools.
I did this without extracting the .ap files. I simply opened them to view them and was able to do a couple mods by double clicking on the bin files and opening with RW Tools.

[latimers]

Mike,

I didn't say (at least that's not what I meant to say) that updates empty the old folders. Most of the folders in RailSimulatorUS were emptied by the TS2014 update and the files all put into the .ap file, thus leaving empty folders.

People seem to be assuming that Steam updates would then only be to the .ap files, leaving any modifications added to the old folders intact. That does not seem to be the case, based on the latest update (unless that was a mistake by RSC).

It seems to me there are several potential advantages to the .ap files:
1. They are more economical on space since one big file takes up less space than a lot of small ones. (Not a big deal these days.)
2. They make it easier for RSC to verify files since only one file needs to be checked rather than many small ones. However, it adds overhead to the file update process since one big file needs to be downloaded and replaced rather than a few smaller ones.
3. They might be a way to leave user-modifications unchanged. (This seems to be disproved by the latest update.)
4. They might make loading faster. (I don't believe this is the case - I think the checking the old folders first and then the .ap file must add to overhead - some people appear to have seen the result of that with increased tile-change stutter.

As far as RW_Tools' route checking is concerned, couldn't it check for an .ap file, unzip it to a temporary space and then perform the usual file checks? For cloning routes, couldn't it just set up the clone and then unzip the .ap file into the old folders in the new version? Similar process for checking scenarios and reskinning models?

Bob.

[OlPaint]

I have successfully restored all my Mods after a "Verify..." using "Doc" Machinist's 2-Clickz utility. But of course I already was using 2-Clickz in TS2013 to restore things that were over-written by the "Verify..." so my Mods Collection was up-to-date in the #REINSTALL folder before I got TS2014 upgrade.

OlPaint

[Chacal]

It appears that either the theory is incorrect or RSC made a mistake in adding files to the old folder structure when it should have modified the .ap file.

Thanks Bob. I believe your conclusion is correct, and I tend to favor the second possibility.
The first possibility includes the possibility that RSC intends to use the new mechanism for its own needs, e.g. for small updates.

[latimers]

@Ericmopar

Even if the theory is correct, it is only the files in the old structure folders that would be protected from a Steam update IF there is a .ap file present. If there's no .ap file present, it will have to update the old folder files. Did you lose some modifications to files where there is an .ap file?

@Everyone

I just started up my full installation, figuring it would then get the latest update to the RailSimulatorUS folder as my DLC-only installation did. However, the relevant folders are still empty.

Now I know that I didn't dream it. I have 55 Mb of files set aside that have today's date on them and only 2.3 Mb of files in my main installation with today's date.

Does anyone else have any files in their RailSimulatorUS\Railvehicles\Diesel\ES44AC\BNSF and SD40-2\BNSF, BNSF_Snoot and BNSF2 folders?

I'm wondering if what I got was an update sent out by mistake and it's now been pulled.

Bob.

[Ericmopar]

@Ericmopar

Even if the theory is correct, it is only the files in the old structure folders that would be protected from a Steam update IF there is a .ap file present. If there's no .ap file present, it will have to update the old folder files. Did you lose some modifications to files where there is an .ap file?


Bob.

That's true and I thought Simmer4's SD40 sounds got extinguished from my Donner folders. (external) I didn't check the tracks.bin that I was telling you about at Steam.

In hind sight maybe it was the DLC with no .ap files that got wiped. The funny thing is that the update left a lot of that alone, it was the cache verification that killed some of my mods.

[mikesimpson]

In the uktrainsim FAQ there is a good story about the AP files in which it states that any files outside of the .ap file will take precedence over those held in the .ap file.

Well this may well be the case, BUT I just wrote an application to unpack all of the .ap files to place the contents in their normal file tree positions. Then I ran a Steam verify cache. This resulted in EVERY file outside of the .ap file being deleted. So it looks like the whole system is now locked down and you can't change anything at all.

Without the files being available, you can't:-
Check routes
Check scenarios
Modify .bin files
Swap rolling stock in scenarios for missing items

On top of this, the Clone Route does not appear to clone all of the scenarios with the route. Also they still have not fixed the Provider window in the right-hand pop-out menu which I reported as broken almost 2 years ago.

I am removing RW_Tools from my site for the time being as it is unfair to take peoples money for this mess.

I agree that you can open the .ap file, modify a .bin file in there and put it back in the .ap - however any update by Steam will put the .ap back to its original condition as its checksum will have been changed by the modification. If placing the modified .bin outside of the .ap file results in it being deleted, then what are we supposed to do?


Mike

[latimers]

Mike,

I think the key might be: What if you unpack the .ap file into the old file structure and then modify one of the files, e.g. swap a loco in a scenario. Then when you run a file verify, does the modified file get deleted again?

Bob.

[_o_OOOO_oo-Kanawha]

In order to protect the integrity of the asset base, any modifications inside or outside of the .ap must be deleted.

My solution, keep a pristine Railworks inside the Steam folder and make a copy of that outside the Steam folder. You can tinker with the copy's files at will, unpack the whole of the .ap's and proceed from there as if nothing has changed.
When you buy a new piece of DLC through Steam or when RSC sends out an update you have to manually copy the changed files from the pristine original to the working copy.

For the Steam Workshop and possible future multiplayer, you can always fire up the pristine original.

Best of both worlds?

[_o_OOOO_oo-Kanawha]

How do route folders work in the .ap format?

Fire up NameMyRoute.exe and compare its window's contents with your route folders' contents.
I find "missing routeproperties.xml" while the .xml in in the MainContent.ap and some folders are still under the route folder?
Likewise "missing scenarioproperties.xml" while the scenario is in the MainContent.ap and an empty folder with the right UUID is in the Scenarios folder?

In that USA install I made earlier I stored each route folders content in a MainContent.ap file in the UUID folder and deleted all files and folders.
Now NameMyRoute.exe cannot list anything under the UUID, because it looks for the routeproperties.xml, which were all deleted.
Upon starting Railworks, I found all scenario folders had been copied back into a new Scenario folder under the UUID, but were empty.
Also all routepropertie.xml files had been copied back.
But the scenarioproperties.xml hadn't been copied out of the .ap, so NameMyRoute reports them missing.
Summarizing: NameMyRoute.exe doesn't look in the .ap stores.

When I wanted to edit a scenario, its contents were copied out of the .ap store and into the scenario UUID folder to be edited.
The other scenarioproperty.xml files were also copied back, so NameMyRoute listed all routes by name again, and all other scenarios of the route I edited one scenario of.

It seems the route and scenarios are well protected this way. Clever guys, those at RSC, aren't they?
Not very useful these findings, but it appears RSC has given it some thought.