[JGZinv]

I know this has been talked about in the distant past (search yields nothing in the last 365 days)
but where is the development on the overhaul of the netcode sitting?

We could probably make a good list of projects that are going to ultimately need smoother
net play, and in particular hit detection before their release.

Last I heard, we didn't have someone experienced enough in that field to do anything significant
and there were other attached issues that were pressing at that time.

So I figure lets start some dialogue on that again, eh?

[Thaeris]

On behalf of Stellar Assault, we fully advocate the furthering improvment of the FS2 netcode.

 

[z64555]

I also had a question on the data being sent:

What data is being sent over the 'net related to the player positions?


For example, X-Y-Z coordinates, direction angles, current velocity, acceleration, etc.

and:
How, in general, does the FS2 multiplayer work from the standpoints of the client computers and the server?

[karajorma]

Well the big problem with the net code is that I'm the only coder who touches it (Taylor does a lot of the PXO stuff but he rarely touches the game to game stuff).

I've been reading through the code whenever I have time in order to get a better understanding of how it works but basically the client reports what they are doing and the server is responsible for working out everything else (collisions, etc included). I've not looked that closely into exactly what data is sent though.

[JGZinv]

So it boils down to we don't have someone versed in that area to make any major headway.

Ok, do we know what criteria we need to look for in a net code specific coder? (Besides the usual,
C/C++, lives off pb&j, etc)  


Do we also know if part of the problem is related to (or complicated by) Squadwar and the other sections of code getting
ripped out when FS2 got released, or is that more a non-issue / we don't know?

[The E]

It's a non-issue, really. The problem is more that the fsnetd code that replaced the SquadWar/PXO stuff was written to much the same specifications as the original code, which of course also meant that it has much the same limitations. Whoever takes this on will have to basically redesign the entire network backend in terms of client/server interaction and lag compensation.

[karajorma]

The FS2NetD code isn't even the issue here. Bear in mind that even with the PXO code gone you could still play multiplayer if you passed your friends your IP address.

PXO/FS2NetD are stat saving and game matchmaking services. I'm not familiar with it but I doubt that Taylor would have made too many big restrictions in the way it worked when he refactored the FS2NetD code.

The real problem is that the actual multiplayer code (the stuff that handles communication between the server and the client machines playing the same mission) is largely untouched since we first got hold of the source cause only a few coders (Taylor, myself and Kazan mainly) have ever bothered to do anything with it.

Without looking at the code I can think of a couple of major issues.

1) The game is set up with a bunch of basic assumptions (Maximum of 12 players, 2 TvT teams maximum, 1 wing per team) which have been defined as constants. Change any of those and you're going to break a lot of things cause the code wasn't designed to use anything beyond those assumptions and it shows in several places.
 The loadout menu is an enormous example of this. It's based around 12 players and will completely break down if you tried to have more.

2) Something is lagging the game with larger number of players. I have no idea what. The result is that as soon as you have over 9-10 players the game lags out. Unfortunately I lack the kind of network coding experience to track down the exact cause and actually finding that number of people to help test is virtually impossible.

[Thaeris]

Here's an interesting tangent - how does the interface code, which is also quite archaic and chock-full of constant values, relate to the netcode? In a sense, the interface is just another factor bogging down the expansion of multiplayer, no?

[The E]

Here's an interesting tangent - how does the interface code, which is also quite archaic and chock-full of constant values, relate to the netcode? In a sense, the interface is just another factor bogging down the expansion of multiplayer, no?

No. Those two areas of the code are pretty isolated from each other; While the interface needs to be updated for new features, it's not the main reason why changes are so hard.

[JGZinv]

So looking at it from say a PCS2 type example, what are the criteria you want to see
in a net coder kara?

[karajorma]

Basically anyone with experience of debugging anything network related in C would be a step up. I have very little/none.

[chief1983]

Small changes tweaks and optimizations could probably help get to 16, maybe even 20 players.  But reaching levels like 64 or 128 players in the same mission, the system probably isn't capable of handling that.  Systems that can are designed with that in mind from the ground up, and even those often lag when that many players get close enough within a mission to actually matter to each other.  You'd probably be talking about doing updates more often for nearby ships and not every entity in the map, the latter of which I'm guessing is what FSO currently does.  I don't know anything about the netcode really, other than to know that to really modernize it you probably need a coder who has a lot of experience working with net code that can handle that many concurrent players to actually know what needs to be done.  That or someone willing to put in the research hours and figure out how to apply some modern methods to FSO's code.

[JGZinv]

Well, the only thing I know of in the current gaming market that is capable of large player groups
is MAG on the PS3.

Not that I'm saying FringeSpace wants it, because I think it's unrealistic... but Tachyon back in '99
oringally came out with 128 player support. Somewhere shortly after release they found out it didn't
work and things were limited to 64 players using Novalogic hosted maps. Player hosted maps have
always had a hard limit of 32 players, even though from a map standpoint, the environments on many
were identical. Granted at the height of Tach's popularity the 64 and 32 player rooms were filled to the brim
and the game list stretched on for pages both public and private. 64 seems like a very unrealistic number to
shoot for though, 32 is pushing it some too. It's not impossible in the FPS world however to see 32 players.


kara -  I've got a few coding related people I know (besides the one I mentioned earlier). Not sure if any have
any network experience, but I'll send out some feelers and see if I get someone that can at least tell us how big this monster is.

[Reprobator]

Why not doing something like was done for the max to pcs2 support? cash price for netcode rewrite

I think before upgrading the max number of player in a game (a 8vs8 tvt would be already great)
it would be great to have a smoother moving ships in multiplayer because right now it's hard to shoot a shaking ship ^^

[Thaeris]

Frankly, even if that ship isn't shaking and you see your weapons making contact but don't do anything at all, that's far worse.

[The E]

Yes, we know that lag compensation is bad. Which is why we need a coder who knows how to implement a better solution.

[JGZinv]

I'm not disputing that. Just making a note that Thaeris and I are basically in the same
state.. which granted network differences aside... there shouldn't be a significant portion of "lag."
Short of being same city, same ISP, or same room... you can't get much better than that.

I'm probably going to end up testing Kali here in the near future to see how IPX mode
handles things differently from TCP/IP. Maybe it'll tell us something.

Still trying to contact the coders I know.. not having much success.

[Reprobator]

I wonder too how is caculated ping cause sunday i was testing multiplayer with a friend, we are 2 streets away from each other (less than 1 km) and both have optic fiber connexion and the same isp, but fs2 gave us a ping of.... 500? i usually have in anygame somthing like 15/20

[QuantumDelta]

I wonder too how is caculated ping cause sunday i was testing multiplayer with a friend, we are 2 streets away from each other (less than 1 km) and both have optic fiber connexion and the same isp, but fs2 gave us a ping of.... 500? i usually have in anygame somthing like 15/20

500 means something is wrong.


A note to Thaeris and JGZinv;
The client only renders hits on ships if shots hit the ships on the client.
If you see a ship or it's shields get hit, on your screen as a client, you missed.
Lag compensation isn't present at all, you see the ships however many fractions of a second after (*discerned via ping) their current position on the host box, if the host box registers you as having fired and you weren't lined up on their computations, you missed, simple as, end of discussion.

Now, from experience;
Anything under 200ms (.2 seconds) is easily playable.
Anything under 500ms (.5 seconds) is 'compensatable for' with a bit of thought and some determination but 200-500 is a bit less enjoyable.

Anything 1-150 can reasonable called 'live'.
Anything under 100 you cannot complain about 'lag' even if you have no prior experience of dealing with it, most brains can't distinguish the difference, even for gamers.

Now, packet loss is something different, if you have that something is wrong on a connection between host and client somewhere in the intarwerbs.
Packet loss has quite random effects on gameplay.. and is insanely hard to compensate for (it's doable up to a point but after about 40% packet loss you're pretty much only ever gonna be able to dodge incoming missiles and not do much else 'cept shoot things that don't move, even then you gotta pray your fire command got to the server...

Anyway, if the current model is to be used at all it simple needs drastically speeding up.

However, several (!) things to consider;

In most online games, you play with locals, or perhaps continental neighbors at worst.
Most games are built with modern architecture in mind, and take full advantage of it.
Most modern games especially, run on dedicated hardware and aren't hosted on your machine.

FreeSpace usually ends up with games where people are regularly playing from several hundred miles distance.
FreeSpace is built with 56kers in mind, being a niche game that was mostly, meant to be hosted by clients, it's netcode is very forgiving for people who do have high latency, while people who expect a host-experience from clients with modern standards in mind, are sorely disappointed because they're looking for the wrong things.
Most FreeSpace games are hosted on a persons computer while it's playing the game itself, any slow downs on that persons computer or in their network directly effects the game.

[Thaeris]

A note to Thaeris and JGZinv;
The client only renders hits on ships if shots hit the ships on the client.
If you see a ship or it's shields get hit, on your screen as a client, you missed.
Lag compensation isn't present at all, you see the ships however many fractions of a second after (*discerned via ping) their current position on the host box, if the host box registers you as having fired and you weren't lined up on their computations, you missed, simple as, end of discussion.

Forgive me, but I don't understand. To me, if I'm seeing something hit, it ought to be hitting. If there's a discrepency and in actuality nothing's happening, that means there's a problem. The means to fix the problem is assumably unknown to you or I, but it's still a problem.

About the last part with FS being good as a 56K game, I think I'd have to contest that, as would JGZinv. We've had several discussions a while back about the 56K connection capabilities of several older games, and something like FS just doesn't stack up to a game like Tachyon, which could not only handle quite a few players over multi (more than FS), but could also run at very high speeds without substantial lag problems. As such, our general concensus is that FS never had a good net code, merely a passable one for the time. Unfortunately, fixing this problem would require a complete re-write of the net code, and that's probably not going to happen over night...