5 replies to this topic

[Landeraxe]

Yes, collisions and knockdowns really need to be in the game. The thing is, their existing system sucked. Mechs knocked themselves down with the merest touch of another mech. When mechs were knocked down, they jumped around the screen until they stood up (seriously frustrating to fire on a mech just to have it vanish and appear ten meters to the left, then back again).

It hurts the game to not have it, but it hurt it worse to have that kind of silliness happening.

Hopefully they are fixing it. To do so properly, in my opinion, they need the following;

1) Mechs should only be knocked over when impacted at a certain minimal speed. The greater size advantage the rammer has over the rammed, the less speed necessary. And light mechs should also be able to knock down heavier mechs as long as they are going fast enough (speed relative to the ramming target), or hit them high enough.
2) Mechs should not jump around the screen when being knocked over; they should get up from where they were knocked down. That doesn't mean that a mech may not be pushed a bit by the impact; it should. But once it comes to rest on the ground, that is where it needs to remain until it gets up again.
3) There needs to be damage for ramming as well (more for the rammed than for the rammer; just like real physics).

I love this game, and I have faith that the devs want to see it perfected as well. We just need patience.

And of course, Death-From-Above should also exist, and knock both mechs involved to the ground.

Edited by Landeraxe, 13 November 2012 - 01:29 PM.

[Koniving]

I can tell you what's going on with the second issue on the list.

Mech jumping around is caused by the same issue as a mech randomly rubberbanding when you have no lag.

The game has both an "expected" or "anticipated" client-process as well as the "actual" networkside process to reduce the perception of the unavoidable lag involved in MWO's anti-hack security measures by having all abilities controlled server-side.

In English, this means that what you see and what the network says you should see will sometimes conflict.

-----

Basically, you press W to start your throttle. The game sends a message to the network, "I want to go forward." As the message is being sent, the game client says "Well, if we go forward we're expecting to see this, so... yeah, okay we're going forward." The network says back: "Okay, you can go forward but there's a freebirth cutting you off." The client replies: "wait, what? Oh no! Our anticipation is wrong. Rewind!"

Poof, you or someone else rubber-bands as a correction, because someone did something that your client did not anticipate from the information given, and has cut you off a moment ago. You didn't see it because to you, it did not happen. The network saw it, but couldn't get the information to you in time, and therefore you got rubber-banded. This especially happens when you and another mech occupy the same space.

If the above example keeps happening, you'll get some violent rubber-banding because your client says "I'm here." The other person's client says "I'm here." The network says "You can't both be here." "Oh yeah? Well I'm here and that's that." "Oh no no no I was here first.." "SHUT UP AND REWIND!" "....okay, sheesh."

------

It was most noticeable in the collisions due to the Network physics and the Client physics never correctly coinciding their stories. You see mech fall forward, collide with building, and slide left. Network saw fall forward, collide with building, but slide right. Either reality could have happened. Your client and the network have an argument over it. Eventually the network ~always~ wins.

And that's the problem they had. The client-side physics and network side physics have issues seeing eye-to-eye. It's been disabled to fix it, however the priority doesn't seem to be that high. If it is, they are having issues getting the engine to cooperate.

[PYR0MANCER]

Part of my post from another thread that got ontp the subject...



Some have said that mechs are designed to not fall over easily and I would agree on that but standing up on two legs is not as stable as being on two tracks with a wide base (someone said something about a tank falling over, bad analogy compared to a mech)...


Since this is a game we can say that the in game pilot (not the player) is making any adjustment needed to stay upright in the case of a collision resulting in what would probably be a change in speed and direction (much like a stumbling human trying not to fall over) but programming in so many different situations such as angle and speed and weight differences is a programming nightmare and would result in even more time talking between server and client, and none of us want that... The devs (and we have no idea what they are trying to do with KD at the moment this is just my opinion on a solution), in order to try and keep the back and forth talk down, would have to pick certain situations in which a KD or falling over is definately going to happen, period, and other times just result in a stumble and speed loss, or even a total reverse of speed to simulate the ingame pilot trying to regain footing...

Lets take falling as an example since it's the easiest to accomplish (the numbers I am about to use are for illustrative purposes only) because we are only dealing with height and one object moving, the mech, the ground is a static object...

Lets say you fall..:

0-10 meters: Null result
11-20 meters: 5 damage to each leg
21-30 meters: 10 damage to each leg and current speed is cut in half
31-40 meters: 20 damage to each leg and a complete stop
41-50 meters: 30 to each leg and you fall to the ground
etc...

Now tonnage might also be a factor in my above example but relying on subjective math depending on the situation is just going to make things worse... Remember how mechs used to blink around after a KD..? It's because the server and client saw the mech in two different places and had to talk back and forth to get the position right, and probably a bit of 'mechs being in the same place after the KD' kind of thing... Trying to calculate what will happen in every situtaion is just going to result in more of the same as server and client talk back and forth about what is supposed to happen and again, none of us want that...

KD's are going to have to be a, it will happen in this situation every time sort of thing and any other result is going to have to be damage and speed change which is an easier thing to accomplish rather than all the math and server/client comms...

K.I.S.S., keep it simple stupid...

Going over a certain speed and hit anything: Damage and KD...
Under a certain speed and hit anything: Loss of speed and damage... Even possibly a reverse in speed and direction...

Tonnage doesn't even have to come into play because higher tonnage does less speed anyway... There would even be a situation where only minor damage would occur and you would just keep walking forward... Say, if you were in an atlas and walking into a building... You're going too slow to fall down and the static object isn't going anywhere so you would just keep trying to walk forward (would be nice if buildings and other objects were destructable to some degree, but that's another discussion)... Pushing might also occur but now we have to introduce tonnage into the mix...

Hopefully the devs aren't trying to over think this and keep it to some very simple variables where people would see it happen and say to themselves 'Yeah, I deserve to be flailing on the ground after doing that'...

[Malteser]

Koniving, on 13 November 2012 - 01:55 PM, said:

It was most noticeable in the collisions due to the Network physics and the Client physics never correctly coinciding their stories. You see mech fall forward, collide with building, and slide left. Network saw fall forward, collide with building, but slide right. Either reality could have happened.

Sounds like Schroedinger's Mech ...

[Koniving]

Malteser, on 13 November 2012 - 02:57 PM, said:

Sounds like Schroedinger's Mech ...

An unintentional but very accurate reference.

[HlynkaCG]

Malteser, on 13 November 2012 - 02:57 PM, said:

Sounds like Schroedinger's Mech ...

Damn you, you bet me to it.

Well played sir, well played.