195 replies to this topic

[Madw0lf]

Wanted to kind of recap some of the finer points Ive made but missed in my first post.

Both ideas have factors which are heavily influenced by the players actions. For a decently skilled player, both options would be able to provide pin-point, hit whatever you aim at accuracy, it just wouldnt be instant, despite any other variables. You really REALLY want to hit that LT? Lock target/hold reticle on, slow down, wait, shoot. All factors in your control.

The general idea is also to keep load increases on the connections and servers to a minimum.

[nehebkau]

Guys,
Playing with arm locking, and targeting reticules is not going solve your pin-point damage issues, not in the least. You are simply going to add another mechanic that the min-max/meta/uber players will find a way around and the rest of us will be hurt by.

Remember how jump-jet vibration was supposed to solve some issues? Didn't work too well, did it.

I know my 'magic energy dissipating armor' seems hokey, but its' far more fair -- if you have armor it should protect you. While I admit the implementation would need some work (like if you have no armor over an area that area takes normal damage), the idea of having a maximum damage per second to a specific piece of armor, having excess damage 'bleed over' is not bad for the game. It would mean players live longer, battles last longer. It also treats the mech as a whole unit rather than individual parts in the same way that modern cars are designed to react as 1 unit in a crash, spreading damage out through the entire car -- decreasing the energy experienced by the car's occupants.

In simple terms, if you hit an atlas' chest with 1 ac 20, that CT takes 20 damage. if you hit with 2 AC20s, you do, just as an example, say 30 pts(max armor damage per second) to the ct and 5 pts to each side. If, within a second, two of you hit the same atlas with 4 AC20s, ct gets 30 pts(max) and each side gets 25 pts(max) of damage. Of course, if your atlas stands in the middle of an entire lance and they blast his CT with, say 8 AC 20s all at once you may end up with (this is damage to the armor -- non armored areas take normal damage):
30 CT(max) damage, 25(max) r-torso damage, 25(max) l-torso damage 20 r-arm damage, 20 l-arm damage, 20 r-leg damage, 20 l-leg damage. (this is just an example and I didn't figure in rear armors ok?) Maybe the maximum damage allowed per second values change by mech weight class, or armor amount or armor type -- just saying that something like this is done in the back-end and doesn't really affect players playing balanced mechs.

Yes, sadly a lance wouldn't have taken the atlas down in under a second in the example above, it would probably have taken 2 or 3 seconds. But at least the atlas pilot would have had a chance to do something -- even if it was only to say 'AWWW FUDGE!' before they died.

Guys, this is in "practical terms", the same mechanic that fast-moving light mechs have now when facing energy weapons -- just applied across the spectrum of mechs. It's time to stop thinking with our 20th century minds by looking at armor as a big piece of metal strapped to a body party and think about what would be possible in a period of FTL ships, stompy-stompy, ray-gun shootin' giant robots.

Edited by nehebkau, 20 February 2014 - 07:55 AM.

[Madw0lf]

nehebkau, on 20 February 2014 - 07:53 AM, said:

Guys,
Playing with arm locking, and targeting reticules is not going solve your pin-point damage issues, not in the least. You are simply going to add another mechanic that the min-max/meta/uber players will find a way around and the rest of us will be hurt by.

Remember how jump-jet vibration was supposed to solve some issues? Didn't work too well, did it.

I know my 'magic energy dissipating armor' seems hokey, but its' far more fair -- if you have armor it should protect you. While I admit the implementation would need some work (like if you have no armor over an area that area takes normal damage), the idea of having a maximum damage per second to a specific piece of armor, having excess damage 'bleed over' is not bad for the game. It would mean players live longer, battles last longer. It also treats the mech as a whole unit rather than individual parts in the same way that modern cars are designed to react as 1 unit in a crash, spreading damage out through the entire car -- decreasing the energy experienced by the car's occupants.

In simple terms, if you hit an atlas' chest with 1 ac 20, that CT takes 20 damage. if you hit with 2 AC20s, you do, just as an example, say 30 pts(max armor damage per second) to the ct and 5 pts to each side. If, within a second, two of you hit the same atlas with 4 AC20s, ct gets 30 pts(max) and each side gets 25 pts(max) of damage. Of course, if your atlas stands in the middle of an entire lance and they blast his CT with, say 8 AC 20s all at once you may end up with (this is damage to the armor -- non armored areas take normal damage):
30 CT(max) damage, 25(max) r-torso damage, 25(max) l-torso damage 20 r-arm damage, 20 l-arm damage, 20 r-leg damage, 20 l-leg damage. (this is just an example and I didn't figure in rear armors ok?) Maybe the maximum damage allowed per second values change by mech weight class, or armor amount or armor type -- just saying that something like this is done in the back-end and doesn't really affect players playing balanced mechs.

Yes, sadly a lance wouldn't have taken the atlas down in under a second in the example above, it would probably have taken 2 or 3 seconds. But at least the atlas pilot would have had a chance to do something -- even if it was only to say 'AWWW FUDGE!' before they died.

Guys, this is in "practical terms", the same mechanic that fast-moving light mechs have now when facing energy weapons -- just applied across the spectrum of mechs. It's time to stop thinking with our 20th century minds by looking at armor as a big piece of metal strapped to a body party and think about what would be possible in a period of FTL ships, stompy-stompy, ray-gun shootin' giant robots.

Actually a decent convergence mechanic like I suggested, wouldnt be able to be "gotten around", merely dealt with (with some decent trade offs as well)

And honestly, in your example, that Atlas SHOULD die after turning a corner into a lance of BoomJaegers.

[nehebkau]

Madw0lf, on 20 February 2014 - 08:30 AM, said:

Actually a decent convergence mechanic like I suggested, wouldnt be able to be "gotten around", merely dealt with (with some decent trade offs as well)

And honestly, in your example, that Atlas SHOULD die after turning a corner into a lance of BoomJaegers.

and he would die, just not in a split second -- more like 2 or 3 seconds.

Edited by nehebkau, 20 February 2014 - 08:43 AM.

[Madw0lf]

nehebkau, on 20 February 2014 - 08:32 AM, said:

and he would die, just not in a split second -- more like 2 or 3 seconds.

It just seems like an overly convouted mechanic to me. Why not just increase armor/internals HP?

[Zyllos]

Madw0lf, on 19 February 2014 - 05:59 AM, said:

I can see this one being quite controversial. In essence what we are doing here, is providing the effects of convergence, without putting the strain of calculating so many different weapons paths on the server (Which is, IIRC why PGI said they wouldnt be implementing convergence).

This is all I have to say about any comments made about having to place strain on weapon calculations on the server:

Lie...

Weapons are already calculated, individually, on their server, regardless if they converge or not. You can test this by getting extremely close to a mech and aim at the very edge of your target, then fire with a LA weapon and RT weapon.

You will notice that the arm will most likely hit but the RT will miss. This is because how the calculations for converging the weapons will produce slightly different results due to geometry. This means that each weapon is calculated individually.

If that is true, which I am almost certain it is, then weapons could fire in all different directions and it would place no extra strain on the server calculations that it does now.

The reason for this is because the trajectory of weapon fire is simply a call of starting point (based on mech, normalizing the animations to not be included in the server checks but still be calculated on the client for visuals only) and then a vector in the path of the weapon. After that initial call for weapon fire, the rest is done with update calls for each server tick.

The only thing that PGI could maybe be complaining about is that currently, the server has to match the client's ray trace to determine distance and cross hair point. They are afraid that if you want unique trajectories with weapons, you will have to include more ray traces, thus taking more performance hits. This is completely untrue and can easily be completed with a single ray trace, like the client/server does now.

Basically, the way I viewed weapons to work is in the following manner:

• Initial ray trace for current tick on the server (to determine where the cross hair is pointed and it's distance).
  
• Include offset from cross hair/player perspective to location perspective of where the weapon is located.
  
• Include offset from weapon location perspective to individual weapon location perspective.
  
• Include mechanic offset for destabilizing aim (cone of fire, moving convergence, whatever).

Basically, what this means is that when someone fires a weapon, you use the initial ray trace as a hypotenuse, then using the (x,y,z) position from the ray trace initial start and player perspective to the physical weapon location on the mech. Having the hypotenuse and the distance from the player's perspective to the weapon location, you can easily use trigonometry to calculate the angle in which the weapon should be fired.

With this, you can calculate the vector of the weapon, and knowing the initial mounted point of the weapon, use the weapon fire function call with the calculated vector and initial weapon mount.

The nice thing about this is all of these values are static. You know the distance to where the cross hair is aiming by the ray trace and you know the distance and angle from the player's perspective to the weapon mount in question. And each of these is already known for each frame of animations for the visual calculations for the client (the server most likely doesn't take into account the exact frame the player was in when firing for determining firing paths, but it easily could do this).

The only hard calculation is the vector to put into the weapon fire call, which can be calculated by these above static values.

This is why I do not agree with PGI's stance that having multiple weapon paths leads to more server calculations.

[Madw0lf]

Zyllos, on 20 February 2014 - 08:54 AM, said:

This is all I have to say about any comments made about having to place strain on weapon calculations on the server:

Lie...

Weapons are already calculated, individually, on their server, regardless if they converge or not. You can test this by getting extremely close to a mech and aim at the very edge of your target, then fire with a LA weapon and RT weapon.

You will notice that the arm will most likely hit but the RT will miss. This is because how the calculations for converging the weapons will produce slightly different results due to geometry. This means that each weapon is calculated individually.

If that is true, which I am almost certain it is, then weapons could fire in all different directions and it would place no extra strain on the server calculations that it does now.

The reason for this is because the trajectory of weapon fire is simply a call of starting point (based on mech, normalizing the animations to not be included in the server checks but still be calculated on the client for visuals only) and then a vector in the path of the weapon. After that initial call for weapon fire, the rest is done with update calls for each server tick.

The only thing that PGI could maybe be complaining about is that currently, the server has to match the client's ray trace to determine distance and cross hair point. They are afraid that if you want unique trajectories with weapons, you will have to include more ray traces, thus taking more performance hits. This is completely untrue and can easily be completed with a single ray trace, like the client/server does now.

Basically, the way I viewed weapons to work is in the following manner:

• Initial ray trace for current tick on the server (to determine where the cross hair is pointed and it's distance).
  
• Include offset from cross hair/player perspective to location perspective of where the weapon is located.
  
• Include offset from weapon location perspective to individual weapon location perspective.
  
• Include mechanic offset for destabilizing aim (cone of fire, moving convergence, whatever).

Basically, what this means is that when someone fires a weapon, you use the initial ray trace as a hypotenuse, then using the (x,y,z) position from the ray trace initial start and player perspective to the physical weapon location on the mech. Having the hypotenuse and the distance from the player's perspective to the weapon location, you can easily use trigonometry to calculate the angle in which the weapon should be fired.


With this, you can calculate the vector of the weapon, and knowing the initial mounted point of the weapon, use the weapon fire function call with the calculated vector and initial weapon mount.

The nice thing about this is all of these values are static. You know the distance to where the cross hair is aiming by the ray trace and you know the distance and angle from the player's perspective to the weapon mount in question. And each of these is already known for each frame of animations for the visual calculations for the client (the server most likely doesn't take into account the exact frame the player was in when firing for determining firing paths, but it easily could do this).

The only hard calculation is the vector to put into the weapon fire call, which can be calculated by these above static values.

This is why I do not agree with PGI's stance that having multiple weapon paths leads to more server calculations.

These are assumptions on your part yes? I mean no offense here, as they look like good assumptions to me, I have to assume there is some technical reason they cannot do this (or it would be too difficult/intensive if they could) which is why I proposed these.

[nehebkau]

Madw0lf, on 20 February 2014 - 08:50 AM, said:

It just seems like an overly convouted mechanic to me. Why not just increase armor/internals HP?

Well, because this method wouldn't affect normally firing weapons and their effect on the mech. A single AC20 shot would do 20 damage to the CT. It would only affect HUGE damage shots by many weapons whereas just increasing HPs would affect everything.

[Madw0lf]

nehebkau, on 20 February 2014 - 09:12 AM, said:

Well, because this method wouldn't affect normally firing weapons and their effect on the mech. A single AC20 shot would do 20 damage to the CT. It would only affect HUGE damage shots by many weapons whereas just increasing HPs would affect everything.

This is true. Its an offputting idea and Im trying to suss out exactly why.

I mean, it doesnt make physical sense to me like I said, I just dont feel like my suspension can go so far as to accept something like that. No ofense meant to you of course.

Edited by Madw0lf, 20 February 2014 - 09:28 AM.

[Zyllos]

Madw0lf, on 20 February 2014 - 09:02 AM, said:

These are assumptions on your part yes? I mean no offense here, as they look like good assumptions to me, I have to assume there is some technical reason they cannot do this (or it would be too difficult/intensive if they could) which is why I proposed these.

Yes, you are partly right. I have made some effort into researching the code for the CryEngine and understanding some of the weapon function calls.

Either way...

[Nothing Whatsoever]

Something that I've wondered is if current Machine Guns could be a template for other weapons for a 'cone' style fire pattern?

For example, go into Testing Grounds with the trial Spider and fire MG's at a target from 120 M or more, and you can see multiple sections light up on the target.

[VanillaG]

A formula based convergence/cone of fire model would give Targeting Computers a use in MWO. They would modify the formula to reduce the variance in where the shots land.

[stjobe]

Craig Steele, on 19 February 2014 - 07:39 AM, said:

Up until Dark Age rule books canon was not specific in identifying how AC's physically interacted although it HINTED at burst fire. I can understand why many see AC's as a one shell(like a tank cannon) weapon.

No. Let's put this silliness to rest once and for all.

Decision at Thunder Rift, the very first BattleTech novel, published in 1986, has this to say about autocannons:

Quote

A chain of staccato cracks carried above the roar of flame and crumbling buildings. The Marauder's autocannon, a tree-sized barrel mounted across the 'Mech's left shoulder, was spewing 120 mm high-explosive destruction in three-round bursts that shattered the street behind the burning carrier

Quote

The quad autocannon fired with a buzzsaw's scream, and left a sour taste of chemicals heavy in the air.

Quote

Twice Grayson turned, dropped the autocannon down across the 'Mech's left shoulder, and opened a rolling barrage of explosive shells against the launchers that were tracking him

Quote

Adrenalin sang in Grayson's blood. He dropped the autocannon across his left shoulder, and triggered a long, rolling burst of hellfire, then snapped the Hawk's right arm up to discharge three lightning-quick bolts of coherent light.

Quote

When Grayson stabbed the firing switch, the autocannon bucked and roared across the Hawk's shoulder, deafening him with an ocean of roaring sound and vibration. Eighty-millimeter high-explosive shells shredded the dish, smashed into the mast with devastating fury.

Quote

Grayson triggered his autocannon, and sent a stream of high-explosive shells hosing toward the brick and glass target.

Quote

At 150 meters, Grayson triggered his autocannon, a long, rolling burst that splattered explosive shells across the Marauder's back and torso armor.

Quote

The Marauder charged. Grayson snapped off two shots, then swung around and away, beyond the monster's reach, ripping off an autocannon burst as it thundered past.

Looks pretty cut-and-dried to me. And don't even think of saying that Decision at Thunder Rift isn't canon; it doesn't get more canon than that.

It even has the following text in the glossary:

Quote

Autocannon: A rapid-firing, auto-loading cannon mounted on some 'Mechs and weapons carriers. Light vehicle autocannon have calibers ranging from 30 to 90 mm, while heavy 'Mech autocannon may be 80 to 120 mm or more. The weapon fires high-explosive or armor-piercing shells. Because of the limitations of 'Mech targeting technology, its range is limited to less than 600 meters.

Autocannons have ALWAYS been burst-fire in BattleTech. Always. They were simply made to have one to-hit roll in the TT game because nobody wants to roll to-hit dice for a 100-shot burst, but every description of an autocannon ever made in anything that's canon has them as burst- or continuous-fire weapons.

Hell, here's the Tech Manual:



See that text there? "rapid-firing, auto-loading, heavy ballistic weaponry - gigantic machine guns"

That's autocannons in BattleTech.

They NEVER were single-shot weapons.

Edit: Fixed quotes, apparently you cannot have more than 10 quote tags...

Edited by stjobe, 20 February 2014 - 04:12 PM.

[StonedDead]

Trauglodyte, on 19 February 2014 - 12:07 PM, said:

Free Look was really put in place to help the pilots to partially shield your torso while keeping your arms on line with your target.

Nah man, it's so you can attack multiple targets at once. It can be done. One time I tried using my joystick as a tiller, with throttle, leg turning, and torso weapons on it. Left the mouse as my torso movement and made one button free look. It took lots of practice to get used to in training grounds, but it worked quite well in combat. It allowed me to attack a catapault in front of me while making the killing shot on a centurion coming over the ridge on frozen night. It was just awkward to use for long periods of time. Free look gives a massive advantage in battle if used properly.

Quote

I still contend my patent-pending "3-Reticle" solution would be the best solution...

In a nut-shell: There would be three reticles, one each for the left arm, torso, and right arm respectively.

The right and left reticles would automatically attempt to attempt to converge with the central reticle. That said, "movement" would cause the reticles to de-harmonize... as the amplitude of the movement increased, so to would the amount of de-harmonization... effect.

Thusly while stationary, mechs would have perfect convergence. Moderate movement would invoke slight de-harmonization and full tilt movement would obviously cause the greatest de-harmonization.

For the sake of balance, poptarting would be categorized as full-tilt movement...

The functional coding is already present as this is roughly how MW:O treats torso / arm reticle limits. This would simply be an extension of this core game mechanic the way I see it...

That would be freakishly awesome with a setup like I described above.

[Varent]

Madw0lf, on 19 February 2014 - 05:59 AM, said:

Hello all, Id like to preface this by saying that;

1) I actually feel the game is pretty well balanced atm (atleast at my "level")

2) I dont "meta"

That being said, I see alot of......weird, suggestions to balance the game flying around, with som common themes. And other things brought up regularly that are.....not to my liking (cough burst ACs cough). So Ive been working on a couple ideas recently and thought Id get some input.

To start I followed a couple of simple rules;

1) Whatever is implemented must be simple to implement, simple to run, and simple to understand (so, KISS)

2) It has to make some logical physical sense (BT stretches my suspension of disbelief enough already....)

So, in order to address one of what seems to be the communities largest complaints, pinpoint damage/instant convergence/etc. I give you first;


Cone of Fire

Used extensively in other FPS games, this is the simpler, though less effective of my proposed solutions.

Implementation: Really all that would be done is to take the JJ shake mechanic and apply it at all times following a basic equation;

shake = %throttle + [.1] * m

where m is a modifier on a per mech basis. So the higher your throttle setting, the more area your reticule covers. The exact form and values for this would be up for tuning, obviously. But this gives another great area to help differentiate Mechs with each one having their own modifier.

The major downside is, an alpha strike would still all hit one location, though it would be harder to hit the one you wanted to.

This would, unfortunately, affect the less skilled more so than the more highly skilled players, who would be able to adapt much more quickly.


Simulated Convergence:

I can see this one being quite controversial. In essence what we are doing here, is providing the effects of convergence, without putting the strain of calculating so many different weapons paths on the server (Which is, IIRC why PGI said they wouldnt be implementing convergence).

We start with this equation;

r = m*(l*tan(a))

Where;
m is a per-Mech modifier
l is the range to target (or reticle)
a is the angle
and r is the radius that will be hit.

What happens:

Lets assume we target a Mech at 700m with our 4 ERPPCs in a Stalker.
Stalker has an m of [.1], our base a value is [5] so our r value becomes [6.2]m
What this means is that our ERPPC alpha will spread over an area of 6.2m radius. What actually happens, is that the damage is split up into n (number of weapons being fired) different packets each with the damage value of one weapon, which each hits a different section at random.

So in our example, we have 4 packets of 10 damage each distributed across what is probably the entire target. The damage is centered around the reticle, so if we are aiming at the CT we have 10 at the CT, 10 each side torso, and 10 to either an arm, leg, or the head.

Now, as we hold our target lock, or hold our reticle on target, our a value decreases which decreases our r, increaseing the number of weapons hitting any singular point.

Now, this solution is more complex, but better simulates actual convergence in its effects. IT would also encourage targetting.

This is all just a rough "sketch" if you will, but a place to start. Comments, questions, suggestions, flames?

Sorta against anything in a shooting game that makes good aim unrewarding. Thats basically what the second option would do.

Regarding the recticle shake. This has been suggested multiple times. Would love to see it implimented with jump sniping as long as its done in a way that doesnt kill jump sniping all together.

[Varent]

stjobe, on 20 February 2014 - 03:59 PM, said:

No. Let's put this silliness to rest once and for all.

Decision at Thunder Rift, the very first BattleTech novel, published in 1986, has this to say about autocannons:









Looks pretty cut-and-dried to me. And don't even think of saying that Decision at Thunder Rift isn't canon; it doesn't get more canon than that.

It even has the following text in the glossary:


Autocannons have ALWAYS been burst-fire in BattleTech. Always. They were simply made to have one to-hit roll in the TT game because nobody wants to roll to-hit dice for a 100-shot burst, but every description of an autocannon ever made in anything that's canon has them as burst- or continuous-fire weapons.

Hell, here's the Tech Manual:



See that text there? "rapid-firing, auto-loading, heavy ballistic weaponry - gigantic machine guns"

That's autocannons in BattleTech.

They NEVER were single-shot weapons.

Edit: Fixed quotes, apparently you cannot have more than 10 quote tags...

flavor text by someone making a board/table top game =/= battletech. That said as well the gms can do whatever they please to create a balanced shooter. and SHOULD do whatever they need to to create a balanced shooter.

battletech feel is and should be secondary to making a functioning game that attracts the largest variety of gamers they can.

[Madw0lf]

Varent, on 20 February 2014 - 04:54 PM, said:

Sorta against anything in a shooting game that makes good aim unrewarding. Thats basically what the second option would do.

Regarding the recticle shake. This has been suggested multiple times. Would love to see it implimented with jump sniping as long as its done in a way that doesnt kill jump sniping all together.

My thought is it would make good aim, timing and patience more rewarding, requiring higher skill to actually hit what you want with what you want.

Reticle shake does exist for jumping mechs.....And that doesnt make a poptarts good aim unrewarding?

[Craig Steele]

stjobe, on 20 February 2014 - 03:59 PM, said:

No. Let's put this silliness to rest once and for all.

Decision at Thunder Rift, the very first BattleTech novel, published in 1986, has this to say about autocannons:









Looks pretty cut-and-dried to me. And don't even think of saying that Decision at Thunder Rift isn't canon; it doesn't get more canon than that.

It even has the following text in the glossary:


Autocannons have ALWAYS been burst-fire in BattleTech. Always. They were simply made to have one to-hit roll in the TT game because nobody wants to roll to-hit dice for a 100-shot burst, but every description of an autocannon ever made in anything that's canon has them as burst- or continuous-fire weapons.

Hell, here's the Tech Manual:



See that text there? "rapid-firing, auto-loading, heavy ballistic weaponry - gigantic machine guns"

That's autocannons in BattleTech.

They NEVER were single-shot weapons.

Edit: Fixed quotes, apparently you cannot have more than 10 quote tags...

And yet in the 3026 TRO (1987) there are a couple of AC20 descriptions that suggest (without specifically saying) that they are single shots. In the same book there are a couple of other examples talking about a very small number of shots (ie, 4 in a burst) which over 10 seconds is a laughable ROF, it would never be described as a 'machine gun'.

The canon was very clear that at that time different producers used different calibres and rates of fire (hence why Thunder Rift has one description and there are others in other source books). There is no reason AT THAT TIME to think that a large calibre single shot weapon was not produced.

The definitive definition from the rule book you have there was published significantly later.

So yes, I think the canon prior to the definitive definition publiched in the Dark Aages HINTED at a machine gun burst type weapon but left it open a little as well.

Is it really such a terrible thing that people could interpret their own version of a fantasy weapon from the grey area they left it as?

[Varent]

Madw0lf, on 20 February 2014 - 05:16 PM, said:

My thought is it would make good aim, timing and patience more rewarding, requiring higher skill to actually hit what you want with what you want.

Reticle shake does exist for jumping mechs.....And that doesnt make a poptarts good aim unrewarding?

it currently only exists on the way up. On the way down it stops entirely. And My thought would be that you have to work for the shake. There are ways to do this such as forcing a mech to have an additional amount of jump jets to prevent the shake, or incur shake under more conditions while jumping, etc. Right now its TOO simple because on the way down its quite easy to aim and fire.

That said regarding again the other issue. It would slow down the game too much if your jsut staring at someone and would drastically change too many playstyles. This game needs to survive on its own as a shooter.

Craig Steele, on 20 February 2014 - 05:18 PM, said:

Is it really such a terrible thing that people could interpret their own version of a fantasy weapon from the grey area they left it as?

This.

And apparently it is a terrible thing to some since they want to just be able to quote things to justify themselves as upposed to coming up with there own unique ideas that will help this game flourish.

I believe the term is being stuck in the past and unimaginitive.

[xMEPHISTOx]

Warning...Nerf hounds in the area, dangerous to all, they do bite. They don't suck, this thing and that thing are OP...they don't suck, nerf it, nerf it all>!

Jump sniping = OP = NERF IT.
Alphas = OP = NERF IT.
convergance = OP = NERF IT.
Premades = OP = NERF IT.
Focus Fire = OP = NERF IT.
Jump Jets = OP = NERF IT.

http://mwomercs.com/...tk/page__st__20

Edited by xMEPHISTOx, 20 February 2014 - 05:32 PM.