Advanced Civ

well,

here is my current build:

its got the reproducible saves that has this crash.

ill continue to work on it.
 
what does the size means: "So I expect that your code somewhere writes a container size incorrectly"?
how can i check the source?
I find these Write calls difficult to locate. The Call Hierarchy in VS 2010 takes forever to search, doesn't work reliably and Write has several overloaded versions that need to be checked. Text search can't easily distinguish between the much more frequently used single-argument versions of Write (which I don't believe can lead to the "failed to compress" error) and the two-argument versions I'm interested in. I've found a few:
Code:
pStream->Write(MAX_PLAYERS, m_abFirstContact); // CvPlayerAI
pStream->Write(GC.getNumReligionInfos(), m_pbReligionFounded); // CvPlayerRecord
pStream->Write(GC.getNumEmphasizeInfos(), m_pbEmphasize); // CvCityAI
Admittedy difficult to see how the first argument could end up being negative in these examples. Maybe
pStream->Write(m_iNumVictories, m_abVictories); // CvInitCore
if a memory corruption were to overwrite m_iNumVictories. Can't say that this sounds terribly plausible. Can you find another way to provoke the "failed to compress" error upon saving? Could it also be some I/O error (unrelated to the arguments of the Write call)? I do recall errors upon autosaving when testing multiplayer games on a single machine because both processes tried to access the same file. I don't recall if that was also a "failed to compress" error message. (And I've worked around that problem by letting only one instance autosave when testing on a single machine.)
the gp, i added a check < 0 and made it to 0 a long time ago.
but its not a real solution, so i removed that and its back . i wanna get to the source.
A city having 0 GP birth rate and hence no valid turn count until the next GP is normal, and the birth probability function (GPProjection) needs to be able to handle that. Treating the turn count as 0 should be the correct way to handle it. Then the birth probability is only based on the GP points accumulated by the city so far (which btw is all that BtS ever took into account when it comes to displaying birth probabilities).
the victory, is there a chance its related to 1 of the 2 victory conditions i added ? (only xml).
cause when i auto played some games now with only the vanilla vic's, i still didnt see this exit / one more turn crash.
I guess? So far I'm really not sure if there are any dependable leads as to which part of the DLL code is involved, if any. I don't know what you're seeing on your call stacks as it crashes.
here fresh from a load try
So that's the try-import CvAltRoot in initRootFolder (BugPath.py). Seems to cause a RuntimeError when trying to write to sys.stdout, which should be PythonDbg.log (via CyPythonMgr in the EXE). I guess if CvAltRoot simply is not present, this should be an ImportError instead, which initRootFolder is already catching. It's not catching a RuntimeError – though I guess it easily could. Would be interesting to know what CvUtil was going to write to PythonDbg.log, but, since we don't exactly have a console to write to, I don't think we could easily direct stdout to a different channel. Could it be that CvAltRoot was in fact found somewhere in your Python or Modules folder?
Not sure if the connection to updateColoredPlots is important (or real).
 
well,

pStream-&gt;Write(GC.getNumReligionInfos(), m_pbReligionFounded);
CvPlayerRecord<br>pStream-&gt;Write(GC.getNumEmphasizeInfos(), m_pbEmphasize);
i look at these two.

could a write read order of tags can cause this? maybe i have something not in the correct order?

--
"failed to compress"
ill try to catch it with more details.
i do lots of compile and replace the dll. you speak of " I/O error (unrelated to the arguments of the Write call)".
maybe the frequest changes does something? im deleted the cache sometimes.

ill try the victory as well again.

--
i applied your gpprojection, so i guess it will be ok now.
i looked for xml files that might bring it down to 0 or less also put a debug check if the change value is -1 when the rate is 0.
seems that the modifier comes as 0 maybe, though it has a + 100 and a max on it.

--
i added it to the mod folder CvAltRoot, after i wrote you about the errors two days ago. also change to the right path.
python debug, maybe i should turn off the python debug flag write message - > isnt there something in the xmls of advc? i vaguely recall.
--
updateColoredPlots maybe a side effect.


--
here are some more funky stuff i got in the past hour, both og game start, map gen:

edit,
another one on space victory, but with a twist,
its player 1, after my human auto played player was eliminated.
the stack went through the save reply.
 

Attachments

  • maperr.png
    maperr.png
    165.2 KB · Views: 10
  • RIVER.png
    RIVER.png
    186 KB · Views: 11
  • space.png
    space.png
    367.8 KB · Views: 10
Last edited:
i look at these two.
No need imo. The assertions in FDataStreamBase.h should catch that issue.
could a write read order of tags can cause this?
That will easily cause the loading of savegames to fail, but writing should work in any order.
i do lots of compile and replace the dll. you speak of " I/O error (unrelated to the arguments of the Write call)".
maybe the frequest changes does something? im deleted the cache sometimes.
I think it would have to be an I/O error specifically involving the autosave file. If the error comes up again, it could also be interesting to look at that initial autosave on the file system – was the file created/ modified at all?
i added it to the mod folder CvAltRoot, after i wrote you about the errors two days ago. also change to the right path.
That probably explains the latest error then – the importation of your CvAltRoot.py failing somewhere unexpected.
python debug, maybe i should turn off the python debug flag write message - > isnt there something in the xmls of advc? i vaguely recall.
I suspect there's just something quite wrong with the CvAltRoot.py. If the paths can be successfully obtained by BUG from the Windows registry, then I wouldn't bother with a CvAltRoot file. Will also have to be excluded from releases (because it'll contain a local path). For logging during BUG initialization, setting fileLogLevel to INFO or DEBUG in BugUtil.py could help. I'm not sure if the corresponding settings in the BUG INI files (configurable from the System tab of the BUG menu) are already in use that early in the process.
here are some more funky stuff i got in the past hour, both og game start, map gen:
Simply a crash in the map script (PythonErr.log)? And then a NULL plot in CvMap::setupGraphical, maybe they're all NULL as a result of an error earlier in map generation?
the stack went through the save reply.
Oh. So what's the call stack?
 
loaded a save,
same rash on updatecolors,
also the python refered to init root.
removing the altroot file .

could entries in the schema xml files that their code was removed from the dll could affect anything?
i found one now in my improvements.

i think ill pm you, not to spam here as you did.
 
Searched the thread and don't think this has been mentioned. I think it would be better if the resource balloons/bubbles didn't block mouse-clicks. If a unit is standing on a resource then selecting that unit requires dodging the resource balloon. When right-click-moving a unit the resource balloon prevents the action taking place.

icon blocking clicking.png

In this picture trying to select the ship gets blocked by the resource balloon.
 
Those plot indicators are still largely out of my hands. I wouldn't know how to approach such a change at all. Can only recommend making them (even) smaller (Map tab of BUG menu) or maybe to aim at the unit's flag.
 
Maybe the
Python:
mouseOverPlot
function could be used. Some random link from google directed me to some civ code and there's this snippet:
Python:
+ def mouseOverPlot (self, argsList):
+
+ if (self.m_bReveal):
+ self.m_pCurrentPlot = CyInterface().getMouseOverPlot()
+ if (CyInterface().isLeftMouseDown() and self.m_bLeftMouseDown):
+ self.setMultipleReveal(True)
+ elif(CyInterface().isRightMouseDown() and self.m_bRightMouseDown):
+ self.setMultipleReveal(False)
+ else: #if ((self.m_tabCtrlEdit == 0) or (not
self.m_tabCtrlEdit.isEnabled())):
+ self.m_pCurrentPlot = CyInterface().getMouseOverPlot()
+ self.m_iCurrentX = self.m_pCurrentPlot.getX()
+ self.m_iCurrentY = self.m_pCurrentPlot.getY()
+ if (CyInterface().isLeftMouseDown() and self.m_bLeftMouseDown):
+ if (self.useLargeBrush()):
+ self.placeMultipleObjects()
+ else:
+ self.placeObject()
+ elif (CyInterface().isRightMouseDown() and self.m_bRightMouseDown):
+ if (not (self.m_bCityEdit or self.m_bUnitEdit)):
+ if (self.useLargeBrush()):
+ self.removeMultipleObjects()
+ else:
+ self.removeObject()
+ return

but that sounds like a lot of work, having to get the mouse target > get the ID of the unit on the target > make the unit selected etc... If only there was a equivalent of `pointer-events: none` that could be put on the balloon object itself, especially since its all the balloons (like notification for espionage event etc), but apparently those balloons are not accessible in the code. Oh well, this is such low priority and tiny detail. I have been enjoying the hell out of the mod, btw. Just brilliant work!
 
Last edited:
Thanks. The part you copied is from CvWorldBuilderScreen.py. Probably gets called by the EXE whenever the cursor gets moved onto a plot on the main map (perhaps over and over while the cursor rests there, perhaps only when the plot changes) in order to give Python scripts a chance to respond to that. It seems that the plot coordinates are not part of the argument list. Instead, the script calls the EXE back with CyInterface().getMouseOverPlot(), likely leading to the same function CvInterface::getMouseOverPlot as CvDLLInterfaceIFaceBase::getMouseOverPlot in the DLL. And, I think likely also the same as the pMouseOverPlot that gets passed to CvGameTextMgr::getPlotHelp, i.e. the plot that help text gets shown for on the lower left. Whereas a plot indicator blocking the cursor will show help text for the resource (or unit) that it refers to. In other words, I assume that the DLL only has easy access to a, let's say, high-level mouse-over plot and not to whichever plot the cursor would be on if all obstructions were removed. One could test whether the result of getMouseOverPlot is not affected by plot indicators after all, but it strikes me as too unlikely to bother. The whole approach also sounds like ... yes, work and also like the resulting user experience could be somehow janky.

I seem to recall a glitch where the cursor ignores the unit action buttons and most of the rest of the HUD. The help text area will show text for the tiles underneath the bottom panel. I only find notes (in the AdvCiv manual) about the opposite problem – the cursor refusing to connect with any plots on the main map and only interacting with the HUD. Anyway, I do imagine that, with full access to the EXE, one could easily set the plot indicators to be transparent to the cursor. (On a side note, I'm not positive I'd want that. Help text for the indicators could at least in theory be useful. I think AdvCiv's list of current and near-future buildings benefiting from Marble and Stone is already slightly useful. Looks like the text could also be specific to the tile that the indicator points to.) Some chance that shaders can impart such transparency...(?) I think they're only concerned with visual transparency.
 
Found a plane overflow bug. If all your cities and cities you have open borders with are full of planes (4 without airport, 8 with), then creating another plane will crash the game upon pressing End Turn. In BTS, the created plane just disappears.
In both BTS and AdvCiv, that includes if there is an available Carrier. A newly created Fighter or Jet Fighter will not automatically rebase to it if created in a full city.
 
Found a plane overflow bug. If all your cities and cities you have open borders with are full of planes (4 without airport, 8 with), then creating another plane will crash the game upon pressing End Turn. In BTS, the created plane just disappears.
In both BTS and AdvCiv, that includes if there is an available Carrier. A newly created Fighter or Jet Fighter will not automatically rebase to it if created in a full city.
A nice, realistic fix could be if a plane is above the limit and cannot rebase to any airport or carrier, than it starts the new turn with 0:move:, as it is just stored in a hangar.
Just brainstorming :)
 
Found a plane overflow bug. If all your cities and cities you have open borders with are full of planes (4 without airport, 8 with), then creating another plane will crash the game upon pressing End Turn. In BTS, the created plane just disappears.
In both BTS and AdvCiv, that includes if there is an available Carrier. A newly created Fighter or Jet Fighter will not automatically rebase to it if created in a full city.
Interesting,
Can you add tge save game ?
I can help f1 debug , until he sees this i guess.
 
Can you add tge save game ?
I can help f1 debug , until he sees this i guess.
[
I think the build option should just be blocked maybe.
No no, I reproduced and debugged it last night. Thanks though. AdvCiv used to block the train-unit button, but I reverted that in response to this post. Still possible to re-able that through XML (CAN_TRAIN_CHECKS_AIR_UNIT_CAP).
That sounds wrong, iirc they just auto-rebase to a closest city. Sometimes neighbor's.
They get scrapped only when there are no such cities, i.e. when they're all already filled with air units. AdvCiv adds a message that says when the unit has been moved due to missing capacity and a different one when it has been destroyed. Seems that I hadn't tested that unlikely case; this was indeed crashing the game.
I'll address carriers and movement points later.
 
So: the forced moves of air units use the same jump-to-nearest method that gets used when borders push units away. (And that's also what can destroy units when they have nowhere to go.) Movement onto transports is not allowed. I don't think I want to change that for land units, but I feel that an exception for air units - despite, in a way, complicating things further - would be a little more intuitive. And I guess there is a real possibility for all of a player's cities to run out of air capacity, and a player might then expect that carriers can (automatically) receive aircraft too. So I'll allow forced air moves onto carriers, but not only as a last resort (that does seem like an unnecessary complication). Rather, if that's the nearest place, they'll get moved onto a carrier.

And perhaps worth mentioning that carriers were already possible rally points (Shift right-click when the city bar is selected), and that AdvCiv tries the rally point before a jump to nearest when a city has no room for its newest air unit.

Now, regarding movement points, AdvCiv takes away an air unit's movement points for one turn after a forced move (actually for all jumps to nearest; so that those forced moves aren't free). So that's quite doable. But it would stop excess air units from being relocated once a spot opens up. I guess the player could instead move the older air units away first, and that will untie the newer ones, or the ones tied down could get moved automatically once there is room somewhere. This does seem already too complicated and strange if it's only aimed at the rare case of all air bases being filled up. It would be more interesting if the forced moves could be avoided entirely that way. I guess that too could work, but probably air units shouldn't be concentrated in arbitrary numbers in one place for balance reasons, even if they can't all immediately fight.
 
I suppose me being unable to get BAT running on my new machine turned out to be a blessing in disguise, because it made me find my way back to this gorgeous mod. Love what you've done with the place!

Nevertheless, a few quick games revealed some small issues to me, prime among them the absence of some features from BUG/BAT/BULL:
  • No display of XP for units in city screen/bar (E.g. if you are running Theocracy and hover over the Horse Archer build option in a city that has a Barracks and a settled Great General, but not the State Religion or a Stable, the unit tooltip would display in green text "2lvls, 3XP from Barracks, 2XP from Specialists" and in red text "2XP from State Religion, 2XP from Stable")
  • Highlighting of the tiles currently assigned to a city when its city bar is selected, (un)improved (un)worked tiles highlighted with colored circles
A technical issue I've encountered:
  • Sometimes the game doesn't recognize keystrokes immediately, but I have to left-click somewhere first
And some game design gripes I have:
  • Imo your implementation of Financial is a bit clunky. Why not just make it so the extra commerce is only applied on tiles with 3+ Commerce instead of 2+? If there's any trait in need of a nerf, it's Financial. I'd even go so far as to say raising the threshold to 4+ would be in order if combined with double production speed for Market and Bank, which fits thematically and gives it more of a money/gold flavor than a research one. I get your issue with not wanting Financial to synergize with Serfdom, but what's imo more pressing is the synergy between Serfdom and Golden Ages. If you have a bunch of dry/non-riverside farms all over the place in the late game, adopting Serfdom for the duration of a Golden Age looks really attractive since all of a sudden tiles that before generated 0 commerce now generate 2, which can easily compensate for the -1 from Towns unless you really went all in on them. In the base game already there's a similar synergy between Universal Suffrage and Production from Towns, but, and this might just be my political bias speaking, I think Golden Ages incentivizing democracy is much more flavorful than incentivizing a return to feudalism.
  • Vassalage removing colony maintenance costs is a bit of a headscratcher from a lore/historical perspective. One way of dealing with high colony maintenance costs is to release the relevant cities as a vassal... and running the Vassalage civic removes that incentive? I.e. running the Vassalage civic makes it *less* attractive for a player to give up direct control of part of their empire in favor of turning it into a vassal? What? I guess one could make an argument that the Vassalage civic implies your civilization is already internally organized in such a way that your entire empire consists of a multitude of vassals, which would make such a move redundant, but I'm not really buying it. Since vassal civs are a feature of the game I think running the Vassalage civic should make it MORE attractive to have a harem of them serving you instead of administering their land directly, not less.
This last point I am about to make has become so extensive that for the reader's sake I'm putting it out of the list so I can put paragraphs in it:

I understand the heavy restrictions on worker capture from a game balance perspective, but I don't find it convincing from a historical one. Since the dawn of civilization (no relation with the mod of the same name), wherever people have gathered a lot of stuff, other people tried using violence to take all that stuff, often to great success. And often that taking included the very people making stuff themselves, in order to force them to make more stuff closer to the aggressor's home and/or according to their needs. Human players simply act in a logical and historically reasonable manner when they try to kidnap defenseless workers of other civilizations in the early game, before economic and diplomatic entanglements develop enough for such ruthless wars of opportunity and aggression to have serious drawbacks. Instead of trying to dis-incentivize this behavior on the grounds that it's unfair towards the AI, which doesn't engage in opportunistic acts of worker-kidnapping, I say the change should be the other way around!
Kmod, on which this mod is based, has a reputation for possessing a scarily smart and ruthless AI, so why not embrace that reputation, really lean into it, and have the AI try and kidnap defenseless workers itself when an opportunity presents itself, whether it's from a fellow AI or a human player. In fact I'd go even further! Let's say it's turn 15, you just finished a worker, the one warrior or scout you started with is off in the wilderness somewhere exploring, and an AI warrior happens to move onto one of the four corner tiles of your capital's BFC, which happens to be on a hill, so they can see your empty city, and what do they see? An easy and defenseless target and potential future threat that they could immediately nip in the bud if they're quick about it. They SHOULD declare war on you and try to take your capital, it's a zero risk high reward strategy if there's not even a single defender inside, which is typical for human players in the early game. It's a no-brainer. In a Free For All multiplayer match it's what a fellow human player would do to you, provided no house rule was established to forbid such behavior.
Instead of trying to put gloves on the human's hands in the early game to prevent them from punching the AI too hard, I think you should take the gloves off from the hands of the AI! Give them claws even, and fangs to bite with! In the base game building a Worker first on Turn Zero is the optimal strategy in 90+% of cases, with only very rare exceptions. It's the first build decision of the game, but it's not really a decision, because it's not a meaningful choice when one option is orders of magnitude superior to its alternatives. What would make your first build order a meaningful choice would be the introduction of risk, of danger, of the possibility that a lucky AI warrior might just march in and take your capital on Turn 15 because you spent all this time building a worker and sending your only defense away to explore instead of keeping them close by in case they are needed to protect the motherland.
Or at least make it, like, a game option or something. "Nasty, Brutish and Short" or "Hobbes was right" or something like that would make for a fancy flavorful name. Or just limit this sort of ruthless opportunism to the very early game, perhaps until the AI discovers Writing which unlocks Open Borders. That would even be somewhat logical: If you have a military unit on the border to someone else's territory, you have nothing to lose and face no negative repercussions, why wouldn't you just march in there and see if you can't nab some stuff while you're here, or sabotage a potential rival's progress? Once you have Writing there's more of a rational incentive towards peaceful co-existence because you can in theory explore their territory with their permission, and boost your economy via trade routes, so declaring an opportunistic war of worker kidnapping does actually have some cons to it instead of just pros.

Anyway those are my two cents, at least before we take inflation into account. :D

Edit: Wait! Speaking of inflation, what's up with that? I saw that point missing in the ingame financial advisor.
 
Consider this a Bug Report:

Traits and their effects aren't displayed on a leader's Civilopedia page.

Screenshot from 2025-03-10 19-05-32.png
 
Yes, this should've been fixed by now – but I still haven't released v1.12:
In Civilopedia leader descriptions are absent, and the message about the function "getCiv" not being defined is displayed.
Ugh, this is an easy bug to run into. Perhaps another release will have to come sooner than I'd hoped.
Seeing that going through @civ4-advciv-oracle-bug's (that is the user name ...) suggestions has turned into a larger project, I don't have an excuse for delaying a release for much longer.
I intend to first go through the savegames provided by civ4-advciv-oracle-bug. Maybe some other to-do will have cropped up by then. At any rate, I'll want to run some tests eventually, hopefully play a little too. So probably a few weeks at best. There's always the development version on GitHub (zip download; folder will need to be renamed to just "AdvCiv"), which lacks such testing. And the manual isn't kept up to date on GitHub. The GameCore DLL usually is up to date or almost; should certainly be consistent with the other assets and thus playable. GitHub can also compare v1.11 and 1.12 for a change log.
 
UI improvement suggestion: Clicking on the Great Person Bar should take you to the displayed city.
 
Back
Top Bottom