This is the content of some pms I didn't want to rewrite everything but maybe someone can get a clue now:
Settings(changed ones):
Goblinarcher:
meshgroupsize 10
melee wave 10
rangedwave 10
irequired 10
Firststrike 0
Firststrikechance 1
Warrior:
meshgroupsize 10
melee wave 10
rangedwave 0
irequired 10
1 Firststrike
I just checked the Goblinarchers in Warlords with groupsize and wavesizes like I had them in the mod.
No problem!
Everything runs smooth and the performance is great so I guess it's either in vanilla and fixed with Warlords or it's in the mod. I will check the model in vanilla(replacing the archer) as well to make sure.
After the first time I checked I thought it could be the firststrikes maybe since we changed that a lot. Did they do something about Firststrikes in Warlords? I know the combat odds often displayed not correct in vanilla now they seem ok. I set the firststrikes like we have them in the mod and still everything is nice.
Well at least that gives me some hope now we can have the model with large numbers at least after Warlords conversion.
Vanilla:
1. I didn't receive a CTD
BUT
2. while in Warlords the goblinarchers used their ranged animation quite frequently without problem in vanilla they only fought melee AND a lack of performance is noticeable here.
It seems vanilla has a problem with large groups which doesn't apply to warlords(maybe because the Warlordfeature could required a new coding of files related to the meshgroupsize?). The case seems to be in the mod that everytime the ranged animation is called a ctd occurs while in vanilla it's just replaced by melee.
Gerikes analyzes;
Here's a brain dump of what I know on the issue:
Well, the error spawns from somewhere in the graphics system (which I call the ".exe", but really mean some part of the system that doesn't include the SDK), but that doesn't mean that the problem IS in the .exe. I really don't know enough about graphics modeling and all that to have any guesses as to how all that factors in, but here's what I do know:
Inside updateCombat (a function inside CvUnit.cpp that's run when combat between two units starts and finishes) there's a function that first calculates the results of the battle (how many hit points are left for each unit). Then, the results are sent to another function that actually creates what happens in the battle (who dies when, how many units go where, etc). This is a process that isn't exact: what actually happens is so complex that it actually just takes some educated guesses to how a battle could progress, then at the end checks if the way it sees the battle working out is "valid" (i.e. when the battle I've created is run, does each unit lose the same amount of hit points that the battle calculations made earlier said they would?). It might take a good 10 or more tries before it gets it right.
Then, once the actual battle moves have been figured out, a function is called that actually starts the action. Here is some of the code:
Code:
int iTurns = planBattle( kBattle); kBattle.fMissionTime = iTurns * gDLL->getSecsPerTurn(); setCombatTimer(iTurns); GC.getGameINLINE().incrementTurnTimer(getCombatTimer()); if (pPlot->isActiveVisible(false)) { ExecuteMove(0.0f); gDLL->getEntityIFace()->AddMission(kBattle); }
Now, I can run the code in debugging mode. That means that I can rather than have all the code executing in it's normal speed, have it execute one line of code and then stop, and not execute the next line of code until I say so. Thus, after the first bit of code executes, the value of iTurns is set to some number. The number of turns in a battle is normally somewhere in the range of 5-30, depending on how long the battle played out. If that number is 523492-bajillion, then I know that there could be a problem with the planBattle function (or possibly the value of kBattle).
I can even go further and look at the function planBattle, located elsewhere in the source file, and look at exactly how it's calculated and look at those data values, trying to see if there are any wrong-looking numbers there.
In all this, I haven't seen anything out of the ordinary.
Here's where I get to the part where I can't look at the problem anymore. The kBattle structure (a structure that holds the variables that tells what subentities to go where during a battle and when) is sent to the the Civ4 system (for lack of a better word: basically, the parts of the Civ4 system that we don't have code access to, which typically has been called the "exe", for, once again, a lack of better words). This happens at the "gDLL->getEntityIFace()->AddMission" line.
Now, when I go step by step through the code, typically this function will go, run, and then return so that I may go to the next piece of code. However, when I try to "step over" this function during times when the CTD happen, I instead get an error message that says it can't read memory location 0x000005, or something to that nature. This tells me that somewhere, either a pointer is referencing a memory location that has already been freed, or data is being loaded into a memory location that can't hold that data. This all happens before the code execution gets back to the SDK.
That's why I believe that the issue HAPPENS in the "exe". However, that doesn't mean that the problem is in the exe. It might be that there is some weird glitch in the planBattle function that passes bad data to the AddMission function, which will cause a crash (although I quickly looked at this case, I really don't have complete knowledge of what the planBattle function does, so I can't eliminate this as an option). It might be that the unit meshes are loaded into some data structure internally which is only set to hold so much data, and we're giving it too much. It could even be that the export script for the model files have a flaw that will cause illegal moves to be done during the animation. I have no idea. All I DO know is that the error happens sometime after the SDK calls AddMission, and sometime before that call finishes.
Seems everytime I load up something gets crippled.
