Dude, you're doing great anyways, lol.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.
Upload your user settings - zip that folder, its in Caveman2CosmosRandom CTDs, on latest SVN. Save attached.
Python bug, upload save, usersettings, and tell how to reproduce it.On latest SVN, strange graphical error.Spoiler Strange Graphical Issue :
Trying to replicate it, I don't know how it happened. If I do, I will post the save file, user settings, and method.Python bug, upload save, usersettings, and tell how to reproduce it.
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).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.
Tar pit is feature, same with young firestAfter 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
Upload save to mediafire or something and paste link herethe save files are 40mb now ? game crashing exit to desktop without error
thankssomethin
Nah. This is what happens when you let the pesky dumb AI flood the memory with 100500 dogs and 1234567890 thugs, lol.This is what happens if you play on Pit's map.
Any worked tile can discover any resource.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.
Improvements can discover resources outside any city radiuses as well, as long as the improvement is not in neutral land.Worked tile?
So it is not profitable to build mine on hills without resource if the hills are outside city radius?
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
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.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'