112 replies to this topic

[Rebas Kradd]

Greyhart, on 14 September 2016 - 12:52 AM, said:

I have a question.

As anyone who reads these forums know the idea of a Cone of Fire is often brought up.

So would a Cone of Fire present additional problems for the hit registration, like convergence? Or would it be a neutral change for hit reg calculation?

Great question, I too would like to see the answer to this, although I am personally opposed to CoF for other reasons.

[Neema Teymory]

Greyhart, on 14 September 2016 - 12:52 AM, said:

I have a question. As anyone who reads these forums know the idea of a Cone of Fire is often brought up. So would a Cone of Fire present additional problems for the hit registration, like convergence? Or would it be a neutral change for hit reg calculation?

By Cone of Fire, I am assuming you mean that the weapons fire "randomly" within the bounds of some angle from the firing vector? If so, yes this would definitely cause problems. The rewind algorithm itself wouldn't need to change at all. It doesn't really care about how the firing vector is determined; however, since the client is predicting shots, it would need to make this random selection first, before the shot is sent to the server. That means we would need to somehow ensure this same random selection is also made on the server, without trusting the client--otherwise, you would be able to hack your client and turn off the randomness. So, this is another thing that would have to be synchronized between the client and server. When you engage your jump jets, something similar to this is happening when you shoot, but it is handled in a special way.

[Raso]

Wait, when you fire mid jump don't you already have shots going in random directions? Why is it special?

Edited by Raso, 14 September 2016 - 09:44 AM.

[Neema Teymory]

Raso, on 14 September 2016 - 09:43 AM, said:

Wait, when you fire mid jump don't you already have shots going in random directions? Why is it special?

It's special in the sense that it only works when jump jetting I feel like the implied question here is: can it be done when not jump jetting? With some work, probably. But it will be subject to the possibility of additional error resulting in this random selection I described. This is just to answer your question from a technical perspective. As far as I know, there is no plan to introduce a feature like this.

[Mystere]

Neema Teymory, on 12 September 2016 - 11:49 AM, said:

This is correct. There is no delayed convergence. Convergence is instantaneous and therefore the server can trust whatever the client's convergence is. If convergence had delays associated with it, we could no longer trust the client, since this would need to become a server controlled feature--otherwise it would be exploitable. Adding delayed convergence introduces another level of complexity in terms of both aiming skill and network synchronization. This feature was considered in the past, but we decided not to add it for various reasons.

So why not instead switch to a fixed convergence system, with the convergence point set by the player in the MechLab or in battle (e.g. via a scroll wheel)? Or as a rough approximation of the previous delayed convergence system, why not adopt a "convergence on lock" scheme? Alternatively, why not adopt reticle bloom with the weapon hit pattern fixed but proportional to the size of the bloom?

[Hunter Watzas]

Thanks for all the answers! Keep up the good work.

Is there a single generic linearization/interpolation model for all mechs?

From personal experience it appears that the faster a mech moves and the smaller it is, the more problems with damage registration on that mech (Hitbox detection, damage registration). There also seems to be a problem (although it has gotten better) of hit detection on mechs when they are in the air either by running of a edge/cliff or using jumpjets.

[Neema Teymory]

Mystere, on 14 September 2016 - 11:17 AM, said:

So why not instead switch to a fixed convergence system, with the convergence point set by the player in the MechLab or in battle (e.g. via a scroll wheel)? Or as a rough approximation of the previous delayed convergence system, why not adopt a "convergence on lock" scheme? Alternatively, why not adopt reticle bloom with the weapon hit pattern fixed but proportional to the size of the bloom?

All these options are all probably possible, but as you can imagine have a large impact on the way the game plays and are ultimately game design decisions. The current implementation of convergence was an intentional design choice, and as far as I know, there is no plan to change the way convergence works.

[Glaive-]

Something that I've wondered about regarding HSR is how much differing gravity levels would effect the system. Back when the HPG map came out, people were discussing the possibility of a lower gravity setting on the map, and I seem to recall that one reason for keeping the gravity consistent with the rest of the game was to avoid the possibility of negative effects on the net-code (along with of course the general design choice to keep gravity consistent). Would a gravity change, or really just movement effected by the environment in general, still present technical issues?

As a semi-related follow-up question, does the movement behavior of jump jets present any specific difficulties to HSR? I seem to recall that they can create some de-sync issues, and I know from experience that jetting onto higher platforms can be difficult do to warp issues



Anyway, thank you very much Neema for being so active in this thread. Your answers are quite informative and interesting to read. I just hope this thread isn't taking too much time out from your work.

[Neema Teymory]

Hunter Watzas, on 14 September 2016 - 11:32 AM, said:

Thanks for all the answers! Keep up the good work. Is there a single generic linearization/interpolation model for all mechs? From personal experience it appears that the faster a mech moves and the smaller it is, the more problems with damage registration on that mech (Hitbox detection, damage registration). There also seems to be a problem (although it has gotten better) of hit detection on mechs when they are in the air either by running of a edge/cliff or using jumpjets.

Yes, the interpolation works the same way for all Mechs and all motions. Positions are simple linear interpolations and angles are spherical linear interpolations. Jump jets are a more non-linear motion, so they tend to be slightly more problematic. When you are using jump jets, there are thrust and air drag calculations which are all non-linear (). When you integrate these motions, frame rate ends up mattering more, which is why there tends to be more error between what you see (high frequency, smooth game simulation) and what is actually happening on the server (lower frequency, quantized simulation). This is probably why there tends to be more complaints about jumps jets.

armyunit, on 14 September 2016 - 12:23 PM, said:

Something that I've wondered about regarding HSR is how much differing gravity levels would effect the system. Back when the HPG map came out, people were discussing the possibility of a lower gravity setting on the map, and I seem to recall that one reason for keeping the gravity consistent with the rest of the game was to avoid the possibility of negative effects on the net-code (along with of course the general design choice to keep gravity consistent). Would a gravity change, or really just movement effected by the environment in general, still present technical issues?

Having different gravity levels in principle shouldn't be a problem. Where things will become problematic is when the gravity is too strong. Certain ballistic weapons, like ACs have gravity falloff, and when we do the projectile rewind for these weapons we assume that the trajectory of the weapon can be approximated very well with a straight line. The more curvature there is in the trajectory (i.e. if it falls too far relative to its displacement over the rewind period), the less true this assumption becomes. This would result in less accurate rewind checks. As it turns out, ACs move very quickly, so the current gravity falloff has only a small effect on vertical displacement of the rewind period, and a line approximation still works very well.

armyunit, on 14 September 2016 - 12:23 PM, said:

Anyway, thank you very much Neema for being so active in this thread. Your answers are quite informative and interesting to read. I just hope this thread isn't taking too much time out from your work.

Speaking of which, again I really appreciate all the interest in this topic, and I would love to keep answering questions forever, but I still have other work I really need to do, and context switching back and forth between doing work and the forums is starting to be noticed. So, I will start responding much less frequently to this thread from now on. I will still check in on this thread periodically. I hope everyone has found some of these answers useful.

[Mechteric]

Neema Teymory, on 07 September 2016 - 10:21 AM, said:

The next biggest related system is movement. If design decided to suddenly add a game mechanic that allowed a mech to stop on a dime and turn in the opposite directly, this would have drastic consequences for the rewind implementation--even to the point of breaking it.

This seems to explain why fast lights don't register hits when they are maneuvering while under fire. They can stop "enough on a dime" it would seem to me, fast enough that 100-200+ms probably can't catch up... Perhaps this is one place where developers can improve the game, by not allowing even the fastest of light mechs to come to a stop in under half a second? Or maybe a full second if they are already at half? I'm sure there's some number of X kph drop in Y milliseconds where it starts to be problematic, it doesn't only have to be zero (immediate) I'm thinking.


And then there's jump jets, you can be moving along at 140kph, and if you tap your spacebar, don't you immediately jump down like 50% of your speed? Sounds like that would be a potential way to mess with the HSR too.
EDIT: Nevermind about the jump jets, I guess maybe it doesn't work like that anymore

Edited by CapperDeluxe, 15 September 2016 - 04:46 AM.

[MrMadguy]

Neema Teymory, on 14 September 2016 - 12:48 PM, said:

Speaking of which, again I really appreciate all the interest in this topic, and I would love to keep answering questions forever, but I still have other work I really need to do, and context switching back and forth between doing work and the forums is starting to be noticed. So, I will start responding much less frequently to this thread from now on. I will still check in on this thread periodically. I hope everyone has found some of these answers useful.

It would be really nice, if there would be somebody, who would also answer some questions about matchmaking and map design. Simply cuz it seems, like MM is completely broken now.
Week ago:




Today:




Player, I was matched against two times within just one hour yesterday. He says, he is Tier 1 and have got there pretty easily.



Can somebody answer simple question: if I have to drop my rating now, then how did I managed to even get to such high rating, while playing exactly the same 'Mechs - almost stock not mastered Maulers and Battlemasters?

Edited by MrMadguy, 15 September 2016 - 01:11 AM.

[Greyhart]

Yes thanks for answering the questions.

You should be given a bonus for this work. In a few short posts you've probably explained more than anyone else ever has regarding the design decisions in the game.

We have some explanation of problems with cone of fire and why we have the convergence we have. Not to mention the errors that appear to happen.

Of course if others responded like you have done on this thread the forums would be dead due to the lack of salt.

[l33tworks]

Hello Neema,

As long as you're here and answering questions, I want to raise an an important gameplay issue with you.

A few months ago the zoom feature was made client side as opposed to being server side since MWO launch. This was supposed to improve player experience and level the playing field, (people with good pings didnt even notice a difference), but it had the opposite effect and actually made it much worse experience for higher pings to the point its broken. The zoom starts to change on its own and behave erratically and erroneously as soon as the "checks" with the server happen if you have over say 250 ping, whereas it was fine beforehand, just a little slow to react.

For example if I zoom in two times by clicking the zoom buttom twice, it will do so properly and instantly client side, but then as soon as the "check" with the server happen, it ALWAYS zooms back out fully on its its own to no zoom, then back into first zoom level, for a total of 4 zooms spanning over a second, and all I've done is clicked twice!

The only way to avoid this is to click really, really slow. Click once, wait for the server to say its ok, then click again, and wait for the server to say ok, and click again etc. You have to do this EVERY time you zoom, click really slowly, one zoom at a time. If you click twice or more before the server has a chance to authenticate the first click, it freaks out and begins to change your client in ways you never did. Obviously on the client you can give inputs a lot faster than the server can authenticate them, so it should not be set up this way otherwise it really is of no help at all to change to to client side if it just messes with the client if the inputs are too fast. Don't you see the flaw in this?

As you said things like heat vision and zoom can be client side and them the server just "checks" its ok. The problem is these checks seem to be over paranoid and over protective and start messing with your client in ways they didn't used to. The same thing happens with setting Weapon groups, You need to set them VERY slowly, or else it will turn on and off weapon groups on its own after server side checks happen.

Can you please possible allow more freedom than the one at a time change or crate a raised interval cluster at which these checks happen to allow greater freedom of client side movement.

Edited by l33tworks, 15 September 2016 - 03:05 AM.

[ibins]

Neema Teymory, on 12 September 2016 - 11:49 AM, said:

The lag compensation algorithm is not limited by the speed of mechs, only player pings. The limit of the rewind system is 500ms, but even when you start to get close to 500ms things get dodgy. Realistically, it should work relatively well up until ~450ms. With that said, the faster targets can move, the more potential there will be for error between the client's simulation and the server state and that could result in more mispredictions.

First of all, awesome article and thanks for spending so much time for answers!

Regarding your above post and the problem of fluctuating pings you mentioned in your article. Have there ever been thoughts of using the system to log and monitor ping manipulations to get rid of those unfair methods? It would be nice to see, that if the systems gets fluctuating pings from a player, it shuts the mech down for maybe 5 seconds or anything similar.

[Mawai]

MrMadguy, on 11 September 2016 - 09:36 AM, said:

Convergence has been made instant exactly for HSR support. Weapons are being instantly converged at point, you're aiming at. As I can see, when OP pressed his trigger, he was aiming exactly at Cheetah's face. Literally at Cheetahs face. Zero doubt.


This crap can have only one possible explanation - Cheetah has big enough hole in his hitboxes between his head and his shoulder. As you can see on this video, at height, OP was aiming at, Cheetah shouldn't have any holes in hitboxes. And here is the problem - many 'Mechs has such terrible hitboxes, that cause constant loses of convergence. I.e. when all of a sudden you hit some tiny slit between body and arm. And it completely messes your convergence - leads to complete miss. Stormcrows has such hitboxes for example. And there is only one possible solution, I have been suggesting for a long time already - add "soft" hitboxes around 'Mechs, that will keep weapons converged at this 'Mech - i.e. simply remove all tiny holes and slits. And in case of Lights we need even better feature - it would be nice to have "Converge at my current target" feature. I.e. make it so leading won't kill our convergence and Lights won't be so cheating.

Interesting point raised.

Convergence is indeed instant. However, if the enemy mech is not located on the server at the point you are aiming on the client ... does the server calculate convergence based on the aimpoint sent by the client and the mech position as calculated on the server or does the server use the converged aim point as reported by the client?

If the client aim point including convergence is used by the server then the weapons should be aimed somewhere near the target even if it is slightly displaced on the server. On the other hand, if the server takes the aim coordinates and calculates the converged aim point on the server based on the target location on the server then it is quite possible that shots that look like they should easily hit on the client ... will actually miss by a lot because the server calculated convergence is off by a lot.

[MrMadguy]

ibins, on 17 September 2016 - 03:38 AM, said:

First of all, awesome article and thanks for spending so much time for answers!

Regarding your above post and the problem of fluctuating pings you mentioned in your article. Have there ever been thoughts of using the system to log and monitor ping manipulations to get rid of those unfair methods? It would be nice to see, that if the systems gets fluctuating pings from a player, it shuts the mech down for maybe 5 seconds or anything similar.

First I wanted to say, that fluctuating ping wouldn't have given you any advantage. Just because you aren't being rewound according to your ping and fluctuating ping would simply mess your HSR up. But then I remembered, what advantage fluctuating ping gives them. Yeah, today I saw such a guy. I wouldn't have noticed him, if he wouldn't have been..."teleporting". His ping was changing between 2 values every 2 seconds. 150...600...150...600...150...600...40...400...40...400, etc. And you know. "Teleporting" exploit actually gives big advantage. May be not to Assaults, but I remember those "invulnerable" Ravens, who were moving quite slow, but your whole team wasn't able to deal any damage to them, simply cuz...when you were firing at such Light, it actually wasn't at spot, you were aiming at. May be it's Wi-Fi router and may be not.

[Hawok79]

I am very happy to see such a Topic with developer ....

Maybe you can tell us:

Tickrate : Server to Client?

Tickrate : Client to Server?

Is there a DDOS Protection aktive?

Main Server Cpu?

and how many virtual Server or Cores are running on one real core?

Greetings

Edited by Hawok79, 05 October 2016 - 06:12 AM.

[TLBFestus]

Neema Teymory, on 07 September 2016 - 10:21 AM, said:

Hey Rebas,
I can't speak on behalf of all other multiplayer games, but in my experience, predicting and lag compensating projectile weapons is generally a much harder problem to solve and so is usually avoided. This would be something that sets MWO apart.

Correct me if I'm wrong, but isn't it more so the variable geometry, more than the projectile weapons that sets MWO apart from other FPS games?

Every CoD, every Battlefield game uses a ton of projectile weapons that throw thousands of rounds in a match, more than MWO does. Or do they calculate things differently in those games as opposed to MWO?


UPDATE: it appears that you may have answered this question in a later post to Quicksilver. Curse me for not reading further first.

Also.....thank you for responding the the OP. It's so rare to see anyone with PGI come onto the forums and just post a forthright response, and I for one would encourage it in the future.

Edited by TLBFestus, 05 October 2016 - 10:16 AM.

[Chuck Jager]

Neema Teymory, on 09 September 2016 - 12:30 PM, said:

Hey everyone,

I appreciate all the interest in this topic. It's getting hard to keep up with all the questions. I'm always very busy around here, but I'll do my best to continue answering. Please don't take offense if I skip you, some of your questions, or am light on details. If you feel ignored and you really want a question answered, feel free to PM me and I'll try to answer your question the best I can..........................................

Very good people skills that answer the need to get a response while not leaving PGI on the hook with an answer that may turn into something worse "than wanna buy a mech pack". It also has a ring of truth not a canned response.

Sometimes being treated like a human by knowing the other human is working on it, but is also not perfect really does help the situation become a shared problem not a ME vs YOU issue. Could PGI lend your services to the US presidential candidates.

[roboPrancer]

Very interesting stuff, all of it. It makes me remember how surprised I was that I could play mwo so well on a connection that was stable but with a very high ping. I never would have guessed that all of these calculations were going on in the backend.