[Aardwolf]

Ok, I haven't examined the specs for either PMF or POF, but this post was inspired by something I noticed in another thread, so here goes:

My current understanding is that each new version of the POF format requires a corresponding tweak to PCS2.

I think there should be an external (not part of each pmf or pof file) specification for each [supported] version of the POF file format somewhere. Like a DLL file that acts something like a plugin, maybe even nothing more than a binary data file of some sort. When the POF format gets updated to include new things, instead of having to create a ton of new stuff (widgets) in PCS2, you could simply distribute a new plugin which tells PCS2 how to:

• Map this version of POF > PMF
• Map this version of POF < PMF
• Display and operate the GUI

Furthermore, if two versions of the POF format are almost identical, you could make a secondary plugin/data file format, like TBMs are to TBLs.

Basically, this would allow for cases of extreme change in the POF format--like renaming or moving a chunk, or an overhaul of the model/bsp storage, or whatever other evil scheme someone comes up with in the next few years of the SCP. Ideally you could design it so that neither this format nor the PMF format would ever need to be revised.

Come to think of it, the "plugin" should be a data file, not a dll, because then it would be easier to make edits to it without having to be in both the PCS2 coding team and the SCP team. As for how it would be created, that could either be handled by something other than PCS2, or a new part of PCS2. However, since it would be closely tied to PCS2 (especially the GUI representation/control part), I would recommend that these data files be editable either in whole or in part with PCS2 or some new part of the PCS2 project.

I know I'm not in charge of this, and that it would be a lot of work, but I think it might also save some work and/or allow it to be done by more people.

Interesting thought: if this sort of thing could be integrated into the FS2 side as well, it might decrease the amount of work needed for FS2 to read new data from the POF file.

I keep coming up with new ideas as I go, but I think I should post now so I get some feedback before I come up with a really stupid idea, try to make it less stupid with an equally stupid idea, and so on, ad infinitum.

Comments on the idea?

[Vasudan Admiral]

Very little has changed about the POF format actually. To my knowledge only two chunks have been added since retail - GLOW  and SDLC for glowpoints and kazans yet unimplemented new shield system respectively, and neither of those chunks will cause problems in older versions of the engine or tools, because they simply won't be recognised. Hardly cause to break the POF format up in this way.

Even if at some later point the BSP system is rebuilt, it would most likely be a one off rewrite, because honestly - just how many more features should space ship models have that would need to be incorporated into the POF file format itself?

[Spicious]

It really doesn't seem worth the effort

Come to think of it, the "plugin" should be a data file, not a dll

Not going to happen.

[ak-73]

I see it like this: if we take my new io script, for example, adding a new chunk type to it, isn't really much work. Anybody who can code in any programming language, has the new format specification and the maxscript documentation can do it.

The idea is basically not bad... but it's always the question whether a general approach is really worth the effort, instead of doing some smaller changes by hand.

For example, my io script doesn't include GLOW and SLDC at this point. But since I now have a script to work from, extending it shouldn't take more than a day or two. Theoretically.

Alex