[Celery]

I recently updated my FS2 Open from 3.6.10 to 3.6.12 Inferno and I don't seem to be able to use my pilot anymore. I put my pilot.freespace.cs2, pilot.FreeSpace2.cs2 and pilot.pl2 files into the inferno folder and when I try to resume the FreeSpace 1 campaign, the game crashes with "FreeSpace 2 Open has stopped working". When I created a new pilot and afterwards put only the pilot.freespace.cs2 into the folder, the game crashes when I select the pilot at the start of the game. Is there something that I'm doing wrong?

[Dragon]

It's impossible (though, with Inferno becoming a standard, a converter would be nice).

[Admiral LSD]

This got me too. I ended up just creating new pilots. A bit annoying, since I lost a bit of progress, but there's not much that can be done until they get around to sorting out the mess that is the pilot data once and for all.

[General Battuta]

I recently updated my FS2 Open from 3.6.10 to 3.6.12 Inferno and I don't seem to be able to use my pilot anymore. I put my pilot.freespace.cs2, pilot.FreeSpace2.cs2 and pilot.pl2 files into the inferno folder and when I try to resume the FreeSpace 1 campaign, the game crashes with "FreeSpace 2 Open has stopped working". When I created a new pilot and afterwards put only the pilot.freespace.cs2 into the folder, the game crashes when I select the pilot at the start of the game. Is there something that I'm doing wrong?

You can't use old pilots with 3.6.12 Inferno builds. You should be creating a new pilot for every campaign anyway, so it's not a huge loss. That necessity will go away once the new pilot code finally gets into trunk.

[Admiral LSD]

I was already creating different pilots for different campaigns (data integrity issues aside, it's still the only way to track progress across multiple campaigns), the issue is that we're now being asked to create new pilots again, even for campaigns we already had separate pilots for (and which were working fine before the changeover). I lost enough progress to find it annoying, but not enough to be really bothered about it. I've since got most of that back and then some, so it's become something of a non-issue, but I can understand if people who were a lot further ahead in various campaigns asre getting more upset about it than I am.

[chief1983]

My guess is the vast majority of players will probably play an entire campaign without changing builds, I tend to try to play a whole campaign whenever I get a few days of not too much RL stuff going on.  If there are players who stretch campaigns out over weeks or months, there could be issues there sometimes but given that we have not really released builds too close together I've never worried about it too much.  If this is causing issues for a lot of players maybe we'll have to look into a way to mitigate it, but the next release should be more graceful than the last change anyway.

[General Battuta]

You probably shouldn't switch builds in the middle of a campaign anyway, like Chief said.

[Admiral LSD]

I have to admit, I was dragging my pilots back in after something like a 2-3 month gap of not playing (no Windows install and 64-bit Linux was giving me more grief than I wanted to deal with) so my specific situation is probably unique but again, I know it's on the cards to be fixed properly at some point in the future so I can ride it out.

[General Battuta]

Yeah. It'll be cool to have one uberpilot across campaigns (though also a bit weird to be going into, say, Derelict as a Captain.)

[taylor]

The new pilot file code is designed from the ground up to be for one pilot playing any number of campaigns.  It has gotten through my tests pretty well, breezing through situations that would completely destroy the old pilot format like it was nothing.  So the days of needing to use a different pilot for everything will hopefully be coming to and end real soon.

And conversion wise, the new code will convert both inferno and regular build pilots pretty easily.  There are some caveats with the conversion abilities though and there isn't a whole lot that can be done about that in the game code.  I'm hoping that someone will help out with a standalone pilot file editing utility which supports all of the formats (I have them all documented now) and will allow people to convert/change/fix pilots more easily.  So keep your pilots around and the new code should be able to convert them from either old build for you.

Oh, and the new pilot file code is pretty much done and will be submitted for group testing later today in the internal forum.  I don't know when it will show up in a public build, but it shouldn't be long now.

[Admiral LSD]

tbph, I'd be happy if all that was done was pilots were managed on a per-mod basis. That is, Blue Planet, for example, would have a completely separate stack of pilots all referencing the Blue Planet campaign to, say, the Port or the Retail campaign. It's a little annoying to not only have every pilot for every mod listed whenever you start, but also having to deal with the errors and whatnot when you forget to change pilots and/or campaigns after switching mods. Again though, I'm speaking from recent, and probably unique experience (As you may be aware, I've been setting it up and creating new pilots a bit lately and therefore been "welcomed" to Vega when I expect to see Artemis Station a fair bit ). If setting it up so you can reliably use a single pilot across multiple campaigns is easier, then so be it.

[taylor]

The new pilot files will hopefully address that problem pretty well.  The player file (.plr) is now completely ignorant of mods.  It maintains separate configuration for hud, settings, and controls which are used for defaults, and a set of stats which are independent of any particular set of data.  The campaign savefile (.csg) now has it's own set of hud config, detail settings, and control config which can be specific to that campaign/mod.  The savefile also has a set of stats which are specific to that campaign.  There is also no difference between single and multi player pilots now, it's just the one pilot that works for both.

During load, every savefile will do an integrity check to make sure that anything which it needs is available.  So for instance, you could play the original FS2 campaign with blueplanet active and the savefile for that campaign will still work if you switch to just the mediavps.  The extra data from the blueplanet mod would have broken old files, but the new format shrugs it off like it's nothing.  And if for some reason it fails even one of the integrity checks the campaign and savefile will fail to load, and the savefile will be marked as not savable to avoid corrupting it.  The new code can even detect the difference between the current mediavps and retail data and can prevent loading a savefile created with the mediavps if you switch back to retail data since there are some changes in the mediavps which introduce incompatibilities.


So I'm actually going to consider the new pilot file code a personal failure if anyone is forced to use a different pilot for different campaigns.

[Satellight]

Thank you very much Taylor (and all the SCP team, of course) for implementing such a wonderful feature. I play many campaigns at a time (because I like many universe  ), and this loooooong list of pilots is sometimes a problem (when i forget to switch from one to another).
Very useful improvement 

[Nuke]

it doesnt really matter to me considering i long ago fried all my pilot files thanks to modding errors. like selecting the wrong pilots for the wrong mods and so on.

the thing i really hope for is that this lets us finally upgrade the game's input code. more joysticks, more axes, more buttons, and more things to bind them to.

[chief1983]

Joysticks and axes, probably needs more than just this.  But adding bindable commands, I think that's definitely more feasible now.  In fact I think it was feasible before.  I've had a FotG pilot with a new key bind added to it, and it's been working fine going between builds that do and don't support the new bind.  I would have probably sought to get the changes committed earlier this year but with the new pilot code on the horizon I decided to wait for that.

[taylor]

the thing i really hope for is that this lets us finally upgrade the game's input code. more joysticks, more axes, more buttons, and more things to bind them to.

I'm not really sure how well this new code will handle input code changes, in all honesty.  The original pilot file rewrite that I was working on before was part of a massive rewrite which included new input code.  So the new input code was designed from the start for maximum flexibility and in turn the original pilot file rewrite was able to take full advantage of those changes in order to handle pretty much any degree of input setup.  This new code doesn't have that luxury, so it is still somewhat bound to the existing control/input setup.

I did leave some room in the new format for a bit of upgrading without breaking anything though.  The big thing with the new code is that it's sectioned off and has safeguards to help prevent corruption.  This means that stuff can be added and removed from pilot files without really breaking anything.  So even if the some extra has to be added to the pilot files in order to add support it shouldn't require breaking the pilot files to get it working.  Builds previous to new input code could still read the new pilots, but the extra control information would be lost.

Joysticks and axes, probably needs more than just this.  But adding bindable commands, I think that's definitely more feasible now.  In fact I think it was feasible before.  I've had a FotG pilot with a new key bind added to it, and it's been working fine going between builds that do and don't support the new bind.  I would have probably sought to get the changes committed earlier this year but with the new pilot code on the horizon I decided to wait for that.

It does break pilots actually.  It will save the number of binds to the pilot file on save, but there is no error checking on read to make sure that too many binds aren't read back.  So in a build without the extra bind(s), reading a pilot file with them, it can write past the end of the Control_config[] array.  You only got away with it because Control_config[] is CCFG_MAX+1 in size.  And I'm not sure exactly what the +1 is for, so something might have been messed up in there and you didn't realize it.

The new pilot code does fix that oversight though.

[chief1983]

Ah, I was under the impression that it would stop reading past it if it ended prematurely, and not attempt to read into the next set of data.  But yeah I can see that goof letting my test slip by.

So you're saying that if we went one beyond the FotG build and started adding another control config value, it shouldn't explode using the new pilot files between builds that do and don't have all the extra controls?  But, beyond that, there's still some more work to do?

[taylor]

Ah, I was under the impression that it would stop reading past it if it ended prematurely, and not attempt to read into the next set of data. 

That would make sense, but the check isn't there.  It's just one of the numerous stupid mistakes/oversights I made during the last pilot file upgrade. 

So you're saying that if we went one beyond the FotG build and started adding another control config value, it shouldn't explode using the new pilot files between builds that do and don't have all the extra controls?  But, beyond that, there's still some more work to do?

Correct, it should work fine.  There would be a problem if you changed the order of controls in any way (swapping, removing something in the middle, etc.) but just adding extra controls shouldn't be a problem.  That's one thing that the previous upgrade I was working on would have fixed, making the control bindings order independent.

In the future a new "ControlEx" section could be added to the pilot files which would handle newer and better input code without breaking anything.  Older builds wouldn't save that information though, they would just ignore it and read in what they do understand.  Still, it wouldn't actually break anything.

[mFuSE]

... so my specific situation is probably unique but again, I know it's on the cards to be fixed properly at some point in the future so I can ride it out.

Not so unique ^^

<- happy i found this thread, knowing know I'm not the only one missing such an import/convert feature.

... It has gotten through my tests pretty well, breezing through situations that would completely destroy the old pilot format like it was nothing.  So the days of needing to use a different pilot for everything will hopefully be coming to and end real soon.

....

Oh, and the new pilot file code is pretty much done and will be submitted for group testing later today in the internal forum.  I don't know when it will show up in a public build, but it shouldn't be long now.

How long could that be? ^^


I'm interested in converting my old blue planet <3.6.10 pilot to be used in [email protected]
I'm pleased to hear that it will be possible to keep him for other campaigns, like war in heaven.


I didn't had time yet to play war in heaven :-(
But, when there will be not to to far away a possibility to use my old blue planet char, i'll be waiting... a bit longer won't kill me ... i hope

[The E]

Don't get your hopes up. It just doesn't pay to get attached to your pilot files; at least not until after the upgrade is in trunk.

Oh, and the new pilot code doesn't convert non-Inferno pilot files, so you're out of luck there as well.