Hype! Looking forward to this

awesome! very cool.

Mushi - can you roll this in to nQuakesv? Also roll in Qizmo while you are at it

"Server side "antilag" which works better and more precise than MVDSV."

Really nice

Another game-mode should be a Storm-like mod

3 vs 1
3 defenders - 3 slow-flying rockets without splashdamage and some reload time
1 attacker - 1 "rail"-like weapon with long reload time but instagib

Goal: Attacker kills all deffenders or capture a flag that is only available for a given time

Just wondering how a server-side-only antilag could possibly work. Cutting edge technology must be.

When antilag came to ezQuake, the first implementation was client side. But after they realized it was flawed, they moved it to server side.

It has nothing to do with the mod but with FTEsv (from Spike) which presumably implements it in a different way that mvdsv. However it's a bit weird that he brings it up for the mod since it has nothing to do with it, nor give any details on why it's "better".

i take no credit for the antilag code, just wanted to ad it so people know it's there.

on another topic getting bug reports is needed, some server bugs are reported and fixed but the mod has none yet which makes me think people who play this game are bots.

The server in the post (fr.besmella.com:2901) doesn't work fyi.

FTE's antilag uses per-attacker logs while whoever ported it to mvdsv decided to use per-attackee logs instead. The subtle difference means that FTE servers more closely approximate what the client saw (the logs are of your own connection rather than other people's), which results in greater LG accuracy and people falsely reporting players having a larger bbox size.
considering ktx players are familiar with mvdsv's less-precise antilag, it makes sense to warn them that their accuracy may improve, but yes this is a server thing rather than a gamecode thing, running ktx in fte would give the same improvement (at the risk of incompatibilities elsewhere).

Thanks for clarifying Spike. Hehe, the point was that it's mentioned in cspree vs ktx comparison, which is, as you mention, not an advantage of cspree but FTEsv and nothing else

i cannot get hold of the guy responsible for fr.besmella.com but in the meantime please use these instead:

quake1.de:28501 (Germany)
nicotinelounge.com:28501 (USA)
N/A for Australia

"The subtle difference means that FTE servers results in (...) people falsely reporting players having a larger bbox size."

Would you mind further explaining this? Did you mean that the FTE implementation results in players (falsely) believing they are getting hit when they shouldn't be. i.e. FTE has a negative side effect versus the MVD implementation? Or did I misunderstand and you mean it the other way around, meaning the MVD implementation makes players feel that way (so the FTE implementation is better in this regard)?

I'm curious because I frequently play with 100ms+ versus Europeans and they often claim that the antilag gives me an advantage because of the lg hitting them around corners I've always wondered if this was just a "fake" advantage, meaning that people get frustrated because they *think* they died after they escaped around a corner, whereas in [my] reality I killed them before they moved out of sight, meaning that the frustration is misplaced since the only reason they think they escaped is because of the ping difference. In other words, if pings were even they would have died *anyway*, just sooner (i.e. without the frustration of thinking they had escaped).

Thanks,
BD

go play cspree, see if it feels better or not yourself.

The problem is that some of them (LPBs) already think that mvdsv anti-lag benefits our (HPBs) aim compared to 12 vs 12 ms. A technical explanation would help us to convince people to play in a fairer server with a proper antilag implementation if that is the case.

the implementation difference affects both HPBs and LPBs.
iirc mvdsv's implementation makes stuttering players a little harder to hit, so switching to fte should favour the LPBs slightly (relative to mvdsv), on account of the HPBs being more likely to stutter.

regarding antilag in general, if someone can easily be shot around a corner, then remember that all of the time that an LPB spends shootable around the corner is equal to the length of time that the HPB couldn't see the LPB after they emerged from the last corner.
antilag balances that out. It doesn't favour HPBs other than for the fact that the lack of antilag penalised them.
the only part that isn't quite fair is the knockback the LPBs might take while around the corner, other than that they're just taking delayed damage (that's kinda what antilag is - from the perspective of the attacker the lag is moved from the attacker's aim to when the attacker's damage actually occurs).

ultimately though, if you want a fair game then enable sv_minping or something, otherwise the LPBs will still have the advantage regardless of whether antilag is on or off.

the one thing I will say against antilag is that HPBs are no longer rewarded for being able to lead their shots accurately, which is a shame.

Thanks for the response! Bogojoker had put together a pretty long list of all the pros/cons of antilag from experience, I wish I could dig it up because there was some good stuff in there.

Regarding the "shootable around corners" being exactly balanced out by having the advantage when emerging out of a corner, this has been my understanding as well.

But I've also thought of it as even though the LPB feels like they died unfairly around the corner, if the pings were even they actually would have died before "escaping" around the corner because they would have been shot dead before having time to hide. So it's not a death that they would have avoided, and the frustration is misplaced because it only feels wrong but on even pings they would have died anyway, just a bit sooner than they thought. Does this argument have any merit?

The other thing I've always wondered is regarding picking up weapons or packs and having time to switch and fire. AFAIK antilag doesn't help at all with this, which is why high ping DM4 is so frustrating: if you're lucky enough to make it to the LG before dying, and you try to switch to LG and fire, more often than not the shot ends up being an SG, not an LG, so you die anyway... It almost feels like even though the client knows that you picked up a new weapon, switched to it, and fired, the confirmation from the server that the weapon was indeed picked up hasn't arrived yet so it forces the client to fire the old weapon. I have no idea how the network code works, but is there anything that can be done about this? Is there any advantage at all to having a weapon script where the switch+fire happens in a single alias, versus one command to select weapons and another command to fire (i.e. do the actions get batched or combined into a single packet when sent by the client or interpreted by the server)?

+1 for the picking up / shooting problem. This is so frustrating.

Regarding the fte vs mvdsv implementation difference, if this is only about the stuttering, it isn't really ping related. It seems to me that it is a problem with PL instead. The more PL. the more stuttering and hard to hit.

And about anti-lag in general, one thing that still negatively affect the HPB's is the knockback blackout. In a LG fight, if you get hit first (which probably will happen if you have 100ms disadvantage), your aim will be screwed because anti-lag is off during knockbacks, then, unless the LPB attacker miserably fails on LG aim, you will never be able to hit him back, because your aim will be misplaced because of the lack of anti-lag.

I cant change settings cuz menu is not working here since i somehow bind those keys to teamplay msg help for commands

Bogojoker's list of high ping/antilag pros&cons: http://pastebin.com/11khAVd0

@tsobo,
Just use forward+back+strafe keys to navigate the mod's menu. There's no need to bind anything new.