God-Emperor
Deity
The problem with the PLE code that I thought I had fixed back in post 17 happened to me again. Evidently it can still try to show info for dead construction ships after they build a starbase when there is another unit on the same plot.
So another attempt at fixing...
On line 290 I added another check. Hopefully, this will catch everything so no more bad units will slip through.
I still can't be certain this fixes it. When is a unit not a valid unit anymore?
Hopefully the new .isNone() check will catch whatever slipped though without it, or at least some of it. On the other hand, it really should have failed the .isDead() check if it was None with the typical error that would look like "'NoneType' object has no attribute 'isDead'". Because of that, I suspect that this will not really fix it. I'm beginning to think that maybe there is some issue with the unit being half-dead, in effect: some of its data is gone (set to None or various C++ equivalents like setting pointers to NULL) but the unit is not yet marked as dead. It therefore passes the validation but doing a variety of things with it causes some to fail (the current crop of errors had it failing when calling .isSelected() and also when trying to get its button image via gc.getUnitInfo(pLoopUnit.getUnitType()).getButton(), which indicated that the unit info was None).
In essence, it seems to be acting like the function that kills the unit is clearing out its data before marking it as dead when what it should be doing is marking the unit dead as the very first thing, then begin the cleanup.
If anybody has any suggestions for more checks that can be done to validate the unit to avoid all these errors, I'd like to hear them.
I'm considering adding more validation (a check that matches the one above) near the beginning of the displayUnitPlotListObjects function, which is where it keeps failing in various ways. Perhaps this later validation would catch it. Unfortunately, it doesn't seem likely due to the lack of multithreading in Civ (if it is semi-dead before the function call, it should still be in the same state after the function call and therefore it should still not fail an identical set of validations since a single threaded application should not be able to do two things, run Python code and continue to modify the object in the DLL, at the same time). On the other hand, it does act like the object is slowly changing since the exact error changes. Initially it failed a few time on the .isSelected() call (11 times). It then switched to failing when trying to get the button (391 times), which happens earlier in the function. It's not clear what ended the mass of errors. It probably either ended because the DLL finished deleting the object, or finally marked it as being dead, or it may have stopped generating errors because I minimized the game (from full screen) and then brought it back, or from when I then clicked on another plot with units on it - it took quite a few clicks to get through the pile of error messages after that but it could have stopped generating more at either of those times.
I guess that's enough grumbling about this (for now).
So another attempt at fixing...
On line 290 I added another check. Hopefully, this will catch everything so no more bad units will slip through.
Code:
if (pLoopUnit and not pLoopUnit.isNone() and not pLoopUnit.isDead()): # G-E bugfix - don't show dead unitsI still can't be certain this fixes it. When is a unit not a valid unit anymore?
Hopefully the new .isNone() check will catch whatever slipped though without it, or at least some of it. On the other hand, it really should have failed the .isDead() check if it was None with the typical error that would look like "'NoneType' object has no attribute 'isDead'". Because of that, I suspect that this will not really fix it. I'm beginning to think that maybe there is some issue with the unit being half-dead, in effect: some of its data is gone (set to None or various C++ equivalents like setting pointers to NULL) but the unit is not yet marked as dead. It therefore passes the validation but doing a variety of things with it causes some to fail (the current crop of errors had it failing when calling .isSelected() and also when trying to get its button image via gc.getUnitInfo(pLoopUnit.getUnitType()).getButton(), which indicated that the unit info was None).
In essence, it seems to be acting like the function that kills the unit is clearing out its data before marking it as dead when what it should be doing is marking the unit dead as the very first thing, then begin the cleanup.
If anybody has any suggestions for more checks that can be done to validate the unit to avoid all these errors, I'd like to hear them.
I'm considering adding more validation (a check that matches the one above) near the beginning of the displayUnitPlotListObjects function, which is where it keeps failing in various ways. Perhaps this later validation would catch it. Unfortunately, it doesn't seem likely due to the lack of multithreading in Civ (if it is semi-dead before the function call, it should still be in the same state after the function call and therefore it should still not fail an identical set of validations since a single threaded application should not be able to do two things, run Python code and continue to modify the object in the DLL, at the same time). On the other hand, it does act like the object is slowly changing since the exact error changes. Initially it failed a few time on the .isSelected() call (11 times). It then switched to failing when trying to get the button (391 times), which happens earlier in the function. It's not clear what ended the mass of errors. It probably either ended because the DLL finished deleting the object, or finally marked it as being dead, or it may have stopped generating errors because I minimized the game (from full screen) and then brought it back, or from when I then clicked on another plot with units on it - it took quite a few clicks to get through the pile of error messages after that but it could have stopped generating more at either of those times.
I guess that's enough grumbling about this (for now).
