Reinforcement CTD: help needed

[Monkwarrior]

I've been searching in the EB forum, as I knew that they had some kind of reinforcement bug, but that was after battle afaik. In my case it is a prebattle CTD, and these are my experiments to demonstrate it is a reinforcement problem:

The tests are made with a celtiberian army (C) sieging a settlement with a small ilergeti garrison (G), and I have a big army (A) nearby.

Test 1: A attacks C, G appears as reinforcement in the prebattle scroll: CTD.
Test 2: G attacks C in a suicidal battle: normal battle. (Conclusion: the problem is neither the settlement, nor armies G and C)
Test 3: A goes far and attacks a gaul army: normal battle. (Conclusion: the problem is not army A).
Test 4: C assaults the settlement and takes it: normal battle. (same conclusion as test 2)
Test 5: A sieges the settlement taken by C and assaults in the following turn: normal battle.
Test 6: A is divided in two armies (A1 and A2) near the settlement. A1 attacks the settlement and A2 appears as reinforcement: CTD. (exactly the same units as in test 5 are involved)
Test 7: The two armies (A1 and A2) are attacked by another big celtiberian army far from the settlement. A2 appears as reinforcement: CTD.

Any idea about the origin of this problem?

[Mad Hoplite]

Hello, Monkwarrior.

I've just read in the TWC wiki about the postbattle bug. I know your problem happens before and no after, but do you have any trait or ancillary trigger with the NumEnemiesInBattle condition?

[Makanyane]

I assume it would need to be something with a PreBattle test and NumFriendsInBattle - you should be able to rule out trait and anc. triggers quite easily, just by making back up of the files and deleting entire trigger sections, if you've got script obviously try running without it and see if result changes.

Question does it CTD when you've got beyond scroll, ie onto loading bar? If so I wonder if that faction could be missing something for the ally battle banners (though I thought that would give you white banner not crash).

Also are generals involved?

[Monkwarrior]

Thanks to both of your for the answers.

@Makanyane
Yes, it happens when loading the battle, when the loading bar is near to the end.

In the meantime I've been testing some other possibilities. Other CTDs without reinforcements are also present, indicating that it is not due exclusively to that.

Generals are involved in this problem. But not always. Some examples:

- Army A has been divided into three: general alone, A1 and A2. I was able to fight a battle with A1, and A2 as reinforcement, without the general present.

- CTD of ilergeti-gaul battle, only one army against one. If general is not present, battle is possible. After defeat, general is again incorporated to the army, and then battle is possible again.

- CTD of ilergeti-slave battle. Only general against slave, CTD. The rest of the army against slave, CTD. Only one unit of slingers against slave, battle fought. In this case, perhaps the presence of an experienced elite unit is responsible (man of hour? adoption?).

As you pointed, I think it is a problem of ancillaries and/or traits, but I don't have NumEnemiesInBattle or NumFriendsInBattle conditions (triple checked ). It must be another one, but... which one?

[Mad Hoplite]

Hey Monk.

Correct me if I'm wrong but a CTD when loading a battle should not be trait or ancillary related.

I don't think the game parses or tests triggers when loading a battle, or does it?

This is from the CTD threads:

Battle Loading CTDs:
- A unit with the attribute mercenary_unit in EDU that has no texture line for "merc" in the soldier, officer, and other related models found in DMB.
- A non-mercenary_unit in EDU that has no texture line in DMB for any faction given ownership of the unit in EDU, for the soldier, officer, and other related models.
- A sprite defined in DMB with no distance value.

I know some of them sound pretty basic but have you discarded all of them?

[Monkwarrior]

The problem with textures for mercenary and rebels was my first hypothesis. But in most cases (I cannot say 100%, but close to it) I've been able to fight the battle with exactly the same units, although in the absence of the general.

I cannot discard this problem in some of the CTD, if there are several causes, but I'm persuaded that it is not the problem in a good number of CTDs, for example the ilergete-celtiberian problem described in detail, where all the units have been involved in battle in one or another ocassion, or the ilergete-gaul battle, where the very same units have fought two battles, one with and one without general.

I wonder the meaning of these conditions:

BattleOdds >= 0.5

I_ConflictType Normal

WhenToTest PreBattleWithdrawal

GeneralHPLostRatioinBattle

GeneralNumKillsInBattle

My concerns are if the game tests the possibility before the battle, and crashes if there is any conflict.

[Mad Hoplite]

All the conditions you mention are in vanilla files, so in theory they're not buggy, rushed or bad implemented like so many others.

Again, I doubt something like that can CTD the game in the middle of a loading screen, but backup and try restoring the original traits and ancillaries.

If that works I'll be a very wrong person very happy :).

[Monkwarrior]

All the conditions you mention are in vanilla files, so in theory they're not buggy, rushed or bad implemented like so many others.

Again, I doubt something like that can CTD the game in the middle of a loading screen, but backup and try restoring the original traits and ancillaries.

If that works I'll be a very wrong person very happy :).

Yes of course, they are implemented, but I wonder if a change in another part of the mod will interfere with them.

Do you know if it is possible to eliminate all the triggers in e_d_ancillaries and e_d_c_traits to have a functional game? I think that restoring the original files is not possible due to the changes in buildings and cultures.

[Makanyane]

yep that was what I was suggesting earlier make a back up and delete all the triggers so you can rule traits or ancillaries out.

You're right you can't remove the traits without a lot of work but if you remove the triggers that in itself does no harm, and is an easy check to see if it is either of those files causing problem.

[Squid]

All the conditions you mention are in vanilla files, so in theory they're not buggy, rushed or bad implemented like so many others.

Again, I doubt something like that can CTD the game in the middle of a loading screen, but backup and try restoring the original traits and ancillaries.

If that works I'll be a very wrong person very happy :).

Unfortunately that isn't quite true, all conditions come from the engine (we have no ability to add new conditions), but there are some conditions that are known to cause CTDs in reinforcement battles (NumEnemiesInBattle is one).

[Mad Hoplite]

Unfortunately that isn't quite true, all conditions come from the engine (we have no ability to add new conditions)

I know. All I was suggesting is that all the conditions that Monkwarrior mentioned were already used in vanilla files, opposed to other stuff in docudemon that is not implemented in game and is broken.

there are some conditions that are known to cause CTDs in reinforcement battles (NumEnemiesInBattle is one).

In the middle of a loading screen?

[Monkwarrior]

Ok, tested e_d_ancillaries and e_d_character_traits with no triggers and the problems are still there.

I will keep you informed.
Thanks again.

[Squid]

I know. All I was suggesting is that all the conditions that Monkwarrior mentioned were already used in vanilla files, opposed to other stuff in docudemon that is not implemented in game and is broken.



In the middle of a loading screen?

I'd imagine it would be during the loading screen, PreBattle events have to been completed before the battle, similarily any traits your generals acquire after a battle have been acquired by the time the campaign map reload, so it would have to be processed during the reloading of the campaign map.

[Monkwarrior]

Now I'm thinking in the possibility of some error in vegetation or something like that.
In the CTD against the slaves, any combination of units of army 1 attacking them causes CTD. I've made the rebel army to move from its position by attacking with a larger army 2, that didn't pursuit them in the strategic map. Next turn I attacked with the very same army 1 and the battle was fought without problems.

This seems to indicate that the problem comes from the position of the armies, not from the composition of them.

[Makanyane]

Just one rude question, sorry! When you get CTD, or OK result from a particular battle are you going back and re-trying same thing again? Just in-case it is actually an intermittent bug with something, and not related to the other factors....

Assuming you've probably done that anyway, if you get the cursor position that the rebel army is standing on when you try and attack it. Put those co-ordinates in custom_locations.txt for a custom battle position and see if you have problem with that (you can then vary armies / season for it easily as well and it takes out any effect from generals)


Only other thing I though of overnight, might be worth reverting to vanilla
descr_formations_ai.txt IF you've changed that. End of loading bar could show its having trouble deploying armies.

[Dol Guldur]

It's been my experience that ai problems are more likely to surface at the beginning of the battle rather than the loading screen, but it's possible during the latter I suppose.

I'd agree with the custom_locations text Mak suggests but note the climate type when you choose it - and, also, if you are running a provincial campaign then you will need to make sure the map.rwm in the base folder is the same as that in the campaign folder for the test to be valid.

[Monkwarrior]

Just one rude question, sorry! When you get CTD, or OK result from a particular battle are you going back and re-trying same thing again? Just in-case it is actually an intermittent bug with something, and not related to the other factors....

Assuming you've probably done that anyway, if you get the cursor position that the rebel army is standing on when you try and attack it. Put those co-ordinates in custom_locations.txt for a custom battle position and see if you have problem with that (you can then vary armies / season for it easily as well and it takes out any effect from generals)


Only other thing I though of overnight, might be worth reverting to vanilla
descr_formations_ai.txt IF you've changed that. End of loading bar could show its having trouble deploying armies.

It doesn't sound rude to me.
I always start from a saved campaign game, and that means the starting position is always the same (unless the reloading introduces some unknown aleatory modification).

Your idea of custom location is very good. I will try that, thanks.

It's been my experience that ai problems are more likely to surface at the beginning of the battle rather than the loading screen, but it's possible during the latter I suppose.

I'd agree with the custom_locations text Mak suggests but note the climate type when you choose it - and, also, if you are running a provincial campaign then you will need to make sure the map.rwm in the base folder is the same as that in the campaign folder for the test to be valid.

I'm not an expert in descr_formations_ai, but it would sound me logical that the same armies deploy in the same way, irrespective of the terrain. Am I wrong?

I don't understand your point about the same map.rwm in provincial and imperial campaign. The file for imperial (the campaign I'm testing) is placed in base folder, but those for the provincial campaigns are included in the folder for each campaign. The maps are not exactly the same, and then map.rwm is not the same for each campaign.

Regarding map.rwm I was thinking in another possible source of errors: what would happen if map.rwm was generated before the introduction of vegetation modifications? Would that affect the transition from campaign to battle map?

[Makanyane]

Dol was just pointing out what I'd forgotten, that the Custom Battles are generated from the imperial campaign/base level .rwm - if you're working on the imperial campaign then it is a valid comparison. If you were working on provincial campaign with a different .rwm it wouldn't be a good test.

I'm not an expert in descr_formations_ai, but it would sound me logical that the same armies deploy in the same way, irrespective of the terrain. Am I wrong?

I was just thinking about the problem you can get with reinforcement armies getting stuck which I think is to do with available deployment area and formation combination - that was only very vague idea though...


If you're working on a save or map.rwm that was generated before other changes that might cause problems! I've had problems with things just going generally buggy when I've tried that for some /data level changes, apart from sm_factions and EDB (which definitely cause me problems) I've not pinned down exactly what you can get away with though. If your veg changes just involved switching models / textures I'd assume you'd be OK, if you assigned stuff to the climates differently I'd be more concerned.

[Dol Guldur]

If you've generated vegetation then leaving out the .vege files is always a sure way to get a loading-bar ctd or - worse still - freeze! ;)

[BozosLiveHere]

I can guarantee it's not trait or ancillary related. The PreBattle event doesn't work (the triggers never fire). Does it happen during the loading bar progress or before?

[Monkwarrior]

Thank you very much to all of you.

Finally the vegetation was responsible for those problems, even the "apparently" reinforcement bug.

The custom battle in the same tile produced the same problem (CTD during loading). The only way to solve it has been to eliminate completely the new vegetation, and generate a new map.rwm.

Now I must look for the mistake in order to include the vegetation again.