Search results

It doesn't appear that the newest version of GeoModder's mod has this issue, so merging in .95 looks like another viable solution for those up to the challenge.

After much hair pulling I think I've managed to fix the issue with this mod. I had 4 separate broken saves and these two fixes got them all working again. First Huyana's improvement art style is rather fubarred in several ways so I went ahead and changed him to the meso american style...

In the code aggressive AI causes the AI to be more likely to go to war and less likely to end war, but in practice the most visible effect of this option is the fact that AIs will build more units and assign more of those units to offensive purposes. You will definitely see a bit more war...

I was still getting intermittent OOSes after this fix. The OOS logger showed that a unit was ending up being assigned to a patrol on one system and not on the other (ending up with UNITAI_COUNTER vs UNITAI_ATTACK). I took a look at the code and after a bit of digging I think I found the problem...

Just tried it myself and managed to get the message as well as losing access to bronze so I'm hopeful that everything is working right. From what I've done in the code it shouldn't matter how you lose the prerequisite resource so long as it is not present on the next turn when it does its one...

I'm still on patch s, so it might have been fixed in one of the subsequent ones. Some of the Basiums have already died permanently, I'll have to check whether or not the real Basium lost his traits as a result...

It should have given a message on the next turn unless you had an additional source of copper. If it didn't then that's something I need to look into, so let me know :)

I'm guessing the illusions get any base promotions the unit starts with, in Basium's case the hero promotion. Which would obviously lead to a lot more promotions. Although you're probably right about them defending too.

In my current multiplayer game Perpentach is the ashen veil founder and has grown quite bloated. He's been fighting Basium for a while now (who I flagged as immortal as part of my Modmod), and he's collected a very strange army of illusions all of which appear to be permanent. So far he's...

I ran into this in one of my previous multiplayer games, couldn't figure out a pattern to it, but strangely it didn't happen to my friend the entire game. Might be attached to a specific civic choice or something, but I've been running similar civics on my current game and I haven't seen it...

For anyone playing TR multiplayer, I've attached a new DLL with an attempt at a fix for the OOS errors related to Assassins. As you all probably know OOSes can be incredibly difficult to track down, and I don't have anyone I can test this fix with so please don't get your hopes up too much ;)...

Can you elaborate on how the score is coming up? Is the display itself screwed up in some way or are the values off? I've only touched the resource converter code in these two versions, so I'm not sure what impact if any that would have on the scoreboard. Could you post the save file so I can...

Random question on that... were AI Assassins potentially in use in the game when it occurred? (ie. one or more of the AIs had the tech that unlocked them) In Assets\Python\CvEventManager.py you could try changing: CvUtil.pyPrint("Victory! Team %d achieves a %s victory" %(iTeam...

I've unleashed many a barbarian Eidolon on unsuspecting AI civs since I altered the dungeon script to create new dungeons every time one is destroyed (only dungeons, not other lairs). It's not quite as fun when the AI in question has the barbarian trait, and the unit I'm using happens to be a...

Thanks Houman, I'm happy to be helping out :) Ron or anyone else here with a similar situation, could one of you provide a save of the turn before you get one of these lock ups? Walter was mentioning this bug as well and it would help me track it down if I had an example to go off of.

Heya folks, time for take two. Unlike last time this is a significant departure from the previous DLL. I've removed all checking for converters currently in the code (it was incredibly redundant) and replaced it with a single check at the start of the turn. I've only tested this enough to know...

I didn't check all of them with the original DLL, but the one that I did, did not crash. I may do further testing later to see if that was an isolated case, but for right now I'd rather move forward with the changes to the converter checks.

Not intending to kill them, as tempting as it may be :lol: As we discussed regarding the performance issue, and now this, I think I'm going to trim down the amount of checking it does significantly. So it will only check the status of converters at key points and at the beginning of the turn...

Ok cool, just loaded up the save and gave it a try. One thing Walter mentioned was that you weren't just getting shortage messages, but were also having production canceled on units that required resources of any type (which I assumed was the more annoying of the two). The latter was what I was...

Yes, the DLL hasn't been changed significantly so the size wouldn't likely change as a result. Thanks for the save, that should help me track down what is going on with the bug I didn't have an example of it for my first pass at a fix :)