• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Will HoS present the netcode disadvantages of UE3?

VodkaGR

Member
Dec 5, 2010
18
10
Hello everyone,i would like my first post to be about something very important for me,netcode.Having been a UT3 and AA3 player,i am totally dissapointed by UE3 when it comes to interaction between player/server

What i mean ; In both games,there is a noticeable fire delay.When you fire the plasma rifle for example,the particle is shown after 0.3-0.5 sec ...In Americas army,the exact same thing happens

Why this bothers me ; It is obvious,it destroys any form of enjoyment online,i have to predict where to fire so my bullet hits the target when he is there,despite the weapon being hitscan and my ping being 60.To be honest i don't even know if the actual bullet is lagging or it's just the particle effect

I have noticed this fire delay phenomenon on every online UE3 game and in Quake live only(if it is somehow connected).I would like to know if this game will have the same problems,as i doubt i can do anything about it or that it is my PC's fault(1200
 
The spec of your PC isn't as important as the quality of your connection...if it's taking 300-500ms for your shot to register, then I'd suggest you need a better connection.
I said that my ping is about 60...i never even play at servers with more than 90 ping.It can't be my connection.Btw,have you played UT3?,and if yes,was everything fine?
 
Upvote 0
Upvote 0
no u dont. If you join a low ping server, there's no bullet lag. and hitboxes are spot on, no lagging behind playermodel.
In UT3 i have joined servers with 50 ping(that's the lower i have ever found though,i am usually about 60) and it was disgusting.If it is a slow game it will probably not be so bad,but then the enemy is jumping around you...meh.
I guess we will just have to wait and see
 
Upvote 0
There is no "disadvantage" to the net code of UE3. It works quite similar to UE2, and Red Orchestra 1 was widely regarded as having some of the best net-code around - with the game being very playable even up to a ping of 200ms. And considering I'm the guy that did the multiplayer network coding for RO1 and I'm doing a lot of it for RO2, you should see similar results in the end. Regarding AA3, I can't speak to it's network code since when I tried to play it it was back when the game wouldn't even function online right after it was released.

When it comes to visual representation of hits (i.e. displaying hit effects/particles) there are two methods possible, and both have their advantages/disadvantages.

Method 1) Calculate hit effects on the client. With this method you get instant feedback on where your bullet would hit (with hitscan weapons). This is great but there is one major flaw - where you see your bullet hit on the client doesn't actually represent where your bullet hit on the server since they are both calculated independently. This was the system that was used in Americas Army 2.X (which I worked on). This system is exasperated by randomness or cone fire, since to simulate the shot on the client you have to simulate the randomness you would also have on the server. The problem is, since it is random the client and the server will have different locations where the bullet will go. This is why in AA2.X you would very often actually see puffs of blood coming off of an enemy that you were shooting, but in reality you didn't hit them at all. Your client side simulated shot had hit them, but your server shot had not.

Method 2) Display hit effects on the client in the proper place by sending the information from the server on where the "real" hit actually happened. The disadvantage of this system is that there is a slight delay between when your shot is replicated to the server and when the hit location is replicated back down to your client. The advantage of this system is that when you see a hit effect appear it actually appears where the real hit happened on the server. In other words, when you see that you blood puffs appearing on an enemy that you shot, you are ACTUALLY damaging them.

In the original RO and since then I have been using method 2. I find the slight delay until the hit effect appears is far outweighed by never getting "false positives" and knowing where my bullets actually hit. Combine this with a non-hitscan system with full bullet ballistics where even if you are playing a non-network game there is a slight delay between when you fire and when your bullet hits, then the delay when playing online is almost not noticeable with a ping < 100 ms.

Also, in your case where you say your ping is 60 ms, but there is a delay 0.3 to 0.5 seconds (300-500ms) either there has to be something wrong with your network, the network between you and the server, or the people coding that particular game. Because in the standard "Method 2" system above, with a 60ms ping it would be about 120ms (or .12 seconds) before you saw the hit effects. Most likely it is a problem with your network, your computer, or your perception of time.

Finally, there are the games with the so called "lag compensation". I've never been a fan of this so called lag compensation because of the side effects it causes. If you have ever been playing an online game and walked completely around a corner only to die when noone could possibly have shot you, it was likely do to lag compensation. With these systems the server stores a list of locations and where a player was at a particular time. Then when a player shoots on his client it sends the firing info and a timestamp to the server. So when the server receives this information it basically "rewinds" back to the point in time when the client fired and checks to see if the shot from some time in the past would hit the player back then. The problem with this system is, that depending upon players ping everyone playing the game has a different view of where the other players are at a particular time. This is why on your machine you could be behind a wall, but the player (who you may not even be able to see on your machine) who has a higher ping than you sees you where you were a short time ago and shoots and kills you. So this is why I think lag compensation sucks :)

I prefer the Unreal net code methodology which uses client side prediction instead of lag compensation. When a programmer knows what they are doing and uses the Unreal net code properly client side prediction gives all of the clients connected to a server a very very close picture of where the other players are actually at on the server at all times. It does this by predicting the physics and movement of the other players. It does this pretty good for super-fast games like UT, and when you slow this down to real world movement speeds like in Red Orchestra this system is rock solid. In other words, in RO when you shoot at someone you can pretty much guarantee they are at where you see them at (up to a ping of 200ms). Likewise when you get SHOT by someone on RO, it was because they could see where you are currently at, not where you WERE a short time ago.

After coding MP network games for nearly ten years, this area is a bit near and dear to my heart, so I'll stop ranting now ;)
 
Upvote 0
Great post.

I don;t know much about net-code but it is one of the reasons i quit BC2. That game not only has terrible blood splatter no hit issues. And it tries to use lag compensation where not only will you die behind cover like mentioned in the post..... but sometimes you will have to fire BEHIND a target ..

In a game with bullet time... instead of leading a target you have to sometimes shoot behind it.... lol

I hope tripwire does a much better job than dice because im very close to quiting FPSs
 
Upvote 0
Thank you VERY much for this informative post.I read it all carefully and it makes sense now.Of course i think method 2 is better and more reliable ,but it was probably poorly implemented in UT.The weapons were also hitscan and leading the target was a clear disadvantage,but in RO2 it should be better.

By the way,i measured the delay with a stopwatch and it is about 0.3+ seconds with ping between 65-75.
 
Upvote 0
The Antilag lag compensation command was one of the worst decisions for COD and hard coding it into COD4 1.3 was a huge mistake. Running around a corner or proning behind a box only to be pulled back out and die because the other player a 100+ ping.

Killcams in the recent CODs highlight this failure even more. It's two different games, what you see and what the other person sees. Sometimes they even get hit reg from empty space. Never come across lag compensation that works. So the way RO deals with it is superb.
 
Last edited:
Upvote 0
Thank you VERY much for this informative post.I read it all carefully and it makes sense now.Of course i think method 2 is better and more reliable ,but it was probably poorly implemented in UT.The weapons were also hitscan and leading the target was a clear disadvantage,but in RO2 it should be better.

By the way,i measured the delay with a stopwatch and it is about 0.3+ seconds with ping between 65-75.

The best thing is to try it for yourself in the original Red Orchestra, the ballistics feel very natural (even for me who for regional, political, and ISP-Bull**** reasons, can't get anything better than 120ms), I'm guessing it'll be a similar netcode for HOES.

I worry not.
 
  • Like
Reactions: Poerisija
Upvote 0