Q2 idea...

[ligisd]

Ok, as we all know(sorta...) ping is a big problem on servers.(for me which lives in fucking norway D:)
I read about UT99 instagib that they had a 0 ping thingy or something which eliminates the ping differences so that the players with best ping
I FOUND IT: The only problem that could come to the mind about instagib when talking about fairness, is the fact that players with a lower ping are advantaged. In UT, shoots are calculated on the server, therefore if you aim someone, with 100ms ping delay, you'll have to adjust your aim to kill the opponent. The lower ping you have, the lesser adjustement you need. There is a Mod called Zeroping which removes this problem, by calculating the shoot "client-side", meaning that you exactly have to aim to the opponent in order to do the kill, which sounds more logical and natural.

Is it possible to make this for q2?

[VaeVictis]

pretty bad idea :/ unlagged code has been discussed over and over

its really glitchy, and no where near what a lan is like

quake2 is actually the best way to do netcode for higher pings, there is no glitching, either it hits or it doesnt, you can adjust toa  certain ping by aiming a distance ahead, and that is a fixed thing

plus, opening up client side hit detection creates new opportunities for cheaters, with quake2 having a fairly limited anticheat system as it is (a module dll that only works with certain clients) it might cause some problems other than bad gameplay :/

[quadz]

Earlier this year, I brainstormed a bit on a hybrid idea, and chatted with Tailgunner a few times about it.

The idea was a Q2 "superserver" or "meta-server" which ties together a cluster of regular Q2 servers (on different continents), providing a master timeline into which weapon fire and item pickup events are integrated, time-adjusted on the master to offset latency to each node.

I've got pages of notes delving into the particulars of possible implementation details.

If I had time to code such a thing, it might be fun to try, in that I think the result would be different from traditional unlagged approaches.  On the other hand, it would still be weird in its own way.  So it's hard to guess whether players would ultimately find it useful.

The main thing it aims to achieve is that your ping is always "local" (in terms of standard Q2 physics) because you would connect to the geographically nearest server node in the cluster.  Also, conflict resolution is equal for every node, in that, relative to players on other nodes, you all share the same advantages and disadvantages in terms of adjusted latency when conflict resolution occurs in the master timeline.

Anyway...

[Sgt. Dick]

It sounds like a neat concept, but also seems very hard to implement.

I don't have the skills to help code something like this, but would definitely try playing it if it were setup.

[peewee_RotA]

To me there are 2 problems that make me strongly dislike latency improvement code.

#1) Calculating hits locally increases the ability to cheat.

#2) Any adjustments make lag unpredictable and the gameplay suffers extremely. The first UT is the poster child for this. Instagib in UT is like Russian roulette. Lag in q2 is very predictable and once you learn your lead time, you can be very effective at it. We've got a boatload of talented players at 150 ping.

[quadz]

To me there are 2 problems that make me strongly dislike latency improvement code.

You're probably not replying to the superserver idea, but I'll provide a contrasting replies anyway, in case it helps clarify the difference.

#1) Calculating hits locally increases the ability to cheat.

Agreed (or more particularly, if the server accepts the client's calculations.)

By contrast, the superserver idea uses unmodified Q2 clients to connect to the leaf servers.

The leaf servers themselves are trusted by the root server.

So there's no change from regular Q2 in terms of possible ways to cheat on the client side.

#2) Any adjustments make lag unpredictable and the gameplay suffers extremely. The first UT is the poster child for this. Instagib in UT is like Russian roulette. Lag in q2 is very predictable and once you learn your lead time, you can be very effective at it. We've got a boatload of talented players at 150 ping.

The superserver idea retains Q2's predictable lag, in terms of the usual Q2 lead time when aiming.

But the lag itself is minimized by being able to connect to a geographically proximate leaf server.

Indeed, the superserver idea was conceived as an attempt to answer the question: what if one were able to connect to a nearby server with an unmodified Q2 client and experience "local" ping with standard Q2 physics, and yet have the 'hits' you're making count across a synchronized cluster of geographically distributed servers?

[ligisd]

What if we start up some servers hosted somewhere in the "middle" of the world so everyone will almost have as high ping?
Also...We must do something to make q2 more popular!

[The Happy Friar]

The superserver idea retains Q2's predictable lag, in terms of the usual Q2 lead time when aiming.
But the lag itself is minimized by being able to connect to a geographically proximate leaf server.

If there's no difference in lag then it wouldn't help for playing against players playing on the other side of the world (like now), it would only treat everybody on the "local" server as "locals" ping wise, correct?  So if I was playing on a Russian server directly my ping would be 250 (for example).  If I used your way, it would still be 250, but any players in the USA would have a much lower ping (to me).

I still see lag coming being added up because you're not just jumping through hubs, you're then leaving the hub, heading to a server & then back).  Even if 5ms was added to & from each server & you had a 3 Q2 server hop between me & you, that would take a normally 250 ping & jump it to 280. 

It's a REALLY neat idea though, it could make a giant persistent Quake game.  Maybe an infinite world ala minecraft:  each server contains only part of the world & as you leave one border you're automatically connected to another server that has more data.  Overlap would be necessary & a new server to handle larger maps (so there's some overlap) but a 8000x8000 Q2 terrain map is still huge & take some time to traverse.

[peewee_RotA]

To me there are 2 problems that make me strongly dislike latency improvement code.

You're probably not replying to the superserver idea, but I'll provide a contrasting replies anyway, in case it helps clarify the difference.

I was not thinking of the super server idea when I said that, but thanks for the clarifications anyway. Was a good read.

A similar idea was floated to me by a former boss when discussing the problem with him. His idea is basically torrenting information between clients. It's a wonderful idea for slow paced games (mmorpgs) with higher security to stop cheat clients... but it probably would never work for FPSes.

Your version seems to solve those problems. 

[peewee_RotA]

We've got a boatload of talented players at 150 ping.

Another solution is if that boatload of players actually get onto a boat and sail to NA... problem solved. 

[reaper]

In any event the geographically distributed system is  a cool idea.

 

[quadz]

The superserver idea retains Q2's predictable lag, in terms of the usual Q2 lead time when aiming.
But the lag itself is minimized by being able to connect to a geographically proximate leaf server.

If there's no difference in lag then it wouldn't help for playing against players playing on the other side of the world (like now), it would only treat everybody on the "local" server as "locals" ping wise, correct?  So if I was playing on a Russian server directly my ping would be 250 (for example).  If I used your way, it would still be 250, but any players in the USA would have a much lower ping (to me).

It's more like a kind of mutal-relativity.

On your local node, the Russian is about (250/2=125) msec lagged; and on his local node it's you that's 125 msec lagged.

The key is that because the leaf server nodes are trusted (unlike clients), the leaf servers can perform hit testing.  So when you rail the Russian, your leaf server tells the root server that the shot was true in your locality.

The root server accepts such events from all leaf servers as potentially true and inserts the events into a master timeline, offset by the network latency to each leaf server.  The master timeline is used to resolve conflicts in cases where two mutually exclusive events occurred in different localities.

For example, if you and the Russian are both racing for the megahealth, you may think you reached it a fraction of a second before him, whereas he may see himself as having reached it a moment before you.  Either way it's clear a pickup occurred, so you'll each hear the pickup sound immediately in your locality.  But you won't be credited with the pickup until the root server peforms a temporal integration of the events into the master timeline to determine which of you really got there first in normalized global time.  (Which sounds fancy, but it's a very simple mechanism since the root server knows the average network latency to each of its leaf nodes.)

So you'll hear the pickup sound, because either way, the pickup really did occur.  But it won't be credited to your health until after (say) 150 msec later.  (Or if the Russian really did get there before you in global time, he gets credited instead.)

But the same goes for crediting weapon hits as well.  So if someone is railing you right when you are reaching the mega, both your pickup and the railshot will be processed by the root in the order they really occured in normalized global time.

So if you really did reach the mega first, your pickup gets credited to your health before the railshot hits you.  (Even if, in the railer's locality, he thought he railed you just before you touched the mega.)

If it's the other way around, though, and the opponent really did rail you before you touched mega, and the shot fragged you... then the mega pickup didn't really occur.  Your local server's state will be corrected by the root server's master gamestate (all leaf servers may make predictions, but their gamestate in terms of item pickups, player health, etc. are ultimately kept in conformance with the root server's gamestate.)

If we allow your leaf server to predict the mega pickup sound, then it will have had (perhaps) 150 msec to have begun playing before it is cancelled by the root.  That's probably not too bad, as 150 msec into the sound is barely getting started.  But I would consider also playing a special sound when the mega pickup is cancelled to indicate a global timeline correction has affected this leaf node.

So anyway, there's a certain potential for weirdness on closely contested events, BUT, on the other hand, it's the same weirdness from every locality.  No particular leaf node has any temporal advantage over the other.

So... it would be fun to know how it actually feels in practice. 

A similar idea was floated to me by a former boss when discussing the problem with him. His idea is basically torrenting information between clients. It's a wonderful idea for slow paced games (mmorpgs) with higher security to stop cheat clients... but it probably would never work for FPSes.

That's an interesting way to look at it.  I don't think it would have occured to me to frame the problem in terms of torrenting, but it lends a novel perspective.

For Q2 leaf/root server communication, I was planning to use the 0MQ library: http://www.zeromq.org/

[reaper]

if I were you I'd erase this thread and put together a prototype system and look into patents : ).

[quadz]

if I were you I'd erase this thread and put together a prototype system and look into patents : ).

Hehe, I consider software patents to be pure evil.

I have a couple ideas that are almost certainly patentable (one involving software fluid dynamics simulation).

What I should probably do is publish the ideas in some way that hopefully counts as prior art so that someone else can't patent them later.

I seriously loathe software patents.

[The Happy Friar]

I think Congress approved the patent law changes that's first come (register) first serve instead of first create first serve.   If that's true you could make up this neat idea, someone googling could find it, make the prototype, patent & then sue you for not paying royalties. 

I'd say patent it & then just let anyone use it and anyone could look it up on the patent databases.