Author Topic: compatiblity issues with missions with the new pxo  (Read 8075 times)

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #15 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.

.
.
.
.
.
.
.
.
.
.
« Last Edit: March 07, 2006, 03:01:36 AM by [dw]-hunter »

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #16 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.

karajorma

  • He is watching YOU
  • Administrator
  • Hero Member
  • *****
  • Posts: 5268
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #17 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.

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #18 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 :)
« Last Edit: March 07, 2006, 07:12:58 PM by [dw]-hunter »

karajorma

  • He is watching YOU
  • Administrator
  • Hero Member
  • *****
  • Posts: 5268
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #19 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.

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #20 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.

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #21 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?

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #22 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.

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #23 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.

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #24 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.

Scrogneugneu

  • Noob in transit
  • Newbie
  • *
  • Posts: 17
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #25 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 :)

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #26 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.

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #27 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.

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #28 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.
« Last Edit: March 10, 2006, 06:15:25 AM by [dw]-hunter »

taylor

  • Administrator
  • Sr. Member
  • *****
  • Posts: 397
    • View Profile
    • http://icculus.org/~taylor
compatiblity issues with missions with the new pxo
« Reply #29 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.