Single Player bugs and crashes v42 plus (SVN) - After April 2022

I moved the unit selection cycling code from exe to dll (I have no idea what is in the exe so I basically reimplemented the code in dll as I saw fit) to get better control over the automatic unit cycling. There were multiple bugs in how and when units got unselected and cycling would happen which annoyed me immensely.
An improvement with it automatically unselecting units that use up all their movement points in a stack is that it no longer auto cycle to a different stack (assuming you won't want to move the remaining units that can move) so one have to move the cam back to the unit one just moved, select it again, unselect the unit with no movement and then use it for whatever task that might have become relevant after the stack moved.
I guess I could make it so that units aren't unselected when they use up their MP without it putting the stack to sleep and triggering an auto unit cycle like it used to do in vanilla.
Anyhow, the point is that we now have full capability to mod unit cycling and selection behavior, this was something C2C never really had before, before we basically just had two exe functions we could call without any inputs to influence what it does; I'm sorry that this expanded mod-ability I added caused some distress in its first implementation.
Dude, you're doing great anyways, lol.
I'm just annoyed by the fact that this new behavior causes the wrong units to leave the group and wander off on their own, defeating the very idea of grouping the units in the first place.
Maybe you could think of some form of different grouping styles in the first place: one for "walking alongside" and one for "combining into a combat group".
The former would split easily, since it's not intended to not-split either, thus it can leave parts behind and keep other parts walking.
The latter would NOT split on its own, UNLESS you manually split it via another button, thus never causing any units to wander off by accident.
That would be a rather useful way to ensure we can group units in a way that we can also predict their behavior, not something semi-random as it is now.
Non-priority, obviously, but would be simply NICE, ya know.
 
Attached User Settings.
 

Attachments

On latest SVN, strange graphical error.
Spoiler Strange Graphical Issue :
1660003094442.png
 
Python bug, upload save, usersettings, and tell how to reproduce it.
Trying to replicate it, I don't know how it happened. If I do, I will post the save file, user settings, and method.
 
Dude, you're doing great anyways, lol.
I'm just annoyed by the fact that this new behavior causes the wrong units to leave the group and wander off on their own, defeating the very idea of grouping the units in the first place.
Maybe you could think of some form of different grouping styles in the first place: one for "walking alongside" and one for "combining into a combat group".
The former would split easily, since it's not intended to not-split either, thus it can leave parts behind and keep other parts walking.
The latter would NOT split on its own, UNLESS you manually split it via another button, thus never causing any units to wander off by accident.
That would be a rather useful way to ensure we can group units in a way that we can also predict their behavior, not something semi-random as it is now.
Non-priority, obviously, but would be simply NICE, ya know.
I also reckon something like this would be a good idea, my two main use-cases for grouping are convenience when sending a big military-only stack to do something (so splitting doesn't really matter that much) and escorting a tribe/settler/etc (where splitting can undermine the whole purpose of the stack).

I've also noticed a possibly-related issue where if I have a group of ships* for the purpose of naval support of a ground invasion, using the bombard defences option with the group prevents me from then using the ranged attack to soften up the defenders on the same turn; I have to find and separate out the ships that used their attack on the bombard action so the rest can do their ranged attack (if I don't, then the ranged attack button is still there with the full stack selected, but the target-tile-overlay dealie is greyed out if I try to use it). I don't recall it working that way in previous versions (I'm still on 42.1.BETA.7097, but I didn't spot anything in the changelog that looks relevant), and it makes that type of attack more fiddly to execute for no obvious benefit.

* Presumably it could also happen with land siege units, but since those often arrive late to the battle and typically only have 1 movement until decently far into the game I tend to see it with ships
 
After planting Young Forest on tile with Tar Pit, the Tar Pit disappears both visually and in description of the tile. Nonetheless Tar Gatherer (in Piau city; there is also Henna on the same tile as Tar Pit) still functions.
The same save file as in https://forums.civfanatics.com/thre...lus-svn-after-april-2022.676574/post-16316858

v42.1.BETA.7121
Windows 7 x64
Tar pit is feature, same with young firest
So young forest shouldn't be buildable on tiles with features @Toffer90
 
Unsure if this is a bug:
In the newest build, new resources are popping up under cities and, when found through improvements, don't seem to correspond with their improvements. I've been seeing mines discovering dye and fig, and farms finding diamonds and amber.
 
Unsure if this is a bug:
In the newest build, new resources are popping up under cities and, when found through improvements, don't seem to correspond with their improvements. I've been seeing mines discovering dye and fig, and farms finding diamonds and amber.
Any worked tile can discover any resource.

Improvements have much higher chance to discover specific resources.
 
Worked tile?
So it is not profitable to build mine on hills without resource if the hills are outside city radius?
 
I'm having a CTD bug every time I pass to the next turn in my save, I looked the python error log and it seems to be related to the AI conquering a city somewhere and then an recursion excepton is throw.

Here is the original exception:
Code:
Original exception was:
Traceback (most recent call last):
  File "CvEventInterface", line 32, in onEvent
  File "BugEventManager", line 292, in handleEvent
  File "BugEventManager", line 297, in _dispatchEvent
  File "BugEventManager", line 305, in _handleDefaultEvent
  File "BugUtil", line 203, in trace
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 212, in print_exc
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 125, in print_exception
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 69, in print_tb
  File "e:/main/civilization4/warlords/assets/python/system\linecache.py", line 14, in getline
  File "e:/main/civilization4/warlords/assets/python/system\linecache.py", line 40, in getlines
RuntimeError
:
maximum recursion depth exceeded

Here is what the the traceback looks like:
Code:
Traceback (most recent call last):
  File "BugEventManager", line 303, in _handleDefaultEvent
  File "RevEvents", line 401, in onCityAcquired
  File "RevEvents", line 455, in checkRebelBonuses
RuntimeError: unidentifiable C++ exception
Traceback (most recent call last):
  File "BugEventManager", line 303, in _handleDefaultEvent
  File "MoreCiv4lerts", line 105, in OnCityRazed
  File "MoreCiv4lerts", line 67, in getCheckForDomVictory
  File "BugOptions", line 498, in get
  File "BugOptions", line 593, in getValue
  File "BugOptions", line 608, in getAndOptionValue
  File "BugOptions", line 599, in getValue
  File "BugOptions", line 1131, in getRealValue
  File "BugOptions", line 599, in getValue
  File "BugOptions", line 1060, in getRealValue
  File "BugOptions", line 230, in getBoolean
  File "BugOptions", line 212, in exists
  File "configobj", line 337, in __getitem__
KeyError: 'Civ4lerts'
 

Attachments

I'm having a CTD bug every time I pass to the next turn in my save, I looked the python error log and it seems to be related to the AI conquering a city somewhere and then an recursion excepton is throw.

Here is the original exception:
Code:
Original exception was:
Traceback (most recent call last):
  File "CvEventInterface", line 32, in onEvent
  File "BugEventManager", line 292, in handleEvent
  File "BugEventManager", line 297, in _dispatchEvent
  File "BugEventManager", line 305, in _handleDefaultEvent
  File "BugUtil", line 203, in trace
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 212, in print_exc
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 125, in print_exception
  File "e:/main/civilization4/warlords/assets/python/system\traceback.py", line 69, in print_tb
  File "e:/main/civilization4/warlords/assets/python/system\linecache.py", line 14, in getline
  File "e:/main/civilization4/warlords/assets/python/system\linecache.py", line 40, in getlines
RuntimeError
:
maximum recursion depth exceeded

Here is what the the traceback looks like:
Code:
Traceback (most recent call last):
  File "BugEventManager", line 303, in _handleDefaultEvent
  File "RevEvents", line 401, in onCityAcquired
  File "RevEvents", line 455, in checkRebelBonuses
RuntimeError: unidentifiable C++ exception
Traceback (most recent call last):
  File "BugEventManager", line 303, in _handleDefaultEvent
  File "MoreCiv4lerts", line 105, in OnCityRazed
  File "MoreCiv4lerts", line 67, in getCheckForDomVictory
  File "BugOptions", line 498, in get
  File "BugOptions", line 593, in getValue
  File "BugOptions", line 608, in getAndOptionValue
  File "BugOptions", line 599, in getValue
  File "BugOptions", line 1131, in getRealValue
  File "BugOptions", line 599, in getValue
  File "BugOptions", line 1060, in getRealValue
  File "BugOptions", line 230, in getBoolean
  File "BugOptions", line 212, in exists
  File "configobj", line 337, in __getitem__
KeyError: 'Civ4lerts'
Can't reproduce CTD.
The error is happening on an empty line (File "RevEvents", line 455, in checkRebelBonuses).
1660566976586.png

So... I guess you are playing an old version of C2C (where that line is not empty) and the issue has been fixed on SVN already.
 
Back
Top Bottom