[FUBAR-BDHR]

Been thinking about the multiplayer mission testing problem that leaves old versions floating around since they override VP versions.  Had an idea.  What do you think about some sort of beta testing flag / date in the mission specs.  If it's set to true the mission won't load after the specified date.  Of course any FREDer could easily remove the flag and/or change the date.  That led me to a second idea.  If it's multiplayer and there is a validated mission with the same name it won't let you run it thus eliminating the spread of old versions to other computers. 

I'm sure someone will have some better or additional ideas.  Heck the beta flag could even be useful in single player.

[Nuke]

i think it would be better to have mission version numbers, which fred will automatically increment each time the mission is saved. then in multi, if the version numbers dont match, xfer the new mission.

[karajorma]

Version numbering isn't hard at all. That's just a simple counter.

The issue is one of figuring out how to get FS2 to gracefully back out of performing the xfer, notifying the host and returning to the forming area. That's not trivial because I'd have to get the host to check with all the clients before xfering as it's no use canceling one client and xfering to another. 

[FUBAR-BDHR]

Doesn't the the host already check the clients for hacked tables right before transfer?  Could it just be added to that checking routine but not let the host continue instead of allowing the existing override?  That in conjunction with some sort of tweak to the mission validation pass should take care of 99% of the cases.  The only time the host should have a newer file then is validate is if he's either the mission creator or doing a test host.  Client having a newer version then the host should only happen if the client is the mission creator.

[karajorma]

Until you release. At which point all the people who just downloaded the game have newer versions than the people who beta tested (which I believe is the problem you're trying to fix).

It goes a bit further than that though, for instance IP gave me the missions for his campaign to stitch together into a campaign. If he fixed any of them further for Thursday's session it means that everyone who gamed that night has newer versions than me because they'll have xfered them from whoever hosted. If I host this Thursday no one one would get an xfer.

I'll need to take a look into it to see if it can be done but we're in a code freeze at the moment anyway so it's likely to have to wait for 3.6.10 to be out before I can really look at it.

[FUBAR-BDHR]

What about a stop light type scenario on the host side.  Something like this:

Green = mission you have is validated.  -- If client has newer version tough luck.
Yellow = mission you have isn't validated. -- The mission is checked against the clients if the same or newer allow xfer. 
Red = mission is validated and you have an old version.  -- Only allow xfer if the clients don't have a newer version.

[karajorma]

The issue isn't what to do so much as whether I can do it without having to change a lot of the xfer code. So far I haven't looked to see how it actually works. It might be easy even.

Either way it's not something I can work on until 3.6.10 except in my own branch (and I should be fixing bugs instead of doing that).

[FUBAR-BDHR]

I was thinking of more of a before xfer validation if that is possible. 

[FUBAR-BDHR]

2 things just hit me that could be a real pain in the arse with this.  First of course is the ever popular standalone server.  Second is in-game joining. 

[WMCoolmon]

I think the only really secure way to do this is to have a master validation server that keeps track of a checksum of every single version of validated missions. The first person to upload a specific mission name gains update rights for that file, which they can then pass on to someone else if they choose (or of course admins can change it).

Consequently the game will ask "Do you want to upload this?" whereas if the checksum isn't recognized, the game assumes that it's a user-made mission with the same name but it's not meant to be a version of the validated mission. Maybe it will pop up a dialog that says "Hey, the mission you're playing has the same name as this, might they be the same thing?"

With version numbers, it's all too easy for someone to open up the file in notepad and add 10 to the number, then resave the file and make whatever hacks they want. Granted cheating hasn't been a big problem that I'm aware of, but it does seem more than a little insecure and a really tempting way to screw up other people's saved missions. And it's inherently infectious - if one person joins a game that has the hacked mission file, leaves, and then joins another game, everybody else will download off that guy. Then they leave and go on...etc etc.

Plus somebody might tweak the mission for their own custom purposes, but also increment the version number to mark it as different. Then somebody joins his game and 'updates' their copy, and the illegit version gets spread and wipes out the original.

EDIT: Master "validation" server also doesn't have to actually validate every mission that it comes in contact with. It could just be a DB connected to Freespacemods.

[karajorma]

Firstly I suspect FUBAR wants to use this for mission development rather than for actual finished missions. Secondly XFERS are one way only Server to Client and I don't particularly intend to change that. So right there we know we're only dealing with the danger of someone poisoning missions when running as a server. A poisoned client can possibly persuade a server not to run a game but he'll probably have more trouble getting the server to replace validated missions with his unvalidated version. So even incrementing the version number wouldn't allow you to keep the ill-gotten points you'd get from the poisoned mission.

That said the problem of people deliberately circulating poisoned versions of missions did worry me before the BtRL launch even despite that. Even if you can't actually gain any advantage on saved stats you can still cheat in your favour or just screw up missions to be malicious. I'd love to see something done about that to be honest but securing FS2_Open against cheating isn't going to be easy since anyone can just download the source and start fiddling with it anyway.

[FUBAR-BDHR]

Kara's right on what I'm trying to get around.  The problem is testing multi mission then when they are finally ready for release anyone that tested can have an old version in their data\missions directory that will override the release version in a VP file.  Or the even worse scenario of a buggy version in one VP and the fixed in a newer VP the host may not have.  Now the host transmits the buggy version to the clients overriding their fixed version. 

I do like WMC's idea as a long term way of tracking missions.  I think I even requested a feature like that as part of the new FS2netD website.  It would give players a quick place to grab the latest mission VP files with validated missions as well as individual missions that may never get validated or are in need of testing. 

Yes version numbers aren't secure but it's usually not the FREDers that cause the problems but the people that just play and don't know what they have in their directories can cause a problem for others.  V tried something with number and lettering the file name.  Believe me when I say it didn't help.  I have so many copies of Cet's missions with different numbers and letters I don't even know which ones are the right ones.  Something in the mission file itself while not close to perfect is at least a little better.  I'm sure there is a better way though.