37 replies to this topic

[Fire and Salt]

As the guy who spins around 180 degrees in midair to alpha a dude in the face, I seriously want my weapons to converge on what I am pointing at, because targeting someone is tedious, and rangefinders exist even now in 2013..... Anyways, I've posted this before, but I think that it is a solution that deals with the problem without causing more or adding unrealistic, arbitrary penalties: What do you think?

Fire and Salt, on 14 July 2013 - 04:20 AM, said:

I have a suggestion that:

•Doesn't add an unrealistic heat penalty.
•Doesn't add any random factor that takes away from player skill.
•Would be fairly easy to implement
•Treats the "AC40 issue" identically to the "6PPC issue" because it doesn't rely on heat.
•Has a plausible physical explanation.
•Seems lore friendly. ("I have 6ML-and-1LL because 8ML magically makes extraheat... that doesn't make sense sorry.)


Here it is:
Whenever PlayerA does more than 20 damage to a specific panel of PlayerB within a half second window, some of that damage is transferred to adjacent sections. I recommend that all damage over 20 is dealt at 50% to the hit panel. So 40 damage = 20 + 10 to the hit panel and 10 elsewhere. This ONLY applies to armor. We will say that this happens because a very large impact places physical stress through the surface of the armor, and some of that stress is transferred to adjacent locations.
The limit of 20 is perfectly matched to the AC20 - the most powerful weapon in the game - which will place all of its damage into 1 location still - as long as they are fired one at a time (such as the individual dice rolls in the classic game)

Ex:
2PPC to CT - 20 damage to CT
3PPC to CT - 25 damage to CT, 2.5 damage to LT, 2.5 Damage to RT
4PPC to CT (Or 2 AC20s) - 30 damage to CT, 5 damage to LT, 5 Damage to RT
6PPC to CT - 40 damage to CT, 10 damage to LT, 10 damage to RT

Now this would only apply to armor - not to internals. Armor would transfer to nearby armor, but NOT to nearby internals. If the panel that it is supposed to transfer to is gone the damage stays where it hit. So lets say my LT is stripped of all armor, and do the same examples:
2PPC to CT - 20 damage to CT
3PPC to CT - 27.5 damage to CT, 0 damage to LT, 2.5 Damage to RT
4PPC to CT (Or 2 AC20s) - 35 damage to CT, 0 damage to LT, 5 Damage to RT
6PPC to CT - 50 damage to CT, 0 damage to LT, 10 damage to RT



I also recommend never damaging a panel to by more than 25% of its current health nor bring it below 5 total health (tunable numbers) with this transfer. Lets say there is a big crack in the LT - the force from a CT hit wont damage the portion to the left of the crack, only the portion to the right of the crack which is connected more solidly to the CT. For example:
A mech has 50 armor left on its CT, 40 left on its RT, and 10 left on its LT.

2PPC to CT - 20 damage to CT
3PPC to CT - 25 damage to CT, 2.5 damage to LT, 2.5 Damage to RT
4PPC to CT (Or 2 AC20s) - 32.5 damage to CT, 2.5 damage to LT, 5 Damage to RT
6PPC to CT - 47.5 damage to CT, 2.5 damage to LT, 10 damage to RT



Damage Transfer Panels:
CT: LT & RT (25% of extra each)
LT: CT (50% of extra)
RT: CT (50% of extra)
Rear CT: Rear LT & Rear RT (25% of extra each)
Rear LT: Rear CT (50% of extra)
Rear RT: Rear CT (50% of extra)
Head: does not apply since the head cannot have 20 points of armor.

Arms could be a special case - they are not connected by armor skin to any other panel, so the damage should not transfer to other armor. However, the stress might damage the internal structure. So lets say 50% of the extra can go to the internal structure, but never bring it below 25% of its TOTAL health (tunable number) How does this help? Well, the armor will protect the weapons from critical hits, but the internal structure simply holds the weapons. So if I have 40 points of arm armor, and you hit me with a 40 point alpha, it would be 20 + 10 damage to the Armor, and 10 damage to the internals. This way I have 10 armor and 10 internal left, instead of 0 armor and 20 internal left. It will now take at least 20 damage to destroy a weapon with 10 health, as opposed to just 10 damage as it is with the current system.


The legs could be similar to the arms, except that they would transfer 25% to their own internal structure, 10% to the corresponding torso, and 15% to the CT internals. The same safeguards would be in place to protect the "transferred to" locations - bearing in mind that this damage doesn't "disappear" - if it can't go elsewhere, it simply stays in the place that it's originally dealt to.

Edited by Fire and Salt, 14 July 2013 - 01:58 PM.

[malice]

I don't agree, necessarily. Here's why:

I think the current reticle behavior is fine, I think it is the behavior of the weapons themselves that should be changed first more if possible. I feel this is a safer approach to the current problem perceived issues with convergence and is more cost effective from a development and programming aspect.

Many proposed ideas sound very creative in nature so far, but usually fail to consider that PGI is a very small budget generally. Therefore, things like how much programming and software engineering is involved is a critical and top priority consideration before any realistic suggestion can be effectively sized up. This goes for everything really, not just this issue. The fact they have been so involved with community opinion and outreach is phenomenal and highly unappreciated, I believe, but that is a thread for another day...

Client-side hit detection or built in system like target-based convergence would definitely require substantial programming (usually the most expensive craft in video game development) to implement, so while I may like the idea in and of itself, I don't think this is a feasible answer, or effective to the problem vs the effort required.

I would rather see the natural behavior of pinpoint accuracy of the weapons themselves change, also that an actual game designer or tech artist could address the issue and be more suited for the role to balance as well (someone who's inherent role is a more creative position innately), instead of a programmer who may not have gameplay in mind or as high a priority as getting it to work.

[Lord of All]

Fire and Salt, on 14 July 2013 - 01:55 PM, said:

As the guy who spins around 180 degrees in midair to alpha a dude in the face, I seriously want my weapons to converge on what I am pointing at, because targeting someone is tedious, and rangefinders exist even now in 2013..... Anyways, I've posted this before, but I think that it is a solution that deals with the problem without causing more or adding unrealistic, arbitrary penalties: What do you think?

I think it's well thought out but I have an issue with just assigning arbitrary number like the "20" you suggest. I'm not quite sure why you think if you spin around and fire you will not hit with this idea and you most certainly will and if you have the target "Targeted" you will get pinpoint on ALL weapons where as If you don't Your primary weapon will still hit Exactly where you aimed it (would be 20 damage if it's an ac20). The others would just scatter around that point. But If you feel and I can see why you would want every weapon to hit pinpoint when close up then a solution may be for the scatter to be an a check basis for range.

What I mean by making the scatter for untargeted (not primary as it will hit exactly where your reticule is) is that say for the Max range of the weapon there will be a 1% chance for the "Converging: weapon" weapon to not scatter and at Min range (Added: By min range I mean zero distance not the max min range that is usually refereed to for figuring out damage range) there will be a 100% chance for that weapon to strike on convergence. What do you think of that Idea? I'm not too keen on it as I believe there is One targeting computer for all weapons and you must target what you want to hit. But this is a problem that should be as seamless as possible so I am not adverse to compromise. But the more "IF's" we build into the process the more complicated the code and as a result the more man hours and server load. I'm really trying to get a K.I.S.S. solution here. that is still logical and also based in Canon. A real tough problem at that!

malice, on 14 July 2013 - 02:29 PM, said:

I don't agree, necessarily. Here's why:

I think the current reticle behavior is fine, I think it is the behavior of the weapons themselves that should be changed first more if possible. I feel this is a safer approach to the current problem perceived issues with convergence and is more cost effective from a development and programming aspect.

I'm not sure what reticule behavior your talking about? The only suggestion I have on reticle is for it to turn green when you have a lock (just the circle). But that is not written in stone It's no deal breaker and really has no effect on this solution.

malice, on 14 July 2013 - 02:29 PM, said:

Many proposed ideas sound very creative in nature so far, but usually fail to consider that PGI is a very small budget generally. Therefore, things like how much programming and software engineering is involved is a critical and top priority consideration before any realistic suggestion can be effectively sized up. This goes for everything really, not just this issue. The fact they have been so involved with community opinion and outreach is phenomenal and highly unappreciated, I believe, but that is a thread for another day...

This is Exactly my argument here! This as the title states is a Simple and easily programmed convergence Idea. I have been programming since 1986 and have a CE degree. I do know what I'm talking about in this regard.

malice, on 14 July 2013 - 02:29 PM, said:

I would rather see the natural behavior of pinpoint accuracy of the weapons themselves change, also that an actual game designer or tech artist could address the issue and be more suited for the role to balance as well (someone who's inherent role is a more creative position innately), instead of a programmer who may not have gameplay in mind or as high a priority as getting it to work.

I agree but that would break the bank and is what you are arguing against in the above paragraph. Unfortunately we cannot have it both ways.

Thanks alot for your input guys I appreciate it and you opinions.

Edited to add what I mean By Min. range.

Edited by Lord of All, 14 July 2013 - 02:59 PM.

[Fire and Salt]

Lord of All, on 14 July 2013 - 02:55 PM, said:

I think it's well thought out but I have an issue with just assigning arbitrary number like the "20" you suggest.

I choose 20 because 20 is the maximum damage any weapon does in a single hit in the TT as well as this game - that way, there is no weapon that automatically spreads its damage - any weapon can be "pinpoint" as long as it is fired in a small enough group.

Lord of All, on 14 July 2013 - 02:55 PM, said:

I'm not quite sure why you think if you spin around and fire you will not hit with this idea and you most certainly will and if you have the target "Targeted" you will get pinpoint on ALL weapons where as If you don't Your primary weapon will still hit Exactly where you aimed it (would be 20 damage if it's an ac20). The others would just scatter around that point. But If you feel and I can see why you would want every weapon to hit pinpoint when close up then a solution may be for the scatter to be an a check basis for range.

How would I have him targeted if he is behind be? Even with the 360 targeting module this only works up to 200m.
FYI - I am referring to a 6ML Jenner or something similar - where I will be bobbing and weaving out of cover too much to keep a lock.

Edited by Fire and Salt, 14 July 2013 - 03:17 PM.

[Lord of All]

Fire and Salt, on 14 July 2013 - 03:07 PM, said:

I choose 20 because 20 is the maximum damage any weapon does in a single hit in the TT as well as this game - that way, there is no weapon that automatically spreads its damage - any weapon can be "pinpoint" as long as it is fired in a small enough group.

Well in this system that number would be the primary of whatever group your using. Makes a little more sense to me.

Fire and Salt, on 14 July 2013 - 03:07 PM, said:

How would I have him targeted if he is behind be? Even with the 360 targeting module this only works up to 200m.
FYI - I am referring to a 6ML Jenner or something similar - where I will be bobbing and weaving out of cover too much to keep a lock.

Advanced sensors and sensor decay modules.

[Fire and Salt]

Lord of All, on 14 July 2013 - 04:53 PM, said:

Advanced sensors and sensor decay modules.

How am I going to fit coolant pods? They aren't just for stalkers, ya' know. Lights tend to have energy heavy loadouts. I don't want to have to carry 3 targeting modules just so I can bob and weave without losing my target and my convergence going to crap. It is hard enough to aim as is when you're going 130kph...

[Lord of All]

Fire and Salt, on 14 July 2013 - 05:10 PM, said:

How am I going to fit coolant pods? They aren't just for stalkers, ya' know. Lights tend to have energy heavy loadouts. I don't want to have to carry 3 targeting modules just so I can bob and weave without losing my target and my convergence going to crap. It is hard enough to aim as is when you're going 130kph...

Yep tough loadout choice.

[Ken Fury]

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

I've thought a long time about any sort of "simple" solution. What I've found is that the easier the solution is to implement, the less solvency and more unintended effects it has. It's not a bad thought though, and I do wish they had an option to converge on targeted enemy range.

The easiest solution is to increase hitpoints and increase regular PPC heat to 9. This is enough to combat high alpha damage. Since the high Alpha Mechs will begin to run into the heat barrier earlier and thus their damage output drops. Allowing Brawlers a chance to get into their range band. Providing a natural counter to all long range teams.

[zinetwin]

I'm going to redirect this over here...
http://mwomercs.com/...s/page__st__580

The first page is Hobo's concept and page 30 has my additional input which I think may help to address your concerns. Just requiring a lock or actual targeting will not hurt snipers nearly as much as you think. Also, if you've noticed wherever your reticule is pointing it gives a range, which means that the mech and targeting computers know how far what you're pointing at is. Doesn't matter if it's a building or a mech, if you can see it, you have range and a firing solution.

The proposed solutions from Homeless (first page) and the stuff I threw in there (page 30) actually offer a solution to pinpoint damage, high alphas, and weapon convergence. Both are valid ideas to handling the problem.

Edited by zinetwin, 15 July 2013 - 12:07 AM.

[Lord of All]

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

I actually asked for this feature quite a while ago (convergence on target range instead of crosshair), and they said no =[

I like the simplicity, but here are a few things to consider:
ECM - This would be a game-changer. They'd have to re-think ECM or it would become the must-have again because it prevents convergence.

Not sure how I missed this post yesterday, sorry Bill. I wasn't aware this idea was already pitched. The closer to release the more imperative a solution be found and one that is easy to code and get out the door without a large lead time for testing (not like that ever stopped pgi from pushing something out that wasn;t tested properly )

AFA the ECM issue well if there is no spotter then the sniper better learn how to chain fire and then they will still get pinpoint as it will be the primary weapon everytime which will still pinpoint or even with scatter on the following weapons the target mech will still be wrecked, Maybe not cored as is happening now also if there is a light doing it's job then the sniper is still Gold. And the reason for ECM umbrella is to protect the Command center and it's support like AMS originally. I'm not sure why that was expanded in later BT as I quit playing it when they just kept releasing add-ons that made the previous releases under powered and worthless. Kind of like the model for all games now.

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

Brawlers vs Snipers - When I'm sniping, I often have time to take a couple of seconds and line up a shot. When I'm brawling, I'm basically just running through a crowd, shooting at everyone, cycling for weak targets. I think this approach ends up hurting brawlers more than snipers

When I'm brawling I get in a mechs face and crush it and most of my weapons are scattering anyway (LBX/SRM). And It's usually targeted anyway. Although yes sometimes I have another mech targeted for long range support but that is actually what is nice about this idea. I have to choose between pinpont for me or for the support in that instance. Remember with this suggestion shots will not miss because of non convergence. Also If you check a few posts back I explain a method where convergence can be adjusted for range that would make snap shot in close range still very effective and still pinpiont in a zero range situation still withing the framework of this method. But I am not really a proponent of doing that I can see that point of view and for the games sake would not argue against it.

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

Twitch Shooting - Even though a lot of people think it has no place in MechWarrior, I like rewarding that guy that can spin a 180 in mid-air and blow away some guy before he gits the ground. This implementation would effectively do away with it.

See above. This would also make module selection tougher. 360 degree targeting?

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

While it might be a slight improvement on the sniper side of things, its collateral effects scare me enough that it would need quite a bit of testing. I think it will end up really hurting brawlers.

I brawl almost exclusively, with that being I addressed this 2 above.

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

Effectiveness - It delays the pinpoint alpha strike, but it doesn't prevent it. In my 732, I fire with a full lock about 75% of the time.

That is not it's intent. If the enemy mech is stupid enough to give you time to get lock then he deserves what he gets. Bad piloting deserves repercussions. I'm not pitching this as a fix all solution just a small piece of the puzzle. Heat Is one other as you well know.

Homeless Bill, on 14 July 2013 - 01:09 PM, said:

I've thought a long time about any sort of "simple" solution. What I've found is that the easier the solution is to implement, the less solvency and more unintended effects it has. It's not a bad thought though, and I do wish they had an option to converge on targeted enemy range.

I completely agree. I just feel this will be easy and simple to implement in a short time, heck any decent programmer could throw this in in an afternoon. Tweaks can be added later as PGI is so fond of doing non-stop.

zinetwin, on 15 July 2013 - 12:01 AM, said:

I'm going to redirect this over here...
http://mwomercs.com/...s/page__st__580

The first page is Hobo's concept and page 30 has my additional input which I think may help to address your concerns. Just requiring a lock or actual targeting will not hurt snipers nearly as much as you think. Also, if you've noticed wherever your reticule is pointing it gives a range, which means that the mech and targeting computers know how far what you're pointing at is. Doesn't matter if it's a building or a mech, if you can see it, you have range and a firing solution.

The proposed solutions from Homeless (first page) and the stuff I threw in there (page 30) actually offer a solution to pinpoint damage, high alphas, and weapon convergence. Both are valid ideas to handling the problem.

Yup I started on that thread but realized there is no way PGI can accomplish that in the allotted time.

A rose of any other name... I read your post and it can be called anything the devs want but you are correct that is the issue and in needs to be solved for this game to be viable. As is now I see a massive flop after the initial "I got a giant Robot to stomp in" wears off and the masses see the massive holes we have all been trying to address.

I don't think PGI has the foresight to see how they are setting themselves up for failure. But that has been proven with this 3rd person malarkey.


Thanks alot for your guys Input, I appreciate it. I really have been a fan of the TT game since the 80's and have been disgusted with every single iteration of a mechwarrior game to date and was hoping this one would be the one finally! Unbelievable in the year 2013 we still cannot create a game correctly. Sometimes I'm ashamed to be a human. Yeah that was over the top but look around the world and your see my real point.

[Volthorne]

Lord of All, on 15 July 2013 - 07:51 AM, said:

See above. This would also make module selection tougher. 360 degree targeting?

The 360° module doesn't allow you to pick up locks behind you, it allows you to maintain them. BIG difference.

[malice]

Sorry - Talking about convergence in general, not necessarily the reticle/UI behavior.

And I'm not saying you don't know what you're talking about. It's not that I don't think it can be done, I think the idea being laid out is too costly for the current situation and may not be the most effective approach.

I don't agree that implementing a programming fix would be better than a design task. I do feel we can't have it both ways, but one is significantly cheaper than the other, which may be the difference between paper and practice when it comes to fixing this for PGI.

Either way, thanks for inviting me to the discussion.

Sorry I don't know how to quote sections. :[ lol

[Lord of All]

malice, on 15 July 2013 - 02:28 PM, said:

Sorry - Talking about convergence in general, not necessarily the reticle/UI behavior.

And I'm not saying you don't know what you're talking about. It's not that I don't think it can be done, I think the idea being laid out is too costly for the current situation and may not be the most effective approach.

I don't agree that implementing a programming fix would be better than a design task. I do feel we can't have it both ways, but one is significantly cheaper than the other, which may be the difference between paper and practice when it comes to fixing this for PGI.

Either way, thanks for inviting me to the discussion.

Sorry I don't know how to quote sections. :[ lol

NP. thx for the input.

[Lord of All]

One year bump for the hell of it.

[Valten]

I agree with others that I should not be punished for targeting one mech and shooting another. In the grand scheme of things the weapons are not so spread out that it would make a significant difference. To add the "realism" that you suggest the game would have to keep track of the angles that each weapon would have been taking from its point of origin to the target mech and deal damage based on that. PGI hasn't even been able to streamline the mechbay sufficiently to keep me from dropping to 1fps any time I change tabs, why on earth would you ask them to perform this level of complex calculation on the fly?

That said, if this feature were implemented then I would expect Clan Targeting Computers (But not the command console) to dramatically alter the modified convergence time such that a mark VII would nearly fully negate the effect.

[Lord of All]

Valten, on 08 July 2014 - 12:49 PM, said:

I agree with others that I should not be punished for targeting one mech and shooting another. In the grand scheme of things the weapons are not so spread out that it would make a significant difference. To add the "realism" that you suggest the game would have to keep track of the angles that each weapon would have been taking from its point of origin to the target mech and deal damage based on that. PGI hasn't even been able to streamline the mechbay sufficiently to keep me from dropping to 1fps any time I change tabs, why on earth would you ask them to perform this level of complex calculation on the fly?

That said, if this feature were implemented then I would expect Clan Targeting Computers (But not the command console) to dramatically alter the modified convergence time such that a mark VII would nearly fully negate the effect.

This thread was created as a quick and easy fix for convergence just prior to release as there was no time left to do the job correctly. The goal was to offer the DEV's a solution a 1 year programmer could implement that would bandaid the issue upon release so that the core issues could be addressed at a later time. but as usual PGI completely Ignored the core issues and look at the lack of players now because of their disregard of the warnings almost a year ago.

[Myke Pantera]

I like the idea, i really do. It will make pop-tarting harder, unless someone holds locks for you, but it will make ECM even more powerful and mandatory as it already is, so i still voted No.

Best suggestion about convergence so far though!

[Modo44]

This should be stickied somewhere. Repeating after Koniving: Implementing weapon convergence over time requires strict timing. Add HSR, and everyone's convergence speed becomes dependant -- in a linear fashion -- on ping because the server has to agree on it. Remove HSR -- make convergence client-authorized -- and you are in "everyone hacks with impunity" territory (i.e. instant convergence on demand). Lose-lose, no go. This is why it was removed, why the "Pinpoint" pilot skill does nothing, and why other mechanics were used.