510 replies to this topic

[Yokomohoyo]

Void Angel, on 11 July 2014 - 03:05 PM, said:

What you're describing is mostly a first-person version of Mechwarrior:Tactics, but with arbitrary firing restrictions and some weapons ignoring a staple of Battletech games - the firing arc. That's not the kind of game this is, and asking for the game to be remade isn't going to get you very far. Also, your proposition would not in fact make buffed Clan weaponry competetive with the Inner Sphere - and even if it did, the only IS 'Mechs that would be balanced would have to equip Stealth Armor. That's not balanced, and customization is another staple of Battletech games.

I am bringing the 21^st century technology of missiles with no firing arc, computerized target tracking while moving, rotating weapons and the appropriate zoom for a weapon to MechWarrior Online which desperately needs to get out of the past. Wikipedia quote “The U.S. Navy now relies exclusively on VLS for its guided missile destroyers and cruisers”. The U.S. Navy gets the technology of VLS missiles that have no firing arc first but in time the missiles will be compact enough for all military vehicles, just like guided missiles have completely replace unguided missiles in all military vehicles for combat against vehicles. Unfortunately MechWarrior Online still uses the obsolete unguided missiles. As a side note I would like to point out that the railgun (Gauss Rifle) is coming to the U.S. Navy first in the Zumwalt-class destroyer and it will be powered by its engine not by the railgun’s power generator. The M1 Abrams has computerized target tracking that can keep its weapons locked on target and fire accurately while moving even with the incredible shake caused by its tracks. MechWarrior Online desperately needs this kind of technology that would justify the randomness of the hits in the canon. The typical firing arc in the canon is 90° front, right, left, back. I would simplify the firing arc by giving the ability to rotate to the weapons just like in most military vehicles and making the firing arc 120° front (horizontal and vertical), 75° right, 75° left, 90° back. With this simplification I would eliminate the firing to the right or left side by weapons in the arms because it is not properly used in MechWarrior Online but if they can get it to work properly then by all means keep it. To my knowledge there is no sniping weapon that does not have the appropriate zoom for the range of the weapon yet in MechWarrior Online there is no control over the advanced zoom and it does not provide for all weapon ranges. All these are buffs are needed to bring MechWarrior Online out of the past and as a side effect balance jump sniping with the other playstyles.

I did not say I wanted to make Clan weaponry competitive with the Inner Sphere. I want to make Inner Sphere mechs competitive with Clan mechs and there is a big difference between weapons being competitive and mechs being competitive. What you have now in MechWarrior Online is the equivalent of socialism where everyone is equally nerfed into mediocrity. I want Clan mechs weapons to be superior to Inner Sphere weapons but Inner Sphere equipment superior to Clan equipment. Inner Sphere’s superior equipment like Hatchet, Stealth Armor, Bloodhound Active Probe, Angel ECM Suite, Triple Strength Myomer, etc. makes them superior at close combat. Then add Inner Sphere’s ELRM to make them superior at extreme ranges. All this would make two completely different factions instead of two equally mediocre factions like we have now. The Inner Sphere faction would dominate close combat and extreme range. The Clan faction would dominate medium and long range.

As a final note I would like to add that making BattleMechs more tank-like is a fiasco because mechs have a skeleton, have muscles, can talk, can walk, can run, can jump, can kick, can punch, can hit you over the head with a hatchet if they disagree with you, they go to sleep when they are tired and when they get mad they explode in anger. If BattleMechs were more human-like they would have to be humans. Unfortunately MechWarrior Online has eliminated all of the human features that mechs have for the human-like combat which is where Inner Sphere excels and instead has concentrated in the tank-like combat of mechs which is where Clans excels. To make matters worse PGI intends to eliminate the human-like jumping of mechs that is crucial for Inner Sphere’s close combat dominance. Nerfing is not the solution it is the root of all evil.

[wanderer]

Void Angel, on 10 July 2014 - 05:18 PM, said:

Read it again; you skimmed over an important detail - I wonder what else you missed?

Which rulesets, and how can you say a ruleset for a completely different game is an authoritative reference for how MWO is "supposed to be?"

You might also want to brush up on the Battletech tabletop rules. Yes, Jumping shots were harder, but you only had a one higher attacker modifier than if you had Run.

That's actually if you'd jumped and LANDED, THEN fired. Firing in midair is quite different, and even a specific example in the rules.



^ Tactical Operations, pg. 86

A poptart shot in tabletop is an astonishingly huge +6 to hit- and mind you, that's before any target modifiers from the target itself. That, BTW for the non dice-chuckers means that at best range on a stationary target, the average pilot has to roll a 10 on two six-sided dice to hit.

Being able to snipe accurately in midair is utterly dysfunctional in game terms.

[wanderer]

Vincent Lynch, on 12 July 2014 - 03:33 AM, said:

Quote: "Table Top (TT) rules add 3 heat instantaneously upon using any number of Jump Jets."

WRONG. That rule existed in 90's TT but was scrapped years (perhaps a decade) ago.

Double wrong- standard jump jets add one heat per MP, but a -minimum- of 3 heat even if you expend less than 3 MP. And that's how it's been since the 90's.

[Void Angel]

YueFei, on 11 July 2014 - 11:54 PM, said:

I don't think any JJ nerf will effectively nerf Jump Sniping, unless the JJ nerf is extremely severe and crippling to JJs. Because Jump Snipers only need to jump about waist-height. On a mech that's 16 meters tall, you only need to jump 8 meters.

If JJs are nerfed so that you can't even jump waist-height, then JJs will be extremely gimped. You wouldn't even be able to perform a DFA against an opponent on the same elevation.

I've given an example of jump shooting where it's not overpowered... that is, jump shooting with lasers. In fact, jump shooting with lasers is probably *worse* than just doing a berm-drill laser shot, because of the necessity of jumping significantly higher in order to have time to squeeze off the 1 second laser burn during the free fall (when reticule is stable).

If anything I'd rather see the weapon mechanics of PP FLD loadouts addressed directly, ala Homeless Bill's proposed system.

Any change, including this one, that increases the heat, tonnage, and/or vulnerability to return fire of a jump-firing 'Mech will nerf the tactic. I'm sure a fully-equipped, jet-capable 'Mech will still be able to jump snipe - but consider: because the height for those jets is lower, while the time taken to reach it is the same, those 'Mechs are going to be easier targets for return fire than they are right now, while suffering significantly reduced heat efficiency. That's a nerf, any way you slice it. It's not going to eliminate the viability of jump-firing, but they don't want to do that - nor do I want them to.

Vincent Lynch, on 12 July 2014 - 03:33 AM, said:

Quote: "Table Top (TT) rules add 3 heat instantaneously upon using any number of Jump Jets."

WRONG. That rule existed in 90's TT but was scrapped years (perhaps a decade) ago.
Current TT rule is 1 heat point per hex of distance covered.
This means, jump jet heat increases linearly with NO "base value".
Should be the same way in MWO: A full burn with 3 JJs should produce the same heat as a "half burn" jump with 6 JJs.
And a full jump with 6 JJs should produce exactly twice as much heat as a full jump with 3 JJs.
I repeat: NO base value.
Please PGI don't make a "canon" rule that has been invalid in canon for about 10 years now!

wanderer, on 12 July 2014 - 05:51 AM, said:

Double wrong- standard jump jets add one heat per MP, but a -minimum- of 3 heat even if you expend less than 3 MP. And that's how it's been since the 90's.

In either case, PGI isn't using the 3-minimum tabletop rule - because it would be clumsy and inappropriate in this game format. =)

wanderer, on 12 July 2014 - 05:42 AM, said:

That's actually if you'd jumped and LANDED, THEN fired. Firing in midair is quite different, and even a specific example in the rules.

A poptart shot in tabletop is an astonishingly huge +6 to hit- and mind you, that's before any target modifiers from the target itself. That, BTW for the non dice-chuckers means that at best range on a stationary target, the average pilot has to roll a 10 on two six-sided dice to hit.

Being able to snipe accurately in midair is utterly dysfunctional in game terms.

And for the real non dice-chuckers, rolling that 10 or higher would have only a 16.7% chance of hitting the target. Even an easily-achieved +2 (defensive) target modifier to that target number would drop the chance down to a mere 2.8% - making such a shot a huge gamble.

However, the rules you're citing aren't for jump firing as it is commonly practiced in MWO, but for taking a snap shot where the enemy has absolutely no means to respond using the standard turn order (though if I recall, there are corresponding Overwatch rules as well.) The inability of the enemy to respond is the reason for the extreme limitations imposed for Opportunity Fire in that instance. Now, I used the Standard Battletech rules in my earlier example for simplicity's sake, but Level Three rules allow a jumping 'Mech to fire (and receive fire) from any Hex it passed through (Tactical Handbook, p49.) The 'mech does forgo one point of its target modifier for jumping, increasing the enemy's target number by +2 instead of +3, and still retains its own +3 attacker modifier.

Thus, while the tabletop rules are authoritative only as a starting point for MWO solutions (which is how the devs are using them,) they do not make all jump-firing insanely difficult, as those who cite the tabletop rules to criticize poptarts often suggest. Now, I'm sure you'll note that there's a small disparity in accuracy in those rules (+3 to hit v. +2 to be hit,) and I think implementing that small inaccuracy would be a beneficial adaptation of the tabletop rules to MWO - which is why my dream solution to jump-firing includes a slight reticle judder (almost a vibration) any time a 'mech was off the ground. However, a disparity in accuracy is not the only way to balance jump-firing, and the changes we're discussing are going to be a help.

PS: Do you have PDF files of your tabletop rulebooks, or is there a reference site you're getting those images from? It'd be much more convenient to look up rules on my computer rather than dig my old manuals out from the closet every time I need to research tabletop (i.e. check my memory.)

[YueFei]

Void Angel, on 12 July 2014 - 07:46 AM, said:

Any change, including this one, that increases the heat, tonnage, and/or vulnerability to return fire of a jump-firing 'Mech will nerf the tactic. I'm sure a fully-equipped, jet-capable 'Mech will still be able to jump snipe - but consider: because the height for those jets is lower, while the time taken to reach it is the same, those 'Mechs are going to be easier targets for return fire than they are right now, while suffering significantly reduced heat efficiency. That's a nerf, any way you slice it. It's not going to eliminate the viability of jump-firing, but they don't want to do that - nor do I want them to.

Yes, but my concern is it will more badly nerf a jumping laser boat even more than the typical jump sniper. If you make JJs ascent half as fast as they are now, that jumping laser boat would need to be exposed for 5 seconds instead of 3 seconds. Every additional bit of exposure time adds to the danger of more enemies turning to focus fire you.

Tweaks to JJs are welcome, but without addressing the core weapon mechanics, we're still faced with the problem that PP FLD is a superior damage application mechanism, both offensively (all damage into one spot dealt at once) and defensively (can maneuver immediately after firing the shot). If downsides were to accompany that mechanism to balance it out, such as increased cooldown, inability to sustain (with a lower heat cap), etc., it might be better balanced.

[FireDog]

Some guys like to pilot their mechs... and rather not have their sports cars get nerfed back to model T Fords. The game is definetly losing fans that like to pilot with all these heavy handed nerfs... My Jester is going to be totally useless soon at this rate.

Edited by FireDog, 12 July 2014 - 02:59 PM.

[Batch1972]

i think you need to tone down the falling damage. lights are hard enough as it is without the additional leg damage from running

[Lefty Lucy]

Batch1972, on 13 July 2014 - 01:31 AM, said:

i think you need to tone down the falling damage. lights are hard enough as it is without the additional leg damage from running

Seriously. I run 4/5 jets on my Jenner, and I already feel like a fat kid on crutches trying to get up stairs, and even if I reserve half my fuel the jets just don't have enough power to keep me from snapping my own legs off.

PGI says they want jump jets to be tools to increase mobility, but they're nerfing their ability to do exactly that.

Ugh, it's the ******* 3 second jenner all over again.

[Threat Doc]

PGI, I don't know whether or not this will help you, but the chatter in TeamSpeak has been a bit more positive of late, even from some of my naysayer friends. Keep up the good work, folks.

[Void Angel]

YueFei, on 12 July 2014 - 12:04 PM, said:

Yes, but my concern is it will more badly nerf a jumping laser boat even more than the typical jump sniper. If you make JJs ascent half as fast as they are now, that jumping laser boat would need to be exposed for 5 seconds instead of 3 seconds. Every additional bit of exposure time adds to the danger of more enemies turning to focus fire you.

Tweaks to JJs are welcome, but without addressing the core weapon mechanics, we're still faced with the problem that PP FLD is a superior damage application mechanism, both offensively (all damage into one spot dealt at once) and defensively (can maneuver immediately after firing the shot). If downsides were to accompany that mechanism to balance it out, such as increased cooldown, inability to sustain (with a lower heat cap), etc., it might be better balanced.

The problem is that you're conflating two parts of the issue, while asking a change to only one part of the issue to address all parts directly. Jump-fired lasers shouldn't be affected more than jump-fired PPCs - they're both affected by jump jet mechanics, but jumping affects pinpoint damage weapons more, because it mitigates the risks incurred by their long cooldown cycles and higher heat. The the weapon imbalance problem is with pinpoint damage weapons being disproportionally powerful due to the benefits of that damage type -current jump jet implementation exacerbates this, but is not a root cause.

Now, pinpoint damage weapons could stand some balancing - they're not the only viable weapons, but they are clearly the best choice if you have the tonnage and space. Yet it's important to note that pinpoint damage guns already have built-in limitations as opposed to other weapons. The PPC, for example, has a 1.00 damage/heat ratio, but the Large Laser's ratio is 1.29. That's almost 30% more damage for the same amount of heat (and therefore sustainability) as opposed to a PPC - the poster child for pinpoint weaponry. Of course, the drawbacks of beam duration is currently balancing that out, with a bit to spare, but that's a relative weapon balance issue, not a jump jet problem.

What is a jump jet problem is the jets' capability of repeatedly hopping up just over cover to rail(gun) enemies with a short enough exposure that return fire - particularly non-pinpoint return fire - is of disproportionally limited effectiveness. This change will help that, in a way that should be pretty minor for the people who rely on jump jets to get around - like Jenners and Gryphons - while significantly impairing the sustainability and risk-evasion of poptart tactics. Current word from the dev's internal testing is that jump jet use won't overheat you - but it will counterbalance most or all of your cooling. That is a huge component of jump-firing tactics: since you can just drop behind cover and wait for your guns to cool, you don't have to take that pesky risk of being murdered while you overheat nearly so often as other players.

In the final analysis, jump jets have become an agility tool, rather than a mobility tool. You can use them in myriad ways to gain advantages over your ground-bound enemies that are not commensurate with the tonnage you invested, or the risks involved with the jets' use. That needs to change, and this change can easily do that. We still need a solution to the disparity in weapon types, but that can be solved simply by tweaking the numbers for weapon cooldowns, damage, heat, et cetera - once jump jets aren't making the problem situationally worse.

Edited by Void Angel, 13 July 2014 - 09:00 AM.

[SethAbercromby]

Koniving, on 09 July 2014 - 03:37 AM, said:

[snip]

...What the **** is going on with PGI and "instant" bullshit? Everything in gravity accelerates and decelerates. It's not oh you hit your jumpjets and suddenly you're going 9 f/s from a 64 f/s fall. NO! You slow down, going -30, -28, -24, -16, -8, 0, +2, +8..

So why are we instantly falling at 30 f/s? Why is 64 f/s ultra rare? Why is it like ghost heat, completely inconsistent? That's where the REAL problem with fall damage rests.
(Edit: Fall damage doesn't seem to scale with distance fallen, either. A long fall or a short fall at the same speed still causes identical damage.)

It's kind of amazing to mess up something as basic as gravity. To prove how even an idiot can implement gravity, here's a mock code as written by an idiot (ie me).

if (isGrounded == false)
{

if (JJActive == true)

{

fallspeed += ((JJcount * JJthrust) - localGravity) * deltaTime;

}

else if (fallspeed > terminalVelocity)

{

fallspeed += localGravity * deltaTime;

if (fallspeed < terminalVelocity)

{

fallspeed = terminalVelocity;

}

}

}

See, was that so hard? Hey PGI, wanna hire me to fix your code?

EDIT:
Okay, using the Code command does not allow for indenation and messes up fromatting. Good to know.

Edited by SethAbercromby, 13 July 2014 - 09:05 AM.

[Void Angel]

... Why would fall damage scale with distance, rather than speed? Impact energy is 1/2 mass x velocity²

I'd also be willing to guess that it's more effective to approach coding from the standpoint of combat advantage and game utility rather than a faithful emulation of physics. You can have faster game development and better game balance, or things like meticulously accurate acceleration curves for jumping and falling - pick one; you don't get to complain about the other.

[SethAbercromby]

Void Angel, on 13 July 2014 - 09:27 AM, said:

... Why would fall damage scale with distance, rather than speed? Impact energy is 1/2 mass x velocity²

I'd also be willing to guess that it's more effective to approach coding from the standpoint of combat advantage and game utility rather than a faithful emulation of physics. You can have faster game development and better game balance, or things like meticulously accurate acceleration curves for jumping and falling - pick one; you don't get to complain about the other.

See the code above? It's the most common and simplest implementation of emulating an evironment with a certain gavitational accelaration. It doesn't consider things like air resistance and the likes that true physics have to consider, but is close enough as an approximation.

EDIT:
Oh yeah, damage could for example be implemented as

damage = tonnage * (fallspeed/terminalVelocity) * 0.5;

What that means is that a 'Mech can suffer up to half of its weight in fall damage based on how fast it is falling in relation of its terminalVelocity.

Edited by SethAbercromby, 13 July 2014 - 09:46 AM.

[Koniving]

Truth be told, I think the game accelerates falling far too quickly. You get the same damage for falling 3 meters as you do for falling 200 meters...

Now that the game does have accelerating ascension and falls it's a bit better. But if I can fall 500 meters and receive the same damage at 3 meters... sure there is the same speed involved; but what this also tells me is that the game has 1) has some kind of fall speed/ascent speed cap that can be used to exploit long falls, and 2) the acceleration of falls is NOT consistent.

Here's an example. Take a Spider 12V and go on Alpine to any of the high mountains with a steep drop off.
First test, run down. Multiple encounters of minor drops resulting in fall damage.
Second test, leap as high into the air as possible and allow yourself to fall.

In the second test you will actually receive less damage.
Unless PGI can competently fix that issue... I do believe that some sort of distance factor should be applied as a temporary measure.

[YueFei]

Void Angel, on 13 July 2014 - 09:27 AM, said:

... Why would fall damage scale with distance, rather than speed? Impact energy is 1/2 mass x velocity²

I'd also be willing to guess that it's more effective to approach coding from the standpoint of combat advantage and game utility rather than a faithful emulation of physics. You can have faster game development and better game balance, or things like meticulously accurate acceleration curves for jumping and falling - pick one; you don't get to complain about the other.

It's actually easier to scale based on velocity squared, that way the server doesn't have to track the mech's historical trajectory to remember what his highest altitude on a particular jump/drop was.

Velocity will naturally increase as a mech accelerates on the fall, and naturally will scale properly with fall height. If you fall twice the distance, your velocity squared will quadruple.

Koniving, on 13 July 2014 - 10:35 AM, said:

Truth be told, I think the game accelerates falling far too quickly. You get the same damage for falling 3 meters as you do for falling 200 meters...

Now that the game does have accelerating ascension and falls it's a bit better. But if I can fall 500 meters and receive the same damage at 3 meters... sure there is the same speed involved; but what this also tells me is that the game has 1) has some kind of fall speed/ascent speed cap that can be used to exploit long falls, and 2) the acceleration of falls is NOT consistent.

Here's an example. Take a Spider 12V and go on Alpine to any of the high mountains with a steep drop off.
First test, run down. Multiple encounters of minor drops resulting in fall damage.
Second test, leap as high into the air as possible and allow yourself to fall.

In the second test you will actually receive less damage.
Unless PGI can competently fix that issue... I do believe that some sort of distance factor should be applied as a temporary measure.

What this tells us is that the fall damage is not scaling properly. It is probably scaling with velocity linearly. It should scale with fall velocity *squared*. That way, one giant fall will completely wreck you. But many smaller falls will accumulate less damage.

[Koniving]

Honestly the fastest I've fallen is 67 f/s.

Doesn't seem to matter how long I've spent falling; even when it comes to the eternal falls of falling out of the map.

But some falls barely long enough to reach up half of a Cicada's leg will spike you to 30 f/s.

[YueFei]

Void Angel, on 13 July 2014 - 08:55 AM, said:

The problem is that you're conflating two parts of the issue, while asking a change to only one part of the issue to address all parts directly. Jump-fired lasers shouldn't be affected more than jump-fired PPCs - they're both affected by jump jet mechanics, but jumping affects pinpoint damage weapons more, because it mitigates the risks incurred by their long cooldown cycles and higher heat. The the weapon imbalance problem is with pinpoint damage weapons being disproportionally powerful due to the benefits of that damage type -current jump jet implementation exacerbates this, but is not a root cause.

Yes, jumping is a way to get a shot off in as little time as possible, superior to doing a berm-drill because hill climb mechanics make it difficult to cleanly do a berm drill quickly. And the wonky physics of MWO jump jets makes the jump happen very quickly. I'd welcome tweaks to JJs, but I also don't want to see it go overboard where JJs ascend and descend super slowly. I mean, I'm fine if ascent/descent is slow with only 1 or 2 JJs... but to strap on 5 or more JJs should give massive boosts.

Right now, whether you have 1 JJ or 7 JJs, you instantly reach an initial ascent speed of about 2 meters/sec, and for whatever reason a mech seems to instantly gain 3+ meters of height from the jump animation. I think reigning that in will help a lot.

On the other hand, once JJs are engaged, they don't really accelerate your ascent speed. You go instantly to an ascent speed of 2 meters/sec, and then even as you hold your JJs for several seconds, it only gradually increases to 2.3, then 2.6, and finally struggles to reach 3 meters/sec. That's not how rockets work. I'd rather see it work by actually gradually accelerating a mech, starting from 0 meters/sec ascent speed.

So, that removes the instantly emergence from JJs instantly launching you up a short distance. Yet it would also make it possible to still make gigantic leaps, you just have to lean on the JJs longer and gradually build up ascent speed.

Basically, I'd be happy if a mech with only 1 or 2 JJs has really crappy jumping performance, like a mech strapping in a small engine has crappy speed and acceleration.

But I'd also want to see mechs that invest 5+ JJs to still jump well.

[Void Angel]

I'm confident that they will jump well. The trouble is that currently jump jets work a bit too well for most chassis. Even leaving aside jump-firing, many skilled pilots will use jump jets to spread or avoid damage to an extent that's not really warranted by their investment in tonnage and space. I've lost track of the number of jump snipers who've used their jets to negate my torso weapons completely by jumping up farther than I can track (or sometimes see,) negating the higher heat/damage cost of their weapons by cooling in the air - and still shooting at me with their AC/5s. I've been in situations in Terra Therma where jump jetting was far less heat-intensive than the environment, too. These changes will help with that.

My trouble with "that's now how Technology X works!" arguments is that you are swallowing a camel and straining out a gnat. We are surrounded by that sort of thing in MWO, starting with the BattleMechs themselves. 'Mech's internal structures, as described in the flavor text, wouldn't be able to support their weight, much less combat stresses; LRMs do no damage within arming range, despite being rockets, but a machine gun will damage armor just fine, while a relativistic stream of charged particles will miraculously have no effect if you're within 90m of its origin; not only should lasers be invisible on HPG Manifold, it should be the hottest map! And almost invariably, you can generate a pseudotechnical explanation for objections along this vein:

"Heat Scale penalties are caused by local overloading of the heat management system, leading to inefficiencies that are perceived as "extra" heat from firing too many of certain weapon classes at once.""The initial burst of jump acceleration is caused by a burst of the maximum pressure in the jump jets assisted by the 'Mech's leg actuators; as the jump proceeds, the reaction mass tank loses pressure, accounting for the curve of actually reduced acceleration during jumps. Design limitations prevent the tanks from re-pressurizing, while the jump maneuvering vents - which allow stabilization and attitude changes - are open."

Of course, one could easily generate a technical, or pseudotechnical, objection, but then we're back to straining at a gnat - because giant robots. Flipping out over "PGI's instant bull ****" is unhelpful and logically inconsistent - far better to talk about the primary focus of all game mechanics: balance.

YueFei, on 13 July 2014 - 10:40 AM, said:

It's actually easier to scale based on velocity squared, that way the server doesn't have to track the mech's historical trajectory to remember what his highest altitude on a particular jump/drop was.

What this tells us is that the fall damage is not scaling properly. It is probably scaling with velocity linearly. It should scale with fall velocity *squared*. That way, one giant fall will completely wreck you. But many smaller falls will accumulate less damage.

Which would be fine with me - I haven't done as much playing with Jump Jets as I normally do with the current game environment; I'll have to drag out my Spider. Still, however the game is calculating fall velocity, it shouldn't hurt to apply one more math step when determining damage.

I guess the point I'm trying to make is that it's better for everyone if PGI uses their small staff to work on keeping their accelerated development pace than spending time setting up meticulously accurate game physics (ten will get you 20 that the fall rates are out-of-the-box from CryEngine, and not a deliberate choice.) Sure the amount of extra effort required would be measured in small increments - but when the budget is tight, it's the little increments adding up that kills you.

[YueFei]

Void Angel, on 13 July 2014 - 12:03 PM, said:

I'm confident that they will jump well. The trouble is that currently jump jets work a bit too well for most chassis. Even leaving aside jump-firing, many skilled pilots will use jump jets to spread or avoid damage to an extent that's not really warranted by their investment in tonnage and space. I've lost track of the number of jump snipers who've used their jets to negate my torso weapons completely by jumping up farther than I can track (or sometimes see,) negating the higher heat/damage cost of their weapons by cooling in the air - and still shooting at me with their AC/5s. I've been in situations in Terra Therma where jump jetting was far less heat-intensive than the environment, too. These changes will help with that.

My trouble with "that's now how Technology X works!" arguments is that you are swallowing a camel and straining out a gnat. We are surrounded by that sort of thing in MWO, starting with the BattleMechs themselves. 'Mech's internal structures, as described in the flavor text, wouldn't be able to support their weight, much less combat stresses; LRMs do no damage within arming range, despite being rockets, but a machine gun will damage armor just fine, while a relativistic stream of charged particles will miraculously have no effect if you're within 90m of its origin; not only should lasers be invisible on HPG Manifold, it should be the hottest map! And almost invariably, you can generate a pseudotechnical explanation for objections along this vein:

"Heat Scale penalties are caused by local overloading of the heat management system, leading to inefficiencies that are perceived as "extra" heat from firing too many of certain weapon classes at once.""The initial burst of jump acceleration is caused by a burst of the maximum pressure in the jump jets assisted by the 'Mech's leg actuators; as the jump proceeds, the reaction mass tank loses pressure, accounting for the curve of actually reduced acceleration during jumps. Design limitations prevent the tanks from re-pressurizing, while the jump maneuvering vents - which allow stabilization and attitude changes - are open."

Of course, one could easily generate a technical, or pseudotechnical, objection, but then we're back to straining at a gnat - because giant robots. Flipping out over "PGI's instant bull ****" is unhelpful and logically inconsistent - far better to talk about the primary focus of all game mechanics: balance.

That's a fair point you make about game balance trumping physics, but in this case I think having JJs adhering to physics would help the gameplay. You'd no longer have that massive initial leap. In fact, with 1 or 2 JJs, you might get a terrible ascent acceleration of like 1 meter/sec^2. It would take you 4 seconds at that rate of ascent acceleration to clear 8 meters for a jump shot, for example.

Or you could shove 5 JJs in and get 3 meter/sec^2. 5 JJs are not an insignificant investment. It'd take you over 2 seconds to jump clear for a jump shot. Still longer than it currently takes for a jump shot.

Quote

Which would be fine with me - I haven't done as much playing with Jump Jets as I normally do with the current game environment; I'll have to drag out my Spider. Still, however the game is calculating fall velocity, it shouldn't hurt to apply one more math step when determining damage.

I guess the point I'm trying to make is that it's better for everyone if PGI uses their small staff to work on keeping their accelerated development pace than spending time setting up meticulously accurate game physics (ten will get you 20 that the fall rates are out-of-the-box from CryEngine, and not a deliberate choice.) Sure the amount of extra effort required would be measured in small increments - but when the budget is tight, it's the little increments adding up that kills you.

Trying to figure out fall height adds work and complexity, and it's really not needed. The equation really only needs to look at the fall speed at moment of impact. That makes it simpler and easier to implement. Then, to compute the damage from the fall, just square the velocity.

[SethAbercromby]

I do agree that linear accaleration should be properly implemented, both with gravitational accaleration on a drop and with JJs on an ascent, but I think we should be careful of getting too overly specific with the physics. Again reffering to my code above, that's how you usually want to implement it, because it is very simple for the server to calculate. And that is a very important thing because the server has to do the calculations for thausands of players playing at the same time. It makes managing calculation simple enough to keep up with all the clients waiting for the server to respond with the new data while still being close enough to reality. Unless, of couse, that's exactly what you were referring to.

Considering damage, I don't think either of us has the right answer how to compute damage. My solution above was to be taken as an example of how to get the tonnage of the 'mech into the equation, rather than having set damage values across all 'Mechs as that is a huge benefit to Assaults while crippling for a number of Lights..