You're bang-on EF, but how the heck did you figure that out?
The key is to start at the bottom of the stack trace. I didn't explain it as I was heading off to bed, but the way a stack trace works is that it shows you the call chain of where the program (Python) was when it encountered the error.
Here's a real world example. "When I went to the supermarket, I broke my leg. I went to the supermarket, but they didn't have any beer. So I went to a liquor store, but they didn't have any good wine. So finally I went to a winery, and while taking their tour I fell down the stairs and broke my leg."
That would be shown by Civ4 like this:
Code:
Traceback (most recent call last):
File "Supermarket", line x, in buyGroceries
File "LiquorStore", line x, in buyBeer
File "Winery", line x, in buyWine
File "Winery", line x, in takeTour
RuntimeError: broke leg
ERR: Python function buyGroceries failed, module Supermarket
Okay, that was a little contrived, but hopefully it helps while reading the following.
ERR: Python function forceScreenRedraw failed, module CvScreensInterface
This is Civ4's generic indicator that it caught an error that was not handled by the Python code. It tells you the module and function that it called initially, but that's not where the error actually happened. Above, I didn't break my leg at the Supermarket, but I broke it sometime during my trip to the Supermarket
RuntimeError: unidentifiable C++ exception
This is the error it encountered. "unidentifiable C++ exception" means that Python made a call to the DLL or EXE (both C++ code) that failed an assertion. An assertion (or assert statement) is code that enforces a logical constraint, e.g. x is non-negative, by "dying" if the constraint is violated.
File "CvMainInterface", line 3386, in updatePlotListButtons
This is where you should start your investigation. This line must have called a C++ function in the DLL or EXE that failed. Looking in your file we see
Code:
[B]screen.addBuildingGraphicGFC[/B]( "InterfaceUnitModel",
[B]CyInterface().getOrderNodeData1[/B](i),
175, yResolution - 138, 123, 132,
WidgetTypes.WIDGET_HELP_SELECTED, 0, -1,
-20, 30, 0.8, False )
The two bold parts are C++ calls. The second one is asking the interface for the
ith item in the build queue. This could fail (I'm guessing) if there isn't a city currently selected, but you can see a few lines above that this was checked already, so it's probably safe.
The only other culprit is addBuildingGraphicGFC(). What other information do I have? You've added a new wonder, and only the city that is building that wonder is getting this problem. It may not be a smoking gun, but I'd say there's GSR on your hands.
File "CvScreensInterface", line 947, in forceScreenRedraw
File "CvMainInterface", line 2993, in redraw
These are breadcrumbs along the way to the error. You use the lines above the line where the error occurred to walk back through the Python code that got you to the error. You can use them to find more context or evidence to determine the actual problem.
They are helpful because you can call any function from any other place in Python, so these lines show you the trail that lead you to failure.
And now that I know the NIF is garbage, I guess I can't avoid NifSkope anymore, huh?
Can't help ya there, but it sounds like you know where to start.
), as they seem to be referencing parts I haven't made changes to...
from NifSkope, any suggestions?
-sigh-...
