phrantic is cpm24 and house of decay (this is t9 right?) is a q3: team arena map. thunderstruck was one of the arenas in ra3map1. there are always 4 different arenas in q3ra maps.

in lan conditions maybe cg_optimiseBW could be 0 and i don't see a reason for allowdownload 0

ah yes, cpm24, dunno how i forgot.

yes, house of decay is t9 and is in Q3TA (mptourney1) but i don't know how to run the map in baseq3 or in CPMA, i can only run it through Q3TA.

optimiseBW at 0 makes a point, but i remember reading somewhere that using it at 1 is also good for LAN. my guess is that it doesn't matter whether it's 0 or 1 at LAN. not sure though.
are the other settings correct? halp please.

yeah i think every command you got is ok. afaik optimiseBW just reduces the ammout of data you are sending to the server. in lan conditions i don't think this is necessary.

phrantic
http://q3a.ath.cx/map/cpm24/

thunderstruck
http://q3a.ath.cx/map/ra3map1/

house of decay
http://63.193.210.31/q3/ta_mapz/mptourney1.pk3

hektik and furious heights are part of the few maps that are newly designed for QL afaik

iirc there is a command to increase server tick rate in Q3, which is an awesome feature by the way and totaly kick ass in LAN environnement.

sv_fps

ye! sv_fps 125

btw does this setting was set to 125 during q3 LANs era?

Anything above 30 had negative effect in vanilla Q3 (or in regular mods like osp, 3w, etc). We had funs on lan with 125 and pmove enabled, but I wouldn't call that better, more like insanely weird:)

The currently used 40 in QL probably required some modifications as well. Iirc they also made it possible in cpma later, but I never tried that one, so if there were lans with cpma@125 fps.. i don't know if those worked out well or not.

it works wonders in cpma feels like xerp when xerp is off but 999999999 better with less bullshit happening.

oh, I just read that Pushpabon said you can'tt change it and it's always 30?

I'm confused now

from what I can tell you can't change snaps as it automatically adapts to sv_fps iirc.

from the CPMA docs: snaps
snaps should NOT be set in your config. CPMA adjusts snaps value
according to the server's sv_fps value. If you join a sv_fps 20 server
your snaps get set to 20, if you join a sv_fps 30 server your snaps get
set to 30 etc...

EDIT: searching through the docs I haven't found anything that would suggest the sv_fps is blocked in fact if you start up a server you can see the difference as setting cg_truelightning 0 with sv_fps 125 looks like 0.85 at sv_fps 30.

EDIT2: There is some stuff in the changelog ( you can look through them ) but nothing that would suggest that sv_fps can't be set.

It's not about snaps which I understand of course... it's about sv_fps and he said you can't change that because it's always 30.

Please note that I understand that you can change sv_fps in CPMA as well, but I never really tested if it has any effect or not, since I never had any CPMA server (ok, I had some a few times but they were just requests for weekends or for single games, and I was never really interested to dig myself into testing non-standard settings like with OSP for example)

edit.: I don't have cpma on this machine, but I will test it later.

Generally it was set between 20 and 40.

kinda awkward to see that even CS and CS.S and almost every SourceEngine games use at least 60 tick rate for the server. It s 2012, Quake is not up do date !: )

hmm can you tell me more? why is it so good for LAN? does it have something to do with listen servers?

I don't think you could find a proper Lan event using listen servers, that would be ....

Maps that are original to QL won't be available in Quake 3 for copyright reasons. You could convert the QL maps to work I think, but it would be more trouble than it's probably worth since they would be illegal to use anyway (what's the point if nobody plays it).

I think House of Decay on Quakelive is the Dreamcast version of the map. I don't know if that exact version exists for Quake 3.

As for running the maps, just drop them in baseq3 and then in-game do /cv map *mapname*. Some of the custom maps won't show up in the selection screen for whatever reason. As long as the .pk3 is /baseq3 though, you should be able to callvote them.

it isn't any trouble at all to convert maps. use quakelivedec to decrypt the QL map PK3, extract the BSP, levelshots, textures, and so forth, and edit the BSP protocol id with a hex editor. done. I made a program to automate a lot of this stuff a long time ago but I'm a lazy piece of shit who has yet to make it usable.

I had no idea it was such a well-known process :(

yeah, I wonder too, you're the best Quake h4xx0r evarrr

wut?

no what I meant was, the House Of Decay that comes with Team Arena cannot be run through Q3 or CPMA, only through Q3TA itself. It is inside the pk3 files of Q3TA so if I try to run it through Q3 then I get a map not found message. Maybe if I extracted it from the pk3....

Just copy the appropriate .pk3 over to your baseq3 folder with all the others.

I'll have to rename them, since they're also named pak0/pak1/pak2/pak...
I'll try it and see if it works.

EDIT: doesn't work.

I *think* you should just copy them over whatever is already there without renaming anything. Back them up first to be sure though.

I think you can't just copy the team arena paks to you baseq3 folder, you have to extract the required assets and make a new pk3 with the required files only.

That only really applies if you're playing baseq3; all other mods load their own vms from their own mod folders.

If House of Decay was a dreamcast map it might be in here: http://lvlworld.com/review.php?id=999

It does present in that pack (as dc_map06), but differs from Q3TA's mptourney1 (e.g. Dreamcast version has all flat floors, probably for lower r_speeds' sake, since original maps were reduced/tweaked/adjusted for the Dreamcast by Raster Productions who did the porting of the game). Both of them obviously differ from QL version (YA/MH, extra teleport, weapon placement).

Are you making a dedicated server for us?

Should I? :P

OH YES YOU SHOULD! :DDD

cg_laghax should be -1 not 0
cl_maxpackets needs to be the same as your maxfps ie 125 if 125, 100 if 100, not 125 and 100 or 100 and 125.
snaps you don't have to set because they follow the server which is always 30 and sv_fps can't be changed, it's 30.
cg_xerpclients is user preference. 0 or 1.

can you explain why laghax should be -1? i'd like to learn more about the inner workings too. remember, i'm trying to get the best settings for lan.

cg_lagHax <-1|0> (default = -1)
A combination of adaptive prediction and an updated version of the
famous "50ms hack" we introduced way back in 99v6 that also does small
amounts of lag compensation. Capped at 100ms no matter what: this is
intended solely to make European / EastUS v WestUS / etc games a bit
less of a hassle, not to hack dialup players into aimgods at the expense
of everyone else. 0 disables it, -1 means "as much as I'm allowed": it's
naturally adaptive. You'll lose some of your "feel" for lag, which
messes up your RL aim, etc. This doesn't suffer from the CS/etc problems
of "total BS" shots that piss everyone off; it's not trying to be some
panacea for modemers; and I'm honest enough to call it the hack that it
is instead of pretending that it magically makes lag suddenly not exist,
but all in all it's a pretty nice end result. If you use this, any form
of nudging will generally make you LESS accurate if your ping's under
100ms, because it'll screw up the adaptive calculations.


I'm not sure but I think the 50 ms hack fixes the default q3/osp behaviour where updates are lagged 33-66 ms even on lan or something.

"I'm not sure but I think the 50 ms hack fixes the default q3/osp behaviour where updates are lagged 33-66 ms even on lan or something. "

Iirc that was part of the cg_smoothclient "solution" which was working well on lan/low ping vanilla q3 enviroments, but was somewhat more random in cpma (cg_xerpClients 1).

http://www.esreality.com/index.php?a=post&...pid1369460

Long explanation on why maxpackets should be the same as your fps:

can, in principle, to write an article in Russian on this subject. vobchem preamble: once upon a time (Q3A 1.29) was a limitation on ku3 cl_maxpackets 100. This caused an uproar in the development team CPMA. In the end common sense won and ID removed this restriction. So, here's an interview about this Quake 3 warping and the cl_maxpackets debate ...
Posted 15:40 on Friday 16th August
Another snippet lovingly thrown at My door by Coder Guru arQon from the Promode Team, this time regarding cl_maxpackets and com_maxfps settings. Now I've been using the settings he hints at, 100/100, along with 0 timenudge for between six months and a year now, and the difference was quite marked at first and has certainly improved my consistancy over time. It's very noticeable with rail, but then coming from a Quake 2 background I'm the type of player so rail dependant that I'd notice it quicker.

Either way, here's the mail in full, enjoy.

> And cl_maxpackets give you the ability to send an update every frame or
> Every 2 frames, 3 frames, or 4 frames (and so-on) which means that the
> Amount of packets you send is still roughly connected to your frames per
> Second.

Yeah, pretty much.

> If this is correct, someone receiving (and capping) at a constant 125 fps
> (Com_maxfps 125), with maxpackets 100, is sending an update to the
server
> Every 2 client frames - ie they receive no difference in connection as
> Someone with settings between cl_maxpackets 63 and 100 (inclusive) so long
> As their FPS remains constant - they will always send 63 updates to the
> Server a second. IOW, for com_maxfps 125, cl_maxpackets 63 =
cl_maxpackets 100

FAIK, yeah. Conceivably, it could slice them as half a-move (see below)
two and half-move, but I've never really looked into it.

> Therefore, for com_maxfps 125, cl_maxpackets 30 will send an update every five
> Client frames - ie cl_maxpackets 30 can = cl_maxpackets 25.

Yep

> My OSP
> Servers set the lower limit on maxpackets @ 30 and I'm wondering whether it
> Would make sense to change that to 35.

Maybe, but I doubt it. Mini-explanation to follow ...

> I know that you roughly follow the European Quake scene and you'll
probably
> Know that one of the biggest problems we're facing atm is "le warp". I'm
> Told that this warping is unintentional and most likely their ISP's fault

Usually.

> But it's a popular opinion that players can cause themselves to warp or
> Become harder to hit by using poor network settings

Up to a point, yeah, but as long as it's over about 25 it shouldn't be
much of an issue, if at all.

> I've never understood how my settings affect my movement on someone
else's
> PC since that's updated (by default) 20 times a second. Surely any
> Maxpackets> 20 would be fine?

That's the theory.

Here's the deal: what you send IN those packets are your moves. What maxpackets does is divvy up those moves into chunks. So at MP 60ish, you get two moves into each packet; at 40ish it's three, and so on, but * you always send the same number of total moves regardless *. Higher MP "feels better" (especially for LPBs) because it means the * server's * getting updated more frequently, so you and it have views "closer" to each other, which is always a good thing: it's analogous to the improvement that higher sv_fps from the server to you brings.

It's all about the MOVES, and those are 8ms apart, so even at MP 25 you're only getting 3 per packet. In VQ3, a 320ups snail is going to move a
whopping 13 units in that time, which isn't even half a player width.

The only advantage to low MP is that you save the UDP framing overhead of the extra packets. Frankly, that overhead is absolutely tiny, and given how much of the * upstream * Q3 conn is empty, nobody should be using 30 except for the most horrifically bandwidth-challenged.

IIRC, the upper limit of 100 rather than 125 is id-enforced by the exe itself. Interestingly enough (and I can't believe nobody's tried this yet) that may well mean that maxfps 100 would actually provide the optimal c / s sync.
It would take someone with iX-class skills to tell if it had any real impact on pmove_fixed movement or not: there'd definitely be SOME differences, but 125fps has been damn close to redundant for CPMA / OSP since January.
The best people to see if it makes a difference to the sync are the LG gods, in the same way that going from MP 30 to 60 affected the LG most.
/ Me cc's four more people ... Daveleon is the ideal guinea pig for both. : P

Where low MP makes people skippy is basically just "unlucky" timing between the most recent moves arriving from the player and the server's
most recent snapshot to the other players. Player movement is OOB - it's dealt with as soon as it arrives; it's only that it doesn't * update * back out to everyone until the next snap. So if you have one of those packets delayed by even 25ms (pretty common - my SHIT conn has a flux of about 60ms even to servers I ping <30 to) then you'll get a server frame at t then 6 moves applied to it at t +5, which is the reality. So if you use smoothclients and / or-ve TN on YOUR client, you'll have them pseudo-predicted quite a long way off in one direction which may well not be the right one: if they're dodging around, there'll be a noticeable amount of correction when you get the next snap.
In case it isn't obvious, this is something else that higher sv_fps improves (though only up to a point).

> I don't have an opinion on this myself - I accept that when I miss it's
> Because I missed (or I blame my ISDN connection instead: oP) but I've had
> One or two causes to think about this. I've recently persuaded a modemer
> Friend of mine to try CPMA (he still plays Q2) and I got him to use ix's
> Settings - rate 3000, cl_maxpackets 30, etc. and unsurprisingly, he really
> Warped quite badly until he raised his rate to 4300ish. Modemer's
settings
> = Modemer's warp?

Yes.

If you tell Q3 to treat your conn like it was dialup, then (duh) you get the equivalent of a low-pinging modem. That's why we HAVE things like maxpackets_min in the first place (and CPMA has had min rate enforcement as well for at least a year - can't remember if we ever ported it to OSP).

What it boils down to is this: Carla's favourite rant. That * competition * servers are still running with modem settings is ridiculous. Unless you're Blokey or iX, you've got NO CHANCE of being able to compete on dialup anyway, and you can forget about team games completely.
(Exceptions apply for skill games like CPMA DM; or if you're iX and it's CTF, in which case you can warp at 900ups and be completely unstoppable as a flag runner.: P)
We generally don't need to enforce client settings too much because deliberately gaying your conn generally hurts YOU even more than it does everyone else, but if you've got people who have a "make me unhittable" bind (not uncommon for RA3 snipefests here) then yes, there are ways to block some of those. For the truly determined though there are plenty more ways to crap out your conn if you really want to, so it seems rather pointless.

99 times out of 100 though, it's just a shitty conn / ISP. If there's a router between the player and the server that's overloaded; or prioritising TCP over UDP because some newb netadmin reckoned it would make web pages load 20ms faster, then you're shafted.

> I want people to enjoy playing in my TDM league (without making it UK only)
> So ... what timenudge / maxpackets settings do you recommend I enforce?

Whatever CPMA sets as the default, except for maxrate which id have hardcoded as something stupid and is covered in the last Carla update.

- - -
pF.arQon

CPMA - http://www.promode.org

I was answering to the second part of your post (the last two lines I also quoted) and you linked something about the first (main) part which I was already familiar with very well from the very same interview:)

but thanks anyway;)

Yeah I was trying to find the explanation to why baseq3 introduces 33-66 ms of lag but I couldn't find the url. the google cache of the ukgamer article that supposedly explains it is nowhere to be found.

Also \docs\client.txt says the following about xerp:

cg_xerpClients <-1|0|1> (default = 0)
A replacement for id's cg_smoothclients that does something useful. :)
-1 - Hacked extrapolation: intended for HPBs
This smooths players out when you use high timenudges, at the cost of
some accuracy. It's typically easier to hit a smooth target that's a few
pixels misplaced than it is to hit one that looks like it's teleporting
all over the map, so this combined with cg_nudge is the best option for
HPBs.
0 - No extrapolation. Fine you're LPB.
1 - id's smoothclients: fine if you have cg_nudge 0, worthless otherwise.
Note that prediction errors, such as players in walls, are likely to
occur. Tends to increase how much other players warp to you.
Use at your own risk.

Yes I remember that article.
What I was trying to discuss is that - somehow- cg_xerpclients 1 (aka cg_smoothclient 1) behaves differently in cpma, and I think the reason is that the prediction buffer is removed/changed. (please note that this is only my guess and I have no proof)

I understand why arQon dropped out id's smoothclient, because it was absolutely useless online, but things changed a lot since. I ping 23-26ms in Frankfurt from more then 800km away and playing on a baseq3 server in Frankfurt with smoothclient 1 feels exactly like like how it feels to play on LAN. (ignoring the fact that baseq3 is pretty much useless)
I don't have to predict at all, everything is just exactly right there where I see it. The problem is that this is not working with cpma where things get random and offset with xerp 1, even only with 25ms lag.

Ok then I have spammed you for nothing and misunderstood the whole question.

if you don't count the time (which I appreciate) it's a good thing because we have all this valuable info in a new thread;)

Found it! Long ass article about quake 3 networking:

http://web.archive.org/web/20020609162807/htt...?author=53

-----------------------------------------------------------------------

On timenudge, and Promode's 50ms stüffe....
3:29 on Monday 21st January

Clarification on Quake 3 networking and what timenudge actually does...

Having received many puzzled comments on my last update, with lots of people writing in to express the same impressions of arQon's OSP/CPM netcode, but not understanding enough about how Quake 3 worked to 'fix' their problems, I thought I'd waste a couple of hundred characters on a crash course in id's networking. Now please bear in mind that my understanding of how the game works is based on explanations from people with much bigger brains than I, not necessarily in the most recent of times, and certainly not always in words of a length I can cope with, but this is the basics I could grasp at :) From this it should at least become clear what timenudge actually does, some of what arQon's done, and why it's such a pain in the arse for players who have extended experience of timenudging.

Consider a single client joining a server, or at a map_restart. At that instant, the server sends the client a packet of information called a snapshot. This packet includes the position of each entity on the map that your client can see, and it's current velocity, i.e. it's speed and resultant direction. At this point, the client stores this information and does nothing with it, despite the real world obviously continuing on and the entities moving across the map.

After a set amount of time, the default being 50 milliseconds, (though this can be changed as I'll explain later) the server sends the client another snapshot, with updated information for each entity. At this point, the client then interpolates the information from the two snaps. In essence, it looks at where each entity was in the first packet, where it is in the second packet, and then draws a path across the map for each. It does this using a simple expression of movement against time, referencing time elapsed at the point the renderer calls for each frame to be drawn against the time stamps in the two snapshots themselves. This gives it an idea of how far through this movement described by the two snapshots the entity should be, relative to how long it is now after the last snapshot was received. This is why, despite only receiving 20 snapshots of information a second, that the client is capable of rendering any number of frames per second the user wishes. Remember however, this movement has of course already happened relative to real time. As each frame is rendered and time passes, the game world obviously moves on, but the client is oblivious of this until the next snapshot is received, when the process starts over.

However, regardless of how many snapshots per second are sent to the client, what you see happening on the screen is always drawn after the real events actually occurred on the server itself. This is not only because of the delay in transit, i.e. your 'ping,' but also because it is fundamentally easier and more accurate for the engine to draw things for you, after they have happened (and the client has a snapshot in hand,) than it would be for the client to use the data from each snapshot to predict things for you so you could see them in time with real life. (Like in other game engines, such as some builds of Half Life for instance.) Otherwise, when things didn't go as the client predicted, (say a player model is thrown to one side by a proximine) the client would have to correct this information on the screen later, and hence entity's positions would be changed instantly, at regular intervals, leaving players 'warping' around the screen all the time.

Why id opted for this method could be hopelessly debated. Client prediction has been tried and tested in several 'community' game engines, giving varied results, some successful, some utterly rubbish. The obvious guess is that they wanted to make the game as newbie friendly as possible, i.e. learning to cope with 'lag' rather than learning to cope with constant 'misinformation' from the client. Understandably, they went for the first option.

So with this information in mind then, it might not sound so strange now if I tell you that what you see on the screen is at least your ping, plus 50ms, behind what is actually happening on the server. Hence even on lan, (with a default server cfg) you still have to aim ahead of an opponent by 50ms to be certain of a hit.

So how is it that we are able to hit anything with this delay? Why does this function at all? Well this is where we talk of context. You see, to those of us who have, at some point, struggled with a modem connection, especially in the rail heavy Quake 2, memories of aiming a good two or three player width's ahead just to hit someone are still firmly imprinted on our minds. 150ms is to people such as ourselves, very tangible, so 50ms still seems like an age. However a newbie with a brand new cable modem may think what they see happening on the screen is almost instantaneous. Hence their impression of 50ms would be much lower. Average perception of what 50ms actually 'looks' like vary hugely, especially with these long over hyped uber connections becoming more and more common, and people's expectations of what games should now play like so confused.

Using arQon's words, even a Promode player running at 600 units per second, (fucking fast) will only cover 30 units in a 50 millisecond time frame. Which isn't much bigger than the hit box that decides where on a model you score a hit. It is quite possible, at fair range, to appear to aim directly at a moving player, and to hit them square on.

The problem however, comes when things happen suddenly. Now consider a client walking off the rl platform on dm6, falling to the floor below, and spotting an opponent at the doorway above the pg. Because the client is moving so fast, the time during which that client is actually able to view the opponent is drastically lower than it would be in normal circumstances. During that time perhaps only one, or two snaps are sent to the client. In these circumstances, although the client is probably told the entity is in view at the time the client actually comes into line of sight with it on the server, the entity itself isn't actually drawn until the next snapshot arrives. Which is possibly too late, as the by the time the server receives the client's packet including it's +attack statement, (which states the client has fired a particular weapon at xyz, from xyz, and requests conformation as to what it hit) the player has already fallen out of view of the target. Remember, you're already that 50ms delay between packets behind real time, then you've got to add the time it takes the snapshot to arrive on your machine from the server in the first place, (your ping) and the same time again for your +attack packet to make it back. Which for an isdner will be around 50ms. That's a 150ms round trip, in a split second line of sight timeframe... And we haven't factored in the chance that the opposing player might have already moved, and that their "I've moved" packet hasn't turned up yet. Understandably, this situation will usually, (and no matter how fast you are to react) get the reply "you missed."

And this is where timenudge comes in. Now contrary to popular belief, setting timenudge to a -ve number doesn't directly force the client to predict further ahead into time as such. What it actually does is change the time at which the client releases the previous snapshot's information for drawing. Now without going into too much detail, which would require some basic, but still very alien sounding mathematics, interpolating the data from just one snapshot doesn't work. It instead just spits out the same descriptions of movement that went in, i.e. the same speed and direction that the first snapshot included, rather than comparing the data from two. Using the standard expressions for motion, it then draws the entities where it tthinks they should be, that much time after the snapshot was received. Thus, although the client draws the entities earlier than without timenudge, the positions at which it places them become less and less accurate with each frame, and it is only when the next snapshot arrives that they are corrected. Hence why, when using negative timenudge, you experience more opponents 'warping' than you normally do.

So you are presented with a trade off. Highly accurate, but slow to respond prediction, that detracts from the player's ability to react quickly. Or fast, but less accurate prediction that allows the player to react faster to a changing situation, but with less confidence in their choice of action. And it comes down to the player. Some people, such as myself, have become lazy, suffering from lack of time to practice, letting the timenudge do the prediction for us. Many however, with enough time to play, have learnt to read the game enough to do the prediction work themselves almost perfectly. Perhaps if it weren't a 'next gen' game, and we didn't expect more from the engine, (as I obviously did when arQon pointed out some of the prediction routines I thought Quake 3 did that it doesn't) we'd all try as hard as we did in those early days of Quakeworld and Quake 2...

Is timenudge the beginnings of unfinished predictive code in the Quake 3 engine that JC didn't get time to finish? Would it have made it in if he'd have had the time to make it 'newbie' friendly? Who knows...

For reference tho, until the introduction of arQon's so called, '50ms code,' many players in the know worked out their required timenudge using;

-ve cl_tn = 1000
----------
sv_fps


This way, information sent to the client would be displayed the instant that it arrived at the client, so at least once every snapshot cycle, this information would as close to correct as possible, i.e. only their ping time, and that of their opponents, out of sync, (allowing them to lead with the minimum distance possible.)

This trade off between styles can be biased tho, depending on the server admin. As I mentioned earlier, the time between each snapshot being released by the server can be changed, and this is done with the much debated about sv_fps setting. It defaults to 20, which means a maximum of 20 snaps per second are sent each client. Working in milliseconds, 1000/20 = 50, i.e. 20 snaps, 50ms apart. Now if the server increased sv_fps, the reaction trade off changes. Although a client using timenudge becomes more accurate, as it receives packets more often to correct the errors in it's prediction, a client not using timenudge gets it's information released much faster, making the events on screen more current, hence allowing the player to react at a greater speed with much better accuracy. So, where timenudging might be desirable on an internet ping, (on a server with low sv_fps,) under lan conditions, where sv_fps can be set much higher, (and delays in communication are much lower,) timenudge only serves to hurt the player. For those on a reasonably consistent internet connection tho, timenudge finally allowed the player to aim *at* the opponent, without any noticeable amount of lead, and hit with a fair degree of accuracy. Laziness perhaps, but isn't that what we were all looking for in better connections?

So what did arQon do, and why is it so problematic for timenudgers? Well without directly using his rather lengthy, and somewhat abstract example, it basically boils down to this. arQon wrote his own timenudge. Rather than leave the client to do all the work tho, as in id's code, promode's prediction is server assisted, making it much more reliable than timenudge under vq3. And although it inevitably leads to some occasional visual cliches where the prediction falls over, it fundamentally makes quake 3 much more reactive, edging that window between things happening on the server and you seeing closed. Unfortunately, like vq3 under timenudge, it is still reliant on server admins to get their sh*t together and learn how to configure things properly. Such as setting higher sv_fps for clients on better than modem connections. (Why sv_fps defaults so low when the client cvar, snaps, which dictates the maximum number of snapshots the client requests from the server is already set to the modemer's 20, is anyone's guess...)

The problem for those of us used to using vq3 timenudge is that because of the way arQon's code works, it changes the way in which timenudge itself works. The change in 'feel' is subtle, but still very noticeable with regard to accuracy, and as timenudging the same way is no longer possible on a server using his code, it makes life for those now dependant on a certain timenudge working for a certain setup impossible.

But for those players with no timenudge experience, or for newbies, it makes perfect sense, the code itself so much more functional than id's. The debate as to how many long term Quake 3 players don't use timenudge, and how many newbies are actually coming to the game to make the new code worthwhile this late, is another story. Personally I'm not sure I can be arsed to relearn the game with this code, as vanilla Quake 3 is already losing its appeal rather fast. Promode itself another thing... But others however are having success, and OSP 1.0/CPM is already showing an amazing reception. Astute readers will have already be signed up for BWCPML... :P

But there you go. The end. A dimebar's interpretation of Quake 3's networking. This should at least explain my irritation with OSP 1.0/CPM, but may also help those tweakers out there a little. Many, many thanks to arQ for his helping writing this article. I've included below the full example he sent me to help understand his changes. Feel free to digest it at your own leisure. :)

Timenudge: It's like your mother said, it's not big, it's not clever, and you'll only regret it in the long run :)




"I'm a bit more pushed for time this weekend than I'd hoped, so here's the VERY simplified version of things (with some inaccuracies as a result, but hopefully it'll get the gist across)

Every player exists in FIVE places at the same point in time, depending on where you're looking from. From oldest to newest, they are

1) Old snapshot on different client 50ms + ping + current serverframe time (i.e. up to another 50) ms out of date

2a) Perceived position on different client The interpolated position between 1 and 3, generally ping + 50 ms out of date Nudges have an effect on this - beyond a certain point, nudging will transform this into the mutually-exclusive 2b case instead.

3) New snapshot on different client ping + current serverframe time (i.e. up to another 50) ms out of date

2b) Perceived position on different client The extrapolated (i.e. predicted) position from 3 if you're a heavy nudger Not technically "out of date", because it's imaginary

4) Server The One True Position, in that it's the one that actually matters

5) Own client ping ms AHEAD of the server

Unless someone's standing still, all five of these are distinct. There is never any time, even on LAN, that a client EVER has an accurate view of (4) except through sheer luck.

So, let's say you have two players on the server, both with 25ms pings. If player A is moving left to right at a constant rate, the positions from player B's point of view (with no timenudge) 25ms after the last time he got a snapshot are:
1...2...3...4...5
although, obviously, 4 and 5 are invisible to him.

The problem is, if player B fires now, even though he sees A at (2) he actually needs to be aiming at (5) to score a hit, because by the time his +attack reaches the server, player A's additional movement will have reached the server too, and A will then *be* at 5 for the only definition of "being" that matters - the server's. So player B, who's got a great ping, STILL has to lead his shot by *75ms* to score a direct hit. If he timenudged -25, he'd still need to aim at (5) but his PERCEPTION of the enemy would be that he was at (3), so he'd only have to lead by 50ms, and so on. As it happens, because VQ3 is so slow that 50ms is usually not quite enough time for player A's hitbox to move completely past (3), so B aiming at where he SEES A is *usually good enough* to get a hit.

Now, if we move 25ms ahead, B gets another snapshot and his positions become:
........12......34...5
(By the time B gets the snapshot, he's already 25ms out of date just because of his ping). The snapshot is also the time that B receives the hit confirmation, which is why a lot of the time you get the hit tone on a shot that CLEARLY should have been a miss as far as you're concerned (or vice versa), but you're wrong because you as a client have *no fucking clue* where the player really was. Look at the gap between (2) in the second set and (5) in the first one. See the klesk demo (baseq3 on a LAN) that I linked in my column a while back for a nice example of this).

What CPMA and OSP do is they apply a timenudge-like effect of their own to try and synchronise the client and server views, i.e. (2) and (4). Because this is handled by the server, which is the only thing that DOES know where people "really" are, it's in a much better position to do that sort of thing than a client is. So on a CPMA/OSP server, what's actually used for testing the shot in that first case is:
1...2...34......5
IOW, player B's view with his 25ms ping is in fact 25ms away from "reality". Ideally, he should still lead by another 25ms, because that's how long it'll take his +attack to get to the server; but again, he'll probably be close enough even if he doesn't. However, if he takes the shot 10ms later then it's actually going to reach the server right after the next transition (server frame), at which point what we're looking at is:
........1.2.....34...5
so in this case he should still have been leading 75ms from his view to be dead on, which is just as bad as the id version. The real difference is that where in the id case he ALWAYS needs to lead by 75ms, on CPMA/OSP he should split the difference of the best and worst-case scenarios (ping and ping+50, i.e. 25 and 75) and lead by 50ms instead. Although it's technically LESS consistent than the id version, even ProModers moving at 600 UPS are only going to travel 15 units in that 25ms window to each side, and the hitbox is wider than that, so shaving the lead distance is very worthwhile.

Now, let's replace player B with player C, who is a timenudging slut :P and see what that means. Going back to the original positions yet again,
1.......3...4...5
we've already established that C will see the enemy at (3) but should still be aiming at (5). On CPMA/OSP though, the positions are
1.......34......5
if she gets the shot there before the transition, and the hit will be tested against 4, which means her view and "reality" matched EXACTLY. The thing is, unless her ping is <25, she CAN'T do that because the round-trip alone means she's onto the next server frame and the positions have become
........1...2...34...5
so she remains the same 50ms out of sync that she was in baseq3. Also, because she hadn't hit the target by the time the server sent the snapshot out, there's no hit tone yet. She has to wait ANOTHER server frame for that, at which point things look like this:
................1...2...34...5
and THAT's when she hears the hit. So, she shot at the original (3) because the whole point of timenudging is to just point at the enemy rather than lead them, but by the time she finally gets the confirmation of the hit, her view of A is fucking MILES away from where her railtrail is drawn, and everything looks like it's totally bollixed. You don't need too many of those for you to start losing confidence in the game and try to overcompensate for what you THINK it's doing to your shots, and once that happens you lose the 'feel' completely. That's why the standard reply to people who are confused by the whole thing is just "don't use timenudge" - they all understand the concept of lag to at least some degree, so they can do that and still feel fairly comfy with the whole thing. OTOH, none of them understand that they were effectively timenudging -100 when they had 25ms pings, and they have no clue what that looks like. The simple answer is: it looks like shit, and it throws your game off totally. So don't do it. :)"

Yes that's exactly my problem with this whole thing.
Since we have such a good net nowadays, I prefer id's dumb cg_smootclient 1 + timenudge -20 method, because than my brain will do the prediction which never fails on today's "lan-like" internets, while any kind of server assisted prediction code or whoaomg unlagged magic just fucks things up...

But on lan where the ping is <5 ms and constant with no packet loss or flux aren't you better off with laghax because it still has that reduction of the original engine's delay so you have to aim less ahead especially on high speeds? I'd rather have to aim directly at the model (where I assume the hitbox to be) than to some random fluctuating or otherwise nonmarked position I can't be sure about.

In theory you would be correct, but it turns out that with CPMA it's still random sometimes but with VQ3 it's just right on the spot all the time unless he is moving really fast like 6-700+ ups (I spent days testing this).
Think about this as raw input; in VQ3, you get things from first hand, while in CPMA, a small amount of randomness gets mixed into the equation for some reason.

Please don't get me wrong. I very well remember the OSP times when the kids spent hours arguing about a server locations because of 10ms difference, so I really like and appreciate the netcode in CPMA, (basically I think it's one of best prediction any game ever had)... I'm just telling that I tried VQ3 with today's internet, and I had to pick up my jaw from the floor.)

Yeah on the client side if you prefer you can disable laghax and just use cg_nudge (which is a better version of cl_timenudge) or even cl_timenudge if you're used to it. I really don't know how baseq3 or osp 'feel' but in my experience cpma feels good. You do what feels best of course.

Got any more articles like this? Maybe something regarding the difference between cg_nudge and cl_timenudge and/or cg_smoothclients and cg_xerpclients?

Er.. do you use 100/100 in quake live?

Why would use this instead of 120/120? The game allows you to set com_maxfps 120 and it will stay there per cg_drawFPS 1.

At least in regular q3 engine valid fps values are 1000/x. 125, 100, etc. Either id has decoupled the engine and the netcode from that or the game lies to you. I use 125/125 in ql and q3 because that's the most you can get.

ps. what I posted was an article/interview from some place.

iirc id made QL not to be fps dependent anymore, but you still need 125MP to get the most out of the netcode.

Quake Live used to be the same way. It was never mentioned in any of their change logs when they changed it, but I first noticed it maybe 6 months ago.

I set 120/120 because sv_fps is 40 and therefore snaps is 40. So I get a nice clean 3 updates per snapshot. Don't know if that helps any but that's just my personality.

renderer was changed some months ago, yes (so you can enter any number in com_maxfps - up to 125 ofc)

physics are fps-independent since I play ql

i've read that too, along with this: http://forum.drc.su/cpma-net-settings-explained-vt3719.html

looks like -1 improves gameplay.

what do you say about cg_predict 0 for LAN?

cg_predict 0 is the best, but you will only get updates at a rate of sv_fps serverside setting (which is 30 by default), so if sv_fps is not 125 (or something high enough like 100 at least), it will just do more "damage" to the experience than good, because playing at 30-40 fps is awful.

but isn't sv_fps 30 the standard value used by all dedicated servers? or was that ages ago.

it is 30 yes, that's why cg_predict 0 is a no-go online:)

oooh i get it now.

and what if your online server pings great (~10ms)? that's almost like LAN anyway isn't it? then sv_fps 30 and cg_predict 0 would still work fine right?

Not really sadly, and it also matters what's the size of the packet you sending/getting there with 10ms.
A sv_fps 125 server would need a lot of CPU power and -most importantly - an insane amount of bandwidth from the server and also from the clients(!)
This would turn an online 4v4 game into a nice lagfest:)

thanks :)

If you use sv_fps 125 in cpma xerp is almost useless and pretty much just makes things worse, on LAN that is.
snaps should be removed in the config because CPMA changes it automatically to the sv_fps value.

hey, hi, pm'ed you = )

http://lvlworld.com/#c=m1&i=1824&d=8%...p;p=review

House of Decay, it's only a remake tho. Looks nice but where is the LG? :(

Edit: Nevermind, somebody already extracted the whole TA tourney mappack from TA, works like a charm, with any q3 mod, tested myself.

http://ex.us.to/pub/maps/mp.pk3 <---- put in baseq3, have fun

As for hektik:

http://ex.us.to/pub/maps/1v1/map-hektik.pk3


Have fun!

thanks. sorry i'm so late :P

np :)