199 replies to this topic

[Vassago Rain]

I like all these bandaid fixes.

[Widowmaker1981]

Mister D, on 18 July 2014 - 02:43 AM, said:

LRM lockon code is already in the game.

A simple Convergence setup can work exactly like the LRM lockon does NOW.

All hardpoints aiming dead ahead to infinity, once a selected target is within a FOV cone (so many degrees based on distance) the hardpoints start to come together, target moves out of FOV cone, Hardpoints slowly drift back to 0,

Im not saying its going to be a piece of cake, and it will take some sensible rebalancing of ECM, and maybe a couple modules.

But it can work with HSR, "IF" it gets done right.

Its definately a smarter decision than adding in all these wonky and convoluted work-arounds, you still end up with the same problem, and likely even more.

The autofocus that we have right now, is actually part of the problem, because you try to lead a target and its throwing off your convergence even worse, because you could be pointed at something 1000 meters away, could be 100, and it changes instantly so you never have a solid reference to where you can be aiming and put damage reliably on target while leading.

You have it stuck in your head that your weapons without convergence will be spraying all over hell like when you are holding down the JJ's and your weapon Hardpoints are doing the walleye vision thing each aiming at a different point offset by like 80 degrees from where you're aiming.

Thats not what Convergence needs to be, and not what I'm talking about at all.

The spread of 0 convergence "should" be simply each hardpoint aiming perfectly straight ahead, but none of them are focused to the dead center of your crosshair.

the initial thing you said is exactly how delayed convergence used to work, and wont combine in cryengine with HSR. (i.e. slowly converging on the aim point as opposed to instantly)

i dont see what thats got to do with LRM lockon, at all.

i was never suggesting that delayed convergence is a cone of fire.

please learn to read before replying.

Again, according to PGI they cannot make non-instant weapon convergence work with HSR

Edited by Widowmaker1981, 18 July 2014 - 03:19 AM.

[bluepiglet]

Gauss rifles will drain a lot energy to charge, and should be so in this game. It should disable all the heavy Energy weapons for a few seconds after being used. And if two gauss is used, both should charge more slowly before firing and Energy weapons disable further longer afterwards.

[Cyborne Elemental]

Widowmaker1981, on 18 July 2014 - 03:17 AM, said:

Again, according to PGI they cannot make non-instant weapon convergence work with HSR

Please explain then.

Because when it comes to code, there is no can not, only will not, or I don't know how.

Is it an engine limitation, something hardcoded?
Or simply lack of programming knowledge keeping it from happening, there is a difference.

Edited by Mister D, 18 July 2014 - 03:27 AM.

[Chemie]

so instead of a 60 alpha you will have a 30 alpha followed by a 30 alpha 0.5 seconds later? not sure that fixes what is broken.
(My example assumes you charge and fire 2xgauss and then fire off 2xCERPPC)

[Viges]

so 4 x c-lbx20 alphas ok?

[pwnface]

Chemie, on 18 July 2014 - 03:28 AM, said:

so instead of a 60 alpha you will have a 30 alpha followed by a 30 alpha 0.5 seconds later? not sure that fixes what is broken.
(My example assumes you charge and fire 2xgauss and then fire off 2xCERPPC)

It actually does fix the problem ( if you think there is one ), getting 50pts of damage in the same component cripples or outright kills most mechs. Getting hit with 30 + 20 + splash spread all over your mech is not nearly as bad. If you are standing perfectly still and let your enemy hit you in the same spot half a second later anyway, the effect would be the same, but that would kind of be your own fault for just standing there and getting shot. I think grouping gauss/ppc into their own weird group where you can't shoot more than two of either is a terrible idea. Allowing 3 is a slightly less terrible idea but might be the only way to balance the huge 50pt alpha strike of a Dire Whale.

[Widowmaker1981]

Mister D, on 18 July 2014 - 03:26 AM, said:

Please explain then.

Because when it comes to code, there is no can not, only will not, or I don't know how.

Is it an engine limitation, something hardcoded?
Or simply lack of programming knowledge keeping it from happening, there is a difference.

Since im not a software developer (mostly work in support. im good with networks and operating systems, have no clue when it comes to coding) i cannot explain. however they have said that, and since they put delayed convergence in to start with and then took it out when HSR was implemented, they obviously think it is a good thing, so i am inclined to believe them when they say it was removed for technical reasons.

regardless of whether *you* believe that or not, thats what they have said, so asking for it back is pointless. looking at other solutions is more productive.

Personally, if pinpoint accuracy with FLD weapons is too much of a problem, my preferred solution would be a (small) dynamic cone of fire, that gets larger with factors like movement speed and current heat level. Before people scream about RNG and randomness.. its NOT random if you are in control of the variables.. want a precise, pinpoint shot that goes precisely where you aim? stop moving, cool down and youve got it. want to be 100% precise when flying through the air at 100kph and almost melting down? tough, your vehicle cant handle it.

Edited by Widowmaker1981, 18 July 2014 - 04:10 AM.

[Thorn Hallis]

Viges, on 18 July 2014 - 03:33 AM, said:

so 4 x c-lbx20 alphas ok?

As they are no pinpoint alphas, yes.

[Kitane]

Thorn Hallis, on 18 July 2014 - 04:08 AM, said:

As they are no pinpoint alphas, yes.

Still enough to remove 2/3-3/4 of a combined CT+LT+RT front torso armor from a 50-60t mech with first alpha and finish the job with a second one...

[Livewyr]

soo... the only PP FLD alpha combination the clan can use to counter IS PP FLD alphas..

Interesting.


No.

[Malcolm Vordermark]

While this plan could work, I would much rather see Jager's suggestion of increasing all PPC recycle times. That would help with the Dire Wolf build and create more of a difference between the long range "sniping" weapons and the brawling weapons.

[Livewyr]

Mister D, on 18 July 2014 - 03:26 AM, said:

Please explain then.

Because when it comes to code, there is no can not, only will not, or I don't know how.

Is it an engine limitation, something hardcoded?
Or simply lack of programming knowledge keeping it from happening, there is a difference.

They *can* code non-instant convergence.. but here is the problem: (As I understand it from CBT)

Game is server authoritative in everything to reduce hacking. (Everything you do, the server authorizes, from moving, to aiming, to shooting.)

The calculations of constantly making minor adjustments to convergence rate provided too much for the server.
What we had:
Every time your crosshair changed range (essentially every time you move it) a new convergence point is created.
From that point weapon convergence would move (at a fixed rate, increased by the convergence efficiency) from the previous crosshair range, to the new one.
This convergence would be calculated for every single possible point of convergence between the old range, and the new range.

Essentially meaning: Every time you move, anything, the server would be doing countless calculations on your convergence: not just where your range was, and is now, but every range between the two.

This x 16 people at the time.

This caused 2 big problems:
1: Bad server lag issues. (Rubber banding, teleporting, and such)
2: Weapons never quite converging regardless of how long they were on target, for whatever reason. (PPCs were particularly notorious.)

-----------------
So they moved to: Where ever your range is, is where your convergence is. A tiny fraction of the calculations and server load.


This is my understanding of the devs' explanation for removing trained convergence back in CBT. (If a Dev would like to poke through with a more thorough/accurate explanation, that would be great.)

[wanderer]

Quote

I like all these bandaid fixes.

For all your PGI MWO balance needs.

[xXBagheeraXx]

Ursh, on 18 July 2014 - 01:23 AM, said:

I've seen you in enough games to confirm this. I don't mean that snarkily, just that I'm also an average player who solos a lot, so we end up in the same matches when your playtimes coincide. I'm the guy saying "gl, diaf" at the beginning of matches and "gg, diaf" at the end of matches. Win or lose, it's my belief that people can always find time to go die in a fire.

How Do I shot mech? xD

[xXBagheeraXx]

Livewyr, on 18 July 2014 - 05:09 AM, said:

They *can* code non-instant convergence.. but here is the problem: (As I understand it from CBT)

Game is server authoritative in everything to reduce hacking. (Everything you do, the server authorizes, from moving, to aiming, to shooting.)

The calculations of constantly making minor adjustments to convergence rate provided too much for the server.
What we had:
Every time your crosshair changed range (essentially every time you move it) a new convergence point is created.
From that point weapon convergence would move (at a fixed rate, increased by the convergence efficiency) from the previous crosshair range, to the new one.
This convergence would be calculated for every single possible point of convergence between the old range, and the new range.

Essentially meaning: Every time you move, anything, the server would be doing countless calculations on your convergence: not just where your range was, and is now, but every range between the two.

This x 16 people at the time.

This caused 2 big problems:
1: Bad server lag issues. (Rubber banding, teleporting, and such)
2: Weapons never quite converging regardless of how long they were on target, for whatever reason. (PPCs were particularly notorious.)

-----------------
So they moved to: Where ever your range is, is where your convergence is. A tiny fraction of the calculations and server load.


This is my understanding of the devs' explanation for removing trained convergence back in CBT. (If a Dev would like to poke through with a more thorough/accurate explanation, that would be great.)

I never knew this. Interesting.

Here is an Idea tho. and something i wanted to post, but cant figure out a way to make shiney little pictures to illustrate.

What about A MINIMUM convergence? What I mean by this is "long range" problem weapons like the ppc and the gauss rifles can have a range at which they no longer converge any closer. Like say at 300 meters the weapons wont converge any closer so that atlas that you were ct coring at 400 meters? Now your arm mounted ppcs are hitting his left and right torso. Lasers and autocannons can either have different minimum convergences, or none at all. all this can be tweaked by a weapon by weapon basis. I dont supposed that would cause too much server lag would it? IT wouldnt be consonantly calculating, it would just check the range. If you were under your weapons minimum convergence, your convergence range was set at a static range. You can break up long range pin poing high alpha builds by giving them different min ranges that will make it much more profitable to close distance with these builds, while keeping them dangerous at long range as they should be.

[Damocles69]

Ghost delay?

Let's just drive ghost mechs in a ghost game on ghost computers

[OneEyed Jack]

Just what we need. More moronic, senseless, and useless nerfs so that the whiney little ******* can move on to look for something else to whine about for awhile, and so that the few whiney little twitch-monkey ******* who actually still think instant pin-point convergence in a game with hit locations is a good idea don't get upset.

FFS, PGI, stop with the bullshit, senseless, illogical, magical-hand-wavey nerfs, fix the real god-damned problem, and let the "I want my shots to go where I aim" crybabies deal with it!

Non-instant convergence, CoF (I damned well know the code can handle that), successful hits applied to random locations (you already have the code for streaks). There are numerous ways it could be accomplished, but these ridiculous nerfs you keep using to avoid the real issue are getting out of hand. Ghost Heat, Gauss charging that for some reason can't be done during the cooldown and capacitors that dump their charge for no logical reason, and now power limits on a fusion reactor that could power a small city? Fix the real problem, and quit pussyfooting around. The vast majority of your players will thank you, and you just might be able to build a balanced game.

Why the hell is it that PGI is willing to piss off every other player in the game with dumb idea after dumb idea to dance around fixing a single, solitary issue, but is so scared to anger the few holdout twerps still clinging to pinpoint convergence?

[Kmieciu]

Since PGI is unable to tweak weapon convergence and does not want to add any random cone of fire, global cool down for pinpoint weapons seems like the next best idea.

Either that, or putting Gauss in the same ghost heat penalty group as PPC. That would mean a heat increase for 2xPPC+Gauss from 21 to 42.6 heat and 2xERPPC+Gauss from 31 to 57.15 heat.

[Livewyr]

Kmieciu, on 18 July 2014 - 05:58 AM, said:

Since PGI is unable to tweak weapon convergence and does not want to add any random cone of fire, global cool down for pinpoint weapons seems like the next best idea.

Either that, or putting Gauss in the same ghost heat penalty group as PPC. That would mean a heat increase for 2xPPC+Gauss from 21 to 42.6 heat and 2xERPPC+Gauss from 31 to 57.15 heat.

Even easier.. Increase the weapon CDs on Gauss, PPC, and ERPPC. (They already shoot the farthest of the FLD weapons.. and on top of that, have the same RoF as short range weapons..)

(6-8 seconds should do it)

If you want to only shoot every 6-8 seconds, bring a PPC/Gauss boat.. if you would also like to shoot faster, bring some different weapons..