12 replies to this topic

[Navid A1]

Some time ago PGI introduced rate of heat loss quirks on some small mechs to compensate for their lack of dissipation due to them, not benefiting from 10 true double heatsinks in their small engines.

However, Those quirks does not seem to work at all.

To test this out, I fitted a kitfox, a mist lynx and a jenner IIC with a single ERPPC. Each of those mechs had 7 engine DHS and 6 external DHS. All unskilled.

Out of those three mechs, the jenner IIC does not have any quirks, while the other 2 have 15% rate of heat loss quirk tied to their CT pod. Also, none of those mechs have any quirks regarding weapon cooldowns.

One would expect the Kitfox and Lynx to dissipate heat more quickly compared to the jenner IIC. But private lobby tests on Canyon Network (as a map no heat offset) shows that all three dissipate the same amount of heat during weapon cooldown.



The mechs stats are:

• 
  Base Heat capacity: 30 + 7 * 2 + 6 * 1.5 = 53.
  
• 
  Base Heat dissipation: 7 * 0.2 + 6 * 0.15 = 2.3 h/s

Test: hold down trigger for a single ERPPC (14.5 heat and 4.5s cooldown)

• 
  Heat after first fire: 14.5 ( 14.5/53 = 27% on heat bar)
  
• 
  Heat after second fire: 14.5 - 2.3 * 4.5 + 14.5 = 18.65 (35%)
  
• 
  Heat after third fire: 18.65 - 2.3 * 4.5 +14.5 = 22.8 (43%)

Those results exactly match what you'll see in-game as well.



I don't know if this was caused by the skill tree or not, since I did not test this before the skill tree. I also did not test this with IS mechs (such as urbie).

Would appreciate it if anyone else can confirm this. If true, this is really really messed up!



I also noticed that newer mechs like the Cougar have "heat dissipation" quirk instead of the old "rate of heat loss". I have not tested the cougar yet, but I think that the old quirk was supposed to be replaced and PGI forgot to update those older mechs.



Can we have a dev response?

Edited by Navid A1, 20 November 2017 - 12:44 AM.

[Jay Leon Hart]

Navid A1, on 20 November 2017 - 12:44 AM, said:

Some time ago PGI introduced rate of heat loss quirks on some small mechs to compensate for their lack of dissipation due to them, not benefiting from 10 true double heatsinks in their small engines.

However, Those quirks does not seem to work at all.

I also noticed that newer mechs like the Cougar have "heat dissipation" quirk instead of the old "rate of heat loss". I have not tested the cougar yet, but I think that the old quirk was supposed to be replaced and PGI forgot to update those older mechs.

I just tested a JR7-IIC-A, KFX-G & COU-E with 1 ERPPC & varying levels of DHS.

The JR7 had a STD 180.
KFK had OmniPods swapped to remove any cooldown bonus.
COU has the issue that every CT has a 5% cooldown quirk. I could have compensated for this by giving the others 4.8% cooldown with the Skill Tree, but didn't want to waste he SP.

I started at 14(7) DHS, where they were all heat neutral when firing on Forest Colony. I then removed 1 DHS per test.
The JR7 started to accumulate heat at 11(7).
The KFX started to accumulate heat at 11(7) also, suggesting the quirk is indeed broken.
The COU started to accumulate heat at 10(7), even with the cooldown quirk, suggesting it's quirk is working.

[Davegt27]

need to put this in that problem tracker/issue tracker


https://github.com/M...t%3Acreated-asc

up vote

https://github.com/M...Upvote-An-Issue

[Tarogato]

Crossposting from reddit:


Okay, did my own testing, and can confirm the findings in the OP.

I took a Kitfox to Canyon Network, in a private lobby with The Lighthouse, and recorded how long it took to cool from 90% heat down to 10% heat. I measured the elapsed time in a video editor, using frame count. Then I took a Hunchback IIC with the same configuration of 7 TruDubs + 3 PoorDubs and did the same thing.


- Kitfox with 15% rate of heat loss quirk: ~21.13 seconds to cool 80% of capacity
- Notafox with no rate of heat loss quirk: ~21.18 seconds to cool 80% of capacity

- Theoretical/expected time according to maths, no quirk: 20.97 seconds
- Theoretical/expected time according to maths, 15% quirk: 18.22 seconds

---

Interesting that I still got a real world value on the server that is 1% worse than the theoretical value. This is what I found also in a completely unrelated test. I'm pretty sure that when you play online, on servers, it takes 1% longer for your mech to cool off, always. It takes 1% longer than training grounds, which I tested earlier, and it takes 1% longer than theoretical calculated "proper" value, which I just verified here.

Shjt's broke yo.

Davegt27, on 20 November 2017 - 04:08 AM, said:

need to put this in that problem tracker/issue tracker
https://github.com/M...t%3Acreated-asc
up vote
https://github.com/M...Upvote-An-Issue

Shouldn't be necessary. This is a pretty big, but likely simple bug, I'm sure Chris will deal with it in time for December patch.

Edited by Tarogato, 20 November 2017 - 04:23 AM.

[Spheroid]

Did the old quirk ever function correctly? I am at a loss why they would create a duplicate quirk if the old one worked as intended.

Edited by Spheroid, 20 November 2017 - 09:29 AM.

[FupDup]

Navid A1, on 20 November 2017 - 12:44 AM, said:

• 
  Base Heat capacity: 30 + 7 * 2 + 6 * 1.5 = 53.

I just want to point out here that engine sinks have the same capacity as external sinks (1.5). When viewing the XML entries for all kinds of heatsinks you see attributes for cooling, engine cooling, and heatbase (capacity), but no mention of multiple capacity types (thus all of them must be the same cap by definition).

<Module id="3004" name="ClanDoubleHeatSink" CType="CHeatSinkStats" faction="Clan">
    <ModuleStats slots="2" tons="1" health="5" />
    <Loc nameTag="@CDoubleHeatSink_MkI" descTag="@CDoubleHeatSink_MkI_desc" iconTag="StoreIcons\ClanDoubleHeatSink.dds"/>
    <HeatSinkStats cooling="0.15" engineCooling="0.2" heatbase="-1.5" />
    <EffectList>
	  <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_double_a" />
    </EffectList>
    <Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed" />
  </Module>

[Navid A1]

FupDup, on 20 November 2017 - 12:46 PM, said:

I just want to point out here that engine sinks have the same capacity as external sinks (1.5). When viewing the XML entries for all kinds of heatsinks you see attributes for cooling, engine cooling, and heatbase (capacity), but no mention of multiple capacity types (thus all of them must be the same cap by definition).

<Module id="3004" name="ClanDoubleHeatSink" CType="CHeatSinkStats" faction="Clan">
	<ModuleStats slots="2" tons="1" health="5" />
	<Loc nameTag="@CDoubleHeatSink_MkI" descTag="@CDoubleHeatSink_MkI_desc" iconTag="StoreIcons\ClanDoubleHeatSink.dds"/>
	<HeatSinkStats cooling="0.15" engineCooling="0.2" heatbase="-1.5" />
	<EffectList>
	  <Effect name="SteamEffect" asset="mech_effects.heatsinks.steam_double_a" />
	</EffectList>
	<Audio OnDestroyedDialogue="BB_Mech_HeatSink_Destroyed" />
  </Module>

Thats what I was assuming at first. But tests showed that engine double heatsinks have indeed 2 heat capacity

[Tarogato]

FupDup, on 20 November 2017 - 12:46 PM, said:

I just want to point out here that engine sinks have the same capacity as external sinks (1.5). When viewing the XML entries for all kinds of heatsinks you see attributes for cooling, engine cooling, and heatbase (capacity), but no mention of multiple capacity types (thus all of them must be the same cap by definition).

Navid A1, on 20 November 2017 - 06:48 PM, said:

Thats what I was assuming at first. But tests showed that engine double heatsinks have indeed 2 heat capacity

I noticed the same thing. TruDubs indeed have 2.0 capacity.

If they didn't, then the tests I ran here would not have have checked out as closely as they did.

[FupDup]

Tarogato, on 20 November 2017 - 07:23 PM, said:

I noticed the same thing. TruDubs indeed have 2.0 capacity.

If they didn't, then the tests I ran here would not have have checked out as closely as they did.

Then that raises the question of where that bit of coding might lie, because logically it would be in there with the other heatsink stats.

[Natred]

They said they "fixed' this like 3 or 4 months ago if I remember right. I noticed this with a bunch of other mechs to the same affect.

[Paigan]

Spheroid, on 20 November 2017 - 09:29 AM, said:

Did the old quirk ever function correctly? I am at a loss why they would create a duplicate quirk if the old one worked as intended.

You assume (as I would, too) that they have some nicely designed data structure where there's one quirk defined and then just assigned to certain Mechs.
The reality will probably be more something along the line that, at least partly, every Mech requires copy & pasting of code and/or XML stuff, manual adjustments, etc. that should actually be a centralized, nicely structured and abstracted concept, but sadly isn't. The reason behind such hacks is always the same: there was initially not enough time to design a proper structure, then there came extensions and they had to be squeezed in with not enough time and afterwards, there's never enough time to overhaul stuff properly (something like 3 years for MWO, without delivering new content in that time), so the software is stuck forever with crappy improvised kludges that make maintaining it and extending it even more a nightmare and terribly error-prone.

For example: On some maps, closing the tactical map sets the speed to 0, on some maps it doesn't. This shows that what is actually the same logic must be (at least partly) be coded redundantly in every map. Game logic for steering the Mech(!) in a MAP(!). Unbelievable, isn't it?
Behavior like that is a definite indicator for badly written code (and yes, I know what I am talking about, I studied computer science and develop software for 10 years now. ultra crappy code is the rule out there, not the exception).

I guess the same applies to quirks.
This in turn means: I assume that every quirk on every Mech can "break" at any time (= with any change), however insignificant and unrelated it might seem. Someone changes a piece of code with crazy dependencies to some other part, someone makes a tiny oversight in some manual editing (fun fact: in MW2, the Battlemaster could be secretly activated as a playable Mech, but could still not be played because someone wrote "batllemaster" in the MW2.exe) and BAM, something is broken, but only for one particular combination (e.g. one quirk for one Mech).

TL;DR: bad code is bad.

Edited by Paigan, 21 November 2017 - 01:08 AM.

[Jun Watarase]

I remember testing this with the KFX-D before and the time to cool i got was pretty similar to what it should be, but its possible that the difference was so minor that measurig error accounting for it.

Edit : Just tested again with the KF-D, it should take me 5.9s to cooldown from firing 4x SRM-6s, but on forest colony it took me about 6.4s.

Edited by Jun Watarase, 21 November 2017 - 08:56 AM.

[Mcgral18]

FupDup, on 20 November 2017 - 07:31 PM, said:

Then that raises the question of where that bit of coding might lie, because logically it would be in there with the other heatsink stats.

Not all the little details are listed in the XML
They don't need to be
It can be a different variable with the Engine, behind hidden variables.
Or just a baseline DHS upgrade bonus
Numbers are numbers, it doesn't particularly matter how they're calculated (as multipliers are always after the sum)

Other hidden numbers which come to mind are missile related. You see mentions of them in the XML (tracking strength, Artemis bonuses and similar), but not actually listed in the Weapon stats.



If only we had a MWOwiki to explain these little details...but not everyone can be so concerned about the little details