Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

QSB network protocol Goto page 1, 2 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic

Should QSB 1.0 require a new network protcol?

Yes |

100%
[ 14 ]
No |

0%
[ 0 ]

Total Votes : 14

Author | Message
--- | ---
Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Sat Feb 06, 2010 6:43 pm Post subject: QSB network protocol |

I felt it was easiest this way, let's just settle it with a vote. I'm asking this because it'd be a lot easier to settle on what features to support if you don't have to care about network protocol compatibility, but it'd make multiplayer-mods made for QSB meaningless.
Note that QuakeWorld engines adopting QSB would have their own variant of this network protocol, QuakeWorld and NetQuake engines wouldn't need to be compatible between eachother.
Also supporting the old protocol would be a requirement.
_________________
Look out for Twigboy

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Sat Feb 06, 2010 8:07 pm Post subject: |

I know there's going to be a new protocol, but what should it support? I'm thinking HUD and movement prediction are two definites.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Sat Feb 06, 2010 8:15 pm Post subject: |

It'd support whatever features the standard supports which are related to network changes. Prediction for NetQuake is definitely overkill, and hasn't been suggested earlier. This is not about suggesting new network protocol related features, but rather if it should be standardized or not. Otherwise QSB 1.0 would be a singleplayer standard only.
_________________
Look out for Twigboy

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Sat Feb 06, 2010 8:49 pm Post subject: |

I say yes. The engine land is in good shape and the important engines would have it implemented, I am sure. _________________ Quake Maps

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Sat Feb 06, 2010 10:53 pm Post subject: |

Yes from me too. It's well past time we had a standardised extended protocol. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010 MHQuake Blog (General) Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Sat Feb 06, 2010 11:04 pm Post subject: |

Yes, QSB should require a new protocol. But this doesn't mean discarding support to protocol 15 (I believe this must be required in fact) and, optionally, any other engine-specific implementation (DP7, FitzQuake 666, etc). _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Sun Feb 07, 2010 12:11 am Post subject: |

Yes. And maybe it can have some kind of compression and support download of maps, models, sprites and sounds. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Sun Feb 07, 2010 1:48 am Post subject: |

Clients should support something a bit better, but I'm not sure its practical to mandate incompatibilities on servers, as I previously mentioned. The preconnection stuff *needs* fixing. QW/DP/Q2 are example improvements here. The current stuff is b0rked with NATS, routers, and the smurf stuff, etc. If there was one replacement, this would be it, stating the protocols that the client supports so the server can give a clean message saying what the client needs to support to connect (or perhaps where to get a compatible one from).
NQ's lack of delta compression results in large demos, and a lot of data flowing over the net. Thinking about it, many engines already have extensions to their existing entities for alpha/scale/etc. Adding such extra fields by adding full delta compression at the same time would potentially reduce conflicts with existing demos from such engines (nehara comes to mind).
Sending the gamedir name would also be good. It doesn't have to be supported clientside, but a nice message saying you're running the mod from the wrong gamedir would be nice. Download support would greatly simplify things too, but questionable - not all engines safely load all data formats (id's did not).
Prediction is too tricky really. It can't really be done without the mod supporting it too, at least not accurately and without huge hacks and assumptions. I do not feel it to be practical without some client side game code of some kind also in the standard. So no prediction.
Clientside game code also applies to HUDs, although a Q2-like hud-string aproach may be workable.
QW engines would need various bits expected by most NQ mods - svc_particle would be the obvious example. QW is a bit more current.
Behaviour should be defined for engines that do not provide everything. Eg: engines unable to render alpha treat ents with low alpha values as invisible, as opposed to silently ignoring alpha. This applies even if the full QSG standard requires alpha. This allows gradual compliance.
_________________
What's a signature?

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Sun Mar 07, 2010 12:37 am Post subject: |

Just one thing, I thought protocol 999 would be a good name perhaps. _________________ ReMakeQuake The Realm of Blog Magic

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Sun Mar 07, 2010 8:49 am Post subject: |

goldenboy wrote:
Just one thing, I thought protocol 999 would be a good name perhaps.

that would only be a good name if you're creating it in an emergency. :s
Having said that, adding 1 and using the version number*1000 would not be too bad a plan.
_________________
What's a signature?

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Sun Mar 07, 2010 4:51 pm Post subject: |

what would be wrong with multiplayer mods again? _________________ QuakeDB - Quake ModDB Group

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Sun Mar 07, 2010 5:16 pm Post subject: |

public servers generally prefer to allow as many clients as possible. By using an extended protocol on a dedicated server, you effectively ban a whole load of clients (any that don't support the extensions). You can draw your own conclusions from that.
Depends on the server implementation, tbh, so imho any such extensions shouldn't be made to exclude the possibility of dual-protocol servers.
_________________
What's a signature?

Back to top |

Team Xlink Joined: 25 Jun 2009 Posts: 320 |

Posted: Sun Mar 07, 2010 5:17 pm Post subject: |

ceriux wrote:
what would be wrong with multiplayer mods again?

They might not work because of the new protocol, unless there was backwards compatibility with the stock protocol along with the new QSB protocol.
_________________

Anonymous wrote:
if it works, it works. if it doesn't, HAHAHA!

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Sun Mar 07, 2010 7:00 pm Post subject: |

I've always wondered why a new protocol was needed for something like movement prediction of the character and why no NetQuake engines support the prediction. Isn't just simply doing the same movement code that the server does on the client as well?

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Sun Mar 07, 2010 7:36 pm Post subject: |

ahh ic so basically if they didnt use the qsb engine the multiplayer mod would be useless? but if it was developed specifically on it. then there would be no problems? _________________ QuakeDB - Quake ModDB Group

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Discussion | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group