NW3 ZP/Lag compensation poll

[Feralidragon]

Well, I am not exactly aiming for realism with this mod (just look at weapons like The Miner, how come a realistic weapon would be able to have all those different kinds of totally different mines? lol), but yes, I try to give a bit of "realism" in what comes to how the weapons affect the environment, although with UT I can't do much.

Anyway, UT is the only game I know with ZP, however there's something else called "lag compensation" which is exactly to do the same as ZP, but server-side.
The ZP concept is not used in other games because since it makes the client the authority on if either a shot hit or not, it's fairly easy to exploit (and no, obfuscation doesn't make it safe specially since obfuscation in UT is shitty and easy to overcome and get the source anyway).
Therefore, games use "lag compensation", which is the concept I explained in one of my posts above, which is solely processed in the server but tries to have the same effect as ZP. It's more secure, it works and it's widely used in almost all FPS games since 2004~2005, for example:
- UT2k4
- UT3
- Team Fortress 2
- Call of Duty (most of them, if not all)
- Battlefield
- Many UDK based FPS games (A.V.A., Blacklight Retribution, etc)

Of course, lag compensation has a few "problems": getting shot through walls just right after you took cover from a >100ms pinger, shots out of nowhere a few times, etc.
But, unlike ZP, lag compensation does not depend on what each player sees, rather it only takes the player ping in consideration, so if the player is too laggy even in movement, he doesn't get any advantage, and thus why it's the method of choice in modern shooters to fight ping.

My system however would be a bit better since I would make a hybrid out of the 2, getting the best of one and another, while trying to avoid the problems each one has: so it gives a good experience, security and doesn't necessarily give an edge to high pingers/laggers.

Anyway, as I mentioned again and again: this system will be completely optional both for the player as for the server, being the server the ultimate authority in these decisions (from the actual shot to either the system is enabled or not), so just in case people don't like, they have options just like ZP has.

[SC]-[WARTZ_{HoF}]

Could you also include a standalone ZP/lag compensation for standard weapons as well.

[UT99.org]

for the sake of clarity can you explain difference between a shock ball, a player, and a redeemer in respect to player server replication. Most people who play all the time would know shooting down a redeemer will only sometimes work, if it is your own redeemer you have about 1 and a half seconds after you launch it that you can get a 1 shot kill on it, otherwise you have to cause damage to a good radius of area of where it 'might' be on the server but not necc where it is on your own screen. On sniper servers they have to be facing the same general direction for a couple of seconds for you to shoot it down, right towards you or directly away from you. I know there was some discussion on redeemer subclasses, and I think there was a lengthy discussion on another forum about it, so is this an example of UT99 built in lag compensation?

Obviously a guided warshell or a player have a mind of their own, but I am trying to convince the small group of zp fans that even lag compensation is a tad rediculous. I know you want to have a go at this Ferali and I will throw a suggestion out there that you release the core of nali weapons and then each weapon as a seperate entity (package) and let the admins decide if they want to use a weapon swapper to add only one of your weapons or all of them and that way you can further customise everything down the track and have optional extras like zero ping rifles

But to conclude all this ranting I should say that I probably won't spend a lot of time playing NW3 weapons except to try it and look at some of the steps further you have taken it from existing mods. The More Rubble weapons, Ut2003 pickups, the sound effects, models and textures you use. The lighting that they have. I really can't wait to see what you have done

[Feralidragon]

Could you also include a standalone ZP/lag compensation for standard weapons as well.

This would be a NW3 only thing at first (I have to remind everyone that this is just theory so far and I still didn't make anything practical). If it ends working out then a small standalone package can be made to make new versions of standard weapons to use it.

for the sake of clarity can you explain difference between a shock ball, a player, and a redeemer in respect to player server replication.

Ok:
- Shockball: the projectile is created in the server, replicated to the client, and from there the server and client update its position in their own (unless the server forcefully detours it from it's position, since shockball is not tear-off unlike many other projectiles);
- The player and redeemer replication are very alike to each other, both are updated in the server and their moves are then replicated to the client, where they are buffered/interpolated so their movement looks as smooth as possible, and in the client-side of the player which is controlling them these 2 objects (redeemer and player) never look laggy at all there, since he's the one giving the instructions in what both should do.
There are differences though:
a) The player replication is much better and much more smooth, as it has special more complex native replication code afaik, while the redeemer tries to do a simpler replication through UScript alone;
b) The redeemer always depends on the player view and other player flags, while the player only depends on the direct inputs from the actual human behind the keyboard;
c) The collision of a redeemer is tiny, so it's easy to miss it online, but replication wise isn't much different from of a normal player.
When I played UT a lot, I could still shoot and kill a redeemer sideways so I don't think there's any major difference with it.

Also, it may happen that when you shoot the redeemer it's not really there, specially thanks to a lower tick rate from the server (let's say that a server runs at 20fps, your PC at 60fps, it means that possibly the redeemer position won't be accurate at least 2/3 of the time, but again the same is true for players and no one notices a thing since player collision is much higher and the players movements are less wacky than a redeemer).

For instance, I played SLV a lot (as well as some regulars of this forum), and SLV is made from a redeemer, yet the sole weapons you have there are the SLV itself and 2 guns, and since their collision is a bit bigger, shooting down a SLV is not a big deal.

UT doesn't have any sort of lag compensation built in, as lag compensation concept demands "record and rewind", whereas buffered moments keep going forward regardless of ping or any other factors.

I will throw a suggestion out there that you release the core of nali weapons and then each weapon as a seperate entity (package) and let the admins decide if they want to use a weapon swapper to add only one of your weapons or all of them and that way you can further customise everything down the track and have optional extras like zero ping rifles

I am already doing that, but to implement ZP I want to do it right. By making ZP versions of each one later would only make redundant and very messy code, and it's a bad programming practice. So it's either really implemented at the core package and then used by the weapons down the tree now, or it isn't at all.
Also, I have my own weapon swapper to be used and the core release is not an option, it's like asking Epic Games to release a UT game without the whole set of weapons...

The pack will be released once with everything, but each admin can pick and choose the things they want and discard packages they don't want completely. From there, the pack is being built in such a way that adding extras and patching will be a simple as to: download the patch, put the files on System/or run umod, start UT, go to Update, click and done.
However the core package itself cannot be patched, as a patch is impossible since in practical terms if I change something later the whole pack would have to be re-released (to avoid online mismatches).