Bug Reporting

[EmperorFool]

It makes sense there I think; that's why I put those other experience/level functions there. I'll take a look at this on the weekend. Oh, and I committed the long-term fix for the BULL options issue. It required code in both BUG and BULL but is pretty minor. Please let me know if this fixes the problem on your end.

 

[phungus420]

Thanks EF, Those fixes work, BULL options are now responding

@Ruff hi, PLE options are still unresponsive though. You must exit the game, and restart and reload before PLE option changes take effect, and some options (such as draw method) don't seem to do anything, though it's difficult to tell for sure, since I have to restart the game every time I want to check something.

 

[Fimbulvetr]

I only tested draw method because that's the only option where I know what it does: setting "Vanilla" makes the filter buttons disappear. It's still working for me.

 

[phungus420]

I must quit and restart to get any PLE options to take effect, even simple things like changing the movement/health bar color on units.

@BUG team:
Any idea of where I could look to see what's going wrong here?

 

[ruff_hi]

@BUG team:
Any idea of where I could look to see what's going wrong here?

I could have the dirty flag wrong.

 

[phungus420]

OK, since Fuyu said that it worked for him, I rechecked things; apon re testing I can now get simple things, like the movement bar and such to respond. However big item changes, such as changing the draw method, and the lines displayed (single or multiple lines) requires a complete reloading of the game. If you start the game with multiple lines, or a PLE draw method, you must reload to change these things. Now in my mind such interface changes requireing a restart are sometimes unavoidable, as the changes requires a reinitialization to take a effect. However when this happens the User should be prompted and told something like "You have made changes to the interface which requires the game be restarted to take effect". Please either add a pop up dialogue box to prompt the user, and let them know what's up, or fix it so that these options are responsive when selected, like all other BUG options.

I also did a full look at the diffs between RevDCM's and BUG's code. I found a couple of lines in CvMainInterface that jdog added that was in some plot list code, I removed them, tested, and put the code back in, no change. All other code differences pertains only to the scoreboard and button positions, or revolutions themselves, and is needed for RevDCM, also I can't see how the code could effect the PLE at all. Just to completely ensure there wasn't an issue with code differences between RevDCM and bug, and also due to Fuyu's report, I rechecked thing using Better BUG AI (it uses the latest BUG SVN). I get the exact same behavior from Better BUG AI, so I am sure this issue is in default BUG code.

 

[ruff_hi]

Hmm - I changed the draw method option while I was coding and checking the BUG version. Initially, I was seeing 2 or 3 unit plot graphics for the same plot (the BUG version wouldn't clear). However, I did get it to the stage where the screen would auto-update correctly (based on the selected draw method) in the background while I had the option screen up. I'll have another look to see that I can still do that.

That said, some of those PLE options don't apply if you use the Vanilla or BUG draw methods. We probably should update that so that they get greyed out or have that info in the hover.

 

[phungus420]

I'm not sure exactly what "draw method" does, but having it's selection grey out items that cannot be altered makes alot of sense. Please check the multiple lines display, as this is the most obvious thing to mess with and see it's effect, and it's what I've been testing, and I'm absolutely positive this is unresponsive (however, like I say you can restart the game, and your changes take effect).

 

[_alphaBeta_]

Hmm - I changed the draw method option while I was coding and checking the BUG version. Initially, I was seeing 2 or 3 unit plot graphics for the same plot (the BUG version wouldn't clear). However, I did get it to the stage where the screen would auto-update correctly (based on the selected draw method) in the background while I had the option screen up. I'll have another look to see that I can still do that.

Haven't checked the last couple revisions, but I also remember this working shortly after you fixed it. Hopefully it wasn't broken by a subsequent change. I'll have to wait a day before I can confirm myself.

That said, some of those PLE options don't apply if you use the Vanilla or BUG draw methods. We probably should update that so that they get greyed out or have that info in the hover.

This would be very helpful. The plot list options screen could use an update to avoid the confusion.

I'm not sure exactly what "draw method" does, but having it's selection grey out items that cannot be altered makes alot of sense. Please check the multiple lines display, as this is the most obvious thing to mess with and see it's effect, and it's what I've been testing, and I'm absolutely positive this is unresponsive (however, like I say you can restart the game, and your changes take effect).

To save yourself some time in the meantime, you could try ALT+TAB out of the game and then back in. Before ruff_hi fixed the draw method refresh, this was a quicker way to make changes.

 

[ruff_hi]

request for revised Unit Plot option tab noted in the PLE thread.

 

[EmperorFool]

I put canAcquireExperience in CvUnitInfo. I was thinking of the other two functions that require a PlayerTypes when I said it didn't belong there. This one clearly does. I expose the two level/experience functions to Python as well plus this one.

 

[EmperorFool]

@phungus420 - I don't know why only the Additional Defense would be giving you asserts but not the other hovers, but I'm fixing them all to do the same building class loop just the same.

 

[phungus420]

Makes sense. Probably in general it's just not a good idea to loop over Units or Buildings, and instead loop over the classes and get the type for each civilization; unless the function specifically needs to look at the building and unit types and shouldn't be grabbing them from the civilization units call for some reason. At least it seems this way.

Edit:
Another thing I did was change the canTrain, canConstruct, and canCreate calls in CvPlayer, CvPlot, and CvCity to start by calling kUnit by reference, and used kUnit.getWhatever instead of forcing the engine to constantly look up the unitInfo by unit type for everything. There are a few loops in the these functions, and it just seemed whoafully inefficient to keep looking up the same informaiton, and kUnit could just be passed by reference at the beginning of the functions by having CvUnitInfo& kUnit = GC.getUnitInfo(eUnit). At least when I was degugging I kept had to keep looping throgh CvGlobals and all that jazz as the engine get the unit info, when defining kUnit at the beginning of the function seemed to solve this.

I'm no coder though, so maybe I'm wrong and this is actually less efficient?

 

[EmperorFool]

It's possible that the compiler could optimize those duplicated calls, but I'm not sure. It's definitely easier to read using kUnit.

 

[OrionVeteran]

We found a possible bug with BUG. EF, can you check out this thread?

http://forums.civfanatics.com/showthread.php?t=361908

 

[OrionVeteran]

I have BUG 4.3 merged together with my new modular Inquisitions and Limited Religions. During Testing:

After about 80+ turns into the game, I get this error when a unit gets the focus in a city: Worker or Warrior -- doesn't matter which.

Python Exception

Can't find type enum for type tag None

The error message doesn't specify which file or function where the problem occured. I've gone through my functions to look at everything that has the word "None" and I can't find the source of the problem. The Python error log seems to be no help. The logs are attached.

Could this be a BUG 4.3 error?

Orion Veteran

 

[EmperorFool]

I've never seen this error, so I doubt it's caused specifically by BUG. Perhaps something in your mod is causing BUG to do something it doesn't do normally. I'll take a look at the logs later and see if there's anything in there I can use.

 

[EmperorFool]

That error message comes from CvUtil.findInfoTypeNum() which BUG only uses in two places (now fixed), neither of them related to this (BUFFY random event fixes and EventSigns), nor should your code. Replace all usages of it with gc.getInfoTypeForString() for faster code.

That being said, the error indicates that you are passing in the special Python value None for the third (string) parameter. This is probably an uninitialized variable that you set based on some if logic and missed one case where it can remain unset.

 

[OrionVeteran]

That error message comes from CvUtil.findInfoTypeNum() which BUG only uses in two places (now fixed), neither of them related to this (BUFFY random event fixes and EventSigns), nor should your code. Replace all usages of it with gc.getInfoTypeForString() for faster code.

That being said, the error indicates that you are passing in the special Python value None for the third (string) parameter. This is probably an uninitialized variable that you set based on some if logic and missed one case where it can remain unset.

Yup! As usual, it was a bonehead mistake that created a difficult error. I had a function that called another function, which called a third function. I tracked it down and fixed it. This was not a BUG issue.




Orion Veteran

 

[hell_hound]

Sorry for not looking through 120 pages for the bug fix or if this is in the wrong place but whenever I download and try to run installation of the BUFFY mod it just says 'The setup files are corrupted. Please obtain a new copy of the programme'
Thanks

Edit-Tried a download from a different link and it worked this time reckon the link might be broken...