Repacking The PRJ / "External" PRJ Referances

[Col.Kell]

Wow, I saw all kinds of modding opertunites when I took the "UNPACK ARCHIVE" button for a test drive.
That would be completely hassle-free if you could unpack the PRJ, replace whatever files you wanted, and "re-packed" the PRJ back together again!
It would make things easier to navigate through, you wouldn't have to worry about not being able to replace files with those of bigger bytes, and it would be less of a barrier on learning of the PRJ inner workings.
Is it possible to "Repack" the archive?

And is there some way that the PRJ can have "external" referances? I was awe-struck early this fall when I learned about the NIAS Mercs shell. I thought it was cool how the game could then utilize BWD's from subfolders outside the PRJ, and play them on the fly.
Do you think it possible to reconfigure NIAS shell to work properly on 31cc?

[Skyfaller]

I thought about it too. From a coding view, it's about the same amount of work as the context menu entries, both methods would have to reconstruct the entire PRJ. The order of files in the PRJ must be maintained. The most convenient way to do this is to maintain a file list in a text file, or to export and import files with a prefixed number. I think the context menu solution would be simpler from the user's point of view, although the entire PRJ needs to be reconstructed for any changes made.

The real challenge to this is reconstructing the PRJ. I may attempt this at some point, but I'm still busy with other stuff.

About NAIS: IIRC, Mercenaries has special code to access files outside of the PRJ. This is what made NAIS possible. It's probably missing in 31stCC DOS/NetMech. BattlePack and Titanium are based on DLL's, so you can't call them directly from a console window, so I doubt NAIS will work with that as well. Feel free to prove me wrong, though.

[Col.Kell]

That would be good, and convinent too. My top purpose for wanting to re-pack the .prj would be so I wouldn't have to worry about inserting too many bytes into the archive.

I don't know why, but (almost always) if you insert a geometry file even SINGLE byte larger than the original, the whole mech or shape will go haywire, and the level unplayable (?). I have a theory how this happens; when polygon data is "concluded" before it is able to connect all the nessecery dots, it leaves unconnected vercities, and the game reacts VERY negative to that. Why can't you increase the size of a polygon? Is there a file size archive from the original shape that could be contradicting the new one? (I have found that you CAN insert larger .SFL or .WAV sound files, they will just have the same lifespan of the old file, and then cut off.)

I just thought of this, you could probably use an external .BWD without the use of a special code or shell, by using that good ol' MS-Dos command prompt.
If you have installed Mech2 under dos, and you have mounted your Mech2 game directory, type in;
(e.g., "MW2 AMY_SCN1" or "MW2 GOLDSCN1" or whatever to get a certain mission.) I haven't figured out how to use a specific player gamepiece BWD along with the DOS prompt, but I it can be done. Trust me on that one.

[Skyfaller]

Inserting files of equal or smaller size happens in-place, meaning that the old file is simply overwritten in the PRJ. If the new file is only one byte larger than the old, another method is applied: the new file is appended to the PRJ. It gets a new header and pointers in the PRJ are updated to point to the appended file. I have tested this only for replacing .MEK files, where it works fine even for larger files. BWD files appear to be a different story though. For replace-by-appending, I might check whether the new header is correct, but there is a problem: IIRC, one field in the header gives the distance to the next file. Because of appending, this field would have to receive a negative value. I'm not sure whether MW2 supports negative values for that field. Again, this could be avoided by rebuilding the PRJ.

For adding files to the PRJ, it might seem straightforward to simply append the file, add a header and update pointers. However, that will not suffice, because the directory for that file needs to be enlarged. I'm not certain if it could be added to the end of file.

Which operation would be more important?

[Col.Kell]

Bigger is bigger, I don't care how we get there.

But I'm guessing that "rebuilding" the PRJ is quite a challenge?
Maybe you could point out where these details are? Or interigrate a "repacker" in MechVM as the next project?
Either way would be great.

Or... if a smaller file is replaced with a larger file in whatever PRJ directory, could it be possible to subtract an equal amount of bytes that were added by removing empty bytes from a large file that was replaced by a small one of the same directory? That sounds like a new mod project for me to try!