Jump to content

Crit Splitting In Mwo, How It Could Work?


44 replies to this topic

#1 Andi Nagasia

    Volunteer Moderator

  • PipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 5,982 posts

Posted 22 September 2017 - 12:37 PM

so this has been a hot Topic recently,
mainly because of the LBX20(11Crits) and Heavy Gauss(11Crits)


but what is Crit Splitting?
in TT Crit Splitting is the Spliting of Crits of weapons that were larger than 8Crits,
weapons like(IS-AC20)(IS-UAC20)(IS-LBX20)(Heavy Gauss) are all Larger that 8Crits,
-
in this case when a weapon is placed in a Location that doesnt have enough Crits,
those Crits(that cant fit) will over flow into an Adjacent Mech Location,
this is called Crit Splitting,

but how could this be implemented in MWO?


=Diet Crit Splitting Concept=
using what we know PGI can and already has programed as a guide,
-
i think those weapons larger than 8 Crits, should be reduced to 8 Crits,
then have a certain amount of Floating Crits(like BattleMech Endo/Ferro) added as well,
this would allow Crit Splitting to be added to MWO, with little departure from TT/Lore,
-
IS-AC20............8Crits..........2FloatingCrits...
IS-UAC20..........8Crits..........2FloatingCrits...
IS-LBX20...........8Crits..........3FloatingCrits...
Heavy Gauss....8Crits..........3FloatingCrits...

this would allow for the Arm mounting of AC/UAC/LBX20 class weapons on,
PHX's, CN9's, ENF's, BSW's, WVR's, DRG's, RGH's, TDR's, BLR's, HGN's, & ANH's,


now usually you place your Split Crits in an Adjacent location,
this wouldnt be the case with full FloatingCrits as i propose in this Idea here,
however i dont see this as much of a problem as IS have Floating ENDO/Ferro anyway,


=Another Crit Splitting Concept=
another way of doing this would be to reduce the Max Slots a Mech has,

for instance an AC20&UAC20,
Slots = 8,//down from 10
 
TotalMechSlots -2,//adding back the 2 we lost from above
This will reduce the Max Mech slots by 2 for Every AC20/UAC20(78 to 76)
this way this can be coded into MWO with just a couple XML edits,

and for a LBX20&HGauss20,
Slots = 8,//down from 11
 
TotalMechSlots -3,//adding back the 3 we lost from above
This will reduce the Max Mech slots by 2 for Every LBX20&HGauss20(78 to 75)
this way this can be coded into MWO with just a couple XML edits, and not heavy work,
(for HGuass just add some from the JJ Code to make them Torso Only)

this means:
Equipping a single AC20/UAC20 will reduce your max slots to 76(from 78)
Equipping a two AC20/UAC20 will reduce your max slots to 74(from 78)
-
Equipping a single LBX20/HGauss will reduce your max slots to 75(from 78)
Equipping a two LBX20/HGauss will reduce your max slots to 72(from 78)


=(Poll)=

Have an idea you feel would work better?
Have a Critique that you feel would make this idea better?
Post below,

Thoughts, Comments, Concerns?
Thanks,

Edited by Andi Nagasia, 23 September 2017 - 10:08 AM.


#2 Brain Cancer

    Member

  • PipPipPipPipPipPipPipPipPip
  • The 1 Percent
  • 3,851 posts

Posted 22 September 2017 - 01:15 PM

The problem seems to be that PGI cannot into a weapon realizing it's in two "sections", almost as if each piece of a robot was a separate unit that happens to just function together. That is, it can't seem to disable a weapon in one location and have the corresponding part disabled in another location, or even treat the two parts as a single weapon. Floating critspace stuff has no effects for destructon (endo/ferro), so it's a moot point there.

The solution is probably "nothing" unless and until PGI grasps it's own game coding better, something that requires outside intervention.

#3 Trissila

    Member

  • PipPipPipPipPipPip
  • Survivor
  • 439 posts

Posted 22 September 2017 - 02:15 PM

I'm trying real hard to think of what kind of insane way they could have implemented 'mech internals such that they can't possibly track crits for a piece of equipment located in a section other than the primary.

Like, at the most basic level... each component of a mech would be an array of critical items, each item containing the ID of the weapon/equipment it represented. Critical hits, then, would roll over these arrays to find out which critical item they hit, look up the ID of the equipment that item belongs to, and then do whatever they needed to do destruction-wise to that item.

I get that they need to track which section/hardpoint the weapon is actually located in, for the graphics, but that could and should be a separate thing from the critical arrays. Under such a system, it wouldn't matter where you split the crits to -- they're still just objects that all reference the same weapon ID on the 'mech, no matter what component they're actually located in.

As a programmer by training and a sysadmin/devops guy by trade, I would love to get some insight into how PGI has actually implemented this stuff that prevents them from using this kind of solution.

#4 Andi Nagasia

    Volunteer Moderator

  • PipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 5,982 posts

Posted 22 September 2017 - 02:18 PM

which is why im suggesting making these weapons 8 crits, then giving them Floating Crits like Endo/Ferro,
this way Diet Split Critting can be added to MWO, with out major reworks in the MechLab system,

although, the Floating Crits wouldnt count as physical items much like Endo/Ferro dont count,
in this sense the Slots they take up cant be Critted, and if they are selected it will just reroll to another slot,

#5 Bishop Steiner

    ForumWarrior

  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • The Hammer
  • The Hammer
  • 47,187 posts
  • Locationclimbing Mt Tryhard, one smoldering Meta-Mech corpse at a time

Posted 22 September 2017 - 02:22 PM

View PostBrain Cancer, on 22 September 2017 - 01:15 PM, said:

The problem seems to be that PGI cannot into a weapon realizing it's in two "sections", almost as if each piece of a robot was a separate unit that happens to just function together. That is, it can't seem to disable a weapon in one location and have the corresponding part disabled in another location, or even treat the two parts as a single weapon. Floating critspace stuff has no effects for destructon (endo/ferro), so it's a moot point there.

The solution is probably "nothing" unless and until PGI grasps it's own game coding better, something that requires outside intervention.

*THIS*

And even if they could figure it out, it would be pretty silly at this point in the game's life cycle to worry over it, especially for something that is pretty rarely used. If we're going to deep dive into the code again, do it for something like Quads.

What's more do it on Unreal so that it's developed for MW5. Aside from Maps and Mechs, and minor stuff, accept that MWO is as "finished" a product as it's going to be. Spending large amounts more time and hours changing stuff here that doesn't directly port over to Unreal is just wasted resources at this time.

So instead of cajoling PGI to chase their tail more than they already do, I'd rather focus on what they can do for MW5, which has potentially little to do with MWO, being on a totally different engine.

#6 LordNothing

    Member

  • PipPipPipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 17,932 posts

Posted 22 September 2017 - 05:36 PM

i dont know if coding this up is as big a deal as everyone seems to think it is. its not hard to branch off a conditional when a weapon is slapped on and then check to see if you can slap on another part elsewhere behind the scenes, and if thats not possible, invalid build/weapon removed.

i think its mostly an asset issue. how many mechs would require a modeling pass as a result? many mechs which could not carry an ac20 would suddenly have that ability. and because those mechs didnt have an ac20 mesh in its model it would require a pass. now would actually be a good time to do it because of the newtech additions that need to be made at an alarming rate of about 5 mechs per patch. it would also play havok with balance for the same reasons. lots of mechs would get heavy weapons support that wasnt planned for.

even the asset problem would be easily handled with code instead of a 3d artist spending time with every mech in the game. if our "dynamic hardpoint system" was in fact dynamic and could grab a uniform weapon model from its own model file and integrate it with the model using a bit of integrative geometry (like a barrel shroud or a modular rack system) on the mech that can be paired with multiple weapon models. to add or change a weapon system would only require one set of new geometry and would reuse the existing interconnecting structures in the mech's model. so the remodeling is gone in favor of some xml editing which is significantly easier. you could bring in new weapons with a much lower integration cost instead of having an ever growing work manifest.

Edited by LordNothing, 22 September 2017 - 06:08 PM.


#7 Bishop Steiner

    ForumWarrior

  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • The Hammer
  • The Hammer
  • 47,187 posts
  • Locationclimbing Mt Tryhard, one smoldering Meta-Mech corpse at a time

Posted 22 September 2017 - 06:07 PM

View PostLordNothing, on 22 September 2017 - 05:36 PM, said:

i dont know if coding this up is as big a deal as everyone seems to think it is. its not hard to branch off a conditional when a weapon is slapped on and then check to see if you can slap on another part elsewhere behind the scenes, and if thats not possible, invalid build/weapon removed.

i think its mostly an asset issue. how many mechs would require a modeling pass as a result? many mechs which could not carry an ac20 would suddenly have that ability. and because those mechs didnt have an ac20 mesh in its model it would require a pass. now would actually be a good time to do it because of the newtech additions that need to be made at an alarming rate of about 5 mechs per patch. it would also play havok with balance for the same reasons. lots of mechs would get heavy weapons support that wasnt planned for.

even the asset problem would be easily handled with code instead of a 3d artist spending time with every mech in the game. if our dynamic hardpoint system was in fact dynamic and could grab a uniform weapon model from its own model file and integrate it with the model using a bit of integrative geometry (like a barrel shroud or a modular rack system) on the mech that can be paired with multiple weapon models. to add or change a weapon system would only require one set of new geometry and would reuse the existing interconnecting structures in the mech's model. so the remodeling is gone in favor of some xml editing which is significantly easier. you could bring in new weapons with a much lower integration cost instead of having an ever growing work manifest.

still goes back to my point... more resources invested than returns justify.

#8 Andi Nagasia

    Volunteer Moderator

  • PipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 5,982 posts

Posted 22 September 2017 - 07:00 PM

View PostBishop Steiner, on 22 September 2017 - 06:07 PM, said:

still goes back to my point... more resources invested than returns justify.

perhaps,
but thats still 3 weapon Types being able to be mounted in 11 Chassis arms where they werent before,
and also 2 weapon Types being able to be mounted in every Chassis Torso with 2 Engine Types,

this may not seem like something big but it adds options that didnt exist before,
how many have wanted to Mount an AC20 in a CN9s or DRGs arms?
this is a change that has been talked about since Beta,

im not saying that it needs full development time, but if it can be get working with out too much trouble why not?
we dont know what PGI looks at for programing MWOs CryEngine so none of us know how hard it would be,
as some times Russ has said are very much possible but dont have development time set out for them,
this may not be a (cant be done because engine) but a (not being looked at, at this time) kinda thing,

#9 Spheroid

    Member

  • PipPipPipPipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 5,069 posts
  • LocationSouthern Wisconsin

Posted 22 September 2017 - 08:21 PM

The solution is very easy. For each split weapon you choose one of eleven slot options of weapons all obstensibly called "LBX20". These would be eleven separate game objects but to the user would seem to be of the same type. I would do this via a drop down or click box.

You then create a game link to the remainder of the weapon that would function in the same manner that a targeting computer is linked to direct fire weapons. The destruction of a targeting computer drops all benefits to weapons once destroyed. If you employ this mechanic you set ammo, velocity or some other value to zero that mimics weapon destruction.

You limit firing arc by setting the torso slot as the active weapon and the arm slot as the slave or TC analogue. Again using existing code.

Edited by Spheroid, 22 September 2017 - 11:27 PM.


#10 The Lighthouse

    Member

  • PipPipPipPipPipPipPipPip
  • Moderate Giver
  • Moderate Giver
  • 1,143 posts

Posted 22 September 2017 - 08:40 PM

This is definitely one of better ideas I've heard. The timing is also right for this.

#11 Spheroid

    Member

  • PipPipPipPipPipPipPipPipPipPip
  • Veteran Founder
  • Veteran Founder
  • 5,069 posts
  • LocationSouthern Wisconsin

Posted 22 September 2017 - 10:22 PM

Another cavet. In mechs that clearly have articulated arm ballistics I would require a ballistic in the torso and arm in cases where a lower arm still exists as in the Highlander-734. The game would equip to the torso and render to the arm.

That means the 732 would be out of luck, but the AC-20 Highlander would be able to equip UAC20/LBX20 no issues since it has the existing limited traverse mechanic already built in.

I much rather go this two hardpoint route over moving the hardpoint to the torso as in the Highlander-736.

For this to work the 734 would delete one missile hardpoint for one additional ballistic. Balance between the variants remains the same and the ability to run stock loadouts is unaffected.

Edited by Spheroid, 22 September 2017 - 11:18 PM.


#12 davoodoo

    Member

  • PipPipPipPipPipPipPipPipPip
  • Liquid Metal
  • Liquid Metal
  • 2,496 posts

Posted 23 September 2017 - 02:10 AM

Move crit into nearby location favoring less restricting ones like side torso trying to fit ct first, make them dynamic slots so theyll move away if you drop anything there.
Completely ignore split crits when taking damage, if split part gets destroyed, weapon stops working.
Also if weapon is split into or off arm then lock arms to torso.

Minimal coding required to implement this, base is already in game.

Edited by davoodoo, 23 September 2017 - 02:19 AM.


#13 Exilyth

    Member

  • PipPipPipPipPipPipPipPipPip
  • Bridesmaid
  • 2,100 posts
  • LocationTerra

Posted 23 September 2017 - 03:06 AM

One way to do it:
You place a (splittable) weapon into a location - it will fit no matter how many slots there are, but as long as there are slot violations, your loadout will be invalid.
The weapon could have a checkbox "split crits" - when unchecked, the weapon has its actual size and is not split, when split, a number of 'split weapon' components are placed in the adjacent location and the size of the weapon is reduced.
(a bit more technical: the weapon could hold references to all split weapon components placed by this weapon and vice versa so that upon removing the weapon, the split components can be removed and vice versa. Similar for critting a weapon: when a split component is hit, the damage transfers to the weapon)

Weapon geometry could be assigned to the actual location of the weapon for now, e.g. a weapon assigned to the LT and split to the LA would be located in the LT.


Mhh.. might have to read up crit splitting in the TT rulebook again.
Anyone know which book/section that rule hides in?

Edited by Exilyth, 23 September 2017 - 05:14 AM.


#14 Khobai

    Member

  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Elite Founder
  • Elite Founder
  • 23,969 posts

Posted 23 September 2017 - 04:28 AM

a better solution is just to make all weapons that take up more than 10 crit slots only take up 10 crit slots

that fix can be implemented in about 5 seconds. and avoids the nonsense of having to code in dynamic crit slots. yes it doesnt follow the construction rules exactly, but the for sake of realistic and simplistic fixes, this is the best one.

although you would need a special restriction on heavy gauss to prevent it from being placed in arms. because thats a no-no in the construction rules and I think that particular construction rule needs to be kept.

Edited by Khobai, 23 September 2017 - 04:32 AM.


#15 El Bandito

    Member

  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • Big Daddy
  • Big Daddy
  • 26,736 posts
  • LocationStill doing ungodly amount of damage, but with more accuracy.

Posted 23 September 2017 - 05:14 AM

View PostKhobai, on 23 September 2017 - 04:28 AM, said:

a better solution is just to make all weapons that take up more than 10 crit slots only take up 10 crit slots

that fix can be implemented in about 5 seconds. and avoids the nonsense of having to code in dynamic crit slots. yes it doesnt follow the construction rules exactly, but the for sake of realistic and simplistic fixes, this is the best one.



Exactly. For balance, core rule ignore.

#16 LordNothing

    Member

  • PipPipPipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 17,932 posts

Posted 23 September 2017 - 06:08 AM

View PostBishop Steiner, on 22 September 2017 - 06:07 PM, said:

still goes back to my point... more resources invested than returns justify.


still with the way these newtech retrofits are going, i think pgi could actually save a lot of time in the future having a coder slap together a truely dynamic hardpoint system rather than have to process every single mech model manually. i worry that this might be the last batch of tech we see on grounds of how much work its turning out to be. even if its just slapping together some scripts to help automate the process. every time pgi releases a mech pack the work load goes up, it could easily get away from them if they let it.

#17 Asym

    Member

  • PipPipPipPipPipPipPipPipPip
  • Nova Captain
  • 2,186 posts

Posted 23 September 2017 - 06:22 AM

View PostAndi Nagasia, on 22 September 2017 - 12:37 PM, said:

so this has been a hot Topic recently,
mainly because of the LBX20(11Crits) and Heavy Gauss(11Crits)


but what is Crit Splitting?
in TT Crit Splitting is the Spliting of Crits of weapons that were larger than 8Crits,
weapons like(IS-AC20)(IS-UAC20)(IS-LBX20)(Heavy Gauss) are all Larger that 8Crits,
-
in this case when a weapon is placed in a Location that doesnt have enough Crits,
those Crits(that cant fit) will over flow into an Adjacent Mech Location,
this is called Crit Splitting,


but how could this be implemented in MWO?
well using what we know PGI can and already has programed as a guide,
-
i think those weapons larger than 8 Crits, should be reduced to 8 Crits,
then have a certain amount of Floating Crits(like BattleMech Endo/Ferro) added as well,
this would allow Crit Splitting to be added to MWO, with little departure from TT/Lore,
-
IS-AC20............8Crits..........2FloatingCrits...
IS-UAC20..........8Crits..........2FloatingCrits...
IS-LBX20...........8Crits..........3FloatingCrits...
Heavy Gauss....8Crits..........3FloatingCrits...

this would allow for the Arm mounting of AC/UAC/LBX20 class weapons on,
PHX's, CN9's, ENF's, BSW's, WVR's, DRG's, RGH's, TDR's, BLR's, HGN's, & ANH's,


now usually you place your Split Crits in an Adjacent location,
this wouldnt be the case with full FloatingCrits as i propose in this Idea here,
however i dont see this as much of a problem as IS have Floating ENDO/Ferro anyway,


=(Poll)=

Have an idea you feel would work better?
Have a Critique that you feel would make this idea better?
Post below,

Thoughts, Comments, Concerns?
Thanks,

Good article....

The problem is the PGI is going the other way: away from 3D precision battlespaces. Every balance pass, nerf, update, tweak, quirk, buff et al. is premised on the "reduction" of range, effect, duration, agaility or lethality....

Players keep responding" what? Why? Simple: Solaris.........

Arena FPS's are close, controlled; and, simplier to operate; create new maps and events; and, creates a new micro-sale paradigm and e-Sports platform... i.e. look at polar post skill tree as an example. In Feb-May of this year, as a new player, I have several confirmed headshots... Long range, 2xGauss Night Gyr headshots.... Now, I couldn't find a headshot in any game I've played or watched on YT that was beyond 500 meters? I've intentionally, and at great expense of time, tried to duplicate a sniper pure headshot.... CT yes. An Arm, yes. A head, at distance, no......... Why? Because PGI has degraded and changed the hit box calculations to limit anything of ranges beyond 500 meters................ Look at the new weapons. Look at the survival buffs and nerfs (armor up and agility down....) Why? To lengthen the brawling battlespace time and limit open field maneuverability. Again, look at the Night Gyr and TBR.... Entire teams have or are in the process of leaving because the writting is on the wall and so obivious to many.........because we've seen this before in other games.

Solaris is the business plan. And, I like your article because it makes a lot of sense..... But, is counter to where PGI is headed: a game with a Red robot and a Blue robot on a small piece of ground, well with in the horizon, that brawl until one is destroyed or they are both are out of weapons or ammunition" "Rock-and-Sock'em-Robots" from the 1960's...............

#18 Andi Nagasia

    Volunteer Moderator

  • PipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 5,982 posts

Posted 23 September 2017 - 09:31 AM

View PostAsym, on 23 September 2017 - 06:22 AM, said:

Good article....

The problem is the PGI is going the other way: away from 3D precision battlespaces. Every balance pass, nerf, update, tweak, quirk, buff et al. is premised on the "reduction" of range, effect, duration, agaility or lethality....

engine desync had to happen, and its generally been a good change,
MWO still have a great deal of strategy, and often Strategy & coordination will win out,

PGI has said they want to balance tech & reduce Quirks, Why?
so a mechs Viability isnt solely based on Quirks, if tech was 100% balance many Mech Quirks would disappear,
this is a good thing, its means we are moving closer to balance, which should be the goal,

View PostAsym, on 23 September 2017 - 06:22 AM, said:

Players keep responding" what? Why? Simple: Solaris.........

Arena FPS's are close, controlled; and, simplier to operate; create new maps and events; and, creates a new micro-sale paradigm and e-Sports platform... i.e. look at polar post skill tree as an example. In Feb-May of this year, as a new player, I have several confirmed headshots... Long range, 2xGauss Night Gyr headshots.... Now, I couldn't find a headshot in any game I've played or watched on YT that was beyond 500 meters? I've intentionally, and at great expense of time, tried to duplicate a sniper pure headshot.... CT yes. An Arm, yes. A head, at distance, no......... Why? Because PGI has degraded and changed the hit box calculations to limit anything of ranges beyond 500 meters................ Look at the new weapons. Look at the survival buffs and nerfs (armor up and agility down....) Why? To lengthen the brawling battlespace time and limit open field maneuverability. Again, look at the Night Gyr and TBR.... Entire teams have or are in the process of leaving because the writting is on the wall and so obivious to many.........because we've seen this before in other games.

MWO is already an Arena shooter, it already has a comp Esports Placement,
this was even before PGI said they would like to look into Esports, MRBC, NBT, this was here first,

not sure what you mean by PGI changing the HitBox Calculations past 500m,
do you have any proof that this is so, this is the first ive heard about anything like this,
also ive recently gotten a HeadShot at 1100 with 3ERPPCs(target must not have had full HD Armor)

many have said that people are leaving because they have seen this happen in other games,
the thing is it changes every year, every year seems to bring another thing thats killing MWO, last year it was
(MWO is Dieing because PGI wants to make it an ESports, we've see this happen in other games!!!)
well ESports hasnt seemed to kill MWO in 6 months as Predicted, so im not worried,

View PostAsym, on 23 September 2017 - 06:22 AM, said:

Solaris is the business plan. And, I like your article because it makes a lot of sense..... But, is counter to where PGI is headed: a game with a Red robot and a Blue robot on a small piece of ground, well with in the horizon, that brawl until one is destroyed or they are both are out of weapons or ammunition" "Rock-and-Sock'em-Robots" from the 1960's...............

um Solaris isnt ganna replace FP, its not ganna replace QP or GP, its ganna be another option,
this idea doesnt conflict with Solaris or PGIs goals, just as the Topic on going back to 8v8 doesnt,
Solaris would benefit from this change as all MWO game modes would, as its a mech lab change,
and having Solaris wouldnt some how mean this cant happen ether, they arnt as such related,

#19 Andi Nagasia

    Volunteer Moderator

  • PipPipPipPipPipPipPipPipPipPip
  • Ace Of Spades
  • Ace Of Spades
  • 5,982 posts

Posted 23 September 2017 - 09:53 AM

View PostKhobai, on 23 September 2017 - 04:28 AM, said:

a better solution is just to make all weapons that take up more than 10 crit slots only take up 10 crit slots

that fix can be implemented in about 5 seconds. and avoids the nonsense of having to code in dynamic crit slots. yes it doesnt follow the construction rules exactly, but the for sake of realistic and simplistic fixes, this is the best one.

although you would need a special restriction on heavy gauss to prevent it from being placed in arms. because thats a no-no in the construction rules and I think that particular construction rule needs to be kept.

well i could code this into MWO right now but it would be Diet Crit Splitting,

ok so heres how i would do it,
IS-AC20............8Crits..........2FloatingCrits...
IS-UAC20..........8Crits..........2FloatingCrits...
IS-LBX20...........8Crits..........3FloatingCrits...
Heavy Gauss....8Crits..........3FloatingCrits...
these Foating Crits are actually a subtraction in the Code


for instance an AC20&UAC20,
Slots = 8,//down from 10
 
TotalMechSlots -2,//adding back the 2 we lost from above
This will reduce the Max Mech slots by 2 for Every AC20/UAC20(78 to 76)
this way this can be coded into MWO with just a couple XML edits,


and for instance an LBX20&HGauss20,
Slots = 8,//down from 11
 
TotalMechSlots -3,//adding back the 3 we lost from above
This will reduce the Max Mech slots by 2 for Every LBX20&HGauss20(78 to 75)
this way this can be coded into MWO with just a couple XML edits, and not heavy work,
(for HGuass just add some from the JJ Code to make them Torso Only)


this means:
Equipping a single AC20/UAC20 will reduce your max slots to 76(from 78)
Equipping a two AC20/UAC20 will reduce your max slots to 74(from 78)
-
Equipping a single LBX20/HGauss will reduce your max slots to 75(from 78)
Equipping a two LBX20/HGauss will reduce your max slots to 72(from 78)

this is how i would add it with out major reworks, ;)

Edited by Andi Nagasia, 23 September 2017 - 09:57 AM.


#20 Khobai

    Member

  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Elite Founder
  • Elite Founder
  • 23,969 posts

Posted 23 September 2017 - 09:57 AM

Quote

well i could code this into MWO right now but it would be Diet Crit Splitting,


but you dont work for PGI. its PGI being able to code it that matters.

like I said a more reasonable and better solution is just to make all weapons that are more than 10 crit slots only take up 10 crit slots.

my suggestion actually has a chance in hell of seeing the light of day. yours not so much.

Edited by Khobai, 23 September 2017 - 09:58 AM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users