full delta compression of linear projectiles

[jal]

This article I wrote might make wonders in Tremulous netcode:

http://www.quakesrc.org/forums/viewtopic.php?t=7929

Implementing it will require the coder implication, since this is far of being a simple port, but a technique description that each one will have to implement himself. Despite it, the results can be impressive, specially at games that make use of these kind of weapons, and what game doesn't even use a rocket launcher? A team based game, with plasmagun weapons might get it's bandwitch peakups reduced way more than considerably. A game like Tremulous, with intense use of pulse rifles and lucifer cannons, could easily get it's bandwitch reduced by more than a half.

[Caveman]

sounds nice
But are there any throttled servers left that can not take the the old demands on bandwidths?

[jal]

Any Trem server with more than 16 slots (and many with less slots too) has troubles right now at base rushes. Don't tell me you've never suffered the "human base is laggy" slideshow happening

Well, this would fix it for good.

Of course, it requires a protocol version change so it's not possible to do in a mod. It can only be implemented as a Trem 1.2 feature.

[Caveman]

uhm... actually only on those server that make no use of *.so

[jal]

*.so?

[Plague]

Shared/Dynamic Library's have the extension of .so.  iirc you can boot a server using the library with +set vm_game 0.

[jal]

Ye' but, what does it have to do with the case? The protocol is in the executable.

[benmachine]

08:04 <@Timbo> i only really skimmed the post
08:05 <@Timbo> but is he suggesting doing trajectories for projectiles?
08:05 <@Timbo> i.e. you know where a projectile spawns and it's trajectory, so
               you don't need to continually update the position across the
               network
08:05 <@Timbo> uh its
08:05 <@Timbo> in that case, q3 has done that since day one

[jal]

I'm not familiar with q3 protocol, but are you sure about that? I know q3 finds the trajectories in this way, but isn't it sending the origin? Cause in q3 projectile spam lags just like at any other quake. No more, no less.

[Caveman]

If you are not familiar with the protocol, then how the fuck did you get the basics for your "patch"?

On a side-note...
q3 != ioq3

[jal]

It's not a patch. It's not made on Tremulous src. It's a technique description valid for any game with a protocol based on delta compressed snapshots. Anyway, I expresed it wrong. I'm very familiar with Q2 protocol, and relatively  familiar with Q3 protocol, but I'm not with the Q3 game code and I don't know details like how the projectiles physics are sent.

And I really think someone should check out if Q3 is really doing it, cause I don't get why the netcode reacts so terribly bad to projectile spam. It should not behave like it does!

[Caveman]

Naaa, no need to check the code to Q3.
I think we keep sticking to the IOQ3-code .)

[jal]

??

Caveman, ioQ3 is Q3 for all it matters for this case. When I talk about Q3 I'm refering to any engine based in Q3 src. Specially ioQ3 which is pretty much unmodified.

[benmachine]

??

Caveman, ioQ3 is Q3 for all it matters for this case. When I talk about Q3 I'm refering to any engine based in Q3 src. Specially ioQ3 which is pretty much unmodified.

To steal a technique from Timbo:

Code: [Select]

$ svn diff -r2:HEAD svn://svn.icculus.org/quake3/ | wc -l
 2070957
two.
million.

unmodified my arse.

[Caveman]

The problem might be the original comparison to Warsow....

But the compare is a moot point.

Warsow is based upon QUAKE 2 and neither on Q3 nor on IOQ3 :)

So while it might be true that the original idea might help lowering the bandwidth-requirement for Warsow, I strongly doubt it to be viable for Tremulous.

With tremulous-lags the problem has never been the bandwidth, rather home-server, morons that don't use *.so with crappy hardware or player-side lag due to slow machines/gfx-cards or processes that should not run while playing (p2p).

[jal]

Caveman, you really don't know what you are talking about.

Benmachine, if there is anything of interest, I'd be glad to learn it. What's it?

And yes, for this purpose (and many others) ioQ3 is unmodified. That's ioQ3 concept, be Q3.

Anyway. I offered something interesting. Wasn't useful? fine. I'm not here for coder penis comparisons. Feel free to think what you want.

[Caveman]

jal, I have no coder penis. I stopped coding when cobol went out of fashion .)

In your post you gave a link to some code from warsow, with a good idea (at first glance).
The problem with that idea is, that tremulous just does not have this problem with lag.

And even if you are right, that IOQ3 is not changed from Q3 in that respect, it totally bears no relevance.

Code from warsow is quake TWO, thus totally not applicable to tremulous, as tremulous is (io) quake THREE.

And that is imho the reason we have not that kind of lag you are describing.

[Taiyo.uk]

Ok, flamewars and coder penises aside.

We still seem to be unsure of whether the delta compression technique is applicable to tremulous. There also seems to be uncertainty about how tremulous sends projectile information over the network since projectile spam does cause heavy lag in many cases.

So, first of all: find out whether tremulous already does this or whether it's sending the origins.



On a side-note, lets all go about this without arguing over irrelevant topics. It would be a shame if something as potentially useful as this never happened due to a petty flamewar.

[Risujin]

08:05 <@Timbo> but is he suggesting doing trajectories for projectiles?
08:05 <@Timbo> i.e. you know where a projectile spawns and it's trajectory, so
               you don't need to continually update the position across the
               network
08:05 <@Timbo> in that case, q3 has done that since day one

I just checked. Sorry guys, unless there is a bug somewhere (such as ent->r.currentOrigin being copied to ent->s.origin) then Timbo is absolutely right. The engine transmits initial position, movement type, and time of launch through ent->s.pos. The projectile entity is only updated when it spawns (or bounces).

Lucifer cannon lag is more likely client side rendering lag related to particles spawned by the explosion.

[jal]

I just checked. Sorry guys, unless there is a bug somewhere (such as ent->r.currentOrigin being copied to ent->s.origin) then Timbo is absolutely right. The engine transmits initial position, movement type, and time of launch through ent->s.pos. The projectile entity is only updated when it spawns (or bounces).

It is nice you checked it Risujin. Thanks.