[SDK] Lead from Behind

[phungus420]

I've asked repeatedly for battle efffects to be removed from RevDCM, I don't understand why they are in, or who uses them... They are just sections of code that can cause problems as far as I'm concerned.

 

[Afforess]

I've asked repeatedly for battle efffects to be removed from RevDCM, I don't understand why they are in, or who uses them... They are just sections of code that can cause problems as far as I'm concerned.

I agree. I'm not even sure that they even work at all, and they cause OOS in MP, so they really should just be pulled. It sounded like a good idea for a mod at the time, but in retrospect...

 

[keldath]

hi there, first of all, great mod!

i need some help: in the cvselectiongroup.cpp,

theres this section:
// if there are no defenders, do not attack
// UncutDragon
// original
//CvUnit* pBestDefender = pDestPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), pBestAttackUnit, true);
//if (NULL == pBestDefender)
//{
// return false;
//}
// modified
if (!pDestPlot->hasDefender(false, NO_PLAYER, getOwnerINLINE(), pBestAttackUnit, true))
return false;
// /UncutDragon


what will happen if i reactivate this line:
CvUnit* pBestDefender = pDestPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), pBestAttackUnit, true);

cause i have dale combat mod (battle effect - that are using the " pBestDefender",
is it crucial if i uncomment this?

same goes for this part - i had to comment it out:
// UncutDragon
// original
//CvUnit* pDefender = pLoopPlot->getBestDefender(NO_PLAYER, pAttacker->getOwnerINLINE(), pAttacker, true);
//if (pDefender == NULL || !pAttacker->canAttack(*pDefender))
// modified
//commented out by me if (!pLoopPlot->hasDefender(true, NO_PLAYER, pAttacker->getOwnerINLINE(), pAttacker, true))
// /UncutDragon




thanks for the mod , and hopefully help.
keldath

 

[UncutDragon]

what will happen if i reactivate this line:
CvUnit* pBestDefender = pDestPlot->getBestDefender(NO_PLAYER, getOwnerINLINE(), pBestAttackUnit, true);

Basically, the game will run a bit slower ... it's purely a speed improvement.

getBestDefender determines the best defender - so it has to loop through all units on a tile, comparing each to the 'best so far'. hasDefender on the other hand returns as soon as it finds a (valid) defender - no comparisons to do, and (possibly) a lot less units to consider.

I haven't looked at Dale's code, so not sure which methods have the conflict. The critical one though is in CvUnit.cpp/canMoveInto - that one cuts the time required for stack combat in half. Removing the others didn't have a noticeable affect - at least on stack combat ... how much of an impact they have on the game in general I can't say.

I do know (from above comments) that others are simply removing the battle affects and using my code instead - but of course it's up to you.

 

[keldath]

hi, thanks for the answer first,

yeah , i can remove the b-effect code,

but i the second comment i wrote you, was of neval bombardment i think, so that would be a bit of a problem i think.

the trouble i had was with cvunit.ai and the selection thing.

others have tryed to merge this with revdcm?

so your saying it will slow my game, humm....tough call.

 

[Roland Johansen]

The formula doesn't really do what you want (or what I think that you'd want). For instance:
-a 40 xp unit (value 3) at 60% odds will defend before a 0 xp unit at 35% odds.
-a 40 xp unit (value 3) at 75% odds will defende before a 0 xp unit at 60% odds.

lol ... I have one saying it's adjusting too much, and one that it's adjusting too little ... I must be doing something right

A bit late response...

Shouldn't valuable units never defend when their odds of victory are not that great? I'd think that most players would prefer the situation where a lesser unit with low odds of victory defends and is sacrificed before a valuable unit is put in serious danger. Most people will prefer to lose the 0 xp unit than lose the 40 xp unit in the above case. Don't you agree?

 

[UncutDragon]

A bit late response...

Shouldn't valuable units never defend when their odds of victory are not that great? I'd think that most players would prefer the situation where a lesser unit with low odds of victory defends and is sacrificed before a valuable unit is put in serious danger. Most people will prefer to lose the 0 xp unit than lose the 40 xp unit in the above case. Don't you agree?

Yes, I agree the adjustment needs to be increased, I just haven't had much time to look at it lately. Using the square of the difference might make sense, but I'm actually thinking it may be the value that needs to be squared instead.

In any case, I will be playing with the numbers to see if I can come up with a more 'reasonable' formula to use.

 

[Cybah]

any news?

 

[UncutDragon]

any news?

Sorry, just haven't had time lately. (My wife sells toys, so as you can probably imagine, the months leading up to Christmas are crazy busy!) I should have a chance to work on it some more now though.

 

[os79]

I'm playing with it in RoM's AND by Afforess. It is an awesome modcomp! I can't tell you how many times my important units are saved by this modcomp! I don't know how it can be improved but if it can be, then go for it! And welcome back!

 

[civ editor11]

I'm forced to agree with os79 I doubt theres much you can do to make this better its already almost perfect

 

[UncutDragon]

Well, thanks guys! Honestly, I don't see doing very much to it, just tinkering with the amount of the adjustment. Currently, we have:

(odds-98)*(value/5)

I'm looking at something like:

((odds-98)-25)*(value/5)^2

(for odds < 98)

Though I'd probably make some new parameters so you can change that as well - so if someone only wants a small adjustment, they can do that (without having to touch the code).

 

[Fimbulvetr]

As of revision 523, this is now part of Better AI. I have not yet merged it into my own mod yet, as I'm a bit afraid of stuff that actually changes basic game rules - and this modcomp does if a stack no longer gets defended by the unit with the best combat odds.

One big question I have: Is staying behind of valuable units based on winning odds or on survival odds?
ie: Does a super valuable unit (with the best combat odds of all possible defenders) hide behind everyone else if it has 100% survival chance but a bad chance to actually win the battle?

 

[UncutDragon]

As of revision 523, this is now part of Better AI. I have not yet merged it into my own mod yet, as I'm a bit afraid of stuff that actually changes basic game rules - and this modcomp does if a stack no longer gets defended by the unit with the best combat odds.

You could actually use the mod and set all the LFB_BASEDON... flags to 0. That would have the effect of computing the 'value' of all units as 0, so the odds are never adjusted. Though it would technically still affect game play since it would pick the best unit according to the actual combat odds instead of a rough estimate based on strength.

One big question I have: Is staying behind of valuable units based on winning odds or on survival odds?

I'd say 'winning' is more accurate ... combat basically has 4 possible results:

1) Defender dies
2) Attacker retreats (after dealing max damage)
3) Attacker withdraws (avoiding death)
4) Attacker dies

The odds used would cover the chance of results 3 or 4 happening. 'Survival' odds would have to include 2 - but all units have a 100% chance of survival against a siege engine (or any unit with a max damage), so that would be a pretty useless figure to use. Although I guess you could argue that a value adjustment isn't needed in that case (i.e: still use odds of 3 or 4 happening, but don't adjust them).

 

[Fimbulvetr]

Yes, I argue it would make sense for the very best unit to defend against a siege unit, even if 'winning' odds are pretty low, no matter how valuable it is.

 

[UncutDragon]

It's not something I'd really considered before, but after giving it some thought I have to agree.

Since there's no risk of death, you'd only be keeping them out to avoid damage (saving them for later ...). And I just can't see that being a strong enough rationale ... especially since units with a max damage generally also deal collateral damage.

So seeing as you're only risking some damage (that you might take regardless), seems pretty clear the best strategy (in general) would be to go with the strongest defender (best unadjusted odds) to try to take out that siege engine.

I'll see about making that change.

 

[Fimbulvetr]

Nice ^^
And while you're at it:
The chance of 4) to happen should be the only factor for a valuable unit not to attack, just as
the chance of 1) to happen should be the only reason for a valuable unit not to defend.
Just in case it isn't working like that already for the attacker.

 

[UncutDragon]

OK, took awhile, but new version is now up!

It includes the above changes discussed with Fuyu (making value adjustment based on chance of surviving - instead of chance of winning). So no value adjustment for defending against siege engines - and best attacker code now factors in chance of withdrawing.

I also changed the value adjustment - the old adjustment was:

(odds-990)*(value/5)

the new adjustment is:

(odds-990)*(value/3)^2

For value 1, that's actually a reduction in the adjustment - but with the square factor in there it increases quickly. This makes each step up in value 'worth' much more than before.

Note that the above is actually the default - I added two new config settings for numerator and denominator, so the actual value adjustment is:

(odds-990)*(value*numerator/denominator)^2

This makes it easy for you to change the degree of adjustment to suit your own preference.

(Note that this *should* be the last update - I have no plans to make any more changes ...)

 

[_alphaBeta_]

@UncutDragon: Are the previous versions of your mod available anywhere (they're useful for maintaining mod merges)? If not, can you (or someone else) make them available temporarily? I have versions 1.1 and 1.2, and I assume there was a 1.0 at some point. Was there anything before 1.0?

Excellent mod by the way.

 

[Fimbulvetr]

If you just want to update Better AI, 1.1 is all you need since that should be the version jdog used.