LiveBahroCaves_District_POTScave.prp is Alway Delet[Solved]

[Mac_Fife]

As for why you see a delete every launch - I bet Minkata is set up with ThinExternal == External, so it does actually check every file at login. It's slower, but for a testing shard probably better to make sure everyone is on the same page.

It's a case of wanting the best of both worlds: A speedy startup, so as not to discourage people from testing and a thorough check to make sure we don't have oddball effects caused by mismatched files.

However, it just occurred to me to ask this: Is the release notes file part of the ThinExternal manifest? I'm guessing it is, which probably explains why the whole problem arose in the first place. Throughout MOULa, there has never been an update to the release notes, so if an update only affects files lower level files (like some of the .dat files) then they'll never be scanned on subsequent updates. In the past, the release notes would change each month.

Even if that assumption is wrong, then possibly adding the release notes to the ThinExternal manifest, and making sure it gets updated for each new release, should then force a re-check of the entire fileset on first usage after any update?

[branan]

It's worth keeping in mind that when the MOUL patching system was implemented, the full data set was NOT in External.mfs - we had age patching at link time.

I've found in my own tests that verifying all the global data - .age, .csv, .fni, .p2f - is very fast. That can all be put in to ThinExternal, and the PRPs and audio files into per-age manifests. Per-age manifests are checked at every link, so even if only a single prp file changes, it will just be patched on age link instead of at startup.

[rarified]

I've found in my own tests that verifying all the global data - .age, .csv, .fni, .p2f - is very fast. That can all be put in to ThinExternal, and the PRPs and audio files into per-age manifests. Per-age manifests are checked at every link, so even if only a single prp file changes, it will just be patched on age link instead of at startup.

Thanks... I'll keep that on the list for a future update on Minkata.

_R

[JWPlatt]

Aren't age manifests only relevant if you can serve them?

Also, a "fast" scan is relative to local conditions. If it's perceptibly slower than how it was recently improved, I might complain.

Before changes like this happen, I think it's important to understand why things evolved as they have and ask those questions.

[rarified]

Aren't age manifests only relevant if you can serve them?

I believe the age manifests must be available from the server for the client to run. They were generated by CJkelly1's ManifestCreator program from an existing MOSS install, since they're never stored by the client on the client host.

Also, a "fast" scan is relative to local conditions. If it's perceptibly slower than how it was recently improved, I might complain.

Perception != Reality sometimes! But we'll leave that testing up to our most sensitive test expert.

_R

[JWPlatt]

Ah, yes, the game files are available, but not the prps, which is how I was thinking.

[branan]

I actually misspoke earlier - .fni files are in per-age manifests, not the global manifest.

.age files are duplicated in both. I'm not 100% sure they're needed in External. Certainly earlier Plasma versions wanted to have the .age files at launch, but if CWE doesn't then .age files can be removed from External.mfs as well.

EDIT: avis and .loc files are also in global. I just looked over my build scripts.

[cjkelly1]

The Manifests.zip file that is in the MOSS tree contains files which generate manifests which have the same entries as were in the GT MOUL. I do not believe the files in the manifests changed from the GT version to MOULa. The only manifest which MOSS does not contain is macExternal, because I do not have a Mac. Symlinking External to macExternal works fine, so the extra files which would be present in the Mac client not being in the manifest does not appear to cause an issue.

I believe you have quite a bit of leeway in the contents of the manifests. Since I test different versions of the client against my personal MOSS shard, I have removed the PhysX DLLs and the two Uru executables from my thinExternal, and it does not appear to care. I would assume you could remove quite a bit more from the manifests, and it would work. Of course, when the client is looking for a needed file and it is not in the manifest nor in the directory, the client can get a bit upset. It would also run into the "clients with different data sets" problem.

[Trekluver]

Here's an update on this issue.

I recently updated Minkata to 1.905 (Yea, I'm slow to this kind of stuff.) and in the process I figured out how to fix this problem once and for all. If you cut and past the dat folder rather than copy and paste it, the file system just changes the folder's index. Therefore, the dat folder (that should now be in your minkata folder) is exactly the same as the one that was in your MOULa folder and not a copy. Then, copy and past the folder back into your MOULa folder. This way if any files get corrupted in the transfer, MOULa can just re-download it again; this is something Minkata cannot do. I've tried this three times (Once for Gehn, Minkata, and TOC) and so far I've had zero checksum errors.