C2C Combat Mod Introduction - Step I (SubCombat Classes)

Thunderbrd · Apr 26, 2013

AIAndy said:
While the effects system would be useful for that it is still in the concept stage so it will take some time before anything is implemented (and it is not a small project).

Since I don't think you want to wait for that, the best approach is probably to have two expression system conditions, one evaluated on each combatant and an effect connected with that.
You might use a promotion to reference the effect. So at the beginning of combat you search for all such effects on both combatants (I assume they will be on promotion or unit type), then check if the conditions evaluate to true. If that is the case for both conditions, then you process the connected promotion and add it to an array. After the combat you process the promotions in that array backwards to remove the effect again.

hmm... So you're saying, you wouldn't want to compile those modifiers on the unit and maintain them as a complex array but rather compile only just before and after combat (or even just before combat odds evaluation and display).

Then tally what applies into a solid modifier and plug that into the odds evaluations (or whatever they apply to specifically) as needed. But it remains one floating array that gets cleared at the end of its need so as to remain in a default cleared status and not requiring a ton of constantly held memory. So in short it leads to some Extra processing, but a lot less memory consumption.

Sounds like something I can follow but its going to take understanding the next level of how you work out your expression system in the first place to achieve it I think.

It's hard to say how long it will take to get the planning solid enough to begin implementation. We may well have time for the effects system to go into effect. I presume with that, you're not talking about trying to convert ALL CURRENT tags as applied to that system right away but rather perhaps gradually convert selectively at first - while mostly leaving the new structure in place for the new stuff we want to do from here right? When you've got your mind applied to things you're a hell of a lot faster than I am at achieving things, mostly I think because you know exactly what you're doing and are not teaching yourself as you go.

Note to Hydro: This is a second post to keep the two conversations separate. It flipped pages here so I figured I'd let you know I responded to you on the last page.

Thunderbrd · Apr 26, 2013

GiuseppeIII said:
Expanding on the idea of Armor/Weapon breakage, we could have blacksmiths who could fix the weapons on the go. I'm thinking they would cost similar to what medical people cost and fixing your units in a city would be quicker but more time consuming.

Also is their an AI to support the combat mod

Interesting concept. That does tell me I should do the breakage under the suspended promotion development I had planned rather than just removing a 'broken' equipment outright. Would leave room open for such a unit to fix one broken equipment in the stack each round.

There is some AI to support the combat mod, yes, but there's still a list of things in that dept that will require developing out. Not so much that we cant begin fully planning out the xml implementation for when its ready and no tasks block us from figuring out what Combat Classes we'll need, creating them, and implementing those that would currently be meaningful. Thinking of Armors in this depth is probably thinking a bit too far ahead for now BUT it does help to think beyond where you are so as to make sure you plan the road between here and there effectively.

AIAndy · Apr 26, 2013

Thunderbrd said:
hmm... So you're saying, you wouldn't want to compile those modifiers on the unit and maintain them as a complex array but rather compile only just before and after combat (or even just before combat odds evaluation and display).

Then tally what applies into a solid modifier and plug that into the odds evaluations (or whatever they apply to specifically) as needed. But it remains one floating array that gets cleared at the end of its need so as to remain in a default cleared status and not requiring a ton of constantly held memory. So in short it leads to some Extra processing, but a lot less memory consumption.

Sounds like something I can follow but its going to take understanding the next level of how you work out your expression system in the first place to achieve it I think.

It's hard to say how long it will take to get the planning solid enough to begin implementation. We may well have time for the effects system to go into effect. I presume with that, you're not talking about trying to convert ALL CURRENT tags as applied to that system right away but rather perhaps gradually convert selectively at first - while mostly leaving the new structure in place for the new stuff we want to do from here right? When you've got your mind applied to things you're a hell of a lot faster than I am at achieving things, mostly I think because you know exactly what you're doing and are not teaching yourself as you go.

Note to Hydro: This is a second post to keep the two conversations separate. It flipped pages here so I figured I'd let you know I responded to you on the last page.

I would not want to go through the business of converting tags at all, so my suggestion was to add a new tag that in XML looks something like this:

Code:

<CombatEffects>
  <CombatEffect>
    <UnitCondition>
      <Has>
         ...
      </Has>
    </UnitCondition>
    <EnemyCondition>
      <Has>
        ...
      </Has>
    </EnemyCondition>
    <PromotionType>PROMOTION_COMBAT_EFFECT_X</PromotionType>
  </CombatEffect>
  ...
</CombatEffects>

Before combat you check if both expressions are true and if they are, you call processPromotion(PROMOTION_COMBAT_EFFECT_X, true). Remember that you did that by adding the promotion to that array I mentioned.
Then after combat you do the inverse: processPromotion(PROMOTION_COMBAT_EFFECT_X, false)

Hydromancerx · Apr 26, 2013

Perhaps they could be set to no armor combat class but be allowed to select the Light Armor promotion which opens things up for them. But I do agree on that last assertion. That would be one of the more advanced effects to eventually be enabled but has been planned for some time.

That sounds reasonable. Same idea could be done for say Archers where they get light armor but would have to take a promotion to get medium armor.

Oh absolutely, yes. But we would start with more a more basic approach by defining the differing types of mounted units as fast or slow. Elephants would be slow, horse archers fast, etc... this has other game bracketing effects but for armor it would certainly mean the slow mounted units would be more tending towards the heaviest armors, taking advantage of being able to protect their riders with heavier armor than one would want to walk any distance in, while the light ones would tend towards the lighter armors to keep up their speed.

Yeah you should see some of the historical Elephant Armors. They were amazing! It really made them like living tanks.

iArmorChange: Think of this as a percent modifier to the amount of damage the system would normally apply to a unit when that unit is struck in a round of battle. Thus this is basically a percentage value but can and should as it progresses exceed 100% and its opposing value, iPuncture, will grow somewhat in parallel in technological weapons development. Armor should also slightly exceed, on average, the equivalent contemporary levels of Puncture in the same age, variances making the system interesting. Thus an Axe with a very high puncture value of say, 25, negates the usefulness of say, a common Chain Shirt offering the unit 20 armor. But the arrows of the same era may have 10 puncture and thus the Chain Shirt reduces the Arrow's damages by 10% on each hit.

Yeah different types of armors would be good against different types of weapon damage.

iFatigue: Each point of fatigue is a % modifier that accumulates every round to the strength of the combatant. Thus even -1% over 10 rnds is a -10% combat modifier. Armors would obviously give cause for fatigue as they are simply more exhausting to fight in. Each point here is potentially very impacting, particularly if the opponent they fight is more heavily armored than their puncture amounts to (that extends the length of the combat # of rounds significantly) or if they don't have enough accuracy vs their opponent's dodge ability to land hits frequently enough to get the battle to completion fast enough before the fatigue really starts to impede them.

Oh I like this. So much potential.

Combat Class modifiers: You made a point about blunt, slashing, and piercing weaponry. The particular weapon a unit is using should add one of those three as a combat class to the unit. Thus the armor should have some combat modifiers against those using the combat class combat modifiers tag.

What each eventually become we should discuss.

And that reminds me that Blunt, Piercing, and Slashing should be Combat Classes on our document list...

Feel free to add that. Having a shared document like this can allow us to both brainstorm and enhance each others ideas.

I also have a few question/comments ...

1. How will equipment slots work? I know we have an armor, weapon and a shield slot. Are we going any deeper than that? Are we thinking about gloves, boots, helmets? Or are those included in the armor package?

2. I was thinking about mounted units. Do you think we should have the ability to "dismount" a mount? Such as a dismounted Horse Archer becomes an Archer. Or a dismounted Calvary becomes a Rifleman.

3. When it comes to culture units I assume they automatically get equipment. Possibly even special equipment. For instance if you have a Samurai unit but don't ave the materials for their unique armor what should be done?

Expanding on the idea of Armor/Weapon breakage, we could have blacksmiths who could fix the weapons on the go. I'm thinking they would cost similar to what medical people cost and fixing your units in a city would be quicker but more time consuming.

This is not a bad idea. This would be very useful for siege weapons to have "siege engineers" to help fix broken siege weapons.

Yudishtira · Apr 26, 2013

The weapons of an entire unit are not just here one day and gone the next. Weapon/armour damage would need to be gradual, meaning gradually declining attack and/or defence strength over time outside a city or outside your borders. Even move speed would decline for mounted units as they lost their horses/horseshoes etc.

I humbly suggest you not to go down this path. It's a whole heap of work for no gain. Better just to factor the durability/obsolescence of the various equipment into the strength of the unit or 'promotion' (as is already the case anyhoo).

Thunderbrd · Apr 26, 2013

Yeah different types of armors would be good against different types of weapon damage.

I also remembered after that last posting that I had put in an Armor adjustment vs combat class tag. As well as Precision vs Combat Class, Dodge vs Combat Class, Puncture vs Combat Class, Withdraw vs Combat Class and I think some others. Anyhow, those could be used rather than a base combat modifier for say, Additional Armor when facing a Blunt Combat Class unit for an armor that has better defense against blunt weapons than others. The inverse would work too...

I'd probably hold off on the equipment breakage and such until later in the project so for now those would be just as or more useful and we just assume equipments tend to be recovered or repaired after battles. Then later we can deepen things to that degree. To some extent, on this matter, perhaps Yudishtira is correct. Since the unit is many troops, not all would have shattered armor and you'd have a % wear on them to really reflect things accurately on breakages and that would be over the top. So breakage and repair mechanics would probably be best isolated as an sub-combat mod option eventually.

Oh I like this. So much potential.

Yeah, cool stuff. But there does need to be some additional factoring on this into the combat odds as displayed. Currently its one of the few factors I could not figure out how to properly modify the odds by. It would have to do with determining the likely # of rounds then apply the average of all the modifiers that would take place up to that point as a modifier to the end total of the odds calculation and that is all rather complex. But that's not to say it shouldn't be used... just another part of the project that needs to be done, more for the sake of the AI than the player even.

What each eventually become we should discuss.

Well... we can submit our ideas and consider them via the document and discussions here.

1. How will equipment slots work? I know we have an armor, weapon and a shield slot. Are we going any deeper than that? Are we thinking about gloves, boots, helmets? Or are those included in the armor package?

Well, this is a connection between Combat Class and PromotionLine. As it works with armors. You won't be able to have two armors at once because your units should only have one combat class associated with an armor category at a time. I don't think we should go to gloves and helmets, leaving them as part of the Armor package, though footwear may have a place in disease defense and movement effects. Just depends on HOW deep we want to go. Probably best to leave those for later design developments I think.

There would be tool categories though. Hunting supplies, ocular devices, animal training tools such as ropes. I'm sure we will eventually go far beyond just armor, shields and weapons.

2. I was thinking about mounted units. Do you think we should have the ability to "dismount" a mount? Such as a dismounted Horse Archer becomes an Archer. Or a dismounted Calvary becomes a Rifleman.

I have had fleeting thoughts on the subject. I agree but would need to do some real thinking on how to implement it so its a later stage design objective.

3. When it comes to culture units I assume they automatically get equipment. Possibly even special equipment. For instance if you have a Samurai unit but don't ave the materials for their unique armor what should be done?

Perhaps the unit should not only require the culture but also all the resources that would make up the minimum materials and tech to generate the equipments associated with them (that may also be culturally dependent.) This would not be much different to other unit prereqs in that the minimum materials necessary for such a unit would be the primary prerequisites outside of tech.

Also: I've been considering that a lot of the naming on our units currently utilizes a presumption of the type of weapons they use in terms of material. This would be able to vary, so is it conceivable we could eventually rename the units along the lines of their era? Prehistoric Spearmen, Ancient Spearmen, Classical Spearmen etc... rather than Stone Spearmen, Wood Spearmen etc... These namings then represent the improvements in strategy throughout the ages which is where the base strength and other similar factors to what are already on those unit definitions. Otherwise, current assignments of Unit Strengths and other base data as they are now should not have to be adjusted much or at all to make this equipment system work to provide more intermediary variations.

Just some discussion of eventual design goals there.

This is not a bad idea. This would be very useful for siege weapons to have "siege engineers" to help fix broken siege weapons.

I've often thought to separate the healing of siege weapons and normal units so that such siege engineers could be used as the healers for those. Again... another late stage project goal.

AIAndy said:
Before combat you check if both expressions are true and if they are, you call processPromotion(PROMOTION_COMBAT_EFFECT_X, true). Remember that you did that by adding the promotion to that array I mentioned.
Then after combat you do the inverse: processPromotion(PROMOTION_COMBAT_EFFECT_X, false)

Fascinating mechanism to consider. So with this kind of system, are you suggesting that we have 'promotions only for use in being processed in and out by these effects conditions' or that when using a promotion on a unit that has such a tag, only that tag should be utilized on such a promotion and the actual effect of the promotion is only processed in and out upon the need to check the conditions of it, thus also limiting us to using such a tag ON promotions? Or something I haven't considered about this structure still? My current understanding so far suggests its the first of those two, right? (Actually this method could be extremely useful in further developing for other planned applications now that I think about it...)

Would it be easiest, when using this sort of thing, to compile unit and promotion displays regarding these effects via a method similar to what you're using with the expression system stuff, which already doesn't sit too well with the promotion line compilations, or would it be even better yet to have to define a unique text display for any given defined version of this application and call on that display, which would also not play too well with the promotionline compilations any better really... ? Or is there a better way overall here for that?

AIAndy · Apr 26, 2013

Thunderbrd said:
Fascinating mechanism to consider. So with this kind of system, are you suggesting that we have 'promotions only for use in being processed in and out by these effects conditions' or that when using a promotion on a unit that has such a tag, only that tag should be utilized on such a promotion and the actual effect of the promotion is only processed in and out upon the need to check the conditions of it, thus also limiting us to using such a tag ON promotions? Or something I haven't considered about this structure still? My current understanding so far suggests its the first of those two, right? (Actually this method could be extremely useful in further developing for other planned applications now that I think about it...)

The first. The "promotions" for this would not be real promotions but just a way to apply temporary changes to a unit's capabilities. Then you can have the CombatEffects tag on real promotions or unit types.

Would it be easiest, when using this sort of thing, to compile unit and promotion displays regarding these effects via a method similar to what you're using with the expression system stuff, which already doesn't sit too well with the promotion line compilations, or would it be even better yet to have to define a unique text display for any given defined version of this application and call on that display, which would also not play too well with the promotionline compilations any better really... ? Or is there a better way overall here for that?

I have not thought about that yet. Personally I think we would be better off in general if the promotion lines behavior would get changed so the promotions in the line don't add up but instead only the last promotion in the line that you have would be active (and include all effects in its XML).

But in general such a tag is not easy to display as you have two expressions that determine if it is active and then you have to display the effect.

Thunderbrd · Apr 26, 2013

The first. The "promotions" for this would not be real promotions but just a way to apply temporary changes to a unit's capabilities. Then you can have the CombatEffects tag on real promotions or unit types.

It would take a bit of work to keep those pseudo-promos out of the pedia displays and such would it not? Or do you have an easy way to make them inactive for that?

I have not thought about that yet. Personally I think we would be better off in general if the promotion lines behavior would get changed so the promotions in the line don't add up but instead only the last promotion in the line that you have would be active (and include all effects in its XML).

But in general such a tag is not easy to display as you have two expressions that determine if it is active and then you have to display the effect.

Generally I think what Koshling did there was brilliant but it doesn't work well with some of your tag methods. Perhaps on yours we could add another, perhaps boolean, tag to explain to the code to compile this in a different way? What you're suggesting there is what I had initially considered which was to rewrite all promos and have the steps up actually replace the previous one. But there are some benefits to this current methods that I've discovered along the way, particularly in making prerequisite fulfilling a bit easier.

As for a tag on this, it would seem to me that the easiest way would be to create a full text reference for each use of this structure and call on that to be included in unit/promo help lists. May not be very clever but it would work and take a lot less time to do that than it would to try to think out how to get everything to potentially come together in an automated display. In the combat help, these effects would be processed in at the beginning of the evaluation as well so would display as if the effect were present... that's not too rough at all for that end.

Hydromancerx · Apr 26, 2013

Also: I've been considering that a lot of the naming on our units currently utilizes a presumption of the type of weapons they use in terms of material. This would be able to vary, so is it conceivable we could eventually rename the units along the lines of their era? Prehistoric Spearmen, Ancient Spearmen, Classical Spearmen etc... rather than Stone Spearmen, Wood Spearmen etc... These namings then represent the improvements in strategy throughout the ages which is where the base strength and other similar factors to what are already on those unit definitions. Otherwise, current assignments of Unit Strengths and other base data as they are now should not have to be adjusted much or at all to make this equipment system work to provide more intermediary variations.

Just some discussion of eventual design goals there.

I have to think on this one.

Thunderbrd · May 26, 2013

AIAndy said:
If you want most combat classes to have an associated free promotion, then no, we shouldn't add extra tags on the combat classes themselves. But I think if we have some tags (mainly against what other combat classes it is strong or weak) then we can have a lot of combat classes without free promotion and that would be worth it imo.

@AIAndy AND Koshling: While the more I think on this, and noting that you've now setup a proper Class for Combat Class tags, the more I think this is a very good way to address very generic issues such as combat modifiers between CC types, I'm a bit intimidated by the AI implications and how it would force us to have to adapt the AI to understand the values on these tags and what they mean to the units they are evaluating for building.

So this is why I address both of you in this. I'd love to use some general tags on the CombatClass class but how would we be best to go about getting the AI up to speed if we were to do so this way?

Koshling · May 27, 2013

Thunderbrd said:
@AIAndy AND Koshling: While the more I think on this, and noting that you've now setup a proper Class for Combat Class tags, the more I think this is a very good way to address very generic issues such as combat modifiers between CC types, I'm a bit intimidated by the AI implications and how it would force us to have to adapt the AI to understand the values on these tags and what they mean to the units they are evaluating for building.

So this is why I address both of you in this. I'd love to use some general tags on the CombatClass class but how would we be best to go about getting the AI up to speed if we were to do so this way?

The AI already understands the differences between combat class modifiers in the way they modify combat odds, simply because it uses the odds to determine which units to attack and defend with. It also already does NOT understand this at a more general level (i.e. - that pikes have bonuses against mounted say) which might cause it to formulate appropriately mixed stacks (so that a variety of units are available at combat time for its odds calculation to draw on). Since it already operates this way, I don; really think there is anything new here. It will make appropriate use where the units happen to be present, and will continue to have the weakness of not necessarily making those units present in the optimal places, until such time as we write code to cause it to do so (which isn't qualitively changed by this).

BTS relies on AI_types to get appropriate stack mixes, but that has rather broken down in C2C, because of the greater variance in capabilities of units (so it doesn't correlate as directly to AIType as it did in base BtS). Sometime this will have to be addressed, but I don't think what you are proposing really changes the equation one way or another to any significant degree.

strategyonly · May 27, 2013

nvrmnd mis read it.

Koshling · May 27, 2013

strategyonly said:
So should WE then put a default limit on stacks, and then the player can decide to move it if he/she wants to, that way WE have it at the BEST results possible?? And if they move it, its on their own reconisis?

Say what?

Nothing to do with stack limits. It's to do with the larger variance in unit capabilities (as compared to base BtS) that makes the lack of aspects of AI more significant in C2C. Nothing that can be done about this apart from either making he units less varied (which would be totally anti-C2C-ethos) or (sometime) writing new AI to handle it.

IMO, it's not (yet anyway) a major problem

Thunderbrd · May 27, 2013

Koshling said:
The AI already understands the differences between combat class modifiers in the way they modify combat odds, simply because it uses the odds to determine which units to attack and defend with. It also already does NOT understand this at a more general level (i.e. - that pikes have bonuses against mounted say) which might cause it to formulate appropriately mixed stacks (so that a variety of units are available at combat time for its odds calculation to draw on). Since it already operates this way, I don; really think there is anything new here. It will make appropriate use where the units happen to be present, and will continue to have the weakness of not necessarily making those units present in the optimal places, until such time as we write code to cause it to do so (which isn't qualitively changed by this).

BTS relies on AI_types to get appropriate stack mixes, but that has rather broken down in C2C, because of the greater variance in capabilities of units (so it doesn't correlate as directly to AIType as it did in base BtS). Sometime this will have to be addressed, but I don't think what you are proposing really changes the equation one way or another to any significant degree.

It still changes the power equation doesn't it? But then I suppose the ability to take 'free promos' into account is also pretty much lacking there too right?

Ok, so in otherwords, its something we should eventually account for but its already a major deficiency so don't let that stop us.

Now the trick will be to get those effects onto the unit like promos but tallying up into the BASE unit details as they should show if you're looking at the unit and considering it for your own build decisions.

Maybe we need to combine their values into the unit once the individual unit in the game is initiated and in the meantime, throw together a mechanism at the end of the individual unit help section that parses a 'From Combat Classes:' section into the BASE unit definition's help hover so that when a player is considering training a unit, they get to see what they're going to have once trained and not be setup for big surprises.

And I'll have to write a new processing function for the CCs that gets called immediately for units when they are built or otherwise take their intial definitions. This is pretty much what happens in init right? When to process in and when to process out when units are being removed and reconstructed is going to be a bit of a trick to sort out...

Also, this will mean that the Combat Class pages in the pedia will be needing some updating further :scan:

Koshling · May 27, 2013

Thunderbrd said:
It still changes the power equation doesn't it? But then I suppose the ability to take 'free promos' into account is also pretty much lacking there too right?

The 'power equation' ?

Thunderbrd · May 27, 2013

The overall value of the unit in general? If a unit gains +50% vs another Combat Class, it could be getting that from its Combat Class modifiers, a promotion, a free promotion, or has it on its base assigned value. If it gets it from an earned promotion in the game, it doesn't really make any difference to how valued the unit is perceived to be when the AI considers whether to build it, but it SHOULD be considering Free Promos and CCs. As I understand it we're still building out the ability for it to consider the Free Promos but the CCs would be totally invisible. And I wonder how much it even takes these base values into consideration. If I'm not mistaken, it does not currently take into account all unit tags, is that right?

Koshling · May 27, 2013

Thunderbrd said:
The overall value of the unit in general? If a unit gains +50% vs another Combat Class, it could be getting that from its Combat Class modifiers, a promotion, a free promotion, or has it on its base assigned value. If it gets it from an earned promotion in the game, it doesn't really make any difference to how valued the unit is perceived to be when the AI considers whether to build it, but it SHOULD be considering Free Promos and CCs. As I understand it we're still building out the ability for it to consider the Free Promos but the CCs would be totally invisible. And I wonder how much it even takes these base values into consideration. If I'm not mistaken, it does not currently take into account all unit tags, is that right?

The valuation routines the AI uses are:

CvPlayerAI::AI_unitValue() and CvUnitAI::AI_genericUnitValueTimes100()

Both of these take account of promotions (whether free or bought it makes no difference). If there are tags that should be taken account of that are not then these are the routines that need them, but they already handle combat class modifiers I think.

Edit - however, only the second of those routines can take account of things not intrinsic to the unit, and it only operates on existing units when determining how to use them. The issue is that the first routine (which is used to decide what to build) runs without any information about EXTRA bonuses a unit will get from non-intrinsic effects (free promotions from buildings or traits generally)

Thunderbrd · May 27, 2013

They do but they don't take modifiers FROM Combat Classes as a source, so we'd want to include them there too.

And if it takes account of promotions, it can't take account of promotions the unit doesn't have yet. Do those value the unit for the purpose of making comparisons between different unit selections that might be built for a particular purpose?

Koshling · May 27, 2013

Thunderbrd said:
They do but they don't take modifiers FROM Combat Classes as a source, so we'd want to include them there too.

And if it takes account of promotions, it can't take account of promotions the unit doesn't have yet. Do those value the unit for the purpose of making comparisons between different unit selections that might be built for a particular purpose?

The latter is used to make combat decisions for existing units. The former is used to decide on what to build. It is the former that needs the most work, to take account of any promotions the units built in a particular city will get for free from buildings or traits.

Thunderbrd · May 27, 2013

Koshling said:
The latter is used to make combat decisions for existing units. The former is used to decide on what to build. It is the former that needs the most work, to take account of any promotions the units built in a particular city will get for free from buildings or traits.

Wow... not taking account of either one as it is now huh? Ulph. Yeah, a lot of work to update all that. :rolleyes:

Sheesh. So since its not taking those into account now, adding values by Combat Class itself really couldn't hurt anything at the moment anyhow. Might be a good thing to get such a change setup soon so that it preps us for adding that into our task list for teaching the AI when we get around to focusing more on that major effort.

OK, I'll be looking at doing this very soon then. My current project of adding the Throwing Combat Class has revealed how useful this would be. I'd like to give some generic modifiers for units against them based on purely their combat classes alone.

For example, I'd like to make Mounted gain +25% against the Throwing Combat Class without having to go through each and every mounted unit adding that. And I'd like to (once we have it) give the Fast Combat Class another +25%, thus we get +50% total on Fast Mounted units.

We already consider our units in similar ways and establish basic generic guidelines. It would be nice to start 'enforcing' those guidelines as gamerules. While its a bit to convert to, it'd make things a lot simpler to setup and maintain.

C2C Combat Mod Introduction - Step I (SubCombat Classes)

C2C War Dog

C2C War Dog

Deity

C2C Modder

Spiritual/Creative

C2C War Dog

Deity

C2C War Dog

C2C Modder

C2C War Dog

Vorlon

C2C Supreme Commander

Vorlon

C2C War Dog

Vorlon

C2C War Dog

Vorlon

C2C War Dog

Vorlon

C2C War Dog

Similar threads