2
Thinking about ghost heat in general, I have always wondered howcome it's not more "normalized". Why does 3x cLPL creat ghost heat but not 2x cLPL+6xcERML? That just doesn't compute...
What I am thinking of has been touched upon before, for example here (http://mwomercs.com/...-voltage-meter/), probably other Places but I don't have time to seach more carefully right now. I am sure this is not a New idea, just mashing up my take on it here. Not to replace ghost heat, but more to "normalize" it and make it more intuitive.
NOTE: This is Energy only, LRM/SRM heat and AC ghost heat is not regulated by this. Imo other systems would do that job better, like redesigning launcher tubes counts and game mechanics for missiles and perhaps recoil or something along these lines for ACs if needed at all. IMO high weight limits AC abuse sufficiently and I don't really have any problem at all with missile spam. Perhaps ghost spraed, lol?
This could be done in two fashions, but both requires a New metric. I would Call it "Energy Bandwidth" or "Effect capacity" or something like that. What it describes is actually the Ghost Heat Threshold With a nicer name.
1. The simple implementation
Just take the weapons fired Within the same 0.5s tick, like the engine does now, but instead of counting weapons, add up the heat generated. Some examples:
2x cLPL: 20 heat
3x cLPL: 30 heat
2x cLPL+2 cERML: 32 heat
2x CLPL+4 cERML: 44 heat
3x LPL: 21 heat
3x LPL+4x ML: 37 heat
Rationale: The intuitive exlanation would be that the mech can only efficiently handle a certain bandwidth of energy before it starts to accumulate heat in an exponential manner. I.e. up to the Energy Bandwith of the mech it builds linearly like non-ghost-heat does now, but passing that point, the curve goes exponential, giving you a "ghost heat". It would work exacly as it does now, but you could fire any combination of weapons and they would all contribute to the bandwidth.
HUD: PGI would have to add a bandwidth meter to the HUD to make this intuitive.
Balance: Here's a nice twist with this, PGI could use Energy Bandwidth as a balance parameter that is independent of Lore and Stock builds. As a "quirk", without actually being a quirk, some chassi could be made to tolerate higher alphas, like for example I am thinking Awesomes could be made to tolerate 3x PPC without inventing some curious exception rules to ghost heat. You'd just give it a higher Energy Bandwidth, like perhaps 32 instead of 28.
Classes: PGI could choose to give difference classes different thresholds.
Engines: Another alternative would be linking it to the engine installed. Not sure if its a good idea or not, but some Awesomes and Battlemasters would benefit, and DWF alpha would be hurt... just an option, probably not the best idea.
Exponential heat: Just to illustrate, the exponent would work something like this: Our test Timberwolf fires 2x cLPL and builds 20 heat. That is below the threshold of 28 and produces no ghost heat. If he also fires his 4 cMLs within 0.5s, he pushes up the sum to 44 heat within the same 0.5s tick and goes above the threshold. The engines uses an equation and calculates that the resulting heat is say 56 instead of 44. By using a single exponential of any combination of weapons you miss out on the ability to punish ghost heat more on some weapons than others, but it becomes much more intuitive.
Edit: something like this depending how you choose your equation. This is a simple y=x+((x-EB<0)?0:(x-y)^exp), or y=x+(above_threshold^exp) where you can choose threshold and exponent.
Predicted Implications:
- Large laser vomit alphas go down and TTK goes up.
- Ghost heat becomes more intuitive and a physical basis could be made up
- A new balance parameter is created that is not restricted by Lore or Stock builds
- Tuning is needed
2. The advanced implementation
This methods is a bit more "realistic" and something I'd like a lot, but I guess less likely to ever be implemented.
The idea would be to instead of using "heat" as input, it would instead use "effect" as input, i.e. heat/duration for lasers, heat/0.5s tick for flamers, and heat/cooldown for PPCs, and a charge effect for gauss while holding charge (this number should be quite big and just added to effect output).
This effect value would then be added up, but instead of using some arbitrary ticks of 0.5s, one would just keep track of all active beams and add up the effect the produce while active. To this value, one would add PPC and gauss recharge effects.
Values:
Name
C-ER LRG LASER 6,67
C-ER MED LASER 5,22
C-ER PPC 3,75
C-ER SML LASER 3,00
C-FLAMER 2,00
C-LRG PULSE LASER 8,93
C-MED PULSE LASER 7,06
C-SML PULSE LASER 4,00
ER LARGE LASER 6,40
ER PPC 3,75
FLAMER 2,00
LARGE LASER 7,00
LRG PULSE LASER 10,45
MED PULSE LASER 6,67
MEDIUM LASER 4,44
PPC 2,50
SMALL LASER 2,67
SML PULSE LASER 4,00
This would feel even more intuitive to me and would allow you to juggle the bandwidth even more depending on the beam durations.
Predicted implications:
- Same as above plus,
- PPC recharge and Gauss recharge can add some background effect
- It doesn't limit firing multiple PPCs which would need something added to it, but it does in a realistic way make it a bit more difficult to charge gauss while burning lasers. Will increase TTK a bit more since Gauss better be fired before lasers and not simultaneously.
That's a very crude draft, running out of time here. I am sure I am like the 32nd guy proposing something along these lines, so perhaps I should not consider it a suggestion as much as a question why we don't have something along these lines? There must be some major flaw I didn't see yet...
Kids awake, time to go.
Edited by Duke Nedo, 03 August 2015 - 06:38 AM.
