Simviation Forums

Hi guys. Talked about this before, but now starting to do something about it. Recently tried to install several campaigns but can't fly any of them because of duplicate airfield data. Some campaign designers even allocate numbers to the basic set of 50 installed with the game to different airfields!
Anyway, started working on a database so I can at least sort out the mess in my installs and get to actually play these campaigns.
In doing so I started with a new 'clean' install of CFS2 and got the airfields.dat file and used that as the basis of the database. I then loaded a campaign (In Defence of Australia). No new airfields installed. I went through the missions and found one (mission 5) which has an airfield number of 8051. The stock list ends at 8050, yet the game had no problems with this, the mission flew normally. The location is Port Moresby (which has the in game id of 8043). Both these numbers are used in the mission file, listed as separate airfields, presumably for the different aircraft (different start points).
OK, so somewhat confused I went to the install I already had and checked the airfield.dat file there. Airfield 8051 in that list is Lord Howe Island, yet when I run the mission, it plays fine. The other aircraft appear at Moresby.
Can anybody offer insights into the workings of this as it may help me develop the database into a generally useful form (although actual coding of a utility or macro I'd leave to someone who knows what they're doing, I'm happy to do this basic 'grunt' work)?

Piers

In my experience the real problem with differing ID numbers in addon missions and campaigns does not come with the basic flying of the mission but when you attempt to go to Advanced Info.  Here are some things to consider.

As you know, when you open any mission where you takeoff or land and you will see a runway entry that looks similar to the ones in your airbases.dat file.  The biggest difference is that the runway numbers in the mission file start at

Hey Cody, thanks! Kinda what I suspected, but you rounded it out a lot more.
Let's see if I'm getting this; a mission file that has a take off and landing airfield id number that matches the airfield.dat file in my game will work (so long as other infrastructure is there).

In the case where the player take off or landing id is different between the mission file and the airfield.dat file, the mission may CDT or else (as has happened) the planes may try to warp from Port Moresby to somewhere in Manchuria and crash on the way or run out of fuel.

In the 'In Defence of Australia' mission I described, the 'odd' number was assigned to AI aircraft (A24's that the player escorts), the player airfield numbers are take off/landing and target. So this would mean that the advanced info won't cause a crash (which it doesn't) unless the AI were flyable and had a human pilot who wanted to access advanced info?

I thought for a bit that the airfield number in the mission related to player; like airfield "0" is where the mission starts for the player, but not so. In that same mission (and several others) airfield "0" is the target (Lae) and airfield "1" is Port Moresby, the start and finish point.

The reason I'm setting up a database (actually a spreadsheet) is to 'rationalise' the airfield and mission files. With this new install as I put in a new campaign I update the airfield.dat file first allocating new numbers as instructed. I then load the missions but open each one and check the airfield data. One of the annoyances is that in the mission file you only get a reference number (although it will match the original airfield data that shipped with the campaign) and a lat/lon. With the spreadsheet I can 'control-f' the lat/lon and see if the airfield already exists in my airfield.dat then just change the airfield id number in the mission. I've also got into the habit of including the airfield name in the mission file as a back-up.

OK, if none of this is glaringly wrong I think what I'm doing will work. Thanks!

Piers