Antilag mutator - a call for testing

[Proud_God]

You're correct, I did replace the core hit detection & damage functions. I was, however, extremely careful to recreate the same behavior that the stock game has.

So what did you change?

 

[Zetsumei]

This might be something off to ask, but could you perhaps add multiple lag compensation methods and gain some statistics on user evaluation.

Basically.

- No lag compensation
- Client side lag compensation
- Prediction based lag compensation (move a player forward from his current direction and speed by the ping amount)
- State based lag compensation (after a shot is fired move a player back to where he was by the amount of ping)

Since the ping estimation of the unreal engine is quite good, server based lag compensation mechanisms might work really well as well. And those are generally safer against user exploitation.

 

[melipone]

Does this still allow for leading targets due to travel time? Or is it just like in hitscan games now where you just hit exactly on the player?

If there is still some lead then maybe a further tweak would be to slow all projectiles down a good amount so you still have to allow for travel time over distance. It was good in Ostfront, and you had to account for bullet dip more. Made long range shots harder or something to learn as you played

 

[Echo Black]

So what did you change?

It's highlighted in the OP...Removal of the hitscan check for close range shots, and of the hitscan check (infinite range!) after a projectile pierces a material. These are the "changes". The latter is (I hope) a bug; The former, one would guess, is a hack TWI employed to diminish CPU usage (which was also in ROOST).

Does this still allow for leading targets due to travel time? Or is it just like in hitscan games now where you just hit exactly on the player?

Yes, watch the second video I uploaded - You can see I'm leading to hit with the sniper quite clearly, and with the Tokarev handgun from far out.


---

 

[Devil_Inside]

I'm impressed! Great job! It feels like a new game.
Now we really need huge maps!

 

[Mekhazzio]

This might be something off to ask, but could you perhaps add multiple lag compensation methods and gain some statistics on user evaluation.

Basically.

- No lag compensation
- Client side lag compensation
- Prediction based lag compensation (move a player forward from his current direction and speed by the ping amount)
- State based lag compensation (after a shot is fired move a player back to where he was by the amount of ping)

A server-side latency compensation method is a completely different project that shares nothing in common with how I've approached it. I'm not very up on doing that just as a comparison lark

Also, I don't think it would be a good fit for RO2 because it is computation & memory heavy to make it work with projectiles, and Unrealscript is pretty slow. My off-the-cuff guess is that you'd probably need access to the actual C++ of the game to be able to implement those in an acceptable performance window. The stock game is pretty close to its practical limits on server performance already.

Does this still allow for leading targets due to travel time? Or is it just like in hitscan games now where you just hit exactly on the player?

If there is still some lead then maybe a further tweak would be to slow all projectiles down a good amount so you still have to allow for travel time over distance. It was good in Ostfront, and you had to account for bullet dip more. Made long range shots harder or something to learn as you played

Bullets in my mutator are not ever hitscan. That was one of my major goals in making it. The default RO2 has this weird amalgamation of hitscan and ballistic projectiles where it can hitscan a bullet for the first 50 meters of shot distance, and it always hitscans everything past a wall penetration. I've eliminated both of those, it's 100% ballistics, 100% of the time.

What they -are- is moving how they're supposed to be. 800 meters per second is very, very fast. At close range, it's almost the same thing as hitscan. I suppose I could add a projectile speed multiplier...but that's kind of weird. Part of the reason for this project was to fix the arbitrary differences in leading from server to server...not add more

 

[MrHello]

Tested it! Amazing, simply amazing.

 

[[TW]Ramm-Jaeger]

Bullets in my mutator are not ever hitscan. That was one of my major goals in making it. The default RO2 has this weird amalgamation of hitscan and ballistic projectiles where it can hitscan a bullet for the first 50 meters of shot distance, and it always hitscans everything past a wall penetration. I've eliminated both of those, it's 100% ballistics, 100% of the time.

What they -are- is moving how they're supposed to be. 800 meters per second is very, very fast. At close range, it's almost the same thing as hitscan. I suppose I could add a projectile speed multiplier...but that's kind of weird...

The reason RO2 (and RO1) use a hybrid pre-fire trace before launching a projectile is because spawning actors is a VERY expensive operation. I did many tests to determine the range at which bullet drop actually became a factor (which was usually 25 meters for SMGs, 50 meters for rifles). Then I used that for the pre-fire trace to see if the bullet would hit something close by before actually spawning one. It saves a LOT of performance on the server (and likely would help on a client in your model as well).

 

[Echo Black]

The reason RO2 (and RO1) use a hybrid pre-fire trace before launching a projectile is because spawning actors is a VERY expensive operation. I did many tests to determine the range at which bullet drop actually became a factor (which was usually 25 meters for SMGs, 50 meters for rifles). Then I used that for the pre-fire trace to see if the bullet would hit something close by before actually spawning one. It saves a LOT of performance on the server (and likely would help on a client in your model as well).

Was the reason to have bullets post-material-penetration become hitscan traces a performance decision, too? 'Cause once we discovered that, it came to light just how exploitable this little thing is. You can purposefully fire through a fence in Spartanovka and have your Mosin Nagant behave like a Railgun on the way out. Add to that the lack of a damage falloff post-penetration... It needs fixing on vanilla ASAP.

---

 

[Proud_God]

Mekhazzio, FYI, I just had a crash playing on Ducky's server. Maybe too much hit markers on the screen...?

 

[Mekhazzio]

It saves a LOT of performance on the server (and likely would help on a client in your model as well).

Yep! I figured that was why you guys did it that way, it makes perfect sense. But, naturally, when the spawning is being done on only the clients, it neatly solves the problem of scaling up to a full server's worth of weapons quite handily. Instant distributed computing. Thus I feel like I can afford to go to 100% projectile firing, which produces higher fidelity behavior and simplifies the code dramatically. The hitscan & projectile split makes for some pretty tortured logic paths and duplication in your stock methods.

 

[MrHello]

Mekhazzio, FYI, I just had a crash playing on Ducky's server. Maybe too much hit markers on the screen...?

I just crashed with the PPSH

 

[Mekhazzio]

Mekhazzio, FYI, I just had a crash playing on Ducky's server. Maybe too much hit markers on the screen...?

Oh yes, the game will implode if you go over the top with those. Unreal provides those graphics as a debug tool, they're not at all optimized. You can erase them by performing an ammo check (hold the reload key). I was tempted to turn them off entirely for the public test version, but they make it so much easier to diagnose a problem - someone can just post a screenshot of it and bam, everything I need is right there.

 

[Proud_God]

Oh yes, the game will implode if you go over the top with those. Unreal provides those graphics as a debug tool, they're not at all optimized. You can erase them by performing an ammo check (hold the reload key)

I know, but that's not enough to clear the buggers when you go full auto. Can you maybe only enable those markers when holding tac view or something?

 

[Ducky]

@Mekhazzio,

In case you are interested, please find attached the server logs so far.

Regards,
Ducky

PS: Nice to see that the bots also have anti-lag

 

[[TW]Ramm-Jaeger]

Yep! I figured that was why you guys did it that way, it makes perfect sense. But, naturally, when the spawning is being done on only the clients, it neatly solves the problem of scaling up to a full server's worth of weapons quite handily. Instant distributed computing. Thus I feel like I can afford to go to 100% projectile firing, which produces higher fidelity behavior and simplifies the code dramatically. The hitscan & projectile split makes for some pretty tortured logic paths and duplication in your stock methods.

Another thing to watch out for when spawning projectiles very close to the player is that sometimes their collision doesn't take effect for a frame. So sometimes this can cause very fast moving projectiles to go through someone if you are shooting a person very close to you. The hybrid pre-fire trace fixed that issue, so you may want to watch out for it.

I just did a Steam community post to get a bunch of players on the FK server to try this out. They are up to almost 64 right now I think. So you might want to jump on and try it out. The really high ping guys like the Aussies on the server seemed to really like it.

 

[Mekhazzio]

Another thing to watch out for when spawning projectiles very close to the player is that sometimes their collision doesn't take effect for a frame. So sometimes this can cause very fast moving projectiles to go through someone if you are shooting a person very close to you.

Yep, I discovered that one early and addressed it.

Thanks for the official community post!

 

[luciferintears]

I still thoroughly believe the best, fairest, and most balanced experience to be had in a shooter is playing with the classic server authoritative hit detection with a good ping (sub 50ms).

This is a great idea for a game like CoD that has 50,000 players on at any given time, whereupon i have a selection of at least 35 different servers all within walking distance of my house.

Unfortunately RO2 is not in that category, and i am repeatedly forced to play on servers 2 oceans away; so i am lucky if i get under 150ms.

Now that that is cleared up, i believe it is safe to say that another solution should be considered; even if it is not to your personal liking

 

[wazups2x]

[QUOTE=*

 

[SparePoerisija]

Taking all I said back - it's nothing like BF3. TWI should hire this guy. He's a wizard, game is damn near perfect now.