hm...I rigged up a "dirty" fix to see how it would basically play out...just flipping the original five cities insures a german collapse.
I have actually started flipping the cities one at a time starting in 1200 or 1250 from the west and working my way eastward (leaving the germans to keep vilnius). Even though St. Petersburg hasn't spawned (because it wasn't founded) yet, the germans always seem to found it as Wiburg anyway.
then, in 1400 and in 1720 I have the 59 tiles north of Moscow flip en masse (I've defined a bum city for each tile). My hope is that after safely and slowly flipping the cities on Russia's western core border (without causing war between russia and the former owners, if any), it will head off german expansion to the northeast and there will be nothing to flip in 1400 and 1720 anyway.
I'm sure I just made you cringe, but I'm afraid a second spawn would have the same effect and collapse germany, swapping one imbalance for another.
Yeah, you should probably not spawn or flip any cities beyond the British Isles anyway. The RFC + Celts modmod quickly becomes antaine's privat modmod...
The reason the Germans collapse is probably because they lose half of their cities in a short period of time. In that case it has nothing to do with stability.
It is possible, though, to build in functionality that compensates for both the stability hit for losing cities and to resets the counter for lost cities. So thanks for the idea!
I'm already done with the rest of the code - all that's left is the actual testing - and the inevitable bug hunt. I'll add the anti-collapse code in there as an additional setting once the function itself behaves as intended.
Oh my, I'm having the most fun I've had in ages with this programming business.
lol, I'm happy to..."help"...I wonder if this germany/russia thing was a problem in the original. I'd imagine it would almost have to be, as the Celts and Carthaginians shouldn't have had an effect on Russian development.
In any event, what you're working on sounds like a much better fix than my "dirty" method, but for now I'll just leave what I've done alone. If the cities can be transferred to russia without hurting the other civs so much the better (and cleaner, codewise).
lol, I'm happy to..."help"...I wonder if this germany/russia thing was a problem in the original. I'd imagine it would almost have to be, as the Celts and Carthaginians shouldn't have had an effect on Russian development.
Yeah, it kinda is and this is also one of the reasons I've been going on about the "second spawn dates" and whatnot. Well, now I'm actually coding this stuff so I won't be having these "issues" myself for much longer...
In any event, what you're working on sounds like a much better fix than my "dirty" method, but for now I'll just leave what I've done alone. If the cities can be transferred to russia without hurting the other civs so much the better (and cleaner, codewise).
I'm debugging like crazy, but now I have to get some sleep as its 1 AM over here.
It turns out Rhye has been forced to overcome some pretty weird obstacles with his city flip code, and I was forced to follow suite before I got it working. Right now I'm struggling with how to use the len command with tuples... (To get a value of how many entries there is in the turple.) All this is pretty new to me so I'll just get a fresh start on it tomorrow.
TL: This is the first coordinate for defining the area. Use any pair of values inside parenthesis and divided by a comma - or use a variable with similar content. BR: This is the second coordinate, like above. tExceptions: This is a turple containing any exceptions to the area defined by the values above. (It can be used both for adding tiles outside of the coordinates and for taking away tiles within the defined area.) The coordinates must be set in pairs within parentheses (divided by comma) set within yet another set of parenthesis (and divided by comma). Or use a tuple variable. iReceiver: This integer value is the index number of the Civ getting the flip. bHuman: This boolean determined whether or not iReceiver can be the human player ("True") or not ("False"). bMinorOnly: Boolean determining whether or not the cities and units inside the area must belong to a minor Civ ("True") or not ("False"). bAIOnly: Boolean allowing only AI controlled cities and units to flip ("True"). bConquest: Boolean determining whether or not the cities will flip peacefully ("False") or not ("True"). If set to disabled ("False") there will be some stability given to the target Civ to compensate for the lost city. Also there shouldn't be any default collapse just because the Civ lost too many cities in a short period of time. (This is also true for custom.cityFlip() as of this update.)
I made this function with the default areas defined in Consts.py in mind, so it would probably be easier to use with those variables (tuples). So, in your case a peaceful transition of all non-human cities within the Russian Broader Area would look like this:
Don't forget about the tNormalAreaSubtract tuple when using Normal Areas, as it is used for taking away some tiles from the Normal Area. Otherwise the area might be larger than defined in Consts.py by Rhye.
As you can see for yourself, you simply substitute tNormalAreaSubtract with tExceptions from Consts.py when adding tiles to the Core Area. You should know from the RFC Atlas that Core Areas (and also Normal Areas) aren't always rectangular in shape, and this is what those extra tuple lists are for. (Since you didn't delete the Carthaginian entries for your Celts they had a spawn area in the Levant... Well, until I deleted those entries for you.)
If you wanna define your own areas for custom.flipArea() you can choose between two different methods. Here's the first one exemplified with the Russian Core Area:
As you would expect, it does exactly the same as the above methods of using the same Core Area.
Now give it a try and report back. Please keep an eye out for any errors or exceptions, because I haven't been able to test every imaginable scenario myself.
Yeah, and you still need to have a "if" statement in order to trigger the function on the right game turn. But there need be no check for human player or player alive (as this is already a feature in custom.flipCity() - the area flipping function uses the city flipping function to do its dirty work)
edit: Adding this to Barbs.py (or whatever file you're using for you flips and whatnot) could make it easier to work with:
Because then you don't have to remember to type in the con. prefix every time to fetch the values from Consts.py (as they will already be defined in the file you're working with).
You should keep track of the German stability in PythonDbg.log to see what the impact really is. If its merely a case of upping the stability bonus, that would be easy to do. (Right now the Civ losing cities to - peaceful - flips get a +2 boost. Its the same amount used by Rhye to compensate for secessions, but it might not be enough. I'll just have to look up what the stability penalty for losing cities is, then...)
Also, you need to look up what kind of collapse has occurred once it does happen. Because there are four kinds of collapse for the AI! Its hard to fix this issue if we don't know what causes the collapse in the first place.
Previously I suspected a "COLLAPSE: Generic" which is caused by losing half of your cities within a certain turn interval. I actually haven't tested if my fix for this works, so I'm pretty much counting on you to do it.
If its "COLLAPSE: Civil War", then its solely caused by instability (less than -40 to be exact).
kk, I'll try to check that, I have all debugging on, but I don't see anything in there that seems to apply. Is the error message always the same, "the X empire is descending into civil war?" Perhaps germany's instability is merely a coincidence
As far as I can tell, the basic stability loss for losing a city (via "trade", not "conquest") is a function of 16 - (number of cities / 2) + 2.
So if the Germans have, say, 10 cities and they lose 5 of them to the Russians on a custom flip, the penalty for the first one would then be 16 - 4 (rounded down from 9 / 2) +2 = 14. The second one would also be 14, the third and the fourth 13 and the fifth 12.
It adds up to a hypothetical total stability loss of -66, which would pretty much ensure a collapse, even with the +10 compensation (5 * 2). Also, there is secondary stability penalties for the expansion (and perhaps diplomacy) category. But we could probably up the stability boost to at least +10 or something (14 would be an average stability loss in the German example above, rounded up).
There is another set of numbers involved in proper spawns and respawns, but I haven't tried emulating those with my code in regard to stability. But we could test the new value first - change the value 2 on line #320 in Custom.py to 10 (or whatever you wanna test out). If it proves unreliable, I could just add that code to custom.cityFlip() (which is actually used to flip the cities).
kk, I'll try to check that, I have all debugging on, but I don't see anything in there that seems to apply. Is the error message always the same, "the X empire is descending into civil war?" Perhaps germany's instability is merely a coincidence
It's CivilizationIV.ini, located in (user)/Documents/Civilization IV Beyond the Sword. If you enable logging without any other changes, it can spot Python exceptions but not much else. That's still useful for spotting typos and the like.
I wonder how much faster the world advances if tech brokering is enabled...does that balance out the old civs vs the new civs better, or does that make everything advance way too fast?
Yes, the old versions were removed. The final release was Celtic Mod v3.0, it has its own thread in the same list where you found this one. Honestly, though, RFC Irish (released this week) makes for a better mod altogether, and really what I should have been doing from the start
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.
