Dhs Effectiveness
#101
Posted 08 November 2012 - 09:24 AM
Now, PGI, are you listening?! Give us 2.0 DHS across the board so we, the REAL TESTERS... can PROPERLY TEST them.
#103
Posted 08 November 2012 - 09:41 AM
Hikyuu, on 08 November 2012 - 08:22 AM, said:
right, because heat is a balancing mechanic to the game.
trying to balance MWO to TT systems is a baaad idea because it's a video game, not a dice roller. essentially your whole post is why DHS got reduced in power, to still apply heat as a mechanic to the game. heat neurtrality is something they don't want to occur unless the pilot forsakes firepower to do so. (IE. taking off heavy heat, higher damage weapons).
ANd you always do this. As long as weapon fire produces heat and you neat to equp something to make it go away, you always trade of damage for your heat neutrality.
ALso, there is very little in the balance of weapons that is based on the dice rolling mechanism itself. There basically two factors that matter for the dice roller:
1) Range. The longer a weapon's range in the table top, the easier it is to hit with it (if at all). MW:O replicates this effect with damage drop off by range.
2) Damage to Hit Location: In the table top, 4 Medium Lasers were not equivalent to an AC20 because the AC20 dealt the damage always to one hit location, the medium lasers would spread. In MW:O, we have weapon convergence, so 4 Medium Lasers are equal to AC20. Except that the devs didn'T make it quite that easy - they gave lasers a beam duration which makes it more difficult to maintain the damage on one spot and one hit location.
You can argue that MW:O's mechanism are insufficient to replicate this effect on weapon balance. But... If that is the case, it would imply:
Long Range weapons are overly penalized
High Single Hit Location weapons are overly penalized.
To figure out if this is true what we can do is create performance benchmarks on weapons -for example weight of a sufficiently "ammoed up" weapon with heat sinks to negate the damage, compared to its damage output. Or comparing mech weapon configurations and seeing how long they last or how much it would cost in tonnage for them to last that duration, and compare that to their damage output.
These performance benchmarks do not look at range or single hit location damage. What we would expect to see is:
1) The longer the range of a weapon, the more its damage to tonnage efficiency should drop.
2) The higher the damage per weapon is, the more its damage to tonnage efficiency should drop.
What we actually observe is this:
Ballistic Weapons efficiency increases with range. The underlying issue here could be the single hit location advantage that the shorter range weapons have. But, there is one proud nail - the Gauss Rifle has both range and single hit location damage advantage to most weapons, and is inside the curve. Also, the AC2 drops compared to Ultra AC/5, LB10 X AC,AC/5 and AC/10.
For Energy Weapons, efficiency drops generally with range, but there are two very notable spikes: The Small LAser and the Medium Laser. Both weapons share two traits - low range, and low single hit location damage. But the small and medium pulse lasers between them are weaker, despite having a similar limitation.
It is also notable that energy weapons generally h ave a lower efficiency (other than Small and Medium) then most ballistic weapons.
Oh, and both ballistics and energy weapons are outperformes by missiles, and between missiles, LRMs are outperformed by SRMs. (Tell me again which one is easier to aim with?)
So it seems that the medium and small laser may be a bit overpowred in Mechwarrior Online, since they benefit from convergence and have no disadvantage from not delivering theoretical hit single hit location damage. Other energy weapons are generally underpowered.
We also observe that the ballistics do not behave as we would want them to behave.
They outperform energy weapons, and higher range leads to more damage efficiency, not less.
Edited by MustrumRidcully, 08 November 2012 - 09:42 AM.
#104
Posted 08 November 2012 - 09:51 AM
#105
Posted 08 November 2012 - 10:00 AM
Vermaxx, on 08 November 2012 - 09:24 AM, said:
Out of curiosity, why do you want to wait until the heat meter is full before applying penalties? They already pad your threshold 1 for 1 to match your heat sunk per 10 seconds value (+1 per SHS and +<whatever the hell DHS are at any given moment> per DHS) in order to address the fact that you got to sink each turn before penalties. The 30 points they give you on top of HS value IS the old TT overheating scale. They just wiped out every other penalty except guaranteed shutdown at the top and chance of boom past that.
If they're worried about crazy front-loading, they need to start tacking on penalties once your heat hits a few points above what your sinks give you (HS+5, if you're looking to match TT, though I'm not necessarily arguing that is a good idea). The free 30 that they give everyone is what lets you spam like mad right up to the shutdown threshold.
Of course, if they did that, the massive disparity between sink rates and fire rates would stick out like a sore thumb.
Edited by SteelPaladin, 08 November 2012 - 10:03 AM.
#106
Posted 08 November 2012 - 10:14 AM
#108
Posted 08 November 2012 - 10:49 AM
dubplate, on 08 November 2012 - 10:43 AM, said:
You realize they do internal testing as well, and would be getting factual data that way right?
If they actually coded the internal test builds accurately. So far, they're at best 1 for 2, and evidence is suggesting 0 for 2.
#109
Posted 08 November 2012 - 10:51 AM
Quote
Nov 08 09:45 (PST)
Hello Squid von Torgar,
This is currently as designed. We are trying out different values to test balancing.
Regards,
Magius
GameMaster
MechWarrior® Online™
#110
Posted 08 November 2012 - 10:52 AM
Quote
- Small Pulse Lasers were only generating 50% of the amount of heat they should have been. This is now fixed.
- Small Lasers, Medium Pulse Lasers, and Large Pulse Lasers were only generating 75% of the amount of heat they should have been. This is now fixed.
#111
Posted 08 November 2012 - 10:56 AM
</UpgradeType> <UpgradeType id="3003" name="StandardHeatSinkType"> <Loc nameTag="@StandardHeatSinkType" descTag="@StandardHeatSinkType_desc" iconTag="20"/> <UpgradeTypeStats type="2" slots="0" pointMultiplier="1.0" associatedItem="3000"/> </UpgradeType> <UpgradeType id="3002" name="DoubleHeatSinkType"> <Loc nameTag="@DoubleHeatSinkType" descTag="@DoubleHeatSinkType_desc" iconTag="19"/> <UpgradeTypeStats type="2" slots="0" pointMultiplier="2.0" associatedItem="3001"/> </UpgradeType>
So internal double heat sinks are still 2.0. Which is fair, since you`re paying 1 500 000 C-Bills for it.
<Module id="3000" name="HeatSink_MkI" CType="CHeatSinkStats"> <ModuleStats slots="1" tons="1" health="10"/> <Loc nameTag="@HeatSink_MkI" descTag="@HeatSink_MkI_desc" iconTag="3"/> <HeatSinkStats cooling="0.1" heatbase="-1.0"/> <EffectList> <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_a"/> </EffectList> <Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed"/> </Module> <Module id="3001" name="DoubleHeatSink_MkI" CType="CHeatSinkStats" DestroyedDialogue="BB_Mech_HeatSink_Destroyed"> <ModuleStats slots="3" tons="1" health="10"/> <Loc nameTag="@DoubleHeatSink_MkI" descTag="@DoubleHeatSink_MkI_desc" iconTag="2"/> <HeatSinkStats cooling="0.14" heatbase="-1.4"/> <EffectList> <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_a"/> </EffectList> <Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed"/>
External DHS are 1.4. So no ninja - changes to the heat sinks at this time! That makes me happy.
#112
Posted 08 November 2012 - 11:49 AM
dubplate, on 08 November 2012 - 10:43 AM, said:
You realize they do internal testing as well, and would be getting factual data that way right?
I don't think PGI even realizes they do internal testing. The bugs/undocumented changes getting through to general release are absurd. So are some of the explanations behind them.
#113
Posted 08 November 2012 - 11:54 AM
SteelPaladin, on 08 November 2012 - 10:00 AM, said:
Out of curiosity, why do you want to wait until the heat meter is full before applying penalties? They already pad your threshold 1 for 1 to match your heat sunk per 10 seconds value (+1 per SHS and +<whatever the hell DHS are at any given moment> per DHS) in order to address the fact that you got to sink each turn before penalties. The 30 points they give you on top of HS value IS the old TT overheating scale. They just wiped out every other penalty except guaranteed shutdown at the top and chance of boom past that.
If they're worried about crazy front-loading, they need to start tacking on penalties once your heat hits a few points above what your sinks give you (HS+5, if you're looking to match TT, though I'm not necessarily arguing that is a good idea). The free 30 that they give everyone is what lets you spam like mad right up to the shutdown threshold.
Of course, if they did that, the massive disparity between sink rates and fire rates would stick out like a sore thumb.
To my knowledge, the base heat cap in MWO is 20, which is the 10 heatsinks you have to carry, and roughly 10 for the bad heat tracker. I think the real TT chart starts negative effects at 5, so maybe they floated us 5 to round out.
Edited by Vermaxx, 08 November 2012 - 11:54 AM.
#114
Posted 08 November 2012 - 11:54 AM
Squid von Torgar, on 08 November 2012 - 10:51 AM, said:
Except it was also denied by PGI in the patch notes (which explicitly said both engine and outside sinks were 1.4). I'm a little sketchy on how the hell we're supposed to know what is a bug and what is not when two PGI sources say mutually exclusive values are both "working as designed."
Vermaxx, on 08 November 2012 - 11:54 AM, said:
Nope, they explicitly said 30 + 1 per SHS you have or + 2 (at the time David wrote the post) per DHS you have. I think it was a closed beta post, though, because I'm having a hard time finding it again. Anybody know how to pull the members list so I can try and search for specifically posts by David Bradley?
Edited by SteelPaladin, 08 November 2012 - 12:00 PM.
#115
Posted 08 November 2012 - 12:05 PM
The reason they probably stuck with 'shutdown at 100%' is because the system has to remember a lot less. It doesn't matter how long it takes you to get there, the game only has to banhammer you at 100%. If they set in a variable bad heat point, then the game has to constantly check your heat versus that and know when to banhammer. Weren't people already saying PGI was trying to streamline the data transfer as much as possible to ease the netcode issue?
If they can do it, they should do it. Lets them add a whole lot of that "immersion" stuff people keep asking for. At least it helps penalize running at the top of your heat gauge all the time.
I honestly thought the heat chart was 20+ sinks over 10. 30 is ridiculous.
#116
Posted 08 November 2012 - 12:24 PM
Quote
Hey I am not disagreeing with you, make of it what you will.
However the evidence is pretty strong for DHS in the engine etc.
We have the OPs tests
My test with the jenner
The XML files
PGI's response to my email on the matter
Other tests confirm the same
Or
We could be imagining it and the patch notes are correct
Really we could do with one of the devs making a statement on the matter (I know they are busy).
As mentioned Bryan did promise to get David to do a full write up.
Edited by Squid von Torgar, 08 November 2012 - 12:25 PM.
#117
Posted 08 November 2012 - 12:37 PM
Amaris the Usurper, on 08 November 2012 - 08:36 AM, said:
A nice way to include these effects into the game would have been to have a "free" range at the bottom of the heat scale: one could move the heat into this area without suffering any ill effects. In absolute (not percentage) terms, the free range would be four plus either the number of HS or twice the number of DHS, so that we would have the same ability to alpha strike as in TT. On top of this would be a range of 26 heat points, over which one would lose more top speed and gain an increasing chance of suffering an ammo explosion or automatic shutdown. Shutdown would always occur at the top of the scale.
It would be easy to check continuously (say 10-20 times per second) for ammo explosion and automatic shutdown in such a way that the total probabilities over 10 seconds match the TT values. Since (to my knowledge) the turn and torso twist rates in MWO scale with the top speed, heat effects on ease of target tracking would be included automatically when the top speed is recomputed.
For physiological effects, the pilot's vision could become increasingly blurred and/or wobbly, with very high levels inflicting permanent injury along with a chance to temporarily lose consciousness.
Also, movement should introduce some random wobble into the crosshairs (especially so for jumping), so that being stationary confers more of an offsetting advantage.
I'm not saying any or all of this should or must be incorporated (i.e., that most of the player base would like it), but I would love to see these features, and I expect that many others would too. Just as many are probably not so much into the BT canon and would just be irritated by the necessary alterations to their play style. Maybe if MWO becomes popular enough, these things can be included in a "hardcore" game mode.
Do you really think it would be better to add all of these elements/variables to heat management when we can´t even agree as to how much heat a DHS should dissipate? Heat management should be simple, not overly complicated IMO.
If we start trying to "fix" by adding new stuff we just make MWO more of a beta and less of the polished fun game that we all hope for.
#118
Posted 08 November 2012 - 12:44 PM
Kmieciu, on 08 November 2012 - 10:56 AM, said:
</UpgradeType> <UpgradeType id="3003" name="StandardHeatSinkType"> <Loc nameTag="@StandardHeatSinkType" descTag="@StandardHeatSinkType_desc" iconTag="20"/> <UpgradeTypeStats type="2" slots="0" pointMultiplier="1.0" associatedItem="3000"/> </UpgradeType> <UpgradeType id="3002" name="DoubleHeatSinkType"> <Loc nameTag="@DoubleHeatSinkType" descTag="@DoubleHeatSinkType_desc" iconTag="19"/> <UpgradeTypeStats type="2" slots="0" pointMultiplier="2.0" associatedItem="3001"/> </UpgradeType>
So internal double heat sinks are still 2.0. Which is fair, since you`re paying 1 500 000 C-Bills for it.
<Module id="3000" name="HeatSink_MkI" CType="CHeatSinkStats"> <ModuleStats slots="1" tons="1" health="10"/> <Loc nameTag="@HeatSink_MkI" descTag="@HeatSink_MkI_desc" iconTag="3"/> <HeatSinkStats cooling="0.1" heatbase="-1.0"/> <EffectList> <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_a"/> </EffectList> <Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed"/> </Module> <Module id="3001" name="DoubleHeatSink_MkI" CType="CHeatSinkStats" DestroyedDialogue="BB_Mech_HeatSink_Destroyed"> <ModuleStats slots="3" tons="1" health="10"/> <Loc nameTag="@DoubleHeatSink_MkI" descTag="@DoubleHeatSink_MkI_desc" iconTag="2"/> <HeatSinkStats cooling="0.14" heatbase="-1.4"/> <EffectList> <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_a"/> </EffectList> <Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed"/>
External DHS are 1.4. So no ninja - changes to the heat sinks at this time! That makes me happy.
Yeah because you care %&%&%& on balancing.
#119
Posted 08 November 2012 - 12:56 PM
now lets whine ....
#120
Posted 08 November 2012 - 01:27 PM
Asesino, on 08 November 2012 - 12:37 PM, said:
Do you really think it would be better to add all of these elements/variables to heat management when we can´t even agree as to how much heat a DHS should dissipate? Heat management should be simple, not overly complicated IMO.
If we start trying to "fix" by adding new stuff we just make MWO more of a beta and less of the polished fun game that we all hope for.
I clearly stated in the text you quote that "Maybe if MWO becomes popular enough, these things can be included in a "hardcore" game mode." Clearly, these are (my attempt at) constructive suggestions for the long term, not demands for changes to the current heat system. Since it is obviously not my idea to ""fix" by adding new stuff," I can only assume that it is yours. In answer to your question, no, I think that your idea is a bad one.
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users