Commanders v. 0.1

No, commander promotions do not replace warlord's ones. Commander promotions are promotions of GG unit itself. When you use lead action great general unit gets deleted. Combat units with warlord promotion still can get exclusive promotions like tactics, morale, medic III, etc.
Ah that makes sense. So to use a commander I assume you cannot attach him as a great general.

If that is the case...
My first impressions are that commanders will be much stronger than warlord units, at least for the human player. If the commander gets control points for battles won by units on the tile, he will probably accumulate points very quickly, even if it's only one per battle. Normally for units there is some limit to how quickly they can become highly promoted because they can typically only win somewhere between 1 and 3 xp from safe battles. Have you considered making commanders only receive control points based on a random chance whenever a battle is won? For example, each time a unit is victorious in battle, the commander has 10% chance of getting 1 point. Have you already done it this way?

I feel there are going to be a lot of balance issues that will need to be ironed out. Getting 0-4 first strikes for example, from the commander on all units on the tile seems like it will be very powerful. It would take 4 promotions on the commander, but that is basically the Drill IV promotion for every unit. IMO it is possible for first strikes to have an out of proportion effect on particularly strong units (e.g. knights).

Anyway, it would take some playtesting I guess, otherwise all of my comments are just heresay.

OK i'll ask you if something will go wrong. commanders use only getUnitHelp function in CvGameTextMgr i think there will be no conflict with ACO.

Yeah, I know it will be ok with Commanders. It's Defender Withdrawal (I think you've been calling it DWM) that I'm concerned about.
 
Have you considered making commanders only receive control points based on a random chance whenever a battle is won? For example, each time a unit is victorious in battle, the commander has 10% chance of getting 1 point. Have you already done it this way?
uh you messing control points with experience points.. control points determine how many units can get commander's help per turn. at born all GGs have 5 control points, it means that GG can command a maximum of 5 units per turn so he is able to receive 5 xp if all 5 units of his army has won their battles (Commander gets 1 xp for each battle being won by one of units controlled by him). I like your idea of introducing randomness (it is not there yet).

You'd better run my mod and place GG, some units and a bunch of barbs to see how it works. my english not so good thats why maybe there is misunderstanding. the idea behind the mod is very sipmle in essence.

Initiative is quite strong promotion, i thought of this too. maybe it has to be given prereqs, for example, morale2 for initiative1, tactics2 for initiative3, operations1 for initiative4. Operations is an another promotion that has to be given prereqs i think.

Spy mission "assassinate commander" may be introduced to nerf GGs.
 
uh you messing control points with experience points...
You're right. In that case, my comments are in regards to the experience points on commanders. Some mechanism should be put in place to ensure they don't accumulate those xp very quickly. I'll have a look at the mod to see what it's like.
 
Bug report: (CTD)

Gamesave attached.

To reproduce crash, select the northernmost GG. Attempt to attach it as a warlord to any of the swordsmen on the same tile. At that point I get a crash to desktop.

Let me know when you have the savegame because I will delete the attachment.

*************



Despite my earlier comments, the Operations promotion seems to be the most powerful promotion. With just Operations I, you can earn a possible 10xp per turn on the commander. Though it sacrifices getting one of the combat-boosting promotions early on. Getting xp was limited by how many battles you fought, encouraging you to limit your battles to when the commander was nearby.

Another comment I would make at this point is that this modcomp in its current form encourages the SOD (Stack of Doom) gameplay. I'm not sure if that's a good or bad thing yet.

Seems to be a well built modcomp overall, so :goodjob:.

If I were to include this in PIG I would prefer to make it an optional component (via the Custom Game menu). Since this mod is SDK based, I am quietly confident it won't be too hard, but I don't want to speak too soon either. Inclusion in PIG would also require that the AI has some understanding of how to use it - it sounds like you are already working on that. :D

EDIT... Attachment removed
 
Bug report: (CTD)
Gamesave attached.
I got it.
Thank you very much!
That were pointer fields pointing nowhere after GG got deleted by attaching to a unit.

I've also developed a promotion tree, so it is not possible now to get Operations I before level 5, that is 26 XP. Operations II can be got at 65 xp minimum etc. *Charismatic does affect levels.

If I were to include this in PIG I would prefer to make it an optional component (via the Custom Game menu). Since this mod is SDK based, I am quietly confident it won't be too hard, but I don't want to speak too soon either. Inclusion in PIG would also require that the AI has some understanding of how to use it - it sounds like you are already working on that. :D
Yeah, AI know how to use it now. I did not do much testing but it seems that it have no problem with commanders. Inclusion into PIG would be great! But there's an ACO+DWM problem still around (and also an another one with a new effect for Initiative IV, pretty the same). I think it's possible to compute an overall survival chance and show it to the bottom from battle 1 outcome statistics.
 
fix 1 to 1.0 beta was released.
  • Thanks KJ Jansson for fixing buttons gaphics!
  • Bug leading to CTD when attaching GG to a unit (tracked by PieceOfMind) was fixed.
  • Promotion tree was developed.
  • Initiative IV effect was changed.

DB page and file were updated.
post #1 was updated.
 
seriously, how did this even get half way down the first page :confused:

excellent modcomp, I'm glad to have it in the next release of ACW thanks to you.

And its no rush on fixing the AI to sometimes still use as a normal GG, its not really that big of deal, but something I'd eventually like to get fixed.
 
As it was revealed, AIs do not attach GGs to combat units in this version of mod.
Thanks to you Shiggs713 for finding this bug!

In 1.0 alpha version i plan to fix this bug and also develop AI in a few aspects for they to handle commanders better.
 


:D :rockon: :band:


they aren't options, but I figured worthy of being on the start up panel.
 
Killmeplease

As I wrote once before I find this very very interesting - in fact so much that I decided to spend quite some time yesterday trying to see if I could incorporate the mod in my own modified version of History in the making - something I have never done before as it involves changes to the dll and I have no experience here what so ever. Well after some hours of research I think I got the overall picture and went through the process of merging the Commanders mod in with the other source files.

The reason I'm writing is because I get a warning/error in cvunit.cpp that is from some of your code and I hoped you could either help me sove it or at least tell me if you experience the same.

For the line for "(int i=0; i<kPlayer.Commanders.size(); i++)" I get "warning C4018: '<' : signed/unsigned mismatch". The code I inserted is shown beneath and has been pasted directly into the other code at (I believe) the right place. I'll include the cpp file as well.

Spoiler :

//@MOD Commanders
CvUnit* CvUnit::getCommander() const
{
if (m_pUsedCommander != NULL) //return already used one if it is not dead.
//???? maybe also it have to be chosen an another commander if pUsedCommander get out of range
{
return m_pUsedCommander; //??error prone? commander can be already dead or settled or etc and not being NULL? although it seems no problem here - no crashes during testing.
}

int iBestCommanderDistance = 9999999;
CvUnit* pBestCommander = NULL;
CvPlayer& kPlayer = GET_PLAYER(getOwnerINLINE());

for (int i=0; i<kPlayer.Commanders.size(); i++) //loop through player's commanders
{
CvUnit* pCommander = kPlayer.Commanders;
CvPlot* pCommPlot = pCommander->plot();
int iDistance = plotDistance(pCommPlot->getX(), pCommPlot->getY(), plot()->getX(), plot()->getY());

if (pCommander->controlPointsLeft() <= 0 || iDistance > pCommander->commandRange())
{
continue;
}

if (pBestCommander == NULL ||
//best commander is at shorter distance, or at same distance but has more XP:
iBestCommanderDistance <= iDistance ||
iBestCommanderDistance == iDistance && pCommander->getExperience() > pBestCommander->getExperience())
{
pBestCommander = pCommander;
iBestCommanderDistance = iDistance;
}
}

return pBestCommander;
}

void CvUnit::tryUseCommander()
{
if (m_pUsedCommander != NULL) //this unit is already using some commander
{
return;
}

CvUnit* pCommander = getCommander();

if (pCommander != NULL) //commander is used when any unit under his command fights in combat
{
pCommander->m_iControlPointsLeft -= 1;
m_pUsedCommander = pCommander;
}
}

bool CvUnit::isCommander() const
{
return getUnitInfo().getLeaderExperience() > 0;
}

//1.0 beta fix 1
void CvUnit::nullUsedCommander()
{
m_pUsedCommander = NULL;
}

CvUnit* CvUnit::getUsedCommander()
{
return m_pUsedCommander;
}
//end fix
//end mod


Thanks for a really interesting mod - can't wait to try it out!

\Skodkim
 
they aren't options, but I figured worthy of being on the start up panel.
it looks awesome :cool: :D

The reason I'm writing is because I get a warning/error in cvunit.cpp that is from some of your code and I hoped you could either help me sove it or at least tell me if you experience the same.
warning is not an error so i have not paid much attention to it. but i definitely had to as my code could be used by others. Thanks you skodim for pointing it out.
To remove warning message, modify that line in such a way:
Code:
for (int i=0; i<[b](int)[/b]kPlayer.Commanders.size(); i++)
size() function return type is long and i variable is of type int, but by the logic of program, size will never be that big to generate an actual error (player will never has more than 32 million commanders).
 

Wow, how do make a panel like that?? I really like it! I can't even figure out how to get the DCM startup pane to show properly... SDK I can work with, but python is beyond me.
 
well i am not original creator, though I've edited it a bunch. Its the from revDCM in revolutionInit.py

you can see how he created it though the format is quite strict.
 
since the site made me double post and I didn't even click twice, I just thought I'd add that the most tricky thing about the python is making sure you have the alignment of the actual code correct. If you do spaces or incorrect tabs it always results in no interface.
 
Thanks for the fix Killmeplease.

It did the trick and even though as you point out it was just a warning I always like to keep these to a minimum.

\Skodkim
 
@ KillmePlease

In your code in CvUnit, this line:
Code:
for (int i=0; i<kPlayer.Commanders.size(); i++)
it comparing an int to an unsigned int, which is fairly safe, but just to be sure it's totally safe, you might want to cast the unsigned into an int, or vice versa. It also makes the compiler much happier. ;)
 
Hi

Just wanted tp say that I am currently playing my first game after I incorporated the Commander Mod.

No problems so far and it really makes the game more fun!!

\Skodkim
 
KillmePlease,

I've found an exploit with Great Commanders. I had 2 on the same tile, and when I attached one to a unit, the other general recieved free XP, like normal units do, which gave me several free promotions.

The fix involves a simple if check in CvUnit:giveExperience(...)
 
This looks really awesome! I would love to add it to the modmod I am working on. How would one go about adding this to an Orbis modmod? Since FfH and Orbis already have Defensive Withdrawals I have concerns because of the earlier discussion. How easy or difficult would this be?
 
Top Bottom