In 1.2 multiplayer the host sets the mission and each player selects a plane. It is impossible to set the AI planes



The MISNxy.dat files on each player's PC select the AI planes so If the mission is an intercept of allied planes one axis pilot might see B17s escorted by P47Cs and another might see B24s escorted by P38Hs

By way of comparison this is the 160 MP screen:

The AIs are set by the host and the MISNxy.dat files are redundant.

I did a "host only" launch and this is a screenie

Mark,

If you erase the *******.MSN files in the savedata folder the game will reasign new default mission parameters from scratch, that is if the game is not modded. The routines in the EXE apply to the original v1.2 game only and the original targetset. For modded games it should actually take new frontlines and changed targets into account but it doesn't as it uses fixed presets when no ******.MSN files are found. This is why most campaign addons caused so many problems, they didn't come with their own modded set.

Sometimes a .MSN file might accidentally contain data which would work with certain planes, i.e. the entries were correct and the game could set an appropiate mission with it. However most of the time the old Savedata folder contained mission data from another game scenario with data that couldn't be used in the new campaign. Read here that the original campaign would also be another game and most .MSN files wouldn't fit the new campaign. Therefore these addons crashed immediately or when a certain plane was selected. However when the .MSN accidentally worked it would keep working for that plane untill another addon would replace it requiring new .MSN data. This find was heavily disputed by certain members as being untruthfull, but I'm still behind it.

I've created a few savedata folders to fix some campaigns but I don't think people were very interested in them after what happened inhere. A new routine in the FXEXE allows recalculating apropiate .MSN files through LOAD in the Mission Parameter screen, taking the new campaign into account but sometimes, probably when none of the .MSN files can be matched, the game will crash immediately after launching EAW, in which case a .MSN file should be created manually, by setting all the right parameters to fit the new environment.

As for the Mission**.dat files per year, they contain the probabillity or chance of certain planetypes appearing in certain mission types. As described by Mr. Jelly all players would need the same or weird things could happen. There's a lot more to what these files do and how they operate but it would be too extensive to write it all down and explain.

VonBeerhofen

That's actually the best way to troubleshoot in less you wish to go in depth.

MrJelly has the post showing the file structure


additionally: from Charles Gunst's EAW Notes

I don't think MISNxx.DAT are used in campaigns

Mates; If you setup and look at the DoxygenDocs-EAW-V1304x

You will be able to explore the workings inside EAW with both hyperlinked code and graphics.

..

Just to clarify
Some of this discussion has been about "*.msn" files such as "Default11.msn" which the 1.2 exe saves in "savedata" when a single mission is flown, and the 160 special version where the exe reads the "MyFile.msn" file to get the mission data.
However, other parts of the discussion are about the "MISN40.dat", "MISN43.dat", "MISN44.dat" and "MISN45.dat" files which are used to generate AI planes based on progabilities.
The two file types are completely different and should not be confused

Thansk for the added images to your one post and the clarification. I had them clear but good to put it out there non the less.

I'll try to have two docs on this , one for 1.2 and others based on it, plus the code groups version as well. I expect these docs to expand and get rewrites alot once I post them, due to the lack of my understanding and lack of info on the subject.

Whoops.. Yes. of course. My bad.

Yes 1.2 separation is a good idea.

Frankly, though understanding the missions data files technical details is not something you could easily go into. i would recommend just supply links to readmes, etc..
Because frankly, to do so with all its intricacies enough to make support docs for others - you would have to learn how to make missions and/or campaigns, and use a hex editor to look at why varous versions of mission files do not mix and match.
Or you can look in the files I provided which can take years to study also.

I like your project the EAWHS but fear you may get a bit too ambitous and will get burned out. EAW is not something I would recommend anymore for people to try to learn to edit, make missions really.
Campaigns are much harder and something I now wish I had spent time on. But the day is past. Nor anymore do we need Skins much or 3dz or really much of anything that we don't already have.
I would hate to see people actually waste to much time like I did on learning EAW stuff, other than the basics like how to set EAW up and fly. Try some add-ons that are ready in a complete package,

Like the 1.28e FullVersion i offer, or other offerings similar that MrJelly or your site has. Or Moggy's, vonOben's, etc.

For old EAW buffs they will already know more or less what to do to find stuff.

Vintage 1.2 types can play with OAWunified, which has hundreds of planes and skins and FM/DM. Some terrains, etc.
or they can try Roel's FX varieties.
But don't mix and match.

New people can try MrJelly's 160 offerings which are sensible.

Anyway, that's my 2 cents for now.

Disclaimer;
If I left anyone out. Or wrote something awkwardly.. Don't be too offended!

p.s As for me. As I said I'm not doing EAW stuff anymore .. (at least publicly)
I looked at the docs I sent you and understand so much now that I find about a dozen edits I'd like to make to the .exe that I could now do..
Thinking of making alternate patch versions .exes and compatible collections at some point when I have more time..

Mark
These days I cannot see that people need to know about "*.msn" or "MISN4x.dat" files unless they only ever use 1.2 with no mods.
These files became a PITA when different theatres arrived on the EAW scene. "*.msn" files were stored in "savedata" and were often contained values which made no sense in a different theatre.
The "MISN4x.dat" files had already caused problems with multiplayer .

Originally the "*.msn" files were impossible to modify because of the "CRC" checksum until I wrote an editor that re-calculated it.

This is the 1.2 list:

ULONG CRC;
ULONG VerNum;
ULONG Status;
char Description[_MAX_PATH];

// things to be modified by single mission parameter pages

long YearNum; // * Time Period: 1940 = 0, 1943 = 1, 1944 = 2, 1945 = 3
long TimeNum; // * Time of Day: Random = 0, Dawn = 1, Day = 2, Dusk = 3, Night = 4
long Weather; // * Weahter: Random = 0, Clear = 1, PartlyCloudy = 2, HeavyCloud = 3, Overcast = 4

// Primary Mission
long MissionType; // Mission: Mission Type
long TargetAreaOffset; // Target: Target location offset in worlddata.

long AircraftNo; // * Number of Aircraft: Random = 0, 1 - 12
long AltitudeBand; // * Cruise Altitude: Random = 0, Low = 1, Medium = 2, High = 3
long AttackHomeBase; // Home Base: Home Base area location offset in worlddata

// Friendly Support Activity
long SecondaryType; // * Secondary Aircraft: None = -2, Random = -1, AircraftType 0 - (MAX_PLANE_TYPES-1)
long SecondarySize; // * Formation Size: Random = 0, Small = 1, Medium = 2, Large = 3
long PilotSkill; // * Pilot Skill Level: Random = 0, Green = 1, Seasoned = 2, Expert = 3

// Expected Enemy Activity
long EnemyActivity; // * Air Activity Level: Random = 0, Light = 1, Moderate = 2, Heavy = 3
long EnemyMainType; // * Primary Aircraft: None = -2, Random = -1, AircraftType 0 - (MAX_PLANE_TYPES-1)
long EnemySecType; // * Secondary Aircraft: None = -2, Random = -1, AircraftType 0 - (MAX_PLANE_TYPES-1)
long EnemySkill; // * Pilot Skill Level: Random = 0, Green = 1, Seasoned = 2, Expert = 3
long EnemyAAA; // * AAA Activity Level: Random = 0, Light = 1, Moderate = 2, Heavy = 3

// things to be set elsewhere...

long MissionWeather; // weather flag
ULONG MissionDate; // Game Date/Time

long TargetOffset; // actual target offset in world database.

long AttackNumMain; // 2-16
long AttackNumSec; // 2-16
long AttackTypeMain; // Main defending plane type.
long AttackTypeSec; // Secondary defending plane type, None = -2, Random = -1
long AttackPilotSkill; // Attacking pilot skill level 0, 1, 2
long AttackMainAlt; // altitude in FEET
long AttackSecAlt; // altitude in FEET

long DefActivity; // 0, 1, 2
long DefTypeMain; // Main defending plane type
long DefTypeSec; // Secondary defending plane type,
long DefPilotSkill; // Attacking pilot skill level 0, 1, 2
long DefMainAlt; // altitude in FEET
long DefSecAlt; // altitude in FEET


A number of the values in the "// things to be set elsewhere... " section were never referenced in routines in the source code. In the 1.28 development I changed two of them to become the interdiction type and the interdiciton size. I also disabled the CRC check to make editing easier.
Later I made the 150 and 160 special exes use the four altitude values, but these only come into play if a "*.msn" file is loaded with the 160 mission editor program. They can add a bit of fun by setting up a "bounce" situation with the friendly altitude much higher than the enemy, or vice versa.

If I do anymore work on the exe it may well be to replace more of the unused values with useful things

Is that why you've setup a thread about .MSN files and the changes you have made to make it work, Mr. Jelly? The way I see it is that users need not know about these files for clean 1.2 since they always work fine, as long as you don't try to mess around with em. The problems started when OAW programmers didn't understand the need for savedata folder managment because no addon theatre ever incorporated these files. The only one which had them was and still is Pacific Tide III and ofcourse they're also present in EAWPRO since it contains a new campaign too.

I still hear you say 'the .MSN files are NOT in use online' because you mistakenly believed that since they weren't changed after an onmline mission they weren't used. The automated selection of bases online and offline depend on their correctness, which I tried telling you some time ago. Like everything in the game users need to have the same files and this is also true for the .MSN files. It makes no difference if they become altered during offline games as long as the basic parameters fit the theatre and frontlines. That's how it works in clean 1.2 too.

The MSN**.DAT files caused problems as some OAW versions messed around with em, which led to different players using different files, besides that your editor failed to recognise that some values in the .MSN files needed changes in what was then called UNKNOWN parameters or parmeters which weren't shown in the editor and therefore couldn't be changed when certain alterations to the game were made. Even when certain changes were made to the EXE, these parameters needed to be changed, as I found out later on, because otherwise the game would crash. I honoustly don't know what the routine is doing and why, all I know is that it's doing it better then the .MSN editor, which is why in EAWPRO it's called when a .MSN LOAD is performed.

Users/Modders who don't understand how things work shouldn't mess around with these files, with or without editors or scriptfiles because it will only mess up their game. That's why The EAW Launchpad never experienced the same problems as 352nd, and it's not because we're not changing the addon regularly but because the changes come with the appropiate parameters in the .MSN files and if necessary MSN**.DAT because I let the EXE do the work of calculating a new .MSN file because the program knows best how to do that.

I'd like to point out that many UNKNOWN/UNUSED values from the past are not meant to be manipulated by users because they're used by the EXE to temporary store parameters as the game progresses, they're reserved and only used in memory. Initially I made the same mistake as Knegel to think that I could use these ''empty'' fields for my own ideas but soon learned that it only caused problems. Still, without such mistakes there wouldn't be progress, right? We've all made them and I admit that even today I occasionally make them because of not fully understanding all of the code, just like you and everyone else who've started out with zero knowledge on C++.

Problems aren't always immediately visible after modding the EXE, sometimes I only recognised there was a problem months later and had to backtrack everything I'd done since then to set it right, just like you've been doing with some of the Codegroup's entries from the past, I was only fortunate enough to understand assembly language as well having experience with Macro assemblers since my days with the ZX Spectrum and C64/128. With two languages it's much easier to understand what the game is doing and you learn new things from both languages. I'll probably never fully understand all the routines, especially not the ones which manipulate the various hardware. There's just too many differences in video and audio cards and what have you, which is why EAW actually is capable of running 6 or more different loops to handle the various videocards from the early days and why there are so many different terrain tile formats.

I just don't have enough different computers to test em all out so I focus on D3D because that's what all my computers use. Therefore some graphics issues came to light thanks to Russ Watson who used the windower, and a later donated XP computer which also wasn't doing graphics the way I programmed them, inspite having a D3D card. It tought me that within the D3D family there were a lot of differences which the game could or could not handle. From it I learned that there is no guarantee that my changes will always work and I'm truely sorry for those who had the misfortune to not have the right hardware to run EAWPRO because I haven't been able to test the program with such hardware due to limited funds. In my defense I can only say that I've seen it work on ALL operating systems with and without the 3D Windower porgrams but the possibillity remains that some hardware will not properly work, which is inevitable due to ever changing progress and the size and complexity of the EAW code.

I hope people realise this isn't meant as an attack on another gameversion but merely sets a few facts straight, which is that we all have made mistakes, that's it's near impossible to comprehend the code fully, irrespective of programming background. I'm amazed there are two working game versions that people can have fun with, and if you don't like EAWPRO then that's fine with me, I've only created it for my own benefit to learn more about programming and that in itself has been great fun for me, inspite of everything else..

BTW, now you may understand why you're not allowed to mess with my game, you can't make it better then I can and there's a huge chance that you'll mess it up, so enjoy it as it comes and maybe later some more will come of it. If you believe you do have the knowledge you can do what you like with it, I don't care if you mess it up but it's not my problem.

VonBeerhofen

Just when everything seemed so peachy..

No again, I concur the .msn files can cause mixups.

So can the MISNx.dat files



The answer is to just use the EAW program to create them via single missions.

Or if you use MrJelly's stuff don't mix and match, just use his program versions and instructions.


------------
On a related note especially to the 1.28x ~ 1.28e / f to 1.3 series;

The main reason people may have a crash or failure to launch in quickmission would be they have not used aircraft selection screen or single mission to set the aircraft type.
Then they add some campaign / mission files from a scenario. And their eaw.ini may have for example p-51 or whatever set as the default plane.
They try a quickmission and ... crash ctd or hang.
Because the last mission or scenario mission they have files for is not for the aircraft type (or nation) in the eaw.ini.


Then again they may have pre-exisiting .msn files in their savedata folder (or folders in some cases).
In some cases the .msn files left over in some versions of downloads were left over from the add-ons / developers / own savedata folder.

For .msn files, you don't need any pre-existing ones.
Selecting each aircraft and single mission and you can create a default .msn for every aircraft type.
Once you have those you should not have a ctd.
-----------

Quickstart or aka 'Instant Mission' parameters have been described in the 1.28x series release documents:

These missions are always a bit unique since the game uses a random generator to generate some parts of the mission.

Note : mission scenario files -- example "Lake Mission" or 'FAW' -- in your EAW folder will be used as the base for the data generating.
(otherwise the default EAW .cdfs data files will be used - the data is not 'created out of thin air' except for a few routines.)

In the case of the random it will take some of the existing data and some the rest is random.
That was at one time one reason you may actually have wanted a pre-existing .msn file. But it was never the recommend.
I never shipped any missions with .msn files and since I don't make campaigns I never had a need to edit MISNx.xdat files and none ever included in my offerings.
SQxx.dat files for OAWunified were provided by OAW team. I never thought they wer needed. AFAIK they never caused any issues either way. btw.

Quickstart or Quick version whatever you choose call it - creates a hybrid mission

The general quirks I found are that:

- enemy fighters and bmbers can start from anywhere regardless of frontline.
- more often than usual EAW 1.2 era - enemy fighters get lost and not sure where their base is to return to.
- allied friendly ai don't stick around long
- bmbers and even enemy fighters sometimes fail to show up for a fight - in fact there sometimes can be no enemies. This is usually when I am using my own scenario files though. Chances are the base is either out of random range or maybe unavailable for that year / base.

if you notice below option 2
QuickVersion=2
will use last selected mission type.

Now if your aircraft in the eaw.ini isn't available or you have .msn file in savedata that is not for that, if the aircraft you set to fly in the eaw.ini isn't availabe in that year or other similar coding reasons, you will get a ctd or hang or error.





disclaimer;. not exactly The Grail. with possibly some inaccuracies but maybe wil help TS on your help pages..

Many years ago in the 7217 days I came up with the "JIM" system and software, with an external program which allowed the user to create a file with the mission settings, and a hacked EAW exe that read the file and immediately launched an instant mission using them.
It had a hack that made it only CTD if the system could not handle 16 bit selection screens.
Previously the7217 CTD occurred if the system could not handle 8 bit screens, and became a massive problem for players who updated their video cards.
This hack applied to the normal 1.2 exe would result in no 7217 CTD, but garbled selection screens which were impossible to use, however, the "JIM" system did not use EAW screens.

This system allowed users who were getting the 7217 CTD to still play EAW, albeit only in instant mission mode.

I re-visited this two or three years ago, but this time with the source code. The upshot was that I could get the exe to read a "MyFile.msn" file and without loading any screens do the sequence that happens when a 1.2 user

1: Starts the game
2: Selects single mission
3: Selects an aircraft which brings up the hangar screen
4: Selects "Mission Parameters"
5: Clicks "Load"
6: Clicks on one of the "msn" files listed.
7: Clicks "Load"
8: Exits "Mission Parameters" back to the hangar screen
9: Clicks "Fly"

A few weeks ago I went back to work on this, and updated the community here in posts about my progress in the "MSN files" thread.
My first post was on February 25th. and I do not know why VBH seemed to question my motives
The upshot has been the public release of the 160 special, and posts I made in this thread re- questions about "*.msn" files and "MISN4x.dat" files.

With the160 special is that the user sees no EAW screens until the loading screen with either the fuel gague in 1024x768, or the target map in other resolutions.
It is ideal for players who still have corrupted selection screens, and we are using it very successfully at GameRanger

I don't have any problem with what you do Mr. Jelly, the problems started when OAW wouldn't work properly in my online games because of the .MSN file problems you just recently described, after I described them already in 2005. It's clear to me that you haven't fixed the real problem since then or understand the cause of it. At least you're giving the .MSN files some more thought as I suggested ever since and some time ago, which I think is what you should do. It might help me personally if you'd admit that I tried to convey these problems to you and show you how to fix it back in 2005, when it wasn't particularly accepted as honoust feedback. I'd like to see you touch the root cause of the .MSN problem and give the game back what it lost, working campaigns, flawless theatres with all the necessary fixes and a fool proof user interface which doesn't allow people to make wrong selections which corrupt these files from there on. I don't think you're quite there yet, as your post above seems to suggest, but I'm looking forward to that day .Good luck and keep up the good work!

BTW, let me know how you fare when you start changing theatres and frontlines, I mean the ones which really move targets around and significantly change the frontlines, Like PTIII or FAW and PAW. It'll be interesting to see how they will benefit from all this.

Roy, you shouldn't believe that whatever anyone says is right. What Ralph describes as ''Quircks'' can only happen when something in the files isn't right! I've never seen bombers take off from enemy airfields ever since I started playing this game in 2000, unless I made it happen myself. Perhaps these ''Quircks'' relate only to his 1.28 version but I still feel things like that shouldn't happen since it doesn't happen in v1.2 either. I also think that the described CTD relates more to an erronous .MSN file then an INI error, it probably may even relate to a programming error by you or Ralph in the code as I described some time ago in the Zeus forum. A small error with big consequences which can exactly perform the way Ralph describes it, especially when no .MSN file is found. No offence meant.

VonBeerhofen

Once again you took a shot at OAW. I do really care as long as the community is aware of the reality.

This is the opening page of the OAW selector released with OAWUnified and used online by several pilots via Chatzy



It hs a "Del MSN" button to delete the rogue "*.msn" files and fix that problem.

It has a list so that the host can set AI planes and make "MISN4x.dat" files, and it used the magic number system.
When the host had set it up the magic number could be copied into chat so that the other players could copy it into their OAW, and in doing so get the exact set-up as the host.
There were never any problems if this procedure was followed, until someone at chatzy with limited OAW knowledge advised other people to change some file or folder names.
This completely stuffed up the system by ruining their OAWUnified installation.

That was when your OAW troubles started, and when several of us left Chatzy in disgust.
Roy and Ralf will confirm this to be absolutely true.

I do remeber that version Mr. Jelly but JG51 never used it, it's the version that drew us over the top because it contained modified weapons which were closer to the fuselage. The latest version I still have is OAW Unified, which is embedded in the OAW folder we used normally. Unified was only used for the lake missions which were led by you before your shown version became OAW number 100 or so. Both Unified and the one before that (The last one JG51 used and still used for modding purposes today) have no savedata folder management of any .MSN files. The ReadMe in Unified is June 2005 and bears Roy's signature and an explanation for the Lake mission. At that time the Savedata issue was long in effect before that date and eventually led to JG51 throwing in the towel.

I have your version too here somewhere in it's original ZIP, as I became a somewhat avid OAW colletor plus what else I could grab, but which version isn't really the point is it? Fact is that up to OAW unified the problems with OAW had been mounting, which I reported about which again led to the decision to abandon further experiments untill more was known. I don't exactly remember when I reported that the .MSN files were absolutely vital for the game but it is a fact that I did on numerous occasions, just as I was trying to make you understand that your target editor wasn't doing things the way EAW wanted to see it, but I believe that was much later. On both occasions I was called a liar who only had subversive plans for the codegroup version and ''proof' was submitted that either was working fine.

I'm still telling you that neither is working fine but if you believe it is or believe that what you're trying now will solve the problems you've encounterd, which I also encountred long before 2005 then I can only say, I tried to help but to no avail. Let me ask you a direct question, are you or are you not encountering issues with campaigns for which you have no explanation? If you don't then I have nothing further to say but good luck with your endeavours and have fun modding.

BTW, what is a Rogue .MSN file? Was there something like a ''Rogue'' mission file, could there have been something like that. I never knew that existed, Is that what was causing so many online problems when I reported them? To me a .MSN file is an essential file which draws everything in an addon together, things will not work without all of em, except for v1.2 but v1.2 will not work with any .MSN file created for a different theatre.

You know what I find funny? That I just looked into my OAW at all the .MSN files present and I found a few large addons from 2002, DAW and Dunkirk, which actually had the full set in an M folder, but no presence of any savedata folder. Well that's not going to work now is it? No wonder there were so many problems, I wonder who told us to do that. In 2002 I wasn't even aware of that stuff, as I was still trying to solve the Pyramid R/S issue by calculating it manually. Even funnier is that it stayed in like that up to June 2005. We didn't know much about Savedata folders or .MSN files back then now did we, and do I recall you saying a bit higher up that these files were causing a lot of issues which was why you adapted to a new ingenious way for the target selection ,but some issues had to be sorted for which you created a new enhanced type of .MSN file to solve all the problems, that is after you've finished with going back in time to JIM will fixit? Will he now, in that case I'm keeping a close eye on how JIM does, but I already know.

VonBeerhofen

Rogue msn files were the ones saved in savedata like "Default05.msn" I find in my own OAWUnified. In 1.2 they are the ones which caused problems when the theatre was changed, so there was a button in OAW so the user could delete them.
However, in that folder there are a heap of SD folders:



These are savedata folders which the selector switched depending on the Q folder loaded
When this happened the the current savedata to its original "SD" name, and renaming the "SD" folder corresponding to the selected Q folder as "savedata".
That way the "savedata" folder in the root folder corresponded to the theatre selected, and in a sense the Del MSN button was redundant.

The current 160Special (which is the replacement for JIM) is running very well. ShoGun and I had some great games using Moggy's Dunkirk theatre, and I have just set up a SPAW planeset with several flying boats which take off from and land on water. It worked well in the host only test I just tried at GameRanger.



The enhanced msn file has the first 400 bytes almost exactly the same as the entire 1.2 version with the data starting at byte 273.
There is no CRC or version number in the first 12 bytes as the checksum check has been disabled in the exe.
Two of the old unused values have been put to good use to contain the interdiction type and the interdiction size in the case of an interdiction mission.
An extra 400 bytes has been added to include the theatre, planeset and description. The latter was shifted from bytes 13 onward to start at byte 529 to allow more room.
In that second section the multiplayer bases for the friendly secondary, enemy primary and enemy secondary aircraft are stored at bytes 721,723 and 725 for copying into the [NETOPTION] section of the eaw.ini file.
The exe does not read anything after the first 400 bytes, but the editor does to give info to the user.
One of the big benefits is that the 160Special exe is using some previously unused values, such as those for the friendly secondary, enemy primary and enemy secondary altitudes.
These actually work, and I have been using them to set-up bounce missions.
There are other unused values, such as the actual number of different aircraft, and it would be easy to make an exe that uses them

Heres a draft of my Help Document for MISSIONS. WIP.

https://eaw.neocities.org/eaw-missions.html

You're not tackling the real problem with your follow up post Mr. Jelly, which is that I reported problems with OAW and online games and weird behaviour up to and including OAW Unified and I was called a liar who's only goal was to attack OAW. That later OAW versions tried to tackle the problem only shows that my concerns were correct and you were trying to fix the problem without excusing yourself for the problems OAW had caused in the Launchpad.

Managing savedata folders is only part of the problem and doesn't solve all the issues which also relate to your target editor and a few other things in the EXE which will also cause problems. Yesterday I incorporated a Savedata folder in every addon folder which needs one, because my version doesn't manage them. When the addon is selected the savedatafolder is also copied and overwrites the one in the gamefolder, problem solved and without a Savedata managing feature things work like a charm, offline that is. Online it's not solving the other issues but at least there's a chance that it will work. BTW, I happen to have these same SD folders in my OAW, a remnant from the version you posted. I forgot to erase them but they're all empty anyway, except for SD Europe_Mission_1 which only contains saved custom missions which will never be used online.

Perhaps this sounds familiar to some who've played the game online. Sometimes one or more players would spawn in totally different areas then the one selected by the host, that is hundreds of kilometers away. There wasn't a cause we could pinpoint for this behaviour and only recently I started understanding why this happened. This player had played another addon offline whereas none of the other players had, and from there on his savedata folder was corrupt. His savedata files got changed accordingly and were no longer in step with ours. It had the wrong target and airbase in it and when the game tried to use them to produce a sensible target and airfield in the next online mission the selection wasn't the same as ours.

I can see that one could create some fun missions with this behaviour if it's under control but it wasn't, so I reported it in SimHQ and was hammered for it. From there on things got worse and worse because people sided with my attackers after being told there were no problems. Since the incorporation of savedata management, as a direct result of me mentioning that the .MSN files were vital for the game, the problems are still not solved 100%, even though there's far less chance of problems then before.

Showing how things are today aren't an excuse for the treatment I've had to endure whilst pointing out problems which were real but denied by the Codegroup, which is the only important reason for me still being here. It's important to me that I can leave knowing that people understand I never lied and tried to help fix a real problem.

VonBeerhofen