[Kiwikkiwik]

sorry for that I posted this before I read your comments.

Obviously if you could give me an Idea of how the scenarios and OOBs interact then that would be very helpfull in discussing how the "Changing OOB stuffs Scenarios" problem can be fixed. But I can speculate a bit in the interim.

So the idea is simple enough. Instead of the scenario using the current OOB files it needs to use the set of OOB files that were current when it was created. So far so good.

I would like to know exactly what use the scenario files make of the OOB files but as all these file sizes are minute by current standards it might be possible to incorporate whatever OOB information the scenario file is looking for straight into the spscn001.DAT file, when it is created, so it then becomes stand alone.

Another approach might be to keep the legacy OOBs

So you could create legacy folders
C:\WinSpww2\GameData\OObs\LegacyOOBs\v13.
By the time you are at v20 you would have 6 legacy OOB folders, \v14, \v15, \v16, \v17, \v18, \v19,
I don't know when the OOB files are loaded into memory, but when a scenario is opened the first thing it needs to do is open the appropriate legacy OOB file, instead of using the current OOB files. So it needs to call the OOB opening function and when it calls that function it needs to supply that function an argument which is the path to the appropriate legacy folder. Which the function should then substitute for the normal path. And then of course when it exits reload the current OOB files in a similar manner, no argument needed just run the function as normal.

To achieve this you would need to include a call to the OOB opening function and the path to the legacy file in the start of the scenario file.

For a scenaorio created today it would be
C:\WinSpww2\GameData\OObs\LegacyOOBs\v14
and if it can't find that folder which it won't as v14 is the Current OOB then when the code fails to find the legacy folder then by default it opens the current folder,
C:\WinSpww2\GameData\OObs. (using an error catcher)

OOB manager already has the required functionality "Restore Default OOBs" and "Pick Custom OOB Set" buttons which if they actually don't call the function that loads the OOBs they perform the same job. So you could press these buttons and then step through the code with Borland C++ watching which lines are used this will tell you what the code you are looking for looks like, and what needs to be included at the start of the spscn001.DAT file.

As a starting point you could drop the "Pick Custom OOB Set" code into the start of the scenario and then give it the correct path manullly. And drop the "Restore Default OOBs" code into the end.

In the purchace screen the code for the Allies button and what happens when you click a flag will also have some useful functionality for this job, for example listing the OOBs that need to be incorporated into the spscn001.DAT file.

As a programmer I would say this is relatively straighforward job. I would be happy to help in any way you deem fit. If it is too difficult a job for your current resources cheap programming assistance is out there.