1911 replies to this topic

[GalaxyBluestar]

GalaxyBluestar, on 11 April 2014 - 08:08 PM, said:

may i suggest that the amount of crit slots an engine has for engine heatsinks be brought into line with the philosophy crit slots for tonnage? cause at the moment i can gain 4 DHS in and engine or 4 SHS in an engine for the same expendature in tonnage howevere not only is the DHS cooling better but for the same tonnage "price" i've saved myself 8 critslots on my mech for other weapon/ammo/equipment. that's one of a few reasons why there's a lot of DHS played and little SHS. just things like this need consideration if tonnage vs critslots is the only way to balance SHS usage vs DHS usage.

Peter2000, on 12 April 2014 - 12:55 PM, said:

Regarding the SHS/DHS tonnage/crit tradeoff:

The traditional argument for SHS being relevant is that they consume fewer crit slots than DHS, therefore making them balanced. While this seem plausible on the surface, it is a fallacy.

Why? EHS - Effective Heat Sinks - the total level of cooling is totally skewed in DHS favor. If you run SHS, your EHS = your SHS. If you run DHS, your EHS = 2.0xEngine DHS + 1.4xOtherDHS.

If you take DHS and at least a 250-rated engine (basically all 'Mechs use an engine this large, or larger), and NO heat sinks, you have already saved 10 crit slots compared to SHS cooling the same quantity (same EHS for 10 in-engine doubles and 20 singles). Excluding engine slots, it takes carrying nearly 30 (I have a table for the exact numbers of crits saved) SHS before you're saving ANY crit slots compared to an eqivalently cooled DHS 'Mech (and you're paying upwards of 12 tons for those one or two slots!). The bigger the engine gets, the higher the tradeoff point.

Since you get so much for free out of engine DHS, SHS need to do something better than them to be balanced. Like heat threshold.

yep

[Troopie]

Whoa, this is amazing thread .

To invisible terrain issue:
Can network lag affect this. Seen this issue a lot in my screen also. I like to play fast light mech, but I have bad rig and servers are quite far, even my internet connection is pure diamonds locally. (Async screen field update?)

Some high hopes from user experience to development points:

First of all, MW:O is complex game, everything is not in chassis and guns!
I see here lot's of people, who dont want to use few mechs and build's to win a match.
They want to use whole mechbay in 12 people drops and have more challenge on tactics, with reasonable fair match. Elo is not solution, its only tool to enable these issues. DO NOT force balance everything!!!.

Game content is lacking challenge. 12-matches are driven to play only meta, because it's only way to win. Every game type is more or less skirmish because of meta builds. At this moment matches are limited about 10 chassis with certain type of weapon sets.

How to get more players, with long partnership with MWO (Paying customers)?
Make gamemode's and rules.

There is reason why serverside admintools are called as gamemaker's, because it gives restrictions and rules to game, what people want's to play. Use MWO's complexity, do not narrow it.

Some suggestions:
Game mode with stock chassis and build's. You can use your owned mechs, but do not force people to make it in mechbay. Just mech selection and play and no affects to current builds etc. at mechbay.

Weapon restrictions. No long range weapons, and/or no long range energy etc. and similar to all weapon types.
Implement these to Conquest, Assault and Skirmish too.

It's good that there is so much chassis, but there is now use for those. Why buy mechs to mechbay, if you are not able to use those ingame?
PGI haves unique world with huge story, use it to make business. Don't make gameworld from business.

Thank you's for everybody, who have been able to keep this thread strictly positive for MWO's development. Main thing is, this would not been possible without Karl Berg's responsiveness.

GOOD JOB KARL B. keep it going!!!

[BlackDragon83]

Just to add my voice to the choir - Karl you're really knocking this one out of the park! It's great to see a thread on this forum that I can read and gain understanding without being depressed or annoyed by the level of open and honest discussion. I think this is a lesson for Paul and others to take note of and follow, as well as to the community on what happens if we stay civil and objective.

A few questions if I may:

1) Are there any plans for the command concole? I vaguely remember Russ or someone saying a year or so back that there were some concepts going through design, but there's been nothing since. At the moment it's a pretty expensive cardboard box sitting in my inventory. If it's not going to be any time soon, may I suggest at least taking it off the purchase list so that unsuspecting new players don't buy one and then get annoyed that it doesn't do much.

2) On the mech trees, am I right in thinking that the pinpoint efficiency doesn't do anything because there's no convergance in the game? How close are we to updating these trees with something more useful?

3) Would it be possible to have a module that gave you a rear-view mirror or 360 wrap-around at the top of the screen, or would that kill the fps because it'd add the need for the server to calculate rays in all directions?

Edited by BlackDragon83, 12 April 2014 - 11:20 PM.

[Caswallon]

Wow quite a read!

Not much to add except wanting to go on record to thank Mr Berg for taking the time to do all this. Epic work sir long may you continue!

[Roadbeer]

Hey Karl. I know you're not a design or UI guy, but if you could pass this along to those who are, that'd be awesome.

Roadbeer, on 13 April 2014 - 07:36 AM, said:

Click hard to find at first Social tab.
Click create group
Invite friend 1
Invite friend 2
Message friend 3 "Hey, we're on TS, come join us"
Wait a couple minutes
Message friend 3 "Hey, we're on TS, come join us"
Wait a couple minutes
Message friend 3 "Hey, we're on TS, come join us"
Wait a couple minutes
See friend 3 go into a match (Probably didn't see the hard to notice "Social" tab flashing)
Decide to launch
Can't launch, someone is on their mechlab screen (Really they were on the "Social" screen, they just didn't go to the "Home" screen before going to the "Social" screen)
Press Launch button
Message about not all group members are ready
Group lead unredies then reredies
Press Launch button
Message about not all group members are ready (they are)
Press Launch button
Play Match
Message from friend 3 "Hey, I saw you sent a message before I dropped after I got back from my drop, What's Up?"
Message friend 3 "We're on TS, come join us"
No reply
Go to website, message friend 3 through there
All members ready
Press Launch Button
Get message about how not all group members are ready
Press Launch Button
Launch...

[Egomane]

Roadbeer, you should know, that posting this once, in a feedback thread, should be enough. Karl already said, that they are reading those.

[Cimarb]

slide, on 12 April 2014 - 06:10 PM, said:

With out getting into a debate on the pros/cons of burst fire on AC's.

Is there any technical limitation to having this in game?

I would have thought that the mechanics (lasers have about 60 ticks per beam) and effects were already mostly present within the engine. You can basically see the effects needed with UAC5 double shots, and chain fired AC2's.

Thanks for reading, love your input.

StJobe had a great write up about how easy burst-fire would be to implement, but I'm on my iPad so can't look it up (well, I could, but it would take an hour or two). Basically, it would just take changing a couple existing variables in the XML file. You could do that and save several versions of the same autocannon as different manufacturer variants to make the system I describe in the link in my signature.

I would love to have Karl discuss the viability or any technical system issues behind doing this, though. Please?

Egomane, on 13 April 2014 - 08:39 AM, said:

Roadbeer, you should know, that posting this once, in a feedback thread, should be enough. Karl already said, that they are reading those.

I can speak from personal experience that "they are reading those" is a very small consolation when there is zero feedback on the viability of ideas. I even submitted my autocannon system through a private message to support and the only response I got was "thanks, great idea, we will forward it". I would love to even get a "we can't do that because of {this}". Even that would be welcome!

[Egomane]

Cimarb, on 13 April 2014 - 08:52 AM, said:

I can speak from personal experience that "they are reading those" is a very small consolation when there is zero feedback on the viability of ideas. I even submitted my autocannon system through a private message to support and the only response I got was "thanks, great idea, we will forward it". I would love to even get a "we can't do that because of {this}". Even that would be welcome!

It's not that easy. There are literally thousends of ideas floating around on the forum (most in feature suggestion where they belong), and every day we get dozens more. Every idea has to be filtered, if it is being forwarded. Those that are forwarded, will again be filtered in various categories. Those categories will be brought up in meetings and again be filtered. If an idea gets an approval in such a meeting, it will get a detailed report, containing points like effort needed to create, compatibility, usability and many more. Each point has the ability to shoot the idea down once more. And even if the idea gets past all this, it can still be canceled during production, because it comes into conflict with another component (maybe from another idea).*

*At least that's the way it is in the development studios I know and have inside contacts to.

So until the developers get to the point of "we can't do that because of {this}", a lot of time has already past. Also, responding to every idea with a detailed explanation on why it can't be implemented, can take a lot of time away from development.

[Karl Berg]

Cimarb, on 13 April 2014 - 08:52 AM, said:

StJobe had a great write up about how easy burst-fire would be to implement, but I'm on my iPad so can't look it up (well, I could, but it would take an hour or two). Basically, it would just take changing a couple existing variables in the XML file. You could do that and save several versions of the same autocannon as different manufacturer variants to make the system I describe in the link in my signature.

I'm not an expert on the weapons systems, but I think this might be a bit troublesome. Alex is also hugely supportive of this model for AC's, as it's actually much closer to lore.

Here's the gotchas: The highly rapid-fire weapons, like machine guns, act as trace-fire weapons similar to lasers. The AC's all simulate with somewhat more physical accuracy, they spawn an actual projectile which has velocity, simulates over time, is affected by gravity, etc..

So while we could shoot off a pile of rapid-fire projectiles, that would have knock-ons that would require additional investigation at the very least. Increases in network traffic, increases in processing time and collision detection costs. Or, we might consider turning AC's into trace-fire at the cost of simulation fidelity. The shells would then fire with effective infinite velocity, no longer have gravity falloff, etc.. That's not necessarily a tradeoff we would like to make.

[Karl Berg]

juju2112, on 12 April 2014 - 04:14 PM, said:

Where I work, some areas are using CA Lisa Service Virtualization for this. So, you can mock up a fake database, web service, or whatever, and your unit tests hit the Lisa instance for those things instead. It's a good way to test things like that that are inherently integrated into other systems. I certainly haven't had the time to learn it myself, though. Too busy, much like yourself I presume!

That sounds crazy useful. I'll have to take a quick look at what that provides, but the aforementioned system engineer working with lua busted / tinker may be well on his way to writing a custom equivalent for us. It requires the service stack to be deployed, and the vm to exist to run it; but it does handle applying various SQL scripts to populate schema, and test data, runs the tests with some arbitrary number of simulated clients, verifies and reports results, etc...

[Karl Berg]

Rad Hanzo, on 12 April 2014 - 04:11 PM, said:

About VoIP :
Is it feasible to integrate a VoIP system into the game that takes into account wave-travel-impediments (hills,trees,steel structures,etc...) and positional placement of sending/receiving units ?

One possible example would be the ACRE TS plugin which connected ArmA2/ArmA3 to the used TS server and provided spatial audio positioning of users (i.e. be able to hear someone talking according to distance from speaker| ~audible radius with proper fall-off of 20m) and futhrmore implemented real-world impediments for wavetravelling properties of also implemented radios (i.e.: hand-radius for squadlevel chat with a range of 1km; backpack radios with up to 2,5k range; vehicle mounted, massively amped radiostations with range of up to 10k) .

So, if one was talking closeby you could hear him directly and correctly positioned (up, dwn, left, right), if he was 200m away use that squadradio (if you knew the chnnel hewas listening to), if he was 3k away you had to have either a backpack radio plus a vantage point free of obstructions/flat plain or a powerful, vehicle-mounted fixed radio.

Thats it for now

We could potentially do awesome immersive things like this. We need to be super careful though. Someone pointed out that if we go crazy with this, like add jamming features for disrupting enemy team comms, or interception mechanisms, it only drives users to not use the integrated VOIP system, and use an external tool like teamspeak. That's a fair point. We would want to integrate VOIP as a communication and convenience tool to improve user experience first, rather than a game mechanic.

[Karl Berg]

o0cipher0o, on 12 April 2014 - 04:39 PM, said:

Well, i did read that post, and also the answer to it. What i'm talking about, aren't the rendering issues related to low settings and distances, but the terrain hitboxes. For example, in tourmaline, in the center, the two cristals walls right on the top of e5, have the hitboxes protruding slightly over the actuall terrain geometry, so that, even from just a bunch of meters away, when everything is rendered, if you shoot at a mech you can see just the head, for example, you'll end hitting an invisible wall, whereas the projectiles should have been fully capable of reaching The target.
I'm not talking about the appearing/disappearing objects around the maps, but about the hitboxes that in some points doesn't coincide with the actual geometry of the map.

This one sounds like good old fashioned content issues. They may have simplified the collision geo way up there for performance, with the expectation that players would not be able to hill-climb that far; that's just a guess though. Art is about as far from my skill set as you can get.

If you report the map and battle grid values, we can get this into the hands of QA for verification, and get it into the map teams bug backlog for fixes if necessary. Thanks!

[Modo44]

Karl Berg, on 13 April 2014 - 09:20 AM, said:

So while we could shoot off a pile of rapid-fire projectiles, that would have knock-ons that would require additional investigation at the very least. Increases in network traffic, increases in processing time and collision detection costs. Or, we might consider turning AC's into trace-fire at the cost of simulation fidelity. The shells would then fire with effective infinite velocity, no longer have gravity falloff, etc.. That's not necessarily a tradeoff we would like to make.

Hitscan ACs would be a sad system. MWO's distinctly not point-and-click gameplay is very appealing. Here's hoping you can find a way to model burst fire within the server/network constrains.

[Karl Berg]

MischiefSC, on 12 April 2014 - 04:43 PM, said:

It actually wouldn't be a hard variable to solve for. Playing in a premade doesn't necessarily given an advantage; what you're really wanting to measure is synergy. How well specific players do together.

So you'd track a paired Elo for every player who plays with another player, this way it self-corrects for the size of the premade team. They get an Elo modifier based on the difference between their 'stock' Elo and their premade Elo with that player and average it with everyone in that specific premade instance. You'd also want a minimum seed threshold before you applied the variable. Dunno what the standard deviation is for Elo in MW:O

<snip..>

Good thoughts. I'm not sure I 100% understand your approach, so apologies if I've misinterpreted something (and correct me please if I have misunderstood!).

It definitely better reflects the biases that can impact player skill than our simple per-weight class system we currently have. However, here are some issues that would need to be considered with pair-wise tracking of Elo:

This is N^2 in memory cost on number of players. We currently have around 1.6 million player accounts or so. Not all are active, but an enormous percentage are or were active at some point, have played games, and have stats and ELO values associated with their account.

A non-sparse matrix of Elo's would then cost around 2.5 trillion entries worst case. Would this is be a symmetric matrix of Elos? Would player A's Elo when playing with player B be the same as player B playing with player A? If so storage costs could be cut in half.

For the 3 player group case now, we have many Elo's being tracked: A-B, B-C, C-A, and potentially the inverse cases B-A, C-B, and A-C.

For the 4 player group case we have A-B, A-C, A-D, B-C, B-D, and C-D, and potentially the inverse cases.

I think this works out to N choose 2 for the general case, so 1/2(N)(N-1); and so a 12 player group (worse case) costs 66 or 132 additional stat writes. That could definitely cause us issues with additional write-pressure at end of game.

Furthermore I'm not certain this is a true general solution, consider a case where players A and B perform *very* well when teamed with C due to C's leadership abilities; but terribly with D. So the pairwise Elo between A and B would heavily depend on the presence of C or D in their group.

To fully generalize using specific Elo tracking I think might require a separate Elo for every single group playing the game. Instead of a 2-D matrix of pairwise Elo's this takes it to an N-dimensional matrix. Definitely outside the realm of feasibility in terms of storage and data tracking costs.

There's another problem with highly fractured Elo's. We see it a bit with the 4 Elo categories we already have in fact, as players switch weight classes and find wildly different match qualities as a result. The more categories of Elo's we store and track, the more Elo's in our system are not seeded or updated correctly for that player. Here is one example with pairwise tracking. A played with B a few times back in closed beta, and B decides to take a long break. A continues playing and becomes very skilled indeed. If B returns and A and B decide to play again, A's archived pairwise Elo with B has him categorized as a new player!

For these reasons I would really love to explore the options we have with tracking just a few Elo's only. Say a solo and grouped Elo only, and examine other emergent properties of teamplay to infer other sources of bias, and this is where I would really want to pull in a data-mining / statistics expert to assist with. Are there correlations with group size? Are there correlations with Mech tonnage? Are there correlations with kill/death ratios? Are there correlations with # of games played? Do these correlations correlate between themselves, so combinations of group size combined with play count? We certainly have the terabytes of data required to curve fit or otherwise experiment with. I realize we won't be able to take this all the way to perfect, but I'm not sure that's a reasonable goal to set out with in the first place. The cool thing is this is one of the places where we can actually run controlled experimentation. We would, on launch of an updated system, be able to say with confidence, 'this new system is X% better at predicting group player skill'.

[Roadbeer]

I need a wetnap

[CyclonerM]

I always supported burst-fire ACs, too. Would it be possible to give it priority for testing? I mean, it might be feasable and i understand from your reply that it is a matter of testing to see if the network can handle the added traffic/collisions.. In MW:LL there are even Rotary ACs that fire a prolonged stream of bullets, but i am not sure if such bullets are only "light" or actual projectiles like the ACs in MWO.

I am certain that having 2-3 bullets bursts would make any other nerf/change to ACs useless. Basically they are the only category of weapon a bit out of place (but a wide category) so i think it would be worth to investigate this change, which has been proposed long ago.

And of course it would be more true to lore (and this is very important for me ).

Thank you for your answers!

Edited by CyclonerM, 13 April 2014 - 10:47 AM.

[Peter2000]

Karl Berg, on 12 April 2014 - 02:53 PM, said:

Any professional statisticians out there?

Professional, no. Grad student in related field, yes.

Karl Berg, on 13 April 2014 - 10:20 AM, said:

It definitely better reflects the biases that can impact player skill than our simple per-weight class system we currently have. However, here are some issues that would need to be considered with pair-wise tracking of Elo:

This is N^2 in memory cost on number of players. We currently have around 1.6 million player accounts or so. Not all are active, but an enormous percentage are or were active at some point, have played games, and have stats and ELO values associated with their account.

Right - which is why I think the same sort of system, aproximated not based on pairwise matching of players, but how much the team's performance changes when a single player is in a group (whether it is his leadership or being led that helps is hard to determine, and kind of irrelevant), would work (and have memory demands N). Some people might synergize differently together, but without incredible resources, that's something that just can't be feasibly tracked in the same way.

If you were to go that route, using a structure other than a matrix would be best, since 99.9% of those entries would be completely useless. You're likely to only get a large enough number of drops to get good data on synergy on with a handful of other pilots. Giving each pilot a table that can be referenced for a (for most players) very small number of partners who result in exceptions to the average grouping ELO adjustment would work better, and scale roughly linearly. Still, keeping track of, and searching through, all matches to generate this table might be a ton of work, if it isn't already done.

Karl Berg, on 13 April 2014 - 10:20 AM, said:

There's another problem with highly fractured Elo's. We see it a bit with the 4 Elo categories we already have in fact, as players switch weight classes and find wildly different match qualities as a result. The more categories of Elo's we store and track, the more Elo's in our system are not seeded or updated correctly for that player. Here is one example with pairwise tracking. A played with B a few times back in closed beta, and B decides to take a long break. A continues playing and becomes very skilled indeed. If B returns and A and B decide to play again, A's archived pairwise Elo with B has him categorized as a new player!

Which is why what you probably want to keep track of is not a replacement ELO for the player when he is in group, but an adjustment from baseline. If a 1000 ELO player is getting 150 ELO benefit from grouping, but then goes and plays solo for a few months and improves to 1400 ELO, grouping then will still help him - ranking at 1150 isn't right! 1550 might not be right either, but that should be close, and allow for adjustment.

Edited by Peter2000, 13 April 2014 - 12:03 PM.

[o0cipher0o]

Karl Berg, on 13 April 2014 - 09:39 AM, said:

This one sounds like good old fashioned content issues. They may have simplified the collision geo way up there for performance, with the expectation that players would not be able to hill-climb that far; that's just a guess though. Art is about as far from my skill set as you can get.

If you report the map and battle grid values, we can get this into the hands of QA for verification, and get it into the map teams bug backlog for fixes if necessary. Thanks!

Roger that, as soon as i can get back to play, i'll make sure to try and track avery invisble wall i see.
I'll also try to make my friends doing so

Edited by o0cipher0o, 13 April 2014 - 12:29 PM.

[Brian Buckton]

Roadbeer, on 13 April 2014 - 07:53 AM, said:

Hey Karl. I know you're not a design or UI guy, but if you could pass this along to those who are, that'd be awesome.

There's some big social fixes coming in the next patch. here are a couple issues that have been addressed:
- Chat history not being retrieved properly after returning from a drop, which directly fixes chat messages received while you're currently in a drop.
- Group launch button throwing up an error when everyone is ready. We now ensure the server gets the message first before switching your state on screen; however, In the next patch you may see a small delay of about ~1 second when clicking ready. I do have another fix to speed up that 1s delay, but it did not meet the patch deadline, so that will have to be deferred till the 29th patch.

[Wintersdark]

Brian Buckton, on 13 April 2014 - 12:24 PM, said:

There's some big social fixes coming in the next patch. here are a couple issues that have been addressed:
- Chat history not being retrieved properly after returning from a drop, which directly fixes chat messages received while you're currently in a drop.
- Group launch button throwing up an error when everyone is ready. We now ensure the server gets the message first before switching your state on screen; however, In the next patch you may see a small delay of about ~1 second when clicking ready. I do have another fix to speed up that 1s delay, but it did not meet the patch deadline, so that will have to be deferred till the 29th patch.

Mr. Buckton, thanks for joining in! It's always fun seeing you in my insomnia-fueled late night MWO sessions

If I may ask: To be clear, does this mean we'll be free to send chat messages to random players in drops, and they'll receive them post drop? In both group chat and direct messages?

Also: Would you consider adding some more visible or perhaps audible alert when you get a new chat message/invite?

Its very easy to miss that little blinking (with moderately low contrast) indicator, particularly at high resolutions. A little notification "ding" when new messages are received while your social window is closed would be immensely helpful.