1911 replies to this topic

[Cimarb]

Karl Berg, on 21 May 2014 - 06:20 PM, said:

Believe me, I've tried.. Dennis, Brian Buckton, and Fox have both popped in at some point to clarify specific points. Maybe if another thread were to be opened, paging some of those other dev's?

I appreciate your efforts, definitely, both on answering them yourself and encouraging others to do the same.

Before I make another post for someone in design (or whatever department, I'm not even sure what they are all named), who would be the best "target" for it? A thread for Paul would be like poking a stick in the community beehive, so someone OTHER than him, lol.

[slide]

Thanks again Karl for taking time, during a period which must be most hectic, to answer our questions.

You do more for PGI's image than just about everyone else combined.

[Belorion]

Any of you guys interested in talking with someone with a Human Computer Interaction background?

Edited by Belorion, 22 May 2014 - 04:24 AM.

[Mister Blastman]

Karl Berg, on 21 May 2014 - 06:07 PM, said:

Hi! Lasers and other trace-fires have the simplest hitreg of any weapons, short of server side homing weapons such as LRM's and streaks. Lasers are done as a set of traces, where each trace is an instantaneous check done against fully rewound positions on the server to determine whether or not a hit has occurred. If a trace hits, it deals that amount of damage integrated with respect to the amount of time that particular trace represents compared to the whole fire event. This is very classic latency compensation found in most other game engines.

Underlying this is the fact that laser damage is a quantized process, based on the number of ticks the fire event performs. Unfortunately I don't know how you performed your damage output tests; so I can't tell you why you're seeing differences between expected and actual output. Hopefully the description above gives you some insight.

Karl, despite your understanding of the back end, I can attest to many, many times where my lasers aren't registering properly. Sometimes partially and others not at all.

This even happens in private matches and I have... a pretty good aim.

It isn't placebo--it is going on and all the time. There have been instances where I have poured medium lasers into a barely stationary mech only to see nothing happen. There are others (and this happens with more frequency) where I might be pouring laser fire into the center torso of a mech moving perpendicular to me at a slow speed only to have it register on one of their arms! The thing is, they are making no effort at all to spread the damage--they are looking at me the whole time.

I have played Mechwarrior on the internet since 1996. I'm extremely familiar with lag shooting. I'm notoriously good at it, in fact. It almost seems like there is HSR lag--different from the internet lag we are familiar with--but that shouldn't be happening, right?

For the longest time I've wondered if our clients aren't properly syncing with the server as that'd explain some of the oddness I experience every single drop. Lately HSR has worked for a drop, or not. It is hit and miss and varies from drop to drop but it is a very real problem--sometimes 40% of damage doesn't register at all.

[IronChance]

Mister Blastman, on 22 May 2014 - 07:19 AM, said:

Karl, despite your understanding of the back end, I can attest to many, many times where my lasers aren't registering properly. Sometimes partially and others not at all.

I see this most often with high-alpha multi-laser builds, like the Stalker or Blackjack. It seems like anything over 4 lasers hitting at the same time causes excess laser hits to not register. Unfortunately, this doesn't repro in testing grounds and I've been unable to get a solid repro case in match. Also, recording a match kills my FPS, so I haven't made too many attempts to try to get clips of this on tape, as the game becomes very frustrating for me at 50 or so FPS.

Karl, is it possible to have internal QA take a look at using a mech like the blackjack 1-x with 8 medium lasers and testing to see if all the damage is appropriately applied during an alpha strike? Also, do they test using an actual internet connection, or is it a LAN environment?

[Wintersdark]

Mr. Berg:

As you have been tasked with beating the Matchmaker with a baseball bat, would you consider, say, weekly(read: whenever is convenient) progress reports here as to what's currently going on with that? I think it's safe to say that the matchmaker is ultimately one of the most influential aspects of the game for players - no matter how much we may want clans/CW/etc, how much fun the game is in the end hinges significantly on how the matchmaker performs.

Now, I don't mean "I'm x% done" (I get the difficulty with eta's and tasks like this); but rather any interesting challenges or programming issues that crop up? So we can get a look at the belly of the beast, as it where?

It'd be very much appreciated, anyways, whatever you can share. I'm sure pretty much everyone is very interested in just how the matchmaker works.

[Grits N Gravy]

The way joystick controls are implemented in MWO creates a fundamental issue with their effectiveness. Currently, using a joystick to aim is suboptimal. Workarounds do exist, but they involve the use of 3’d party software available only to specific brands and models of sticks. The workarounds also tend to be a bit clunky and require tweaking when changing mechs.

The current joystick setup controls the rate of axis turn in MWO. For example, deflecting the stick 10 degrees to the right causes the torso to rotate at a rate 10 degrees per second. Centering the stick stops the rotation. Thus two moves of the stick are required to place the reticule on target. A deflection of the stick to start the axis turn and a deflection of the stick back to center to stop the turn. It’s both double the workload and counter intuitive.


The problem lies with how the scripts Entities .xml treats movements. The action map.xml feeds the positional data of the joystick as the Rotational speed of axis. Thus we end up with our current behavior.

http://docs.cryengin...-MovementParams

The ideal behavior for a joystick would be absolute positioning. Where a full deflection of the joystick would cause the axis to rotate to it’s maximum position and stay as long as the stick is held in that position. A deflection of the stick back to center would cause the mech to rotate back to center position on that axis.

The idea is, you take the max positional axis of the stick, (which u can get from a DirectX call) divide by the max range of motion of the mech’s axis to derive at positional data. For example, a 8 bit stick reports between -256 and 256 across the entire axis and a mech can rotate 180 degrees, 90 in either direction. Thus moving the stick’s position from 0 to 1 would rotate the mech .351 degrees. When the stick is moved back to center and reports 0,0 the mech axis would return to center.

This would be a whole new class of movement. While not a stock behavior, It’s possible to add it for joystick functions while preserving the current input scheme for the mouse. You would need to add the new action to the GameActions.actions Something like DECL_ACTION(TorsoPostion) Then add it to Actionmap, default .xml. Then the entities
http://msdn.microsof...v=vs.85%29.aspx
http://technicalgame...ode-moving.html

If you guys get a chance please reexamine how joysticks are handled. They are currently pretty worthless for aiming.

[Loc Nar]

Grits N Gravy, on 22 May 2014 - 07:19 PM, said:

The way joystick controls are implemented in MWO creates a fundamental issue with their effectiveness. Currently, using a joystick to aim is suboptimal. Workarounds do exist, but they involve the use of 3’d party software available only to specific brands and models of sticks. The workarounds also tend to be a bit clunky and require tweaking when changing mechs.

The current joystick setup controls the rate of axis turn in MWO. For example, deflecting the stick 10 degrees to the right causes the torso to rotate at a rate 10 degrees per second. Centering the stick stops the rotation. Thus two moves of the stick are required to place the reticule on target. A deflection of the stick to start the axis turn and a deflection of the stick back to center to stop the turn. It’s both double the workload and counter intuitive.


The problem lies with how the scripts Entities .xml treats movements. The action map.xml feeds the positional data of the joystick as the Rotational speed of axis. Thus we end up with our current behavior.

http://docs.cryengin...-MovementParams

The ideal behavior for a joystick would be absolute positioning. Where a full deflection of the joystick would cause the axis to rotate to it’s maximum position and stay as long as the stick is held in that position. A deflection of the stick back to center would cause the mech to rotate back to center position on that axis.

The idea is, you take the max positional axis of the stick, (which u can get from a DirectX call) divide by the max range of motion of the mech’s axis to derive at positional data. For example, a 8 bit stick reports between -256 and 256 across the entire axis and a mech can rotate 180 degrees, 90 in either direction. Thus moving the stick’s position from 0 to 1 would rotate the mech .351 degrees. When the stick is moved back to center and reports 0,0 the mech axis would return to center.

This would be a whole new class of movement. While not a stock behavior, It’s possible to add it for joystick functions while preserving the current input scheme for the mouse. You would need to add the new action to the GameActions.actions Something like DECL_ACTION(TorsoPostion) Then add it to Actionmap, default .xml. Then the entities
http://msdn.microsof...v=vs.85%29.aspx
http://technicalgame...ode-moving.html

If you guys get a chance please reexamine how joysticks are handled. They are currently pretty worthless for aiming.

The problem with joystick aiming is that joysticks are engineered specifically to generate directional velocity commands like you encounter in flight (first or higher order of control), however reticule aim in MWO is coded for direct positional manipulation called zero-order control, like the cursor in your browser. Because of this, only positional controllers stand a chance, (the old joystick in a shooter' conundrum), however not all positional controllers are mice...

Controls Demystified(?)

[slide]

Karl,

Just read that you have bee put in charge of the new MM code. I feel you are he right man for the job.

Hopefully you won't be stymied by too many problems or micro managed too much.

Good Luck

[Tekadept]

Russ stated that "it was always going to be necessary to rewrite the matchmaker code for cw".

Now that you are in charge are you going to be adopting a "do it once do it right" kind of attitude? and actually design it from the ground up rather then trying to push the 3/3/3/3 square peg through the triangle hole? and THEN work on fixing the MM for CW?

I find it hard to be believe were we 90 days from CW so often, and yet finding out this nugget that the match maker was never up to par and had to be redone to actually support CW. If CW was always 90 days out and required a new matchmaker, surely we should have the new match maker prior to that up and running?

Edited by Tekadept, 23 May 2014 - 12:19 AM.

[Grits N Gravy]

Loc Nar, on 22 May 2014 - 09:58 PM, said:

The problem with joystick aiming is that joysticks are engineered specifically to generate directional velocity commands like you encounter in flight (first or higher order of control), however reticule aim in MWO is coded for direct positional manipulation called zero-order control, like the cursor in your browser. Because of this, only positional controllers stand a chance, (the old joystick in a shooter' conundrum), however not all positional controllers are mice...

Controls Demystified(?)

PC joystick do not generate velocity data. They output positional data in an absolute value. http://msdn.microsof...v=vs.85%29.aspx

The way cryengine applies that data by default, transforms the absolute data into a vector. However, It is possible to use absolute data supplied via directx to position the axis of the mech. This is would be done by creating a new "GameAction" or rule within the GameActions.Actions. Thus, it is possible to use the absolute data reported by directx to position the torso twist or pitch in an absolute manner.

So, instead of applying an acceleration to the movement code and solving for position. The stick reports the desired position, via the coordinates provided by Directx, solves for acceleration and then applies acceleration to the mech axis. It takes same amount of time and cost roughly same in computing power as the current system.

Also, real flight sticks don't generate directional velocity, The generate absolute positional movement. A stick manipulates the ailerons and elevators position. The position of the control surfaces and aerodynamics are what determines the rate of change. If a flight stick generated velocity data, the only way to maintain circular flight would be with a stick which could be pulled to infinity. A system in which a flight stick provides acceleration data would only be workable in a fly by wire system and would be about as effective MWO's joystick implementation.

The problem with joystick aiming in mwo is that cryengine takes the absolute data from directX and uses it to generate acceleration data. It basically says your max positional data of y 256 is max axis acceleration. Even in this function it's not very well done. As a 16 bit stick basically reaches max acceleration at much earlier point in it's throw. As a 16 bit joystick reads postions along it's axis from 0 to 65,536. Given a stick with the same travel, a 16 bit stick reports the same acceleration at .0039 of it's throw as does an 8 bit stick (reports to 256) at full deflection. The same behavior is exhibted via the mouse if you raise your DPI. All the sensitive setting does is lower the cap of the reported output of the axis. It's a software behavior issue, not a control order issue.

Edited by Grits N Gravy, 23 May 2014 - 12:29 AM.

[Mawai]

Karl Berg, on 21 May 2014 - 06:07 PM, said:

Hi! Lasers and other trace-fires have the simplest hitreg of any weapons, short of server side homing weapons such as LRM's and streaks. Lasers are done as a set of traces, where each trace is an instantaneous check done against fully rewound positions on the server to determine whether or not a hit has occurred. If a trace hits, it deals that amount of damage integrated with respect to the amount of time that particular trace represents compared to the whole fire event. This is very classic latency compensation found in most other game engines.

Underlying this is the fact that laser damage is a quantized process, based on the number of ticks the fire event performs. Unfortunately I don't know how you performed your damage output tests; so I can't tell you why you're seeing differences between expected and actual output. Hopefully the description above gives you some insight.

Hi Karl,

Thanks very much for the description and comments. Although it should be as simple as you describe, I too have encountered situations where lasers clearly seem to have hit but don't do the full damage expected. I was wondering if you have debug telemetry that tracks the damage application and hit registration of each portion of a laser pulse ... analysis of this data might give some insight as to whether everything is working as intended all the time. Looking for issues like sandwiched pulses where the middle one misses and the other two hit ... or possibly issues with the duration calculation and thus net damage from the pulse.

Is such detailed debug telemetry actually available to you?

[Mawai]

Hi Karl,

I want to wish you best of luck on your next project ... the re-write of the matchmaker

I read Niko's post on Russ' comments in which he says that the matchmaker needs to be rewritten to properly support the matchmaking design ... and that you have been handed this task!

Given the high profile of the matchmaker within the community, I hope that this doesn't cause too much stress ...

Anyway, best of luck, and if possible please design the re-write in such a way that it will support any distribution of mechs and not just 3/3/3/3 ... I think the design really needs that built in flexibility (even if it is not used initially) since I don't really know how well the community will adapt in the long run.

In the short run, folks have no problem jumping in whatever mech to get a match ... in the longer run, the players still have their preferred mechs which at the moment are mostly heavies and assaults. In addition, they have invested in hero mechs and other mechs that earn additional income or bonuses ... and it is quite possible that these are ones they may prefer to play in the long run ... and that these are not distributed evenly by mech class ... which means that once the excitement dies down and grinding recommences .. you may run into substantial queues.

[Cimarb]

Tekadept, on 23 May 2014 - 12:18 AM, said:

I find it hard to be believe were we 90 days from CW so often, and yet finding out this nugget that the match maker was never up to par and had to be redone to actually support CW. If CW was always 90 days out and required a new matchmaker, surely we should have the new match maker prior to that up and running?

Please don't take this as personal, but can we (the community) get over this "90 days" thing?

Whoever said that originally obviously had no idea what they were saying and probably upset a LOT of people that actually DID know what was going on. It happens all the time in advertising, and I'm sure development is the same way. Let's get over it and worry about what is currently going on. It's like complaining about 3PV still...

[SuperBroHeroFella]

Hi Karl,

blessed be your thoughts and fingers for coding the matchmaker! We are all with you in these exciting times. Don't forget to catch fresh air!

[Dimento Graven]

This was question was asked, and for whatever reason it resulted in ire and apparently was removed:

Quote

...
I was wondering that since you've been tasked with Match Maker (version what, 5.0 now?) if you would be so kind as to overrule those above you and put in a large group queue (5-11), as this will be necessary to community warfare anyway, and maybe regain some good will towards the players who are already looking for greener pastures.
..

However, I believe this is actually very REASONABLE question given that, from what I understood the MM is going to go through an almost total revamp, AGAIN, to address the issues of implementing a workable "3/3/3/3" (which in my experience while it was working did ZERO to address the issue of pug stomping).

If even if it's not a 'total revamp', but just a SIGNIFICANT amount work that's going to occur, I too believe that "larger pre-mades" should should be accommodated.

We have the situation now where we can select multiple "game modes", the solo dropper should also have the option to select "Solo Only" and/or "Group" queues as well.

And please don't throw a fit about an old response already having been given. Since there's going to be, at least, a significant amount of changes to the MM, those reasons aren't necessarily going to apply any more, so YES, it SHOULD be reevaluated and reconsidered, as originally in closed beta, many of us thought this a GREAT feature of the game.

Edited by Dimento Graven, 23 May 2014 - 06:43 AM.

[Dimento Graven]

Cimarb, on 23 May 2014 - 06:07 AM, said:

Please don't take this as personal, but can we (the community) get over this "90 days" thing?

Whoever said that originally obviously had no idea what they were saying and probably upset a LOT of people that actually DID know what was going on. It happens all the time in advertising, and I'm sure development is the same way. Let's get over it and worry about what is currently going on. It's like complaining about 3PV still...

This is an object lesson that speaks to properly managing expectations.

When you SAY you'll have something out in 90 days, the customers WILL believe AND expect it.

When 90 pass, and it's obvious you've missed it, AND you don't say anything about it for a long while, then come out with a statement that's along the lines of, "Good news, NOW we're almost done designing said feature, we'll begin coding shortly", it's not an unreasonable reaction from the customer to be upset.

It really isn't.

This isn't a failing on the customer's part, it's a failing on the PM's part for doing a piss poor job of managing expectations.

[Cimarb]

Dimento Graven, on 23 May 2014 - 07:20 AM, said:

This is an object lesson that speaks to properly managing expectations.

When you SAY you'll have something out in 90 days, the customers WILL believe AND expect it.

When 90 pass, and it's obvious you've missed it, AND you don't say anything about it for a long while, then come out with a statement that's along the lines of, "Good news, NOW we're almost done designing said feature, we'll begin coding shortly", it's not an unreasonable reaction from the customer to be upset.

It really isn't.

This isn't a failing on the customer's part, it's a failing on the PM's part for doing a piss poor job of managing expectations.

I totally agree with you, and I'm not saying people shouldn't have been upset or that whoever said it didn't drop the ball, repeatedly, but it's beating a dead, rotted horse with a crowbar at this point. It isn't helping the situation to keep bringing it up, as they just dismiss the whole thing (as well as anything discussed along with it, unfortunately), so it would help everyone if they dropped it and moved forward so we can get these questions answered.

[Heffay]

Dimento Graven, on 23 May 2014 - 07:20 AM, said:

This is an object lesson that speaks to properly managing expectations.

When you SAY you'll have something out in 90 days, the customers WILL believe AND expect it.

When 90 pass, and it's obvious you've missed it, AND you don't say anything about it for a long while, then come out with a statement that's along the lines of, "Good news, NOW we're almost done designing said feature, we'll begin coding shortly", it's not an unreasonable reaction from the customer to be upset.

It really isn't.

This isn't a failing on the customer's part, it's a failing on the PM's part for doing a piss poor job of managing expectations.

Moving on...

[Dimento Graven]

Cimarb, on 23 May 2014 - 07:51 AM, said:

I totally agree with you, and I'm not saying people shouldn't have been upset or that whoever said it didn't drop the ball, repeatedly, but it's beating a dead, rotted horse with a crowbar at this point. It isn't helping the situation to keep bringing it up, as they just dismiss the whole thing (as well as anything discussed along with it, unfortunately), so it would help everyone if they dropped it and moved forward so we can get these questions answered.

In the case of a business though, it's not an actual person with its own memory. Businesses should be repeatedly reminded of their mistakes so that they can avoid making them again.

A policy of "forgive and forget" with a business is VERY bad policy for the customers.

I don't mind us customers reminding PGI at every relevant opportunity to NOT DO THAT AGAIN.