Inside3D!
     

QSB network protocol
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  

Should QSB 1.0 require a new network protcol?
Yes
100%
 100%  [ 14 ]
No
0%
 0%  [ 0 ]
Total Votes : 14

Author Message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sat Feb 06, 2010 6:43 pm    Post subject: QSB network protocol Reply with quote

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
View user's profile Send private message Visit poster's website
Downsider



Joined: 16 Sep 2008
Posts: 477

PostPosted: Sat Feb 06, 2010 8:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sat Feb 06, 2010 8:15 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Spirit



Joined: 20 Nov 2004
Posts: 476

PostPosted: Sat Feb 06, 2010 8:49 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Sat Feb 06, 2010 10:53 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Sat Feb 06, 2010 11:04 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Sun Feb 07, 2010 12:11 am    Post subject: Reply with quote

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
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Feb 07, 2010 1:48 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Sun Mar 07, 2010 12:37 am    Post subject: Reply with quote

Just one thing, I thought protocol 999 would be a good name perhaps.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Mar 07, 2010 8:49 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
ceriux



Joined: 06 Sep 2008
Posts: 968
Location: Florida, USA

PostPosted: Sun Mar 07, 2010 4:51 pm    Post subject: Reply with quote

what would be wrong with multiplayer mods again?
_________________
QuakeDB - Quake ModDB Group
Back to top
View user's profile Send private message Yahoo Messenger
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Sun Mar 07, 2010 5:16 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Team Xlink



Joined: 25 Jun 2009
Posts: 320

PostPosted: Sun Mar 07, 2010 5:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
Downsider



Joined: 16 Sep 2008
Posts: 477

PostPosted: Sun Mar 07, 2010 7:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
ceriux



Joined: 06 Sep 2008
Posts: 968
Location: Florida, USA

PostPosted: Sun Mar 07, 2010 7:36 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    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