[MOD] MagisterModmod

[MagisterCultuum]

The new installer download doesn''t appear to be working.

Not that it isn't working, more that ModDB doesn't think it exists. For it to fail to downland, you must have the ability to downland in the first place.

I had no trouble downloading them, so I'm not sure what to say.

Is there an easy way to troubleshoot "Waiting for Other Civilizations" issue from logs? I'm just tired of going through the list of players and killing of their units in world builder to just to find out who is the problem now/again.....I really like this mod, but I just wish you(MagisterCultuum) would fix these "Waiting for Other Civilizations" bugs/issues, before you add new features in to the modmod. I'm sorry I don't mean to be negative, and as I said I really like your modmod, but wouldn't it be prudent to fix these issues before moving on to new things? Keep working on this great modmod it is really great.

Waiting for Other Civilization issues are usually caused by AI issues handled in C++. Since I don't compile my own DLL but use the MNAI versions provided by Tholal (or Terkhen, or lfgr more recently), WoC issues are mostly out of my control.

 

[Tholal]

Waiting for Other Civilization issues are usually caused by AI issues handled in C++. Since I don't compile my own DLL but use the MNAI versions provided by Tholal (or Terkhen, or lfgr more recently), WoC issues are mostly out of my control.

Actually, all of the known hang-up issues have been fixed in MNAI. If players are still finding this issue in this modmod, then it's likely due to some python AI coding (and potentially the way it interacts with the DLL code). That being said, these sort of issues are very difficult to debug. Most of them I had to track down by adding and moving logging code until I tracked down the line / section that was causing the trouble.

 

[CainStar]

So there is no easy way to track down the problem on my own? Well in any case I hope this can be fixed, since it is a really letdown to hit one these WoC bugs quite often during gameplay. Not to mention it kind of kills the fun, gameplay vise, since you are essentially elimination an a player by cheating.

EDIT1: I stopped playing my last game because of "constant" WoCs, and so because of "accumulated" infomation from the previous and current game, the WoC problems seems to be related to two leaders/factions Dain the Caswallawn and Os-Gabella. Perhaps somebody could take a look at what AI calls they make perhaps these problems could be fixed. Please if there is anyway I can help please hesitate to ask =)

EDIT2: Found out that the problem with Os-Gabella stems from skeletons.

EDIT3: Hit another WoC. Killing all skeletons from Os-Gabella didn't help this time, but killing all AI units attacking did. Another clue perhaps =)

EDIT4: Another. This one solved by killing of all AI Warwizard units from Os-Gabella.

EDIT5: Yet another WoC but this time it's Kandros Fir and I even tracked down the unit that was causing the problem: unit ID 868379. Let know if you need anything savegames logs etc.

 

[Terkhen]

So there is no easy way to track down the problem on my own? Well in any case I hope this can be fixed, since it is a really letdown to hit one these WoC bugs quite often during gameplay. Not to mention it kind of kills the fun, gameplay vise, since you are essentially elimination an a player by cheating.

As Tholal said, the best option in these cases is checking how the DLL and python code interact. But you can provide some additional information about the error even without programming knowledge with some extra effort. I cannot assure that it will provide enough information to solve the issue, but perhaps it could be enough to lead others to look in the right place for it.

Since the More Naval AI DLL (which is the one being used by this modmod) already includes extensive logging (and even better for AI), you could try to check the logs for weird stuff even without coding knowledge. In the best case scenario for "waiting for other civilizations" issues, you could find that a log message or group of log messages repeats themselves endlessly. If that's not the case, knowing the last log line would help in reducing the candidates for the error (as we will know that the code starts looping some place after that).

In order to get these logs, you need to modify your ini file as indicated in the More Naval AI testing guide. The log you need to check would be in the following path: "C:\Users\(USERNAME)\Documents\My Games\Beyond the Sword\Logs\BBAILog - (PLAYERNAME).log".

This log does not appear with all DLL compilations and I don't know for sure if the one being used currently by MagisterModmod has BBAI logs enabled. If you see another logs (PythonErr, SynchLog and so on) in the folder but you don't find any BBAILog files, let me know and I will provide a DLL with logging enabled so you can test this.

 

[CainStar]

There is indeed a BBAILog file in my logs folder. The problem is I have no idea what I'm supposed to look for, I hardly think that there is going be aline in there that says HEY I'M THE PROBLEM HERE =).

My knowledge of Civ4 is very basic, changing text, graphics etc. I can upload BBAILog or/and other files if somebody with better skills wants to look at them, or if somebody is willing to give me some pointers that's ok too, oh and I do have 15 years of experience with computer so not a total n00b. Just never got into coding....well other than some basic HTML.

 

[Terkhen]

Well, checking what is happening in coding issues requires this kind of knowledge. You asked about a way to track the problem on your own and I told you about the easiest one

If you upload the logs (better if it is all of them), I'll take a look at them. Bear in mind that unless something obvious is happening in them I won't be able to help much (as I mentioned, a line appearing all the time or something fishy in the last line of the log), as debugging would require significantly more effort and my own plate of stuff to fix is already quite filled.

 

[Cutlass]

I got a waiting for other civs lockup too. It's been months since I played much, so forgot how to try and do anything about it.

 

[CainStar]

Well, checking what is happening in coding issues requires this kind of knowledge. You asked about a way to track the problem on your own and I told you about the easiest one

If you upload the logs (better if it is all of them), I'll take a look at them. Bear in mind that unless something obvious is happening in them I won't be able to help much (as I mentioned, a line appearing all the time or something fishy in the last line of the log), as debugging would require significantly more effort and my own plate of stuff to fix is already quite filled.

Here are the log files for you, when you have the time to look at them....and thank you in advance

 

[Terkhen]

Some parts of that BBAILog are extremely suspicious. At the end of the BBAILog there is a group of lines that indicate some kind of problem.

Stack 5423115 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5414949 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5431304 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5439499 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5447717 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5455880 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5464075 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5472293 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5480456 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5488651 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5496869 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5505032 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5513227 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5521445 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5529608 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5537803 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5546021 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5554184 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5562379 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5570597 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5578760 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5586955 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5595173 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5603336 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5611531 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5619749 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5627912 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5636107 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5644325 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5652488 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5660683 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5668901 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5677064 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5685259 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5693477 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5701640 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5709835 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5718053 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5726216 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5734411 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove
Stack 5742629 (led by Warrior (581666), size 1) starting ConquestMove
Stack 5750792 (led by Soldier of Kilmorph (303118), size 1) starting ConquestMove

As you can see, the same units [Warrior (581666) and Soldier of Kilmorph (303118)] are starting ConquestMoves many times each turn as if they were in some kind of loop. More worringly, it seems that their stacks are switching all the time. This group of lines appears twice on the logs, as "(Khazad) setTurnActive for turn 700" seems to be run twice on that log. This is quite weird too :/

 

[Tholal]

That sort of log entry generally indicates that the two units are grouping together, then ungrouping, then grouping again… on and on.

Since this doesn’t happen in base MNAI, there is something different about the units (I believe that SoKs have some changes?) or possibly the area they are in that is causing this. But figuring out the exact problem and fixing it would require a save game and a bunch developer time debugging and locating the exact problem.

 

[MagisterCultuum]

Soldiers of Kilmorph in my mod have one less strength than those in FfH2/MNAI, but start these additional promotions:
Heavy
Guerilla1
Guerilla2
Mountaineer
Tinkerer

Tinkerer allows the Repair ability, to heal Golems, Naval, and Siege Units.

Guerrilla 1, 2, and Heavy are basically the same as in the main mod.

I suppose it is possible that Heavy could be the problem, as it would make the unit slower than the rest of the stack. I suspect the AI would just make the whole stack go more slowly though.

Mountaineer allows the unit to move through impassible terrain. i.e., Peaks. (The unit itself has the <bCanMoveImpassable>1 tag too and so does not need the promotion, but the promotion lets the unit maintain the ability after upgrading.)

I suspect that is the problem. The AI keeps trying to move the stack through a mountain range, but the Warrior cannot go there with the Soldier of Kilmorph. The warrior might be unable to leave its current area at all, while the Soldier of Kilmorph could pass between areas with ease.


I suspect that this problem would happen in base MNAI too but would be much less common, as the units that can move through peaks would be just a few late game national units.

 

[Terkhen]

I suspect that is the problem. The AI keeps trying to move the stack through a mountain range, but the Warrior cannot go there with the Soldier of Kilmorph. The warrior might be unable to leave its current area at all, while the Soldier of Kilmorph could pass between areas with ease.

I suspect that this problem would happen in base MNAI too but would be much less common, as the units that can move through peaks would be just a few late game national units.

Checking the code, I see that CvSelectionGroup::canMoveInto returns true as long as one of the units of the group can move to a certain plot. This method is also used on CvSelectionGroup::groupPathTo, so the AI (or anyone else, really) will be able to plan paths that cross mountains with groups that contain both units that can pass peaks and units that can't. On CvSelectionGroup::groupMove, the code checks CvUnit::canMoveInto for each unit. Units that cannot move to the tile will be placed in a new group, while the others will move to the tile.

What happens when a human player tries to move a stack with a normal unit and a Soldier of Kilmorph to a peak? I'm starting to suspect too that this same issue could be happening in other mods, as in mine the only unreproduceable "waiting for other civilizations" errors now happen only on the really late game and I've never been able to find what is happening.

 

[Tholal]

I suspect that this problem would happen in base MNAI too but would be much less common, as the units that can move through peaks would be just a few late game national units.

You are probably correct.

Checking the code, I see that CvSelectionGroup::canMoveInto returns true as long as one of the units of the group can move to a certain plot. This method is also used on CvSelectionGroup::groupPathTo, so the AI (or anyone else, really) will be able to plan paths that cross mountains with groups that contain both units that can pass peaks and units that can't. On CvSelectionGroup::groupMove, the code checks CvUnit::canMoveInto for each unit. Units that cannot move to the tile will be placed in a new group, while the others will move to the tile.

Interesting. Sounds like canMoveInto needs to check the whole stack. I wonder why it was coded that way. Perhaps there are potential scenarios where this would be an issue?

What happens when a human player tries to move a stack with a normal unit and a Soldier of Kilmorph to a peak?

Pretty sure that nothing happens. You just arent allowed to make the move.

 

[zldrago1000]

The vast majority of my endless turn loops involve one or more units looping starting conquest move. It's not always soldiers of kilmorph though. Sometimes I saw units such as horsemen looping endlessly. I'll play tonight and report the units that have the issues.

They usually only start around mid game however. Don't see them early on.

 

[Artiss]

I approve that almost every big game in MagisterModmod sooner or later have ended by WOC. And the reason is usually some units endlessly stacking up to go conquest. When that error strikes first you can simply look in BBAI-log for the problem units and through world builder delete them. And at first it seems solve the problem, but afterwards similar troubles with other units grows like snowball killing the game

And yes, it is not only soldiers of kilmorph issue. Endless WOC may cause any unit.

 

[MagisterCultuum]

Checking the code, I see that CvSelectionGroup::canMoveInto returns true as long as one of the units of the group can move to a certain plot. This method is also used on CvSelectionGroup::groupPathTo, so the AI (or anyone else, really) will be able to plan paths that cross mountains with groups that contain both units that can pass peaks and units that can't. On CvSelectionGroup::groupMove, the code checks CvUnit::canMoveInto for each unit. Units that cannot move to the tile will be placed in a new group, while the others will move to the tile.

What happens when a human player tries to move a stack with a normal unit and a Soldier of Kilmorph to a peak? I'm starting to suspect too that this same issue could be happening in other mods, as in mine the only unreproduceable "waiting for other civilizations" errors now happen only on the really late game and I've never been able to find what is happening.

You are probably correct.



Interesting. Sounds like canMoveInto needs to check the whole stack. I wonder why it was coded that way. Perhaps there are potential scenarios where this would be an issue?



Pretty sure that nothing happens. You just arent allowed to make the move.

When a human player orders a stack of units to move into a tile which is impassible for some of them, then those who can move do so while those who cannot enter the tile stay behind where they were.

The group gets split, without any prior warning that it would.

It also seems that when using "Go To Mode" with a stack of units including those who can and cannot move onto a certain type of tile, that it will show the move is possible for the first tile of that kind but impossible for any other tiles of the same type if you try to plan a route through multiple adjacent types of the said type.

If none of the units in a stack can move onto such a tile, then it will show even the first move as impossible. If all of them can, then it will appear possible for them to keep moving deeper into such tiles.



All this does not just go for stacks including units like Soldiers of Kilmorph who can move through peaks. It also applies in stacks containing some Water Walking units (like Drowns) trying to enter the sea, and to stacks containing units like my Frost Giants who cannot enter Deserts.

The vast majority of my endless turn loops involve one or more units looping starting conquest move. It's not always soldiers of kilmorph though. Sometimes I saw units such as horsemen looping endlessly. I'll play tonight and report the units that have the issues.

They usually only start around mid game however. Don't see them early on.

I just got to thinking that what I have written in def unitCannotMoveInto(self,argsList) could also lead to such problems.

That code makes it impossible for summons to enter rival cities that have Rings of Warding, or for the Undead to enter cities containing the Sidar UB Shrine of Arawn.

(That could be why Skeletons were causing someone issues a few posts back.)

It also makes it impossible for units with the Bound by Compact promotion (i.e., Balors and Demon Lords) to enter non-hell terrain, and should stop bAlwaysHostile units from entering and capturing rival superforts.

None of those would be relevant until mid-game or later.

I don't see why any of those should matter for ordinary horsemen though.

 

[zldrago1000]

Just had my first WOC endless turn: This time it looks like a catapult is the culprit. However immediately preceding them are a soldier of Kilmorph and a Stygian guard trying to merge onto this group? I had always assumed it was the unit that was looping that was the problem, but now I'm not so sure. Also it looks like the catapult is trying to be placed in different stacks.

Player 5 (Doviello) setTurnActive for turn 190
Player 5 (Doviello) has 5 cities, 54 pop, 384 power, 81 tech percent
Team 5 has met: 0,1,3,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,; at war with: 15,16,18,19,20,; planning war with:
Enemy power perc: 1382 (296 with others reduction)
Checking for Upgrades...
Checking for Promotions...
Chariot (unit 1228824 - UNITAI_ATTACK) choosing promotion Combat IV (value: 44)
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
50 bonus to slaying promo for enemy civ
Vicar (unit 1310764 - UNITAI_MEDIC) choosing promotion Demon Slaying (value: 732)
Vicar (unit 1310764 - UNITAI_MEDIC) choosing promotion Mobility I (value: 67)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Mind I (value: 90)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Spell Extension I (value: 85)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Combat II (value: 87)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Combat III (value: 86)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Combat IV (value: 87)
Mage (unit 1302576 - UNITAI_MAGE) choosing promotion Combat V (value: 80)
Stack 4587533 (led by Mage (1146911), size 5) starting ConquestMove
...targeting city Ildelver (final value: 621)
...trying to assault target city
...iComparePostBombard = 0
...pillage around city 2
...checking MageMove()
...switching to WarWizard
Stack 4833325 (led by Mage (1237019), size 1) starting ConquestMove
Stack 4948004 (led by Catapult (794649), size 1) starting ConquestMove
Stack 4964396 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 4898859 (led by Horse Archer (1269783), size 1) starting PatrolMove
Stack 4849673 (led by Chariot (1032242), size 4) starting PatrolMove
*** KOMBAT! ***
ATTACKER: Chariot (Unit 712726), CombatStrength=1400
DEFENDER: Player 50 Unit 10576030 (TXT_KEY_LEADER_BARBARIAN's Elephant), CombatStrength=800
Elephant Slain! (Unit 10576030 - plot: 84, 31)
Stack 4980785 (led by Chariot (1294337), size 1) starting PatrolMove
Stack 4980785 (led by Chariot (1294337), size 1) starting PatrolMove
Stack 4464673 (led by Chariot (1130511), size 1) starting PatrolMove
...staying to guard city
Stack 5038127 (led by Chariot (1163304), size 1) starting PatrolMove
Chariot (unit 1163304 - UNITAI_ATTACK) seeking defensive ground
Chariot (unit 1163304 - UNITAI_ATTACK) moving to defensive ground (67, 31)
Stack 5038127 (led by Chariot (1163304), size 1) starting PatrolMove
Stack 3743795 (led by Beastman (204818), size 1) starting PatrolMove
Stack 4972544 (led by Beastman (49152), size 1) starting PatrolMove
Stack 4685832 (led by Soldier of Kilmorph (532493), size 1) starting PatrolMove
Stack 5013518 (led by Beastman (163852), size 1) starting PatrolMove
Stack 5005328 (led by Soldier of Kilmorph (516099), size 1) starting PatrolMove
Stack 4767784 (led by Ranger (1196074), size 1) starting ConquestMove
...targeting city Iosichaard (final value: 1850)
Stack 4767784 (led by Ranger (1196074), size 1) starting ConquestMove
...joining group on plot
Stack 4997145 (led by Soldier of Kilmorph (499748), size 1) starting ConquestMove
...targeting city Iosichaard (final value: 560)
Stack 5029926 (led by Vicar (1310764), size 1) starting ConquestMove
...joining group on plot
Stack 4644894 (led by Soldier of Kilmorph (483357), size 1) starting PatrolMove
Stack 4800517 (led by Stygian Guard (1212432), size 1) starting ConquestMove
Stack 3366915 (led by Beastman (122890), size 1) starting ConquestMove
Stack 5046291 (led by Mage (1302576), size 1) starting ConquestMove
...moving to merge group
Stack 5054506 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5062694 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5070890 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5079078 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5087274 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5095462 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5103658 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5111846 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5120042 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5128230 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5136426 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5144614 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5152810 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5160998 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5169194 (led by Catapult (1277969), size 1) starting ConquestMove
Stack 5177382 (led by Catapult (1277969), size 1) starting ConquestMove




I just had another WOC issue: Ill post it below.


Player 24 (Infernal) setTurnActive for turn 196
Player 24 (Infernal) has 2 cities, 36 pop, 249 power, 91 tech percent
Team 20 has met: 0,1,3,5,6,8,9,10,11,12,13,14,15,16,17,18,19,; at war with: 1,3,8,9,10,12,13,14,15,17,; planning war with:
Enemy power perc: 243 (85 with others reduction)
Checking for Upgrades...
Checking for Promotions...
Sect of Flies (unit 647173 - UNITAI_ATTACK_CITY) choosing promotion Mobility I (value: 71)
Sect of Flies (unit 647173 - UNITAI_ATTACK_CITY) choosing promotion City Raider I (value: 32)
Sect of Flies (unit 647173 - UNITAI_ATTACK_CITY) choosing promotion City Raider II (value: 59)
Sect of Flies (unit 647173 - UNITAI_ATTACK_CITY) choosing promotion City Raider III (value: 76)
Archmage (unit 638977), starting AI_upgrademanaMove (size 1)
Build Ice Node mana value: 1
Archmage (unit 638977) building Build Ice Node with value of 1 at plot 88, 58
Stack 548880 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 770061 (led by Meresin (8192), size 4) starting PatrolMove
Stack 909316 (led by Sect of Flies (647173), size 1) starting ConquestMove
...moving to merge group
Stack 909316 (led by Sect of Flies (647173), size 1) starting ConquestMove
...joining group on plot
Beion'Chegon (Great Sage) constructing Academy at 89, 1 (value: 244)
Stack 925697 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 933900 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 942081 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 950284 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 958465 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 966668 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 974849 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 983052 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 991233 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 999436 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1007617 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1015820 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1024001 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1032204 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1040385 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1048588 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1056769 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1064972 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1073153 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1081356 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1089537 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1097740 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1105921 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1114124 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1122305 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1130508 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1138689 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1146892 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1155073 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1163276 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1171457 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1179660 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1187841 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1196044 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1204225 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1212428 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1220609 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1228812 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1236993 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1245196 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1253377 (led by Horse Archer (614413), size 1) starting PatrolMove
Stack 1261580 (led by Horse Archer (614413), size 1) starting PatrolMove

 

[TrippedOnACloud]

I've repeatedly had WoC lockups when one or two units from a civilization with which I have Open Borders attempts to attack a Dragon Fanatic or Wyvern Rider garrisoned in one of my cities. Skipping or deleting the unit(s) in question resolves the issue, and moving the DF/WR further from my borders or onto an inaccessible tile appears to cause the AI to ignore them. I've seen them cause lockups on both PatrolMove and ConquestMove in the AI log, for what it's worth. Haven't seen any other repeatable WoCs in the last two or three releases.

Doubled Immortality-granting promotions appears to cause some odd behavior. I haven't done any testing, but in my latest game one of my Adventurers is being duplicated whenever it upgrades. He currently has both Immortal from Blood of the Phoenix, and Life III. The resulting clone loses Immortal but retains Life III, I believe. Adventurers with Immortal but without Life III don't clone on upgrade.

Is there any particular reason the Guardian Elemental from the Tower of Elements has Hidden Nationality? The AI seems to like suiciding on them when you have Open Borders.

Black Mirror-ed Great Engineers are capable of building improvements.

In the Order vs Veil rioting event, which offers the choice between 50% removal of the selected religion, 25% of both, or tossing the rioters in the dungeon, the dungeon option was unavailable to me despite having a dungeon present. Possibly caused by the dungeon being provided by the Tower of Eyes rather than being built?

 

[CainStar]

Well it seems like some of you are making progress =). If you want I can upload my current savegame. It is at the same "state" that the log which I provided is.

EDIT: PLEASE I MEANT TO SAY I CAN UPLOAD MY SAVEGAME.....how in the h**l did I manage turn 'can' into a 'can't' is beyond me.

 

[Tholal]

Those last couple of log entries are interesting because it is just one unit involved in the loop. The DLL has code to force the game out of a loop if its due to a single stuck unit, so these log entries indicate to me that the issue does involve a python call somewhere.

I've repeatedly had WoC lockups when one or two units from a civilization with which I have Open Borders attempts to attack a Dragon Fanatic or Wyvern Rider

Interesting. I dont have Magister's mod installed on my machine at the moment. What is special / different about those two units?