209 replies to this topic

[Greeve]

Awesome Idea!!!

[El Bandito]

wanderer, on 14 September 2015 - 11:00 AM, said:

Can't change the title- that's a mod thing, IIRC.

Yes you can. Just edit you post and choose "Use full editor". Also, PGI better balance ECM before they even consider this proposal. Cause ECM will be real hax under this mechanic.

Edited by El Bandito, 14 September 2015 - 11:53 PM.

[GreyNovember]

Issue.

Suppose it converges at the target's range if you're locked on.

We define the targets's range as the range given to us by the lockbox. This is most likley the center of mass of the model; or the feet as a pivot point, from experience handling models and importing them into a game.

Not all of a target's parts are at the given range.

Your solution would mean our convergence is on the CT; making targeting side torsos and arms harder.

[Livewyr]

Sounds like a great idea on the surface... but how does ECM play into this?

I can assume it won't work like it does now (or the Raven and ACH will be godly on a level we've not seen).
But how will it work? If disrupts the locking even a little bit, it would be worth it's weight in Gold.

I believe the simplicity was false advertising.

[Sadist Cain]

Wouldn't this be a lot more efficient code wide also?

Just thinking that at the moment convergence for weaponry has to be calculated dynamically for every mech in the game. So it stands to reason there is constant math relating to the rangefinder and the trig required to get all hardpoints to aim on that point. Wouldn't that mean for every time the range changes on the crosshair there's code that must run?

However with this new system mechs who are unlocked have their convergence point fixed, ergo very minimal math as a result. Mechs who are locked on to a target will only have to have calculations running for the distance between the targetted mech and the offensive mech.
Saves the engine having to worry about converging at 5m then 500m then 20m then 1200m etc.

If anything wouldn't this make Hit reg work more efficiently?

[Spurowny]

Nice idea, but I'm betting making it work with HSR (the reason we have instant convergence) takes it off the options table.

[TheCharlatan]

I must admit this is a great idea.

P.S.: ECM needs to be nerfed if this even has to be considered.

Edited by TheCharlatan, 15 September 2015 - 05:51 AM.

[Hans Von Lohman]

Spurowny, on 15 September 2015 - 05:44 AM, said:

Nice idea, but I'm betting making it work with HSR (the reason we have instant convergence) takes it off the options table.

It still would be instant convergence. This idea changes nothing.

Right now your convergence is set by what is under your gunsight (there is a range readout in the corner of the reticle). It constantly changes as you pan around and look at different terrain, or enemy mechs. It already sets the convergence instantly as you look at nearby things and far away things.

We're just asking for that to be removed. Instead your convergence needs to only be two choices. Your current target's range, or infinity if you don't have a target.

Yeah, it sounds weird. We're actually asking for mechs to become worse at shooting than they currently are, but the idea is to promote lock-ons as an important thing to have, and this is the best, simplest idea to get "information warfare" and scouting to become a real thing.

[Iqfish]

Bump because this needs to happen

[StandingInFire]

This is a great idea, simple yet effective.

Unlike most the other proposals it is simple to explain and intuitive so it would be new player friendly as well and encourage everyone to lock on targets.

[Solahma]

Wow, this is a fantastic compromise between the playerbase that is for an against the current convergence of weapons. It adds value to information gathering and target locks. It would actually make this infotech stuff worthwhile and add a lot of depth to combat that is much needed from the current point/click shooter many claim MWO to be.

Excellent simple idea man. We really need this to happen in the next PTS.

PGI PLS

[GreyNovember]

Sadist Cain, on 15 September 2015 - 03:46 AM, said:

Wouldn't this be a lot more efficient code wide also?

Just thinking that at the moment convergence for weaponry has to be calculated dynamically for every mech in the game. So it stands to reason there is constant math relating to the rangefinder and the trig required to get all hardpoints to aim on that point. Wouldn't that mean for every time the range changes on the crosshair there's code that must run?

However with this new system mechs who are unlocked have their convergence point fixed, ergo very minimal math as a result. Mechs who are locked on to a target will only have to have calculations running for the distance between the targetted mech and the offensive mech.
Saves the engine having to worry about converging at 5m then 500m then 20m then 1200m etc.

If anything wouldn't this make Hit reg work more efficiently?

I think you might have it mixed up.

Hit reg doesn't exactly need your exact aim point.

All it needs to know is x projectile was being fired with x Vector, or x beam was active from this origin point, pointing towards this point, with a given beam distance.

There also isn't that much of a calculation apart from "Have the part that looks like it shoots not move, and emit the necessary effects so it looks like it travels properly to the reticule." This isn't too different from the weapon points being parented on a body. They just now all look at the same point as an added line.

At least, that's how I'd do it.

[rook]

This is a great idea.

I agree that ECM will have to be revamped; you could use ECM to 1. only effect lock-on weapons outside of some range (like 150m) and 2. ECM blocks all info sharing for enemies if within that rage (like 150m)

[Talorien]

Hans Von Lohman, on 14 September 2015 - 02:48 PM, said:

Easy. Just make ECM work into information warfare as well. Make the ECM coverage field a lock on delay feature instead of a lock on prevention feature.

This makes perfect sense!

[Alexander Garden]

Need to move this over to the re-balance sub-forum.

[SpiralFace]

I do like the idea, but I think its:

1: not new player friendly
2: makes ECM and info warfare in general WAY too powerful because its absolutely necessary.
3: I can only believe a lot of programming on the dev side to get it working.

Would be nice to see, but not all encompassing.

[Hobo Dan]

I like the idea.

[Queen of England]

I like this idea. OP: I think you can add a poll to this now that it's in the PTS forum.

[pyrocomp]

Beeing a good idea as it is, it still isn't nearly a solution to the information warfare. This merely forces players to hit 'R' button without adding any other or just any value to the information itself. E.g. you still don't need scouts. Pity.

[wanderer]

Quote

1: not new player friendly
2: makes ECM and info warfare in general WAY too powerful because its absolutely necessary.
3: I can only believe a lot of programming on the dev side to get it working.

1) About 2 minutes in the new PTS tutorial. Less. It already tells you to press "R" to target, right?
2a) Just as needed as the other 3 pillars they're building 'Mechs on. Information is -supposed- to be needed.
2b) I'd like to see ECM swapped to a "makes target effectively "further away" for sensor range purposes" rather than "blanks all sensor readings" and it's "distancing" effect be a % of the 'Mechs own detection range (so lighter 'Mechs will generally benefit more from ECM).
3) Not even that. It actually simplifies convergence- instead of dynamically updating it as you sweep across multiple ranges, you'd have your "unlocked" convergence or your "locked" convergence. This gives you an "iron sights" mode that'll predictably fire with no lock and something very much like the current norm when locked and firing at said locked target. The only oddity will be firing at another target while locked on another one- in which case, you're going to either want to swap locks, unlock and fire "iron sights", or deal with the resulting damage spread (depending on how close/far the secondary target is relative to the locked on).