83 replies to this topic

[Momolicious]

I too have seen barely touched mech *(both my own armor indicator and target armor indicators)* Show outer armors still nearly untouched yet they core out. I always assumed this was a 'lucky' crit (boxcars).

Perhaps this is 'modifiers' at play? (movement/terrain/etc)

[TerebNeerg]

DaZur, on 30 October 2012 - 05:07 AM, said:

Right now everyone is pointing to damage not registering on the target mech. Is it possible it's the other way around? I.e... The damage is actually registering on the target mech but the paper doll indicator is not syncing with the actual damage inflicted.

Watch the videos I linked. There is no doubt that the target's location is being represented incorrectly on the client side.

Now... that's not to say that there isn't another issue with the paper doll being wrong. I've had myself take internal CT damage with armor still showing on all locations.

[superbob]

Random damage to internals while armor is still intact may be due to overheating. Shutdown and overheating visuals/sounds are triggered client-side, damage is server-side. If somehow your client thinks you generate less heat then the server calculated then you will start taking internal damage without apparent reason, like you would after overriding shutdown. [edit: or don't dissipate heat as fast as your client thinks you do, eg. DHS is even more broken server-side.]

AFAIK damage readouts are entirely server-controlled, but maybe they are prone to network packet loss (so you randomly miss an update to mech damage status).

Edited by superbob, 30 October 2012 - 07:18 AM.

[Ironbound]

I agree with all of this. Literally half the time I blast a shutdown mech right in the cockpit, I get no damage registered. Then it starts back up and warps thirty feet. I don't know what's happening but I am very much not happy.

Also, autocannons:

The delay on autocannons is random. Which is bad enough, but honestly I would be semi-okay with that since I would just have to maintain my lead until the shot is fired. But the autocannon goes where you aimed when you pulled the trigger. As in there is literally no way to reliably aim an autocannon. If you lead a moving target, you have to get lucky. You have to lead not just for lag, but also for input lag, both of which are random. One out of every four times I fire an autocannon, it lags enough to completely miss anything moving at any speed. This is a serious problem, because:

Balance. No one is getting any balance information if half of our guns work way worse than they should. When everyone is using lasers and lrms because those are the only reliable weapons, those will seem OP, and we'll balance them. Then, if netcode is fixed, the autocannons that were balanced for being unreliable now become OP. Rebalance, and we've just wasted months of balancing.

This needs to be fixed pronto,

[GaussDragon]

Just make the game client side. A lot of us are running on faith, faith that this will get better but that's those of us who are MechWarrior die-hards. How much do you think casuals with no attachment to this game will tolerate shot delays, variable lead times based on your ping and outright damage not registering? This is 2012, this kind of stuff should not be acceptable to any game that takes itself seriously.

[xZaOx]

When you have to lead lasers something is wrong. Everyone is using LRM and streaks because thats the only thing for the most part that registers..Needs to be addressed asap.

[Accujack]

Purplefluffybunny, on 30 October 2012 - 01:11 AM, said:

If you take a look at this site you will see that they have an advert up for network programmers. So, I expect a proper fix won't be along until they have the skill sets in place to fix it.

Worth repeating.

The problem with the game isn't actually "Hit Detection"... it's that what happened was actually a miss, and the client showed you a hit instead because the client was out of sync with the server.

I put up a big post on this elsewhere, but I'll summarize here in case anyone's interested.

Because of limited bandwidth and relatively long round trip times between the server and most of the players (100 ms is really too long for most real time games) the server and client use a lot of prediction to determine game events.

For example, the player increases throttle, the client sends a message to the server saying "I'm moving at X speed in Y direction" and the server notes this and updates the player's position, as well as recording the current speed and direction for prediction purposes. The server then has a model of the game state with the player in it, and combined with the other players' locations and the map data can run the game. The client simultaneously displays the client side copy of the map with all the bells and whistles that make the game fun to look at.

If the server and client are synced, then no problems happen. Some interval after the client sent the "moving" message, the server still knows exactly where the player's mech is because the client hasn't send a message saying "stopping now", "turning" or whatever. Based on the player's speed, direction and last known position the server can calculate quickly where the player is. The client performs the same calculations in the same way, wrapping the player in an environment based on the map plus the player's speed and position plus all the speed and position data for all other players (received from the server).

It should be obvious that the server has to know where each and every player mech is to run the game successfully. Otherwise it couldn't count down cap timers, calculate whether weapons hit or not, determine whether players can see each other, etc.

The "hit detection" problem (and several others) happens when the server and client don't have the same game state, even for a fraction of a second. Example: Mech A sees mech B in the crosshairs, and player A presses fire on his LLAS. A split second later (let's say 50ms, or a twentieth of a second), player B makes a right angle turn to avoid A. Player A has a 150ms ping, player B has a 70ms ping. Because of the network lag, the messages get to the server in the order turn, fire. So even though A saw B and fired *before* B turned, from the server's point of view the shot missed because B turned "first".

So why does the client show a hit, then? Prediction. There is simply not enough time for the server to determine whether a hit happened and tell the client that it did so it can display the explosion in real time. If it tried, you'd see a lag for explosions similar to the lag for weapons firing... sometimes a significant delay. So the client predicts what will happen, showing the explosion in all its glory... then it receives a message from the server saying "you missed" because of the ping issue. So what does it do? The client can't move the player back in time, it can't "take back" what it already showed. All it can do is go on with gameplay, because the player is now in a different position looking at something else.

It should also be obvious that there's no quick solution to this. If for example the client messages to the server were tagged with a time stamp, it would be possible to determine the order things should happen, but that's only if the server could trust the time stamp. A hacked or cheating client could wait until it received a "you got hit" message then send a "I turn left" message a second in the past. Presto, immunity from all incoming weapons.

Things get even more difficult when the server gets slow due to a server side bug or if the player's client is running on a low spec computer. If the client can't keep up with the server messages, it may be putting all its cpu into displaying an impressive explosion while the message telling it "you missed" is waiting in the queue.

By the way, this is exactly the same problem as missiles "passing through walls", rubberbanding effects, the teleport when mechs fall down, and other problems.

In the case of missiles or other weapons going through walls to hit you, what's happening is that the missile did hit you... you didn't get behind the wall in time to prevent it. Because your client wasn't up to date with the server's game state for whatever reason, it predicted you'd make it behind the wall safely (because you sped up, turned, or whatever) and displayed that.

So when your client gets the message from the server "missile hit, LRM, X damage" then it has a limited amount of choices. It can ignore the hit, showing you the wrong total armor left and damage. It can show damage to your mech silently, skipping showing the missile hit, which would really upset players. Or, it can show you that the missile hit you even though you thought you were safe. Rather than do a complicated "missile flies around wall and through window, stopping to open door first" graphic, it just slams the missile through whatever it needs to in order to hit you.

It's not that the maps are buggy with holes in walls, it's that a very complicated graphical engine is trying to keep a distributed simulation in sync across 17 computer systems with the connections in between them being very, very slow (relatively). It doesn't always work perfectly.

You shouldn't honestly expect a game with some "twitch" gaming aspects to let you play decently over a 120ms connection. Try playing Counter-Strike with a ping time more than about 80 milliseconds and you'll consistently die. It's positively amazing that MWO does as well as it does with the Crytek3 engine and only one set of servers worldwide.

Long term the fix for the problem is to have servers distributed across the Internet (NOT the World, it's not quite the same layout) so everyone has a decent (150ms or better, hopefully under 100ms) ping to the servers. Also, the net code still needs optimization and maybe some rework, but after all this is a beta. And they're hiring.

Erik

[Accujack]

GaussDragon, on 30 October 2012 - 08:51 AM, said:

Just make the game client side. A lot of us are running on faith, faith that this will get better but that's those of us who are MechWarrior die-hards. How much do you think casuals with no attachment to this game will tolerate shot delays, variable lead times based on your ping and outright damage not registering?

They'll tolerate that a LOT better than a game filled with players with aimbots, cheat enabled clients, teleport exploits, and other bugs that mean they have no chance whatsoever to do well.

If you make the game AT ALL dependent on the client telling the truth about what it's doing, then you make exploits easy. Multiplayer online games have to be server mediated to avoid easy cheats.

[NarTrig]

Accujack, on 30 October 2012 - 09:02 AM, said:

Worth repeating.
(snipped)
Erik

the major issue here IS hit detection because if you look back to the notes they "fixed" it... it has become apparent through our "testing" (read playing for fun) that their change made it severly worse. IMO it cant be that hard for them to look at their old code (hoping they keep their old versions laying around) and revert their changes to "movement"

edit: just wanted to add that hitting a moving target for me isnt as bad as someone who is powered down but it might have to do with me usually having a low latency and decent FPS

Edited by NarTrig, 30 October 2012 - 09:20 AM.

[Accujack]

NarTrig, on 30 October 2012 - 09:18 AM, said:

the major issue here IS hit detection because if you look back to the notes they "fixed" it... it has become apparent through our "testing" (read playing for fun) that their change made it severly worse. IMO it cant be that hard for them to look at their old code (hoping they keep their old versions laying around) and revert their changes to "movement"

What makes you think that putting the old code into the current code base would even work? Also, you're aware that a lot of the changes made can't be reverted because they fixed *massive* bugs like the one causing endless server lag, right?

It's not as simple as hitting "undo"...

[Hades Serpent]

Accujack, on 30 October 2012 - 11:38 AM, said:

What makes you think that putting the old code into the current code base would even work? Also, you're aware that a lot of the changes made can't be reverted because they fixed *massive* bugs like the one causing endless server lag, right?

It's not as simple as hitting "undo"...

Indeed. Calm down people. Programmeers who play this understand just how ******* hard this can be. The point about no easy undo button is quite apt. Hell, I've gotten myself into annoying spots with simple Python programs a few times because I made changes that significantly improved one thing, fixed other things, but broke something else. Reverting to a previous codebase is often not an option because you've completely rewritten the functions you might want to pull out of the old code.

They're looking for help to make improvements. That's good enough for me. What would be *really* cool is if they could also use data they collect on some games to create better predictive models for the client side; that'd be a monumental task requiring more than a few mathematicians and computer scientists though.

[superbob]

Accujack, on 30 October 2012 - 09:02 AM, said:

It's complicated

I know it's not simple to fix or a random desync generator that devs put in the game just to troll us players. I also have some idea of the depth of the simulation going on server side... They don't even trust the client about torso twist and arm aiming, even that only gets sent as a command to start rotating mech parts to such-and-such angles, the speed at which they move being controlled server-side. (I tried editing client files to make torso-twist super fast, could look around fast but aiming was limited to server dictated twist speed)

TBH I can't imagine how they managed to get such an overengineered system to work in the first place, and I'm not surprised it doesn't want to work well in field conditions. I understand that fixing the problem at hand is going to be difficult, which is why I'm concerned about it. But at the same time, fixing the issue is not my problem, I only want my mech to hit what I'm pointing my mouse at. I don't really care how hard it will be to fix, if it's even within PGI's capacity to do that much, it's their fault for teasing me with such an awesome and overambitious game. Now that I've seen it, they've got to make it work, even if I know that what I expect of them is most likely some heavy-duty wizardry in the nobody-tried-it-before zone.

[Airman0386]

+1 to the frustration issue.
I have started just shaking my mouse back and forth as I shoot in hopes that something registers. Doing this against someone with Streak SRMs however.... you die pretty quickly, as they just click the button, not worrying about hitbox location.

[Belisarius1]

I'm straight-up in disbelief at how bad this game's netcode really is.

It was horrible to begin with, and it continues to get worse.

This is a huge deal.

[Fuzz]

I too have been experiencing worse-than-usual hit detection since the latest patch. I've come to expect this with most ballistic weapons, but I haven't had too much of a problem with lasers, until recently. As with others, I've had situations where what appears to be a direct hit on my screen will register no damage on the enemy mechs.

I can lead the lasers and lag aim and get better results. While it shows me firing into the dirt and ground on the screen, I can see my opponent's damage indicators light up.

My ping time is usually low, usually in the 40-60 range, so in my experience, a lower ping isn't necessarily helping.

[ShootToThrill]

SSRMs aren't exactly reliable either, though. I don't know if it's just the Dragon, because it happens more against these mechs than any other, but, running a StreakPult I've had 6 out of 8 volleys of streaks do absolutely nothing against the front torso of a Dragon. Once the Dragon overheated and I got around the side though, volleys started reliably doing damage against the arm and side torso.

[Angel Dust]

Not sure it's ONLY a network problem. I've had alot of problems hitting near stationary mechs (or mechs running in a strait line) since the patch. I mean, hitting a centurion in the back with 6 mpl and 10srms a total of 5 times should imo down it a couple of times over. Never encountered that problem before the last patch (or at least not that noticable).
But then again, maybe they introduced the 'ghost mech' skill without us noticing it.

[TerebNeerg]

Angel Dust, on 30 October 2012 - 03:11 PM, said:

Not sure it's ONLY a network problem.

It is definitely NOT just a network problem. There are many examples of people having to "lead" stationary or slow-moving targets.

[Sturmwind]

superbob, on 30 October 2012 - 07:16 AM, said:

Random damage to internals while armor is still intact may be due to overheating. Shutdown and overheating visuals/sounds are triggered client-side, damage is server-side. If somehow your client thinks you generate less heat then the server calculated then you will start taking internal damage without apparent reason, like you would after overriding shutdown. [edit: or don't dissipate heat as fast as your client thinks you do, eg. DHS is even more broken server-side.]

AFAIK damage readouts are entirely server-controlled, but maybe they are prone to network packet loss (so you randomly miss an update to mech damage status).

This suggestions sound somewhat plausible to say to least....I've experienced it more than once, even on the frozen city map, that I haven't been hit once, get into position to fire at the enemy, shoot and BOOM - selfdestruct - while firing LRM20s without having had any heat produced before the counter showed 42%, but me Mech exploded straight away with NO indication why...weird?

[Cest7]

Noticed blatant hits not registering on myself and my targets