@Thunderbrd: I'm not with the very latest SVN version but regarding the stack freeze after an attack, I noticed that after an attack, the attacking unit is not split off from the stack. In other words, if I re-select the stack, and wake it up, the unit that attacked is still part of the stack (and on zero movement points if it only had one). If the attacking unit dies, there is no problem but if the attacking unit survives, the stack freezes afterwards. So I'm guessing that the problem is with splitting off the attacking unit from the stack directly after the attack.
Hmm... shouldn't be that bad. It should only e when the tech cost starts to exceed 2 million. I'll take another look - it was a quickfix I put in place.
When I looked from main menu pedia this bug didn't happen at all - it assumes default values it seems.
On Eternity tech costs are 10x higher.
X grid where you have Military Science (X grid next to Industrial Lifestyle) is last one before overflow - it has cost of 207480.
Then there are overflowed values up to Propoganda X grid - few columns later after Modern Lifestyle. This tech that stops overflowing anymore costs 428844.
i really dont care that much about "stack" attacks since i really dont use it, but some do, and ur explanation if fine with me, as long as people know what is going on .. .
also i have noticed since about three SVN updates ago that, turn times have increased alot lately, i am only in Ancient era and turn times have increased from before from around 10-15 seconds, to around 15-25 seconds per turn . . . may not seem alot to u'll but then it equates to later in game to looooong turn times . . IMPO,, now what??
@Thunderbrd: I'm not with the very latest SVN version but regarding the stack freeze after an attack, I noticed that after an attack, the attacking unit is not split off from the stack. In other words, if I re-select the stack, and wake it up, the unit that attacked is still part of the stack (and on zero movement points if it only had one). If the attacking unit dies, there is no problem but if the attacking unit survives, the stack freezes afterwards. So I'm guessing that the problem is with splitting off the attacking unit from the stack directly after the attack.
When I looked from main menu pedia this bug didn't happen at all - it assumes default values it seems.
On Eternity tech costs are 10x higher.
X grid where you have Military Science (X grid next to Industrial Lifestyle) is last one before overflow - it has cost of 207480.
Then there are overflowed values up to Propoganda X grid - few columns later after Modern Lifestyle. This tech that stops overflowing anymore costs 428844.
i really dont care that much about "stack" attacks since i really dont use it, but some do, and ur explanation if fine with me, as long as people know what is going on .. .
also i have noticed since about three SVN updates ago that, turn times have increased alot lately, i am only in Ancient era and turn times have increased from before from around 10-15 seconds, to around 15-25 seconds per turn . . . may not seem alot to u'll but then it equates to later in game to looooong turn times . . IMPO,, now what??
It seemed to shorten some for me. Some things were corrected to process correct which may have slowed previous incorrect shortcuts. At other points it might also help to reduce turn calculations. Some situational give and take. I know we should probly work on speed more soon.
Thats the reason i asked for saves that show these Problems.
I can see the Problem in the save @strategyonly posted above but i didn't have time to look at it. But from what he wrote it seems
gDLL->getInterfaceIFace()->changeCycleSelectionCounter should get called somewhere but it isn't after the Master Hunter attacks.
Thats the reason i asked for saves that show these Problems.
I can see the Problem in the save @strategyonly posted above but i didn't have time to look at it. But from what he wrote it seems
gDLL->getInterfaceIFace()->changeCycleSelectionCounter should get called somewhere but it isn't after the Master Hunter attacks.
I can provide a good test game I use that I setup in wb. It's really annoying that you can't save game option changes though because if you want to test without the Without Warning option, each time you load you have to change it. But otherwise it works pretty good for this. I'll upload it for you as soon as I can. Might make all this a lot easier.
That must be something that's always been called down the line after an attack somewhere as it's not called in UpdateCombat anywhere, so that must be part of my problem is that I'm hunting for the trick to releasing the units in the wrong area of the code.
That must be something that's always been called down the line after an attack somewhere as it's not called in UpdateCombat anywhere, so that must be part of my problem is that I'm hunting for the trick to releasing the units in the wrong area of the code.
That function has become terrible complex i really hate looking at it.
The problem in the save from @strategyonly is caused by a missing call to getGroup()->clearMissionQueue(); that call was in line 4763 of cvunit.cpp but it has been commented out.
The svn isn't working like it used to so i can't check then that change was made or why.
Also it seems that the calls to checkRemoveSelectionAfterAttack and clearMissionQueue are now in made in reversed order as they where in vanilla.
I found an error in CvUnit::resolveCombat but i didn't make any changes to UpdateCombat in my last commit.
Thats because even if i know uncommenting that call to getGroup()->clearMissionQueue() fixes something i don't know what it breaks.
I found an error in CvUnit::resolveCombat but i didn't make any changes to UpdateCombat in my last commit.
Thats because even if i know uncommenting that call to getGroup()->clearMissionQueue() fixes something i don't know what it breaks.
This setup game has been used for a few tests. As you can see, there's a surrounded group of units that represent a blend of melee, mounted with withdrawal, a general (not yet a commander) and a number of other helpless units. They are surrounded by varying barbarian units representing different movement/attack scenarios. One thing to keep in mind is that it takes 4 attacks to clear the automatic wins against barbs in this test setup. Some defended plots are easier to attack than others so that you can have the expected win or expected loss scenarios. Many plots have units waiting to ambush. If you change the game option to not having without warning you can see how it works without that.
The problem we're working on here tends to be well testable by attacking the east plot and the southeast plot. However, to ensure that nothing has fouled up stack attack after any change, make sure to test attack the north-west and the east plots with the whole group on the bug stack attack and on the game option stack attack (if the bug option is on, the other is as well so you don't have to test both in conjunction). And also test the same without either option on.
I'll do some further stress testing of some of the things you suspect need to be changed and report back my findings. I'll start with reporting, with graphics, how we are running with the current SVN code. Expect more edits to this post to come.
This is what it looks like before any attacks. I'm initially testing the code as it is on the SVN now. There is no stack attack currently on.
After an attack to the East, where there are numerous weak barbs, the stack remains selected but the unit that attacked is now deselected and you can continue your attack or move with the units that have not attacked yet.
After an attack to the Southeast, where there is just one weak barb, all units have moved in. The unit that was in combat is no longer selected BUT, as SO has reported, the units that did not attack are still selected, even though they have no further movement left and the focus should have left.
Before we start looking at testing the proposed solution and possibly other configurations, let's take a moment to prove that the attack options are working as intended with the current configuration.
To the Northeast, there is a worker - but there are 3 criminals waiting in hiding to ambush there.
Attacking to the Northeast on no stack attack options, you have all 3 come out and ambush the primary attacker (since he defeats them all, causing 2 to flee and one to die - this is mostly due to the handicaps we're getting against barbs) and the worker is captured and no bugs in the process take place. All units move in and we lose the selection on that group. (That last bit is quite interesting so I ran another test on that to see which wrapup configuration in updateCombat is being hit here because that's NOT bugged.)
Spoiler:
Code:
if (m_combatResult.pPlot != NULL && !bSamePlot)
{
//defender escapes to a safe plot
pDefender->move(m_combatResult.pPlot, true, true);
bAdvance = canAdvance(pPlot, ((pDefender->canDefend() && !pDefender->isDead() && pDefender->plot() == pPlot) ? 1 : 0));
//TB Combat Mod (Stampede) begin
if (m_combatResult.bAttackerStampedes || m_combatResult.bAttackerOnslaught)
{
getGroup()->clearMissionQueue();
bFinish = false;
attack(pPlot,true);
}
else
{
if( getGroup() != NULL )
{
if (bAdvance)
{
PROFILE("CvUnit::updateCombat.Advance");
getGroup()->groupMove(pPlot, true, ((bAdvance) ? this : NULL));
}
else if (!bStealthDefense)
{
changeMoves(std::max(GC.getMOVE_DENOMINATOR(), pPlot->movementCost(this, plot())));
}
getGroup()->clearMissionQueue();//This may not be necessary, maybe
}
else
{
//TB Combat Mod (Stampede) end
if (plot() != NULL)
{
if (!bStealthDefense)
{
changeMoves(std::max(GC.getMOVE_DENOMINATOR(), pPlot->movementCost(this, plot())));
}
}
}
getGroup()->clearMissionQueue();
checkRemoveSelectionAfterAttack(bAdvance);
}
}
Looks like the first iteration takes place in defender withdraw (lines 4897/4898), as does the second. The third, however, is the usual:
Spoiler:
Code:
if( getGroup() != NULL )
{
if (bAdvance)
{
PROFILE("CvUnit::updateCombat.Advance");
/*getGroup()->groupAttack(pPlot->getX(),pPlot->getY(), 0, bFailedAlreadyFighting, bStealth, plot());*/
getGroup()->groupMove(pPlot, true, ((bAdvance) ? this : NULL));
}
// This is is put before the plot advancement, the unit will always try to walk back
// to the square that they came from, before advancing.
/*getGroup()->clearMissionQueue();*/
checkRemoveSelectionAfterAttack(bAdvance);
}
At line 4763/4764, where getGroup()->clearMissionQueue(); is commented out.
Thereafter, no further calls to checkRemoveSelectionAfterAttack are taking place. And although it used the same spot in the routine as it did in the attack to the East, here it works entirely as intended and shows no bug. Go figure. Must have something to do with the previous calls being run before reaching this point.
So then we select the original Stack Attack option:
And attack again to the NE. Same results as if stack attack was not on (the reason all 3 units ambush the same leading unit is because that's what they are supposed to do - although technically the attacker is still the unit moving in, an ambush should not cost an attack movement - which is what I was trying to keep from happening when I moved the order of movement cost and actual move. I'm not sure how this is actually still working without that change but somehow it still works fine - I probably later corrected the looping so that all of the attacks are taking place before even one ends up charging it's movement cost, which it really should.) Anyhow, rejoice, no bugs. A quick check on where clear mission queue and remove selection after attack reveals it follows the same pattern as the non-stack attack version.
Core Stack Attack, attacked to the East. All things work properly, including leaving the selection after the move/attack correctly. All 7 combats are won.
Core Stack Attack, attacked to the Southeast. As you can see, this works completely correct. The units moved in after the attack and selection focus moved on to the next available unit.
Let's take the same steps with the BUG Stack Attack option.
Bug Stack Attack, Attack to the NE. Again, works correctly all around.
Will continue in next post due to pic upload limits.
Attachments
After Attack to the Southeast without stack attack - shows bug.GIF
Bug Stack Attack attack to the East. All functions as intended.
Bug Stack Attack attack to the Southeast. All functions as intended.
So if I take out the commenting in the code and reverse the order:
Code:
if( getGroup() != NULL )
{
if (bAdvance)
{
PROFILE("CvUnit::updateCombat.Advance");
/*getGroup()->groupAttack(pPlot->getX(),pPlot->getY(), 0, bFailedAlreadyFighting, bStealth, plot());*/
getGroup()->groupMove(pPlot, true, ((bAdvance) ? this : NULL));
}
// This is is put before the plot advancement, the unit will always try to walk back
// to the square that they came from, before advancing.
/*getGroup()->clearMissionQueue();*/
checkRemoveSelectionAfterAttack(bAdvance);
}
to
Code:
if( getGroup() != NULL )
{
if (bAdvance)
{
PROFILE("CvUnit::updateCombat.Advance");
/*getGroup()->groupAttack(pPlot->getX(),pPlot->getY(), 0, bFailedAlreadyFighting, bStealth, plot());*/
getGroup()->groupMove(pPlot, true, ((bAdvance) ? this : NULL));
}
// This is is put before the plot advancement, the unit will always try to walk back
// to the square that they came from, before advancing.
checkRemoveSelectionAfterAttack(bAdvance);
getGroup()->clearMissionQueue();
}
And if it's good in one spot to have this order of events 1-checkremove 2-clearmissionqueue then it really should be like that for all places where these 2 show up right? So switching those in each location.
Without any stack attack options, I attack to the East and after the first unit attacks, the stack goes to sleep and loses focus and you end up having another unit elsewhere is selected.
If I go back to select the previous stack, all units are put to sleep and the attacker wasn't deselected. If we attack to the SE, it works quite nicely now with this configuration.
So if I then go back and reverse again so that it's in this order:
getGroup()->clearMissionQueue();
checkRemoveSelectionAfterAttack(bAdvance);
Same thing happens when I attack the NE and when I attack the E-> and . Also same thing happens when attacking to the SE.
Flat out, order appears not to matter and if I have clearMissionQueue on, it puts the stack to sleep after every attack and moves on and if I have it commented out, everything works great except for after attacks you get stuck on selected groups. There's gotta be something I'm missing here.
And then - I've run out of time to test withdrawal against ambushers, which I suspect is part of the reason I had some things in place that made some other things fail to operate properly.
Flat out, order appears not to matter and if I have clearMissionQueue on, it puts the stack to sleep after every attack and moves on and if I have it commented out, everything works great except for after attacks you get stuck on selected groups. There's gotta be something I'm missing here.
This isn't a new issue from what you're saying and looking at the vanilla code does anybody remember if vanilla Bts had issues with StackAttack as well?
I have to see if i'am having some more free time for this today. But it seems clearMissionQueue has to be called there so I would put it back in and the answer for these problems is in that function. Maybe a part or everything that function does should only be done if the whole group is out of moves. If that works in all attacking scenarios it's necessary to confirm that all other usages of clearMissionQueue still work as well.
I get a reproducible CTD with this game. It only happens with the newest changes by alberts2 in SVN 9987, 9986 is OK (I also get CTDs with 9986 but they are not reproducible, reloading the last save and they won´t happen again for a while).
Recipe:
Run the attached save (warning: this will take long!)
Do a recalc (not sure if this is necessary)
Press the "w" (wait) button about 8 times.
After a short while windows gives a message that civ4 is not responding.
I also tried emptying the cache which didn´t help.
This isn't a new issue from what you're saying and looking at the vanilla code does anybody remember if vanilla Bts had issues with StackAttack as well?.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
so i can't check then that change was made or why.
