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

[dw]-hunter

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

taylor

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

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #32 on: March 10, 2006, 07:20:13 AM »
ok, im just making suggestions :)

[dw]-hunter

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

taylor

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

karajorma

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

taylor

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

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #37 on: March 10, 2006, 07:55:38 PM »
there is no issue with the default :P its force low, and host force high

Scrogneugneu

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

taylor

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

tom

  • Newbie
  • *
  • Posts: 16
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #40 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.

[dw]-hunter

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

tom

  • Newbie
  • *
  • Posts: 16
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #42 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.

tom

  • Newbie
  • *
  • Posts: 16
    • View Profile
compatiblity issues with missions with the new pxo
« Reply #43 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 ;)

[dw]-hunter

  • Hero Member
  • *****
  • Posts: 567
    • View Profile
    • http://www.teamwars.org
compatiblity issues with missions with the new pxo
« Reply #44 on: March 16, 2006, 05:49:07 PM »
:D hehe, FS2_Open is going to have the multi features i enjoy having