C2C: Promotions

[Thunderbrd]

It IS part of the combat mod. I'd actually intended it to be even a touch stronger than those suggested numbers, but the same basic plan. +5% per turn to a max of 5 turns for each step along the Trench line (each being a total possible additional defense of +25%.) The tag for that is iDigIn for base unit ability and iDigInChange for promos.

Although powerful, the trump ability an attacker could develop would be iOverrun (iOverrunChange for Promos.) The value of a unit's Overrun ability would equate to a reduction in the defender's overall fortification defense value(s). Thus if I had a 50 Overrun and I was up against a Defender who was gaining 100% Combat Bonus from Fortification in total, when I attack, the Defender only gains 50% Combat Bonus (100% - 50%)

Tanks and Elephants and such that could charge through and destroy fortifications as they went would be the type of units that could gain Overrun and Infantry and such would be the types to gain DigIn abilities.

It's available for use on the SVN now but as Koshling has pointed out, it could probably use some AI work on a strategic level. It does favor the right type of units for the promo selections though so probably wouldn't be TOO bad for now. Just that the AI should really consider the moving/fortifying of DigIn skilled units more carefully.

Ah... one more note: Trench was also intended to receive the iFortCollatDefChange tag too... maybe 5% per level. This builds up the unit's resistance to collateral damage per round fortified and Overrun also counters its built up resistance value in the same way as basic fortification.

 

[ls612]

It IS part of the combat mod. I'd actually intended it to be even a touch stronger than those suggested numbers, but the same basic plan. +5% per turn to a max of 5 turns for each step along the Trench line (each being a total possible additional defense of +25%.) The tag for that is iDigIn for base unit ability and iDigInChange for promos.

5% seems like enough to start, given how much defense a unit can build up already if it is in the right place. I generally think in C2C that the defender is more favored already than it should be. I understand that there will be other things coming that may change that but for now I'd like to start small.

 

[Thunderbrd]

If you aren't using Overrun and Knockback to counter it, I'd agree that a 1 value on Dig In (which equates to +1% Combat Modifier per round fortified plus the base 5% per round with a limit of 5 rnds to maximum) is probably capable of staying within game balance and any more would be pretty rough on attackers.

S&D also plays into the picture as a counter to defender positions that usually works so well that it allows me to invade cities before I can even knock down the city defense %. In the field its absolutely lethal.

But then again, it, too is an option that still needs some ai work.

 

[ls612]

If you aren't using Overrun and Knockback to counter it, I'd agree that a 1 value on Dig In (which equates to +1% Combat Modifier per round fortified plus the base 5% per round with a limit of 5 rnds to maximum) is probably capable of staying within game balance and any more would be pretty rough on attackers.

S&D also plays into the picture as a counter to defender positions that usually works so well that it allows me to invade cities before I can even knock down the city defense %. In the field its absolutely lethal.

But then again, it, too is an option that still needs some ai work.

I'll be implementing the SAD modifiers once Koshling writes AI for it (which he said he intends to do this cycle). I still would like most of the Combat Mod stuff to be optional though, this is just the stuff I like.

 

[Thunderbrd]

As I've said before, surely not ALL of it would need to be optionalized. I'm quite happy for you to determine what you feel would benefit the 'core'.

 

[Hydromancerx]

@Thunderbrd & ls612

So Thunderbrd has talked about many cool features in the Combat mod for months now. When will we see some of them implemented? Or should I say which feature will be implemented first?

 

[Thunderbrd]

I've made a major breakthrough that will enable a lot more of the combat mod to go into development soon. More on that when I'm ready to commit.

It will apply to traits first, and my first priority is getting the traits developed properly for the Developing Leader option. But as soon as I'm done with that, I can get back and start applying the method as proven there for traits and wrapping up the coding loose ends for the combat mod and it can then go into full xml production. Might still be a version or two before I can get any actual application.

In the meantime, if ls612 wants any of it for the core application, with some discussion between us, he could work some of that out for the main mod. Most of the combat mod is prepared for xml application with the exception that AI work needs to be done on a lot of it still, as noted in the last few posts.

 

[ls612]

I've made a major breakthrough that will enable a lot more of the combat mod to go into development soon. More on that when I'm ready to commit.

It will apply to traits first, and my first priority is getting the traits developed properly for the Developing Leader option. But as soon as I'm done with that, I can get back and start applying the method as proven there for traits and wrapping up the coding loose ends for the combat mod and it can then go into full xml production. Might still be a version or two before I can get any actual application.

In the meantime, if ls612 wants any of it for the core application, with some discussion between us, he could work some of that out for the main mod. Most of the combat mod is prepared for xml application with the exception that AI work needs to be done on a lot of it still, as noted in the last few posts.

Does this mean we could use 2 sets of traits; the sgtslick set and my set? That would solve many problems IMO.

 

[Thunderbrd]

Yes. This does mean we can use Slick's as default, then yours and mine as options. I'm in the final stages of preparing to push the change to the SVN that enables this too. I've left the development of your option up to you but if you like just let me know what you want it to be named and I can put it on the option list. I just figured you might wanna do it yourself to have another practice shot at creating one. My optional set will be called Complex Traits.

Once the option is established, the rest is all xml work from there Very easy to apply but overuse could certainly end up overwhelming the load times so we'll have to be a 'little' selective about what can be done this way and what shouldn't be. Generally speaking, a couple of optional traits sets shouldn't slow things down much at all.

One of the things I'll be doing afterwards, however, is developing out another list of trait tags that you may want to wait for to finalize your design with. I am compiling that list now and by the end of it I believe I'll be calling the traits section good for tags for a long time to come.

All in all, my goal on this team has never been to irritate others by enforcing they play under rules they don't like. Even the promotion obsoletion system is something I'll optionalize once its use has shown us where our current promo structures are irrational as they are and those irrationalities have been repaired. I understand that every player is different in their preferences, that if you put 100 players in a room together you'll never find two that would appreciate all the same options...lol. So to me, enhancing our ability to optionalize C2C is a huge priority.

This can apply to so much we already have in the game that creates disagreement... for example, it won't be difficult to make Alternative Timelines an option rather than through a modular structure that new players are intimidated to manipulate to play the way they prefer.

But the test run here is on traits and you'll be able to jump on that development before I can because I've got some more to do before I can re-envision a whole trait structure. So you can be a pioneer in using this system for us.

 

[ls612]

Yes. This does mean we can use Slick's as default, then yours and mine as options. I'm in the final stages of preparing to push the change to the SVN that enables this too. I've left the development of your option up to you but if you like just let me know what you want it to be named and I can put it on the option list. I just figured you might wanna do it yourself to have another practice shot at creating one. My optional set will be called Complex Traits.

Once the option is established, the rest is all xml work from there Very easy to apply but overuse could certainly end up overwhelming the load times so we'll have to be a 'little' selective about what can be done this way and what shouldn't be. Generally speaking, a couple of optional traits sets shouldn't slow things down much at all.

One of the things I'll be doing afterwards, however, is developing out another list of trait tags that you may want to wait for to finalize your design with. I am compiling that list now and by the end of it I believe I'll be calling the traits section good for tags for a long time to come.

All in all, my goal on this team has never been to irritate others by enforcing they play under rules they don't like. Even the promotion obsoletion system is something I'll optionalize once its use has shown us where our current promo structures are irrational as they are and those irrationalities have been repaired. I understand that every player is different in their preferences, that if you put 100 players in a room together you'll never find two that would appreciate all the same options...lol. So to me, enhancing our ability to optionalize C2C is a huge priority.

This can apply to so much we already have in the game that creates disagreement... for example, it won't be difficult to make Alternative Timelines an option rather than through a modular structure that new players are intimidated to manipulate to play the way they prefer.

But the test run here is on traits and you'll be able to jump on that development before I can because I've got some more to do before I can re-envision a whole trait structure. So you can be a pioneer in using this system for us.

How will this work? Will the extra XML be in our modules or in the Core with different names? Also, how will the fact that you can only use one set of traits at a time be enforced? IE, how will you make sure no one uses Complex Traits and whatever I name my option at the same time? That I'm sure would cause errors.

 

[Dancing Hoskuld]

How will this work? Will the extra XML be in our modules or in the Core with different names? Also, how will the fact that you can only use one set of traits at a time be enforced? IE, how will you make sure no one uses Complex Traits and whatever I name my option at the same time? That I'm sure would cause errors.

If you are using the WoC standard for XML there should be a tag AndNotGameOption which you can use. It would have the effect of turning both off if both options were on. We don't have a way it enforce either/or situations at the XML or MLF level. IT would not be perfect but it would be better than having both on from what I have seen.

 

[Thunderbrd]

How will this work? Will the extra XML be in our modules or in the Core with different names? Also, how will the fact that you can only use one set of traits at a time be enforced? IE, how will you make sure no one uses Complex Traits and whatever I name my option at the same time? That I'm sure would cause errors.

It wouldn't cause errors, one would simply override the other (whichever was found first in the check for valid option edits.) More on that later but I do have it in mind to see if I can make it possible to make it impossible to select two incompatible options and make it mandatory to have an option selected if you are going to select an option that requires it... a couple small projects I'm also working on to keep that sorted out properly.

In the XML, you'd write the redesigned trait in full in the core traitsinfo.xml file (though you COULD do this via a module if you wished) and use some designated tags that state if the game is playing under the stated option then the designated trait is replaced entirely by this one.

The only tags that cannot be redesigned for replacement are the most basic ones, the description, name and button - which I'm hoping I might even be able to figure out later but for now its ok to have that one weakness in the structure. The problem with those is they load through a much more genericalized loading structure that makes it tough to identify that we're even loading for a trait rather than any other particular game object. Perhaps AIAndy or Koshling could assist in that region but the coding there confused me a bit as to how I could get those base tags to work.

You'll also have an OnGameOption and NotOnGameOption tag to assist here. Much as DH suggested below. You'd always want to indicate that your optionedit entry is only to be utilized on the game option its activated under. And also with the OnGameOption tag, you can add traits that would not appear under any other option that aren't actually even edits of core existing traits.

I'll show you the xml very explicitly once I've pushed the change.

If you are using the WoC standard for XML there should be a tag AndNotGameOption which you can use. It would have the effect of turning both off if both options were on. We don't have a way it enforce either/or situations at the XML or MLF level. IT would not be perfect but it would be better than having both on from what I have seen.

It's not on all classes unfortunately. I've had to add OnGameOption and NotOnGameOption to the traits class and I believe I added them to promotions as well. I'm hoping they're already on and functional for Units, Civics and Buildings so that I don't have to mess with that step when I get to making it possible to option edit those. The use of OnGameOption is an essential step to making the option edit structure to work properly.

 

[strategyonly]

Just noticed that the promotion Heroic II is done quite well, infact, it is the opposite of what you think it is, i think, it takes away per turn when it is activated, for killing a person/unit. Its not much but this happens to be quite relevant really, at least i think so????

screenies: During and then after

 

[charlesb96]

Where do all Y'all get the pictures for the promotions? I have some ideas for new promotions but no pictures or icons to use.

 

[Thunderbrd]

We make them.

What are your ideas?

 

[charlesb96]

extending the Great General Commanders promotion line. Two lines, General staff, adds 1% strength per level, and Command, adds 1 command point per level. Level 2, 3, and 4 just require the previous level, but level 5, 10, etc, require both General Staff and Command 4, 9, etc. This is to prevent from just adding the General Staff for the strength, you can only get to level 4 then you have to do the Command promotion.

 

[Thunderbrd]

I've often thought the Command point expansion by promo would be a good idea. Isn't there already a promo line that gives + Combat Strength Modifier (%) though?

 

[charlesb96]

Operations gives command points and range, morale gives strength. These two just give 1% or 1 command point, a small boost like a real General who has reached his acme and just gains small tweaks, mostly from his troops respect and admiration. But he can still get some promotions and not cap out.

 

[Thunderbrd]

I see... advanced promos that don't give as much so to speak. hmm... May not be a bad idea overall. What do others think?

 

[sp00n]

Advanced as in "after" or "instead"?
Instead, certainly no, and as for after, I'm not sure. I'd regard that as nice to have, but there are more pressing concerns. Especially since it already does quite take a while to get a commander to full range and points (which will always be the priority, so that he'll level faster).

There could be some special promotions with more variation though, like for the hero units, i.e. amphibious attack, or chance of survival, use enemy roads, etc.