Talking in idealistics: Networking

[eezstreet]

NOTE: If you don't care much about technical stuff in JKA, best to turn back now, as I will use quite a bit of coder buzzwords here that I don't want to explain at the time of this post.

 

Okay, so we all know that getstatus and getchallenge are a huge issue. No doubt. But what could we possibly do to solve this?

Well, I have been mulling over a possible solution now, but I have found some new motivations to support talking about it. The solution? A second port.

 

Traditionally speaking, RTSes and even FPSes have been using UDP as well as TCP for ages. I'm not sure why Quake 3 doesn't do it, but basically the idea is that you use the TCP port to handle getstatus and getchallenge, so that the UDP port (the game) goes unhindered. You'd want to check the last used getstatus request, and simply not send anything back (kinda like how flood protect works in JKA).

Downside? It breaks your server's support for the master server. Sorry. Also, it prevents any clients using base JKA from using your mod. Bad. Also breaks all trackers.

 

This also has the side benefit of allowing for Peer to Peer Lockstep. Another of JKA's major flaws is that it handles missiles and crowd NPCs (even effects!) under the same respect as a general entity such as a player. That's fine and all, but that has some really bad effects if you want to make a bunch of missiles on screen at once. This could likely fix the issues with the Flechette lagging the game so badly on some servers. No real downside of peer to peer lockstep, other than perhaps people's clients not being able to handle all the awesome graphics at once XD

 

 

 

This brings me to my second point: a second entitystate/playerstate. With the guidance of @@Scooper, I have been working on a system of a second playerstate/entitystate combo which removes the limitation of what values are in ent->s and ent->client->ps. I added some new areas to those: ent->x and ent->client->ns, which do just about the same thing and can be accessed through pmove. The only thing I have left to do is get them organized into the client snapshot and get everything all predicted and lerped properly. They're kinda sticky at the moment, because the server runs at 25 FPS while the client runs at about ~60-90, so obviously some things which are meant to look smooth will look a bit chunky. That is, until the snapshot system is all figured out.

So far, I managed to port this system to JKG, and I will be using it for the saber system as well as moving some values which were previously kept in the userint crap (ironsights and sprint stuff mostly) into it.

 

There's only one downside to this though: people running on base can't connect to your server, even if they have the mod in question. No can do. The UI does some sort of networking before the mod even gets loaded, so you'll wind up with an error about illegible messages or some such.

[Astral Serpent]

Awesome, also why care about those lesser scum that don't use your mod?!

Well, unless your mod were intended to be server-side only.

 

 

 

because the server runs at 25 FPS while the client runs at about ~60-90, so obviously some things which are meant to look smooth will look a bit chunky.

 

why not sv_fps 125?

[eezstreet]

why not sv_fps 125?

Because then clients with low FPS would crash.

And I also don't like having hitches on every server frame.

[Scooper]

I believe I've mentioned it at some point eez, but it's possible to make the second entitystate/playerstate allow people to connect even though they don't have the required mod. You have control of when the server writes the states to the client, so you can decide to not write it to the specific clients who don't have the required client mod. The issue will be synchronizing on the clients who have the mod when they should start reading the second entitystate/playerstate. Maybe use an userInt for that? And the serverside mod will have to be aware that some of the clients will not have the second entitystate and playerstate available, but they can still be used on server side.

 

But I imagine that most mods that will benefit from the extra networking capabilities will already be heavy clientside dependent, so support for people playing without proper clientside modification might not be necessary.

( Only talking about compatibility for the network states, not the extra port stuff. I don't know what you have there that might cause base clients to not be able to connect =] )