@f1rpo: Sorry for the spurious report about the trade connections. I updated to latest and tried to recreate the problem without the road to Guangzhou, and couldn't, so chalk that up as either FIXED or NOTABUG.
Spurious I guess, but I'm still glad to have corrected that special rule for islands. And it's an interesting situation with the lake connecting the capital with rivers that don't actually flow into the lake.
As for other river-trade stuff, where is the intended behavior documented? I don't want to tug your sleeve with a dozen whatabouts unless that's necessary.
My changes are documented under change id 124 in the manual. (I wish the id was something more sensible like "advc.tradenet" ... Not sure if Git branches would've been suitable for organizing changes at that level.) But this example, as far as I'm aware, is entirely according to BtS rules, for which the best documentation is arguably CvPlot::isTradeNetworkConnected. One other thing that confused me once about the BtS rules (screenshot attached) is that "mesopotamian" tiles connect rivers. Perhaps obvious really; a tile bordering on two rivers is connected to both of them, thus all those tiles are in the same CvPlotGroup.
As for the dotmap stuff, I know Python pretty well. I could try and whittle down that to-do list if you'd like.
Oh. That would be very nice, I'd appreciate it if you could look into it. I was just about to do so myself. Haven't gotten beyond locating the modules (CvStrategyOverlay.py, CvOverlayScreenUtils.py in Python\Contrib) and noticing/ remembering that they're actually fairly complex and -maybe- well-written. As for clearing upon map re-gen or a player switch (change of CvGame::getActivePlayer), going through BUG\BugEventManager.py might be cleaner than calling a dot map function directly from the DLL - though either way would be an improvement over the status quo. Hiding only the city dots placed by other players when the active player changes would be nicer than just clearing; not sure if it's worth the effort. As for saving the color selection, I wasn't seriously going to implement that, though perhaps it's actually easy; obviously the dot locations are being saved already. Reloading Python scripts doesn't really work correctly in BUG-based mods (I have a few notes about that under id 009b), so the dotmap getting cleared isn't the biggest concern in that area. Anyway, I've just done a quick test, and reloading scripts caused a city dot that I had just placed to disappear but not those loaded from the savegame that I used for the test.
That would explain why cities are wandering in and out of stability... Stuff defenders in, city says "may revolt if 4 are removed", then a couple turns later it wants another half-dozen units. [...]
It was pretty unrealistic of me to assume that players would just notice the causality. I'm generally sorry that all these test games are getting pretty much wrecked by the mod. At least the major issues are getting fewer now that I've stopped introducing new ones.
Double whips helping with unhappiness really isn't an issue specific to conquered cities, so maybe a better reason for nerfing Slavery in conquered cities is that the new owner can otherwise whip units for revolt suppression in the very city that needs to be suppressed. That would make the insurgents look pretty dumb.
So you can't whip the city down, but everyone in it is foreign-culture angry and/or you may be short tiles to work due to enemy culture, so it just starves anyway.
Turning that around: So there are angry citizens and too few tiles to work, but you don't really mind because you were going to whip the city down anyway. I agree though that the effect of whipping on foreign culture strength is too strong. It shouldn't come down to "you can't whip."
And costs you 80gpt in maintenance while it does. (well, maybe not in that save, but it does later in the game)
That can be unfair, I agree. The player can't really anticipate whether the Courthouse will survive, how high maintenance will be and how long it'll take to construct a new one. It's also weird for a single city to be such a money sink. I guess, in the late game, Universal Suffrage could be a way out. But having Slavery as an additional option is better. (That's to me the main argument in favor of a hurry ability: Sometimes, whether by a player's own fault or a fault in the game design, not being able to get a building or unit for some 10, 20, 30 turns is too punishing.) So if I decrease the hurry anger/ revolt penalty, it should again be possible to speed up that crucial Courthouse.
Going back to the Delft example, requiring 15 garrison strength (instead of 11 when not whipped) would seem too little, 20 too much, so I'll aim somewhere in between. The aim being that it'll usually remain undesirable to whip conquered cities so long as the new owner's culture is much smaller. On Marathon though, due to the longer anger duration, 15 could be fine.
Guess if I'm stuffing a dozen archers in every city, I might as well use Monarchy all game.
Well, hopefully, if you don't routinely whip those cities, that won't be necessary anymore. Without the hurry anger, two Garrison I Archers would suffice to pacify Delft (well, 0.7% revolt chance then). And no need to shuffle them around then either.
Wait, what? A dead civ gets harder to pacify when the game era advances? But if I leave him a size1 foodless city somewhere it doesn't?
In BtS, it's always the game era that matters. I'm not fond of (indirectly) using the era of unmet civs. So ... perhaps the average era of civs known to the new owner. Could also use tech score or an average weighted by civ population, but it's probably better not to have foreign culture strength increase gradually or potentially fluctuate; might lead to more micromanagement.
Map is from "random script map" (leader and civ were also random). Not actually sure which one it chose, and I didn't notice.
Archipelago according to the Settings tab. But it turns out that Random Script Map doesn't simply defer to other map scripts; it contains modified copies of Archipelago etc. Also, it has a custom terrain generator derived from the standard terrain generator – to which I've made changes causing the derived generator to crash. Hopefully I can work around that in the standard generator so that I don't have to copy Random Script Map into the mod. (That would place it near the top of the list on the Custom game screen; don't want to endorse it to that extent.)
Oh, one more thing. I usually just use State Property. Actually went corps instead on the below screenshot. Have corp costs always been this insane and I just forgot? Yes, I'm in Free Market.
I also got the -25% inflation event this game. [...] I'm making half that back from my HQs (in wall street city, so 688+200%), but it's still expensive. [...]
I don't think anything has been changed about that other than inflation being included in the displayed costs. Mining Inc. costs 20% more maintenance than in BtS. I had actually meant to revert all the K-Mod adjustments to maintenance costs of specific corporations; looks like I missed that one. The costs scale with city population and the number of consumed resources. With all that land you probably have a lot of resources. I recall a thread in the K-Mod forum where a player complained about high corporation maintenance. Huge map, I think also Marathon, and he had basically conquered the entire map and spread corporations everywhere.
Then why does the game allow you to continue play after "victory"? Obviously, the game makers realize that people like to keep going. So, why build mods that make this untenable? That makes no sense.
[...]
Turn 1105 April 1977
Current civics: Representation, Free Speech, Emancipation, Free Market, Pacifism.
[...]
261 total cities
[...]
Expenses: 104,332
Unit cost: 34
Unit supply: 2
Civic upkeep: 4164
City Maint: 55,413
distance: 3197
# cities: 15,140
colony expenses(?) 2323
corp payments: 34,753
Under current game mechanics, even if you eliminate ALL fossil fuels, and workers could plant forests, you still can't build a sustainable civ unless you starve yourself down to about 10 pop per city. Again, ridiculous.
[...]
This seems to happen fairly regularly. Might be fixed now (i.e. once I commit my changes). The pathfinder assigns a cost of 1000 for every movement point and adds smaller costs in order to choose between paths of equal movement cost. There are weight parameters for those extra costs. I think the per-step weight was simply too small. It got outweighed by a combination of preference for straight over diagonal moves (aesthetic reasons; only for human players) and a random-like tie-breaker (to avoid paths having the exact same cost). My only worry is that scaling some of the other weights up along with the per-step weight might have unforeseen consequences, especially since the cost per movement point is still 1000. Well, they've been scaled up before, I'm not too worried, but it'll be something to watch out for.
Can you look at the Map hut result?
I've gotten 3 in this new game, and none have revealed ANY tiles.
Sadly, randomseed is on, so I can't give you a save.
@Elkad: You're right, it picks a revealed tile as the center of the area to reveal -- but the center should actually be an unrevealed tile. Will fix.
Fyi, I've added an XML switch (GlobalDefines_advc.xml) for overriding the new-seed option a little while ago. Untested though ...
When loading from a savegame (CvGame::read; game options have already been loaded at this point), it does the following:
Code:
if (isOption(GAMEOPTION_NEW_RANDOM_SEED))
{
if (!isNetworkMultiPlayer() &&
!GC.getDefineBOOL("IGNORE_NEW_RANDOM_SEED_OPTION")) // advc
{
m_sorenRand.reseed(timeGetTime());
}
}
So if a potential bug is encountered in a game with the new-seed option, the player can exit, enable the override in XML, restart and load the latest savegame. That way, the player should be able to reproduce the problem without the RNG getting in the way. Or if I receive such a savegame, I can do the same thing. (Actually, I might just always enable the override because I don't play with the new-seed option myself.)
I've taken another look at AI_attackCityMove. There are actually AI_stackVsStack calls in there too, but that function only considers targets that can be immediately attacked. So it seems that, for moving toward a target, only AI_anyAttack could be used. But nothing would stop the target from moving away – and the city attack stack from pursuing it indefinitely. (Like an AI Frigate chasing a Privateer.)
Either a bug or counterintuitive behavior w.r.t. whipping. I have a city that can 3-pop whip to one hammer less than the price of a courthouse, which is correctly reported as -1 overflow in the event log and the city's production bar (screenshot 1). So far, no problem, as far as I'm concerned.
Minor display bug: the whip button, which usually shows overflow on mouseover, doesn't (screenshot 2).
After whipping, there's one hammer left to complete the build, and because of that(?), there is the option to whip again (screenshot 3). The inconsistency is a little troubling.
Worth noting: the city's 1.25 production bonus turns 270 whip hammers into 337.5, which is .5 less than enough to exactly fill the bar. Something, something, rounding, counting forward vs counting backward.
Either a bug or counterintuitive behavior w.r.t. whipping. I have a city that can 3-pop whip to one hammer less than the price of a courthouse, which is correctly reported as -1 overflow in the event log and the city's production bar (screenshot 1). So far, no problem, as far as I'm concerned.
In order to minimize overflow, the idea is that hurrying through Slavery only covers the remaining production cost minus any guaranteed production, i.e. production from chopping and 1 from the city tile. (All other tile production isn't guaranteed because the assigned citizens could get sacrificed or the city owner might reassign them before the end of turn.) So -1 overflow is indeed correct when the BUG option for not including the current turn is set. Well, not entirely correct as negative overflow arguably doesn't exist, and a little puzzling in any case. However, if I just treat -1 as 0, then those two cases can't be distinguished, and I'd rather not write special game text for the -1 case. Perhaps the 1 should be included even when the "include current turn" option is not set, but then the option won't really do what it says. Maybe it's good enough as it is, and those options are disabled by default anway.
Minor display bug: the whip button, which usually shows overflow on mouseover, doesn't (screenshot 2).
In this case, the UI code had actually ignored negative overflow; fixed.
After whipping, there's one hammer left to complete the build, and because of that(?), there is the option to whip again (screenshot 3). The inconsistency is a little troubling.
Attached: v0.97-pre8 (edit: no longer the latest), to be combined with #7.
* Fix a crash upon cycling to previous unit
* Fix map outcome (goody huts)
* Fix minor path finder issue
* Fix hurry overflow being off by 1 sometimes
* Fix one more issue with AI not finding a peace proposal when asked "what is the price for peace" (thanks @SuperXANA)
* Fix a K-Mod bug that had lead the AI to use the "Big Espionage" strategy too frequently
* AdvCiv changes to standard terrain generator no longer interfere with custom terrain generators. Potentially affected scripts (in the earlier pre-release versions): RandomScriptMap, Rainforest, Highlands, Earth2, Donut, Boreal, Arboria, Fantasy, Great_Plains, Hub, Oasis, Ring, Wheel, Ice_Age, Team_Battleground
* Revolts:
- Reduce impact of hurry anger on revolt chance
- Warn about hurry anger in hover text of nationality bar
- Compute tech progress in a way that doesn't reward keeping the cultural owner alive
(details: Git commit message)
A pair of information leaks in located Event Log entries:
Civ -> Capital: Great Person births are located at the civ's capital, so the player can click on them to see where that civ's capital was at the time of the announcement. Mostly-dead civs that have retreated to islands can have their position unfairly given away.
Capital -> Civ: War/peace declarations are located at the active party's capital, so "Unknown has declared war on Unknown!" can be resolved to "A civ with a capital where Berlin now stands has declared war on Unknown!". Not sure which is the best resolution: strip the location info, fill in the names, or not announce/log the event to begin with.
Hi f1rpo! I've been having a blast with your mod. I'm liking almost all the changes I see. Much appreciated that you're further continuing the progress I previously enjoyed from karadoc's mod, and to a small extent my own PIG Mod. Your mod has reinvigorated my interest in the game after a long break!
Onto feedback...
I noticed it was recently brought up there was something weird going on with GP points relating to National Epic. I'm definitely getting something weird going on in my current game. My GP Farm has currently only 4 sources of GP points - 1 Great Prophet point from Moai, 1 Great Artist point from National Epic, 12 Great Merchant points from 4 specialists, and 6 Great Engineer points from free engineers from Industrial Park. The Industrial Park was only recently constructed (since the last GP birth) however. But even still, it's unexpected to see the the Great Prophet probability currently at 45%. It completely dwarfs the Great Artist rate of 3% even though the same number of both points should have been generated the whole time. At a ratio of 1:1:6:12, I don't see how probabilities of 45%:3%:14:38% are arising. The merchant, engineer and artist probabilities look about right though. Something specific to prophet points? I already had the previous GP pop out as a great prophet to my dismay but I figured I'd just lost track of what points had accumulated. The fact it's happening again has me convinced something's wrong.
He covered that upthread. 97prerelease straightens out GP probabilities.
You need to get 97pre7, and then paste the pre-8 update (bugfix) into the folder as well.
He covered that upthread. 97prerelease straightens out GP probabilities.
You need to get 97pre7, and then paste the pre-8 update (bugfix) into the folder as well.
@PieceOfMind: Thanks for the kind words; great that you're liking the mod. Yeah, some of your balance changes have stuck around, I guess most prominently the +1 Farm commerce from Serfdom. (At least it's my guess that karadoc adopted that from PIG.) If any AdvCiv change bothers you (particularly), I'd of course be interested to know about it.
[...] Something specific to prophet points? I already had the previous GP pop out as a great prophet to my dismay but I figured I'd just lost track of what points had accumulated. The fact it's happening again has me convinced something's wrong.
This squares with the previous bug report, where Great Artist had greatly inflated odds. When the projected odds don't add up to 100, my v0.96 code adds 100 minus the sum to the GP with the lowest unit id – among those GP for which any progress has been made. Great Prophet has the lowest id among GP; the next lowest is Great Artist. So I'm hopeful that this is just a display bug and already fixed in the nightly builds. (Which would mean that the first Great Prophet was just bad luck coinciding with the display issue.) Please note that the version Elkad linked to is at best a beta version; it may have worse problems than spurious GP odds.
I've updated my list of changes that other DLL mods could easily adopt (lower part of post #4). I've turned the whole list into Git commits based on K-Mod 1.46. As a by-product, my kmod_tweaks Git branch now contains a DLL that is essentially the K-Mod DLL with bugfixes (hopefully no new bugs ) and the BULL pre-chop option.
Civ -> Capital: Great Person births are located at the civ's capital, so the player can click on them to see where that civ's capital was at the time of the announcement.
They should be located wherever the GP was born. If that city was founded in the fog of war (i.e. tile revealed, city unrevealed), then, yep, the city name and its location are leaked. I've added an is-revealed check for the city.
Capital -> Civ: War/peace declarations are located at the active party's capital, so "Unknown has declared war on Unknown!" can be resolved to "A civ with a capital where Berlin now stands has declared war on Unknown!". Not sure which is the best resolution: strip the location info, fill in the names, or not announce/log the event to begin with.
This confused me because "unknown" is only shown for civs whom the active player hasn't met, and war declarations are only announced to civs that have met both war parties. My conclusion is that those messages were sent before you took control of your current civ, i.e. the problem only affects the Rise & Fall option. So the (K-Mod) code that decides whether to conceal the identity of a civ must not decide based on the currently active player. I've had to work around that anti-info-leak behavior on earlier occasions, but, in this case, there is no good workaround, so I've finally cleaned it up – hopefully without giving away civ identities in one of the few situations where an unmet player can actually get mentioned in game text.
Now that I've written at length about city tile production getting subtracted from hurry overflow, I've decided to revert that change. Avoiding 1 hammer of overflow isn't worth the added complexity. (I still think that not stacking hurry overflow with feature production is a good idea – all upside –, and counting all city production when computing hurry gold also still seems sound; so those changes remain in place.)
Ironclad upgrades to destroyer, but an ironclad in the queue when you finish combustion (actually when i hooked oil a turn later) is just lost hammers.
Don't think it's supposed to be that way?
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.
Not sure if Git branches would've been suitable for organizing changes at that level.) But this example, as far as I'm aware, is entirely according to BtS rules, for which the best documentation is arguably CvPlot::isTradeNetworkConnected. One other thing that confused me once about the BtS rules (screenshot attached) is that "mesopotamian" tiles connect rivers. Perhaps obvious really; a tile bordering on two rivers is connected to both of them, thus all those tiles are in the same CvPlotGroup.
from the city tile. (All other tile production isn't guaranteed because the assigned citizens could get sacrificed or the city owner might reassign them before the end of turn.) So -1 overflow is indeed correct when the BUG option for not including the current turn is set. Well, not entirely correct as negative overflow arguably doesn't exist, and a little puzzling in any case. However, if I just treat -1 as 0, then those two cases can't be distinguished, and I'd rather not write special game text for the -1 case. Perhaps the 1 
Maybe it's good enough as it is, and those options are disabled by default anway.
) and the BULL pre-chop option.
