1911 replies to this topic

[Coralld]

Tekadept, on 10 May 2014 - 06:19 AM, said:

I know its probably too hard, but I wonder what % of those % are just bringing meta

Short answer... Too many.

In all fairness though, from my experience, I would say at least 50% of heavies, 60 to 70% of Assaults, 30% for Mediums (PPC/AC10/20 Shawks and 2x PPC Cicadas and Hunchies) and I would say around 10% for Lights.

[TheCaptainJZ]

If you think about it, what the meta is is a little bit more open these days compared to the past. There was a time when a dual guass catapult ruled the battlefield. now you see a lot of similar but not exact weapon combinations that a multitude of variants can use.

[9erRed]

Greetings all,

Question for Karl about network and our current engine:

Q: Without going into too much depth could you expand on some of the issues concerning objects in the MWO environment being destructible, and where PGI is in relation to having some level of this brought into the various maps.

I understand object destructibility is mixed within and through out numerous fields for the PGI team, but are there specific limitations with the engine that may be slowing down implementation?

Thanks,
9erRed

[3Xtr3m3]

Karl Berg, on 09 May 2014 - 10:41 AM, said:

This is a bit complicated. I've just looked through all of the code again to see where all the config values come from, and indeed the mdf turn parameters and the engine rating are used. Beyond that, here are some of the factors:

- Engine rating gets divided by mechs max tonnage to calculate an effective engine rating for that mech.
- There are separate turn speeds for mech legs, upper torso pitch, upper torso yaw, arm pitch, and arm yaw
- The mech leg turn speed is affected by your engines current power output* when actually in-game, the higher your throttle, the faster you can turn
- The scaling of that mech leg speed is done using a three-point linear interpolation, controlled by the factors:

   TurnLerpLowRate
   TurnLerpMidRate
   TurnLerpHighRate
   TurnLerpLowSpeed
   TurnLerpMidSpeed
   TurnLerpHighSpeed

- Several mdf parameters are converted from degrees to radians, and then multiplied by engine effective rating and skill-tree bonuses

The following parameters are directly converted from degrees to radians ( * (Pi / 180)) in-code:

   TorsoTurnSpeedPitch
   TorsoTurnSpeedYaw
   MaxTorsoAnglePitch
   MaxTorsoAngleYaw
   MaxArmRotationPitch
   MaxArmRotationYaw
   ArmTurnSpeedPitch
   ArmTurnSpeedYaw
   MaxFreeLookPitch
   MaxFreeLookYaw

So I think in general, the formula you are looking for is <mdf value> * (Pi / 180) * (<engine rating> / <mech max tonnage>) * <skill tree fudge factor>

That covers pretty much everything except the leg turn speed, which is affected by throttle rate and a more complicated multi-lerp implementation to determine actual turn speed.

Now, to understand the leg turn rate requires those 6 factors I mentioned earlier: TurnLerpLowRate, TurnLerpMidRate, TurnLerpHighRate and TurnLerpLowSpeed, TurnLerpMidSpeed, TurnLerpHighSpeed

Lets define some notation to make this easier to read/write:

TurnLerpLowRate = inLow
TurnLerpMidRate = inMed
TurnLerpHighRate = inHigh

TurnLerpLowSpeed * (<engine rating> / <mech max tonnage>) = outLow
TurnLerpMidSpeed * (<engine rating> / <mech max tonnage>) = outMed
TurnLerpHighSpeed * (<engine rating> / <mech max tonnage>) = outHigh

Throttle = x

The throttle is used as an interpolation value in the following way:

if (x < inLow)
{
	return outLow;
}
else if (x > inLow and x <= inMed)
{
	float factor = ((x - inLow) / (inMed- inLow));
	return outLow + factor * (outMed - outLow);
}
else if (x > inMed and x <= inHigh)
{
	float factor = ((x - inMed) / (inHigh - inMed));
	return outMed + factor * (outHigh - outMed);
}
else
{
	return outHigh;
}

To get turn speed for any given throttle setting should involve using that above function. Also a disclaimer; I put this together pretty quickly, so there could very well be errors. Don't take this as 100% completely confirmed.

Hopefully that helps!

* The actual throttle value used in-game maps to engine output power, so this input varies with hill climb factor, how long the mech has been accelerating, whether or not you're running into a wall, etc..

edit: formatting

A very hard quote to get the full gist of what Karl is saying. I think he is showing just how much time and thought have been given to making a more realistic Mech simulator.
If so, wow. totally blown away here.
Thank you Karl.
And if your guys in design and development put equally long hard thought to CW, then woo-hoo it is going to be epic!

[evilC]

Hi Karl,
So much win on this thread, I really had lost all hope of proper dialog with the devs over MWO but after reading this I see some light at the end of the tunnel.
To let you know where I am - I am still active in this game, I am not at the point of quitting yet, but I do have a policy of not putting any more money in until I see real change (Save for the slayer I had to drop cash on as I needed it for a comp drop).

Because of the respect I have for the way you are handling this, I will try and keep this as non-ranty as possible - please forgive me if I do get a little emotional at points.

I recently saw a thread where players were asked for information that would help fixing of stick controls.
My response to this thread was that keyboard / mouse do not work properly yet, so why were they they bothering with the fluff? I mean, hell, I own a TIR and want head tracker support as much as the next man, but there are more fundamental issues to be solved first...

Everything I stated in that response is still the case, except for zoom in/out commands (Which I think was actually patched in prior to me making that post and I had not noticed), but predictably the implementation was something of a failure.

How is it even possible to add zoom in/out functionality and not have it bindable to mouse wheel? It beggars belief. Binding anything to mouse wheel was broken ages ago (Like a year or so) and not a word from any dev as to why. My personal guess is that as mouse wheel is the only "key" to only send a key down event but not an up event, this causes an issue with the bindings code. This is corroborated if I do a simple remap using AHK - if I remap wheel up to Z it does not trigger the zoom. If I modify the script to send an up event for the Z key, it works.
Even when I use AHK to remap the wheel to the zoom in/out buttons, it is still not ideal. For example, if you have adv zoom fitted and send multiple zoom in commands within 200ms of each other (common when it is mapped to wheel), strange things can happen - you go to zoom 1.5, then 3, then adv zoom, then back to 3 (ie the adv zoom window pops up briefly then closes). Sending the commands slower than 200ms will not result in adv zoom opening and then closing.
The only solution I found is to write a script that handles zoom and have the script be authoritative by using the "go to zoom x" commands and not the "zoom in/out" commands - the script decides what zoom the game should be in, not the other way around. Interestingly, if I do not also leave a 200ms gap it is still possible to have weird things happen - even though I send the keys "Go to zoom 1", "Go to zoom 1.5", "Go to zoom 3" in order, they may not be executed in that order...
I had zero success with letting the game be authoritative and having the script issue zoom in/out commands - it behaved fine in testing grounds, but was unusable in a match.
FYI, the code I use is linked in my sig.

It also seems like it should be a trivial fix to make Arm Lock Toggle a proper toggle and not a momentary, yet it has never been done.

What I said in that post regarding Arm Lock and it's implications for Head Tracking are also still very relevant and it seems you are the person to answer these questions:

evilC, on 18 April 2014 - 06:42 AM, said:

Arm Lock causes inconsistent mouse behavior
With arm lock off, if you move the mouse quicker than your mech can twist, the viewport (head look) moves to where you would have twisted to, then the torso catches up to where the viewport is looking.
With arm lock on, instead of twisting the view, it "throws away" this extra movement.
Until you understand what is going on, this can be confusing and will also interfere with your ability to improve aim through muscle memory.
Also, how will this work with absolute input? Surely keeping things as they are would break absolute stick mode? If the user is also using TrackIR, how will this work?
Surely you will need a re-design here...

Could you please clarify as to how these issues have been handled in your TrackIR implementation?

Yeah, I know stuff like arm lock toggle / TAG toggle may seem of low importance, but the usage stats on my scripts that solve these issues tell a different story - Fire Control (See sig) peaked at 3,500 uses a month in March (Interestingly, usage dropped for the first time ever in April- down to 3,300) and I doubt the majority of users are using it for the fire timing functionality (ie macro'd ACs) 100% of the time - From support requests and people I speak to regularly who use it, arm lock toggle and TAG toggle are the most popular features.

Cheers

evilC

Edited by evilC, 11 May 2014 - 05:07 AM.

[Butane9000]

Karl,

I understand from reading this thread your not too involved in the actual design philosophy of system but their implementation. If possible can you pass this idea along to those who design the systems. This has been posted numerous times across the forums for fixing certain issues but they've never got a fully in depth response before.

SHS vs DHS

We know as of right now that the design devs believe DHS to be the end run. That ultimately every mech should have them equipped. But this makes SHS useless in all but stock matches. One very strong suggestion was change the heat dissipation values on both types of heat sinks to give them both usefulness.

SHS - have these dissipate heat faster but have a lower heat cap. This would make SHS useful mostly for lights and mediums who tend to use lower heat generating weapons. If lights and mediums want to use high heat generating weapons (PPCs, AC20's etc.) they can upgrade to DHS.

DHS - These should increase the heat cap significantly but because they are "bigger" they should dissipate heat less quickly. The idea is those high heat weapons like PPCs and large ACs can be fired more often in a short time but then it takes longer to cool off. If mechs wanted to go for less burst and more stable firing they can use SHS to dissipate the heat more quickly but not be able to fire as many weapons as fast.

Variant Usefulness

As of right now many mechs have ultimately 1 or 2 variants (heroes not counted) that are ultimately used by the majority of the community. Many recommendations have been made. Reading through this thread I saw at least one involving remaking the pilot trees to be designed around each variant individually.

But there has been other suggestions. Such as limiting hard point sizes to a certain amount of critical slots (ala MW4) or having a "small" and "large" hard point system where small weapons (SL, ML, SRM2, SRM4, SRM6, LRM5, LRM10 etc) and large weapons (AC10, AC20, Gauss, PPC, LL) can go into different slots. This way it gives players a better reason to go with the variants less used.

Because right now the general consensus is that most people opt for the variant most capable of performing the current "meta' which is stifling both variant and build variety.

Light & Medium Balancing vs Heavy & Assaults

Per earlier in this post and well known is lights and mediums aren't played nearly as much as heavy and assault mechs. How can we fix that? 3/3/3/3 is possible but it's fatal flaw is players who've grown accustomed to the handicap of higher tonnage and more "health/armor" the bigger mechs provide will feel stifled when they are forced to shift over to lights and mediums. It's also a problem because SRMs are still not where they need to be HSR wise. I know there's been improvements as I have started taking SRMs back out into the field but they still have issues.

Some ideas tossed around are giving lights and mediums bonus to C-bill income to encourage their play. Another option is changing the mandatory minimum 10 heat sink requirement for the lower tonnages. I know this would significantly help the Locust and Commando as well as other lights. It'd also improve the use of some mediums which are the weight class most effected by engine weight vs armament due to their tonnage. The other issue is fixing mech scaling. Currently some medium mechs (Shadowhawk for one) are as tall as an Atlas which is 45 tons higher. Here's an example I have posted elsewhere:

Spoiler

If possible please pass these onto the devs. I won't say the community is 100% right on these but we'd like to know if they've at least been considered from a design stand point.

Thanks

[Krinkov]

I'm playing the game with an AMD Fx8120 and I get a 20% to 30% performance boost by turning off cores 1,3,5 and 7. Another member of the clan achieved similar performance gains with his 8 core processor as well. He believes it is because the game is attempting to perform floating point calculations on the extra four cores which are not designed to do floating point ops. Could you shed some light on this? Is his theory correct?

[Amerante]

There are many suggestions about role warfare, and redesign the pilot trees for each mechs are really good one.

PGI already made some changes to the game that translates the TT basics into a real time shooter. Even if some of them are questionable, I feel they made the game better.
Some suggested that they should take example from EVE, and I agree with that.
They could add the weightclasses some unique bonuses, for example:

Lights: 360 degree radar or increased radar range by default
(reason: lights by design are scouts, and provide information to the rest of the team)

Meds: they gain speed and mobility like they would have X (eg +20) higher engine rating.
(they are light hunters, flankers)

Heavies: additional free "phantom" heatsink (eg +1) that provides a littlebit better heat management
(they supposed to dish out damage)

Assaults: additional free armopoint on all locatons (+5 on all loc)
(they lead the charge, and take the punishment instead of meds and heavies.)

These are just ideas, numbers are just example, the important is the concept, that makes weightclasses feel more unique, by giving them bonuses that only they can utilize.

[Shlkt]

Karl Berg, on 09 May 2014 - 03:11 PM, said:

Light: 16%
Medium: 21%
Heavy: 35%
Assault: 28%

The discrepancy between lights and heavies highlights the importance of estimated wait times when 3/3/3/3 finally arrives. Right now we've got 119% more heavies in the queue than lights; if player preferences did not change for 3/3/3/3 then the wait time for heavy mech drops would be at least 119% of the average game length. That's what... 10 minutes? Too long by far.

Players can and will balance the queue if wait data is presented to them; you'll still get longer wait times for the big guys, but if players can know beforehand that their Jager will wait an extra 4-5 minutes then they've at least mentally prepared themselves for the wait. Known wait times are less likely to induce rage.

Finally, notice that most players had been assuming that medium mechs would be in higher demand. Without live wait data you'd have tons of guys waiting in the heavies and assaults, getting frustrated, and then trying to drop in mediums to speed things up! It wouldn't actually speed things up, though, because the light 'mechs would have been the bottleneck. Just another reason why live wait times are important - players can't balance the queue or their own expectations without the correct data.

[EDIT: yes, wait times can differ by Elo; that certainly complicates the problem, but I still think the data is very important to keeping the players happy]

Edited by Shlkt, 12 May 2014 - 04:49 AM.

[Vermaxx]

The only thing Butane pointed out that I'd support is mech sizing.

There is no point in making single heatsinks relevant, because clan sinks are flat better even if they're only 1.4 each like ours. Assume every mech costs 1.5 million cbills more, because that is the only reality here or in tabletop.

Variants having restrictions isn't going to fix the meta or add variety, it's going to force people to use other variants just to get x build. It's also going to make certain builds require a totally new mech, or be impossible. That's not an improvement. The lack of a back end game is why certain builds rule: the only goal in MWO is to be as meta as possible and win as much as you can. There's no bigger goal.

I totally agree the mech sizes are all jacked up. There needs to be uniform heights based on weight, they're either designing every model without considering previous ones, or they're using book value heights and sizes where available. Those values are completely irrelevant in a fps rather than a board game. I already think the world scale is all wrong, but fixing that would require a total rework and doesn't matter unless they add in infantry or tanks. At least make smaller mechs BE SMALLER.

Can we get away from this 3333 thing? Focus on groups of four - no more than four of any class and allow four player groups to pick anything they want. 3333 totally makes every match largely even, but it's proven to be hell on the matchmaker and creation timers. Blocks of four is easier, compatible with small group players, and doesn't even require you find some of every class.

Edited by Vermaxx, 12 May 2014 - 05:40 AM.

[dangerzone]

I think our good friend Karl Berg died. Rest in peace

[Bilbo]

dangerzone, on 12 May 2014 - 09:35 AM, said:

I think our good friend Karl Berg died. Rest in peace

????

[Cimarb]

dangerzone, on 12 May 2014 - 09:35 AM, said:

I think our good friend Karl Berg died. Rest in peace

Bilbo, on 12 May 2014 - 09:50 AM, said:

????

I'm pretty sure he just means Karl hasn't posted in a few days. Not how I would have said it, but...

[Heffay]

Bilbo, on 12 May 2014 - 09:50 AM, said:

????

Apparently the expectation is for Karl to post over the weekend, or first thing Monday morning at the start of the workday after his last post was late Friday afternoon.

Then again, I've seen posts of his at one in the morning, so who knows what kind of schedule he works.

[Egomane]

dangerzone, on 12 May 2014 - 09:35 AM, said:

I think our good friend Karl Berg died. Rest in peace

Please remember that Karl has a life.

Considering we just had a weekend since his last post, it's absolutly possible that he simply wanted to spend some time with his family, friends or hobbies, instead of answering questions about work. Don't you agree?

[Jman5]

Hey Karl, I have a hypothetical question for you. Let's say design told you they wanted artillery/airstrike module to launch a projectile canister onto the ground. That way players could see it coming when an opponent places the smoke 2 feet behind them. Would this be difficult to do if you were just copy/pasting the ballistic art asset from another weapon?

[p4r4g0n]

dangerzone, on 12 May 2014 - 09:35 AM, said:

I think our good friend Karl Berg died. Rest in peace

This is why we can't have nice things

[Cimarb]

Jman5, on 12 May 2014 - 10:11 AM, said:

Hey Karl, I have a hypothetical question for you. Let's say design told you they wanted artillery/airstrike module to launch a projectile canister onto the ground. That way players could see it coming when an opponent places the smoke 2 feet behind them. Would this be difficult to do if you were just copy/pasting the ballistic art asset from another weapon?

I think that would be really cool, though the AirStrike animation is already pretty spectacular. Does artillery have anything other than the smoke - I don't think I have ever noticed it if so?

(I am one of those people that is almost always zoomed out sniping, so even if the smoke is slightly in front of me and jets are flying over me, I can't see the stuff until the rounds start hitting...)

[9erRed]

Greetings all,

Considering that the Mech's sensors can detect and advise the Pilot of 'incoming Missiles', they should also be able to be linked to there higher Command Channel.

- This command channel consists of all the other elements that are not currently 'in the Battle', the orbital units, the aerospace elements, and the ground elements, all possessing sensors and communications that could advise the Mech's Pilot that there was an arty or missile launch detected.
- Plotting the anticipated target location should only take seconds, and enough time to warn the Mech Pilot that munitions are 'inbound'.
- These 'other' friendly elements should also be able to see orbiting aerospace units and advise when they are on an 'attack run', as some Mech's were (from Canon) dedicated AAA units and it was there job to engage these type of air units.
(yes, Jaeger I'm looking at you.)

So, indeed there should be numerous methods of having indications of any ordinance arriving on the Battlefield. There was earlier discussion from Bryan or Russ about new game assets being made available, 'Orbital sweep' was one, updated sensor data from Aerospace flyovers another. If these elements are around/over the Battle space anyways, they should be monitoring what is happening.

Sidenote:
I would like to see a unit that was set up to actually engage aerospace fighters.
- On detection of incoming fighters the Mech 'auto turns' to their incoming flight line.
[If not decisively engaged at the time]
- the pilot is responsible for the actual engagement and firing, but the Mech turns to face the threat.

Just info,
9erRed

[Mawai]

Karl Berg, on 09 May 2014 - 03:11 PM, said:

I have some recent numbers, this is for a single day of telemetry:

Light: 16%
Medium: 21%
Heavy: 35%
Assault: 28%

Yay! Real numbers thanks very much!

Now ... here are the expected queue times with 3/3/3/3 assuming this distribution is representative.

nLaunch is the number of folks launching in an hour (and is actually completely irrelevant to queue times)

0.16 * nLaunch light
0.21 * nLaunch medium
0.35 * nLaunch heavy
0.28 * nLaunch assault

0.16 * nLaunch/3 matches are formed in one hour since the light mechs are the limiting factor
0.16 * nLaunch mechs in each class will get a match in the time frame - the rest are queued

After one hour there are:
0.21 * nLaunch - 0.16 nLaunch = 0.05 * nLaunch mediums in queue
0.35 * nLaunch - 0.16 nLaunch = 0.19 * nLaunch heaavies in queue
0.28 * nLaunch - 0.16 nLaunch = 0.12 * nLaunch assaults in queue

Every hour there are 0.16 nLaunch mechs of each class which get a match ... everyone else is queued ... so after one hour of uptime the queue times for the last mech entering the queue are:

medium = 0.05 * nLaunch / 0.16 * nLaunch = 0.05/0.16 hr = 18.75 minutes
heavy = 0.19 * nLaunch / 0.16 * nLaunch = 0.19/0.16 hr = 71.25 minutes
assault = 0.12 * nLaunch / 0.16 nLaunch = 0.12/0.16 hr = 45 minutes

Please note that the queue times are COMPLETELY INDEPENDENT of the number of players launching in an hour - it is ONLY dependent on the mech class distribution.

In addition, these are queue times after one hour ... the queue times increase linearly so they will be twice as long after 2 hours and so on.

ANY imbalance in mech distribution generates queues quickly, PERIOD. I've said this in at least half a dozen forum posts.

e.g. a 24/25/26/25% distribution queue times after one hour:
0.01/0.24 = 2.5 minutes for assault and medium
0.02/0.24 = 5 minutes for heavy
In three hours they will be 7.5 minutes and 15 minutes
Even 2.5 minutes is too long in my opinion ... however, I don't think we need worry since I don't think we would EVER see a mech distribution this evenly matched ... to start with, it would require 50% more players to drop in light mechs than do currently ... and I am not sure that there are enough folks who even like light mechs to make up that difference.

So .. I think that the 3/3/3/3 paradigm is broken as currently designed and will NOT work with a real distribution of players. Expecting players to switch mechs to get a match faster will just mean folks will quit rather than play a mech they don't like.

Fundamentally, I think the matchmaker MUST respond to the mech distribution in the input queues or the design is broken.

My suggested fix for this was the following:

Monitor queue times. Set a maximum acceptable queue time (I choose 2 minutes).

When all queue times are 2 minutes or less - generate 3/3/3/3 match distributions

IF a queue goes over 2 minutes then adjust the distribution to increase the number of mechs from queues over 1 minute proportional to the number of mechs queued ... so that the long queues reduce over time ... the rate limiting step is still the class of mech with the least number in the queue. This may mean generating 1/2/5/4 or some other distribution for a while to reduce queues - it has to be adaptable - BUT the matches will all be evenly matched with the same classes and ideally tonnage on each team. Folks don't really care about 3/3/3/3 - they do care about balanced matches.

When all queues are 1 minute or less go back to generating 3/3/3/3 until a queue hits 2 minutes - rinse and repeat.

This would mean:
1) All matches are balanced for weight but there will be some variety in matches.
2) At least some fraction of matches will be 3/3/3/3 ... the closer to equal the queues are the more 3/3/3/3 matches there will be
3) The maximum wait time is 2 minutes
4) The game will not force people to play mechs they do not want to play in order to get a match in less than an hour ... this is crucial for player retention ... if I have to wait even 10 minutes for a match that only lasts 10 minutes ... I won't be playing MWO at all ... and there are probably a lot of folks in this boat.

Feel free to pass this one along Karl if it is worthwhile.

Edited by Mawai, 13 May 2014 - 06:38 AM.