Unpacking all AP files

[joeflint]

Other than disk space usage, is there any downside to just unpacking all the AP files and running the game that way?
Thanks
Joe

[Chacal]

Yes. It invalidates the whole internal mechanism for checking corrupt files, and for updating files.
If you do a local files verification in the Steam client, or if DTG updates some assets, you will get the new files but you won't be using them.
It's better to unpack only files that need to be modified.

[buzz456]

Au contraire, I believe if you run a cache verification I believe it wipes out the stuff outside of the .ap folder and no I'm not going to check this out as I can't remember the last time I did that....oh wait you could try it with just one asset group and see if I'm right.

[Chacal]

In my menory (such as it is), this happened only once, the first time they implemented the ap files system.
But I'm like you, too lazy to check it out.

[buzz456]

I'm not too lazy just don't want to take a chance on what I have now which is a nice stable setup working just fine. I believe if it ain't broke don't fix it.

[Chacal]

Yup. Avoiding trouble fits in my broad definition of laziness.

[buzz456]

OK here's the report. I unpacked the New Jersey Shore route and then uninstalled it by unchecking the box in my library. After starting Steam my unpacked assets were all still there but the .ap file was gone. I then checked the box in the library and Steam re-acquired the .ap file. All of the loft, Road, Track tiles have the new date on them so I assume that Steam looked at them to see if any were missing however they have the same dates on them as before. The same goes for all of the other categories however all of the information was still there. I had made no mods to this route so I'm not sure what would have happened if I had.

I'm going to go try this with a piece of rolling stack because I sure think it used to anyway empty the folders outside of the .ap. They were still there just empty after the re-load.

[Ericmopar]

Au contraire, I believe if you run a cache verification I believe it wipes out the stuff outside of the .ap folder and no I'm not going to check this out as I can't remember the last time I did that....oh wait you could try it with just one asset group and see if I'm right.

This is correct. It won't always remove the file tree itself, but the cache verification will most definitely snip off the bins and other modified files at the end of the external file tree.
(Leaving unsuspecting victims to glance at the external file or folder tree with the mods and think the whole thing is still there)

[DapperDan]

That's why with the few mods I have I've got them nicely stored away in my 2-clix folder so if I have to do a verify I've got them all ready for reinstallation.

[buzz456]

That's why with the few mods I have I've got them nicely stored away in my 2-clix folder so if I have to do a verify I've got them all ready for reinstallation.

+1

[joeflint]

Yes. It invalidates the whole internal mechanism for checking corrupt files, and for updating files.
If you do a local files verification in the Steam client, or if DTG updates some assets, you will get the new files but you won't be using them.
It's better to unpack only files that need to be modified.

In either of the situations you mention I would unpack the AP files again with the overwrite existing files if they exist option selected. Being lazy the last time I had some updates I just unpacked all my AP files. I did not take super long and I did other stuff while it ran in the background. I did break the work into chunks (4-5} but that i just me being cautious.
Joe

[JohnS]

the ap file is not compressed either so it doesn't really save space just puts everything in a neat little file.

[mikesimpson]

I have a very large number of .ap files, and while testing RW_Tools, I unpacked the whole lot in just 2 runs, one for Assets and one for the Content files and it worked fine, although the time that takes is dependant upon the speed of the users PC and also how much RAM is available.

Mike