Game Warden Forums

Freespace => FS2NetD => Topic started by: [dw]-hunter on March 02, 2006, 06:27:50 PM

Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 02, 2006, 06:27:50 PM
I just wanted to ask how the compatiblity issues with missions with the new pxo is going to work?

I was talking to kara earlier today, and came up with the idea that you could make it so when a person joins a game the host (if hes on fs2open) would check to see if all the players were fs2open players, if there is a retail user, it will force the server not to be able to play FS2_Open only missions. Just a thought :)
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 02, 2006, 10:14:55 PM
The problem is that you would have to have a minimum version number saved with each mission and some way to check that.

Missions without a number would be assumed to be Retail.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 03, 2006, 07:10:47 PM
yea the missions would need some kind of tag that symbolizes that it is a FSOpen file, a different file extention would do the trick
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 03, 2006, 11:25:51 PM
Not really. If we're seperating FS2_Open and FS2 Retail missions we might as well make it so that FS2_Open missions are aware of which build is needed to run them.
Title: compatiblity issues with missions with the new pxo
Post by: Scrogneugneu on March 04, 2006, 01:15:45 AM
Might as well combine those 2 ideas : internal tags for the minimal version recognition, and a different extension for a quick visual check.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 04, 2006, 03:36:30 AM
it has to be a different extention or retail hosts will see those missions as playable missions
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 04, 2006, 08:43:53 AM
Quote from: '[dw
-hunter']it has to be a different extention or retail hosts will see those missions as playable missions


But by that logic so would any older build of FS2_Open. So you'd need three or more extensions.

The easiest way is simply to have FS2_Open hosts not appear to clients that can't play the same game they can. Older versions of FSO could simply be lumped in with retail.

How easy that would be to code rather than simply design is another matter of course.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 04, 2006, 08:32:40 PM
regaurdless the non retail missions have to be a different extention so they arent seen by retail
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 05, 2006, 12:57:13 PM
No they don't. Re-read what I wrote.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 05, 2006, 11:48:50 PM
Yeah but what if the player is already in the game and why would you want to make the game exclude players from the game?
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 06, 2006, 12:32:37 AM
Because if they are playing on retail they can't play FSO missions and are only going to crash out if they try.

Having a new file extension is going to do bugger all to prevent that.

Let me give you an example. I'm hosting on FS2_Open. You join the game on Tom's Build. I pick an FSO mission (with a different extension). What's going to happen as soon as I click commit? Either the mission xfers or simply kicks you out anyway. If it does xfer successfully your client will crash the instant it tries to run it.

Changing the extension alone will do bugger all.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 06, 2006, 03:43:04 AM
karajorma is right, an extension change isn't going to do anything to stop or even reduce the compatibility problems.  We have to network the compatibility in.  Luckily this is simple to do, just detect whether the mission is FSO only (by flag or whatever) and modify the server version in the game_active advertising packet.  Retail will just ignore those missions and go with whatever else is compatible with it's server version.

The dynamic server version bump is going to happen anyway since we have to do it to support more than the retail number of ship and weapon types.  Provided that you aren't doing freaky stuff with the tables you will be retail compatible, but if the engine detects that you are over the retail compatible limits it will automatically (and temporarily) bump the server version so that you can neither host nor join a retail compatible game.  Future FSO only missions could do this same thing with very little work on the code side.

The dynamic server version bump thing is waiting on the switch to dynamic ship and weapon type limits, which in turn is waiting on the new pilot code.  No ETA on when it will all be public, but the various pieces of code work have been going on for nearly 6 months now.  All of this has been planned for so don't worry about it, yet. :)
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 06, 2006, 07:18:22 PM
Quote from: '[dw
-hunter']I was talking to kara earlier today, and came up with the idea that you could make it so when a person joins a game the host (if hes on fs2open) would check to see if all the players were fs2open players, if there is a retail user, it will force the server not to be able to play FS2_Open only missions. Just a thought :)


Reread the first post kara, thats how it prevents the retail player from crashing ;)

Quote from: taylor
The dynamic server version bump is going to happen anyway since we have to do it to support more than the retail number of ship and weapon types.  Provided that you aren't doing freaky stuff with the tables you will be retail compatible, but if the engine detects that you are over the retail compatible limits it will automatically (and temporarily) bump the server version so that you can neither host nor join a retail compatible game.  Future FSO only missions could do this same thing with very little work on the code side.

The dynamic server version bump thing is waiting on the switch to dynamic ship and weapon type limits, which in turn is waiting on the new pilot code.  No ETA on when it will all be public, but the various pieces of code work have been going on for nearly 6 months now.  All of this has been planned for so don't worry about it, yet. :)


Why would you make it so it kicks people out who are retail players? Dont we want the game to be fun for everyone?
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 06, 2006, 08:18:30 PM
Quote from: '[dw
-hunter']Reread the first post kara, thats how it prevents the retail player from crashing ;)


Doesn't need any change in extensions to do that though does it? My issue was this whole unnecessary idea of changing extensions.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 06, 2006, 10:55:36 PM
Quote from: '[dw
-hunter']Why would you make it so it kicks people out who are retail players? Dont we want the game to be fun for everyone?

I meant that from the FSO side.  If FSO detects that it's running in a state that wouldn't be retail compatible then it would prevent retail clients from connecting to you.  Retail clients wouldn't see a FSO host in this case, and FSO clients wouldn't be able to connect to retail hosts.  This should only ever happen with some mods/missions though (like a multi capable version of Inferno) so it wouldn't be a general thing.  Most of the time, when playing multi at least, you would be retail compatible.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 07, 2006, 02:40:07 AM
Your still excluding players by making it so people cant see the game. Excluding people is just unreasonable. We all want this game to be fun for everyone and excluding players doesnt accomplish that. Just please take this into concideration.

.
.
.
.
.
.
.
.
.
.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 07, 2006, 04:38:24 AM
Quote from: '[dw
-hunter']Your still excluding players by making it so people cant see the game. Excluding people is just unreasonable. We all want this game to be fun for everyone and excluding players doesnt accomplish that. Just please take this into concideration.

Sorry, but I though this entire discussion was about compatibility and preventing problems.  If a retail client/host gets ahold of an FSO client/host with the functionality that I outlined then the retail client/host WILL CRASH!  Period.  Excluding them is the ONLY way to prevent this, there is no other option.

It's completely hypocritical of you to request an extension change for compatibility reasons, since that will do jack shit to prevent problems (but actually cause them), and then complain about a true solution which would prevent incompatible clients and hosts from communicating.  If an FSO host is running something that a retail client can't handle then the retail client shouldn't even see the host.  Same for FSO clients and retail hosts.

The entire point of this change is to help ensure compatibility without having to use two different executables.
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 07, 2006, 06:38:25 PM
Quote from: '[dw
-hunter']Your still excluding players by making it so people cant see the game. Excluding people is just unreasonable. We all want this game to be fun for everyone and excluding players doesnt accomplish that. Just please take this into concideration.


Sorry but I have to disagree with that. If I go on PXO to play an FS2_Open mission I don't want to constantly have to be making an ass of myself by booting retail clients whenever they join. After a while it would get annoying and people would stop giving a full explaination and just kick.

Not much fun if that starts happening to someone new to the game.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 07, 2006, 07:09:26 PM
Quote from: karajorma
I don't want to constantly have to be making an ass of myself by booting retail clients whenever they join. After a while it would get annoying and people would stop giving a full explaination and just kick.


*Sigh*Whats wrong with playing the missions that already exist when someone on retail plays the game? Cetanu didnt make his missions fun enough? :p

Quote from: taylor
If an FSO host is running something that a retail client can't handle then the retail client shouldn't even see the host.  Same for FSO clients and retail hosts.


Atleast make it posible for them to see the game, and when they try to join it gives them the error message saying "The mission selected isnt compatible with your build." So they know that it isnt a problem with their computer, and also so if they use both retail and scp they know to switch builds so they can play :)
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 07, 2006, 08:06:54 PM
Quote from: '[dw
-hunter']*Sigh*Whats wrong with playing the missions that already exist when someone on retail plays the game? Cetanu didnt make his missions fun enough? :p


You have got to be fucking kidding me! If I want to play an FSO mission I'm going to play an FSO mission. I'm most certainly not going to accept having my choice of which games I can play being overruled by the fact that someone has chosen to join my game on an outdated client.

I have a lot of respect for Cetanu and his FREDding skills but his missions are old and FSO is capable of so much more. I certainly see no reason why people should hold back on that potential just because one (small) group of people refuse to move with the times.

Quote
Atleast make it posible for them to see the game, and when they try to join it gives them the error message saying "The mission selected isnt compatible with your build." So they know that it isnt a problem with their computer, and also so if they use both retail and scp they know to switch builds so they can play :)


While that is a nice idea it may be completely impossible. It depends on whether the error messages Retail displays are hardcoded or recieved from the server. If it's the former then the only thing that can be done is to prevent the games showing up.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 07, 2006, 10:46:21 PM
Quote from: '[dw
-hunter']
Atleast make it posible for them to see the game, and when they try to join it gives them the error message saying "The mission selected isnt compatible with your build." So they know that it isnt a problem with their computer, and also so if they use both retail and scp they know to switch builds so they can play :)

There is no way to do this with retail since it would require changes to retail code in order for this to work.  Compatibility is determined by the version number and an incompatible version just won't show up in the server list.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 08, 2006, 01:04:02 AM
I dont think its that hard to ask tom to put a little more code into his build so that the error message will show up. otherwise it wouldnt show a message, it would just not let you join, right?
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 08, 2006, 01:25:22 AM
Quote from: '[dw
-hunter']I dont think its that hard to ask tom to put a little more code into his build so that the error message will show up. otherwise it wouldnt show a message, it would just not let you join, right?

Tom's build is irrelavant.  The changes must be retail compatible and the only way to do that is to have the host not be visible to retail clients.  Tom's build can integrate the needed changes in to handle the FSO clients/hosts, but then there isn't much point in not using FSO, and it would mean a substantial number of changes to Tom to manage.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 09, 2006, 07:55:22 PM
well what about making it so it gives a game is full message? Some kind of message atleast.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 09, 2006, 09:39:36 PM
Quote from: '[dw
-hunter']well what about making it so it gives a game is full message? Some kind of message atleast.
Like I said previously, rejecting incompatible clients just isn't a viable option.  If the choice is 20 servers in the list, 19 of which will give you a rejection, and only 1 that you will allow you access, then that's a pretty bad option from a usibility point of view.  If you can't play with that client/host then it you just shouldn't be given the option to do so.  One server in the list, one that you can reliably connect to, that is the only safe and user friendly way to handle the compatibility issue.

We can't do anything that retail doesn't support.  Retail doesn't support a custom message with a rejection (not to my knowledge at least) and it doesn't advertise build capabilities either.  If we don't know what to reject, since it can't say that it's not compaitible, then we couldn't reject it anyways.  Rejection is also done on the host side but we have to support both client and host compatibility checking, something all previous builds can't do.  We also can't even get to the point of rejecting as just that could present a compatibility issue.  The initial join (and all related) packets would never be able to change from retail since we would have to maintain comaptibility in order to reject a retail client/host.  Preventing the ability to modify the join packets in the future isn't acceptable when there is not only an easier way, more compatible way, and also safer way, to get the job done.

The dynamic version bump technique is going to be used, period.  There is no other feasible option.  If you can find one I'll listen, but you haven't even come close to a decent solution so far.
Title: compatiblity issues with missions with the new pxo
Post by: Scrogneugneu on March 10, 2006, 03:45:10 AM
I don't really catch what your "dynamic version bump technique" is, could you explain a litlle more?


What I would see as feasible is simply adding a "hey, it's me, the FSO build version x.xxx.xxxx.xxxx!" message when a FSO client is trying to connect (or even just check the current game status). If the server detects it, it calculates if that client is able to play the current game and answers accordingly. If it's not present, then it's a retail version (or an older FSO client), and the server answers saying that he's not accessible.


I really don't know how this is handled in the code, but adding a tag in the FSO client would do the trick. The server has the job to decide if the client who's trying to connect should be able to do so. It would require no change from retail, a minor change on the clients, and a little tricky part on the server (say, by default the version is retail, unless the special greetings message is part of the incoming packet) to determine if everything is going to be fine.


I don't know if what I just said is exactly your dynamic version bump technique, but I would like to know more about it :)
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 04:08:16 AM
Quote from: Scrogneugneu
What I would see as feasible is simply adding a "hey, it's me, the FSO build version x.xxx.xxxx.xxxx!" message when a FSO client is trying to connect (or even just check the current game status). If the server detects it, it calculates if that client is able to play the current game and answers accordingly. If it's not present, then it's a retail version (or an older FSO client), and the server answers saying that he's not accessible.


This is kinda what i suggested, but i agree, just like toms build does, when a person joins a game, the build version and type should be announced in the chat. "x user is using an unmodified retail or old scp build" for instance when that certain tag isnt present just like the hacked tables thing is announced to the game members only this shows when a client joins a game, rather then the moment you press the accept button.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 10, 2006, 05:26:02 AM
I think that everyone just doesn't quite grasp exactly how the multiplayer works.  FS2NetD/PXO have nothing to do with game compatibility, they merely accept server availability as broadcast when you host a game and announce it to clients looking to connect.  That's all it does.  All of the identification and validation steps are done entirely on the other end (the client and host side).  You can think of FS2NetD/PXO as basically a phone book and all it's doing is giving you a list of numbers to which you may connect.  But the phone book is useless if the your phone and the phone of the person you are calling aren't compatible.  Even then you would still need to know area codes, have long distance on your line, etc.  FS2NetD/PXO can't help with this any more than your phone book can order your favorite pizza for you over the phone just by you pointing a finger at a line on that page.

We can't add a message that comes from the server/host side and lets you, the connecting client, know that you aren't compatible since we would have to modify all retail builds to do this.  We can't reject retail clients for the same reason, it would just be a blind rejection.  And as I said the client and host still have to communicate to even get that far.  In an incompatibility situation all communication must be considered incompatible.  The only exception is the active game packet, the one that broadcasts a game is available.  It's the only one that we can't change without messing everything up.

We can't send a message identifying the build version since both client and host have to support that data packet.  Retail builds won't support it.  FSO doesn't support it.  It can be added to FSO, but only if Tom forks over the code for it so that we're compatible.  Even so that is only useful for the clients and hosts that support it, and no retail build would.  If Tom's thing is only a chat message and not a game packet then it does no real good for us as version detection since it could be easily faked or hacked around.


As far as the dynamic server version goes, it's just what it says.  The retail host/client version is 47.  Since we still have to support that it will be considered a fixed default.  But, if an FSO build detects that it is playing a mission which isn't retail compatible (via a mission flag) then it will bump the version number at runtime to, say, 48.  All retail hosts/clients are still at version 47 so when the active game packet is broadcast it checks the version number, sees that it doesn't match, and refuses to list that game.  FSO builds would need to do this for all sorts of conditions: mission incompatibilities, mods, new weapons (like fighter beams, or SSMs), and dynamic tbl limits which would go over the limit which retail FS sets.

When you are done with the game, or move to a different mission, then FSO will re-evaluate it's compatibility status and can, if it's deemed ok to do so, lower it's server version back down to normal.  You wouldn't have to exit FSO for this to happen so you could run a non-compatible mission for a quick game, then switch back to a retail compatible mission for retail clients, all in one session.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 06:10:02 AM
Quote from: taylor
We can't send a message identifying the build version since both client and host have to support that data packet.  Retail builds won't support it.  FSO doesn't support it.  It can be added to FSO, but only if Tom forks over the code for it so that we're compatible.  Even so that is only useful for the clients and hosts that support it, and no retail build would.  If Tom's thing is only a chat message and not a game packet then it does no real good for us as version detection since it could be easily faked or hacked around.


Who is going to fake their version first off, and tom's thing IS a chat message sent by the host, your going to need to play toms build and take a look this feature to understand. Its quite simple really, toms builds from version 1.3.4 and up i belive all have tags that identify its version, when a person joins and they dont have the version tag a message is displayed : " X is using an older toms build or a SCP build. " where as if its labeled it says "X is using version Y".

Im sorry if im frustrating you with all of these things im suggesting. But this one should be concidered because your going to need to know what version people are using when they join your game regaurdless if the thing lets a person in or not, because different missions can be selected after a user joins the game.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 10, 2006, 06:42:52 AM
Quote from: '[dw
-hunter']tom's thing IS a chat message sent by the host, your going to need to play toms build and take a look this feature to understand.

I don't use Windows.  If Tom ports his build to Linux, or provides me with the source, then I'll take a look.  Otherwise, any features in Tom's build are nothing to me.

Quote
Its quite simple really, toms builds from version 1.3.4 and up i belive all have tags that identify its version, when a person joins and they dont have the version tag a message is displayed : " X is using an older toms build or a SCP build. " where as if its labeled it says "X is using version Y"

But it has to be supported by both parties!  Compatibility is determined by both client and host, if one doesn't support the chat message then it's totally useless.  This is the entire point, we have to do what is compatible with retail in order to actually be compatible.  If retail can't interpret the chat message then the chat message is useless as a compatibility measure.  Anything we do has to be done as if it was for retail only and that means our compatiblity measures have to be in line with the capabilities of the code originally released by Volition.

Regardless, we've exchanged numerous game packets and switched game states before the first chat packet is exchanged, and we can't let it get that far if the games are incompatible.  Anything beyond the active game packet could be non-compatible.

Quote
...because your going to need to know what version people are using when they join your game regaurdless if the thing lets a person in or not, because different missions can be selected after a user joins the game.

Hence the dynamic version bump.  Switch a mission and it re-evaluates the compatibility.  If it's not compatible then it changes the version number in the active game packet and if it is compatible then it restores the default retail compatible status.  If the client/host is incompatible since startup (using a mod or has more than retail ship/weapon limits) then the version bump is constant for the entire session.

If a non-compatible mission is selected *after* clients have connected then it will send out a compatiblity update packet.  If any client doesn't respond then it's kicked and it won't see the game as availble again.  But in this case we know that the host itself is compatible so we only have to run compatibility checks on the mission.  If the host itself wasn't compatible then the client wouldn't have been able to connect in the fist place.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 06:46:47 AM
Quote from: taylor
I don't use Windows.  If Tom ports his build to Linux, or provides me with the source, then I'll take a look.  Otherwise, any features in Tom's build are nothing to me.


I guess I will take a few screenshots for you i guess.

Quote from: taylor
Quote from: dw-hunter
Its quite simple really, toms builds from version 1.3.4 and up i belive all have tags that identify its version, when a person joins and they dont have the version tag a message is displayed : " X is using an older toms build or a SCP build. " where as if its labeled it says "X is using version Y"

But it has to be supported by both parties!  Compatibility is determined by both client and host, if one doesn't support the chat message then it's totally useless.  This is the entire point, we have to do what is compatible with retail in order to actually be compatible.  If retail can't interpret the chat message then the chat message is useless as a compatibility measure.  Anything we do has to be done as if it was for retail only and that means our compatiblity measures have to be in line with the capabilities of the code originally released by Volition.


So what, the retail player wont get the message, big deal. Atleast the SCP players will.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 10, 2006, 07:10:54 AM
Quote from: '[dw
-hunter']So what, the retail player wont get the message, big deal.

The retail player will get the message, it's just basic chat, but it won't do anything with it.  We need action to determine if it's compatible or not.  A message simply saying "You aren't compatible, please go away now." does nothing for compatibility.  A retail host wouldn't send the message, so.. what, you have to assume that everything on it must be retail compatible?  Then I guess you wouldn't mind if I put my retail compatible build (according to the non-existent chat message) with 200 ship types up against your server and then crash your sever and all clients out because of memory overwrites and/or faulty data?  How about I put up a retail compatible mission to play that will exploit a Volition buffer overrun bug (that I fixed over a year ago) during mission load?

Compatibility means that it shouldn't ever be an issue and a chat message does absolutely nothing to address the problem.  The chat message is neat, and that's all.  We need some cooperation to actually keep it all working well but it should never be left totally up to the end user to determine if they are compatible or not.  If you aren't compatible then there shouldn't be any choice in the matter as to whether you can play or not.

And keep in mind I'm the coder who has fixed more bugs that anyone else.  I know most of them, from memory leaks to buffer overruns to missing safety checks.  I not only have the ability but also the knowledge to take out pretty much any build of Tom's or retail.  This is open source now so if I can do it then you know that others can as well.  I want compatiblity just as much as anyone else, but it's going to be done right.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 07:20:13 AM
ok, im just making suggestions :)
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 07:27:07 AM
Another thing i just thought of thats in toms build is when you press the accept button, before it continues after that, it checks to see if everyones on low object updates, if not it forces them to low object updates, dont ask how but regaurdless what build they are using it applies to all as what i understand. Also, in game statisics, although its a crude feature in toms build, only host can see it, its a nice feature to have, you dont have to count peoples kills in F4, because it does it for you. it also has in game kicking and banning as well, there are so many more features i dont even know of in his latest build. If tom could tell you everything it does perhaps you could include those, perhaps he may give you the code for it. :)
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 10, 2006, 08:44:07 AM
Quote from: '[dw
-hunter']Another thing i just thought of thats in toms build is when you press the accept button, before it continues after that, it checks to see if everyones on low object updates, if not it forces them to low object updates, dont ask how but regaurdless what build they are using it applies to all as what i understand. Also, in game statisics, although its a crude feature in toms build, only host can see it, its a nice feature to have, you dont have to count peoples kills in F4, because it does it for you. it also has in game kicking and banning as well, there are so many more features i dont even know of in his latest build. If tom could tell you everything it does perhaps you could include those, perhaps he may give you the code for it. :)

Sounds like neat stuff.  I'm not sure about the object update change since I would think it should be a user or server preference, but I don't play multi enough to know if that's really an issue or not.  It's a pretty simple thing to change though.  And it is a host side option, the host would modify it's local jr info and only send updates based on what the lowest common denominator might be.  Because of this it would reduce object updates for all client machines without affecting their real settings, allowing it work work with any client and not cause any sort of compatibility issue.

So, tell the man to pony up the code already!! ;)
Title: compatiblity issues with missions with the new pxo
Post by: karajorma on March 10, 2006, 03:50:34 PM
Is object update even an issue for non-56k players these days? I appreciate that it was a problem when FS2 launched but is it still? I've certainly not had problems when playing BSG games with the rest of the dev team.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 10, 2006, 07:13:24 PM
Quote from: karajorma
Is object update even an issue for non-56k players these days? I appreciate that it was a problem when FS2 launched but is it still? I've certainly not had problems when playing BSG games with the rest of the dev team.

Not sure.  The reason I'm not terribly happy with it automatically reducing object updates for everyone is that it's a pilot setting.  And it defaults to low.  It you forget to change it then everyone hurts because of that.  If it defaulted to high (what most people would likely use these days) then it wouldn't be as much of a concern.  Those who need lower updates would have to remember to change the setting, otherwise everyone has to remember to change it.  Tom could have easily changed the default though so this may not be an issue with his builds.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 10, 2006, 07:55:38 PM
there is no issue with the default :P its force low, and host force high
Title: compatiblity issues with missions with the new pxo
Post by: Scrogneugneu on March 11, 2006, 12:24:07 AM
Quote from: taylor
FS2NetD/PXO have nothing to do with game compatibility, they merely accept server availability as broadcast when you host a game and announce it to clients looking to connect.  That's all it does.  All of the identification and validation steps are done entirely on the other end (the client and host side).  You can think of FS2NetD/PXO as basically a phone book and all it's doing is giving you a list of numbers to which you may connect.


I dont quite understand why you wouldn't be able to modify FS2NetD in order for it to perform those validations before even publishing the servers. I know it currently can't, but does that mean it can't ever gain that capability? Just add in some functions and verifications. The principle is that a server can request that any clients able to see him has at least version x. FS2NetD can then filter the broadcast, even before the clients know it.



As for the rest, I now understand your dynamic version bumping idea. It's great. But I still can't see why the solution I mentionned above wouldn't work.
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 11, 2006, 12:53:31 AM
Quote from: Scrogneugneu
I dont quite understand why you wouldn't be able to modify FS2NetD in order for it to perform those validations before even publishing the servers. I know it currently can't, but does that mean it can't ever gain that capability? Just add in some functions and verifications. The principle is that a server can request that any clients able to see him has at least version x. FS2NetD can then filter the broadcast, even before the clients know it.

Because the FS2NetD/PXO server would have to be kept up-to-date will all version and compatibility information for every version of FS2, FS2_Open (both releases and every CVS build), every mod, as well as missions.  Every time we add a new network feature to FS2_Open the compatiblity and version info would have to be updated.  It's far too limiting and would require so much micro-management that it's just not worth it.  And it still wouldn't get around the fact that the game is designed to do compatibility checking on the client and host side, not on the tracker side.

The host would have to send it's capabilities to the FS2NetD/PXO server, and so would the client.  Once again, we are back to the fact that we can't modify retail to do this, and the fact that all of the host filtering is done on the client side.  If we leave all compatiblity and version checking as it is, with the client and host, then we don't have to manage anything.  The client and host will already know their campabilities and are perfectly capable of doing the filtering themselves with one simple version check in a small active game broadcast packet.
Title: compatiblity issues with missions with the new pxo
Post by: tom on March 14, 2006, 11:49:52 AM
Quote from: taylor
Tom's build is irrelavant.  The changes must be retail compatible and the only way to do that is to have the host not be visible to retail clients.  Tom's build can integrate the needed changes in to handle the FSO clients/hosts, but then there isn't much point in not using FSO, and it would mean a substantial number of changes to Tom to manage.

I think it would be much easier to integrate my OEB modifications into Retail or FSO.

Concerning the object updates issue, there is no need to worry about that. Multi-experiences of many players show that low is the best client-side setting. After releasing the OEB some people requested to integrate some kind of object updates control, because new pilots often didn't get it how to change it or some pilots tried to sabotage games. The result was lag or the loss of connection to the host. By the way there is not only a limitation to low object updates. The host can set it to any value. Thus it can be disabled virtually by setting it to lan.

Other useful features (my opinion) as mentioned before:

Ingame kick
It's no tool to get new "friends", but sometimes the host is glad to have it ;)

Knocking on the door.
If someone tries to join a game (which is not in forming state) the host gets a message. That's a good way to say hello and to restart a game.

Ingame stats.
This feature isn't very important, but in coop missions it's interesting to be informed about current stats.
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 14, 2006, 07:30:37 PM
it would be cool tom if you could give taylor the code for those features so he can integrate it in :)
Title: compatiblity issues with missions with the new pxo
Post by: tom on March 16, 2006, 04:37:02 PM
Quote from: '[dw
-hunter']it would be cool tom if you could give taylor the code for those features so he can integrate it in :)

No problem :)
Just tell me wher to send it.
Title: compatiblity issues with missions with the new pxo
Post by: tom on March 16, 2006, 04:37:15 PM
Quote from: '[dw
-hunter']it would be cool tom if you could give taylor the code for those features so he can integrate it in :)
No problem :)
Just tell me where to send it.

Edit: Well, that's the way to increase the post count ;)
Title: compatiblity issues with missions with the new pxo
Post by: [dw]-hunter on March 16, 2006, 05:49:07 PM
:D hehe, FS2_Open is going to have the multi features i enjoy having
Title: compatiblity issues with missions with the new pxo
Post by: taylor on March 16, 2006, 06:42:29 PM
Just PM me here or on HLP with a link to the changes.