Thunderbrd's pre-v37 debug checklist

[Thunderbrd]

BugList

• Setup some early Human barbarian spawns and additional neanderthal unit spawns to create some diversity out there in wilderness hominid encounters.
  -A little involved...
  
  
• Start threads with polls on each option in the Tips and Tricks section, with a central thread to be stickied.
  
  
• Write out a guide for v37 players. Stuff for the pedia, Tips and Tricks section, and some training videos to go with it all.
  -LAST task
  
  
• Crash - actually a freeze - when player is defeated.
  -I'm currently admitting some defeat in my first attempts to solve this. I've learned a lot about the problem, it's simply a matter of the interface freezing. The game continues in the background, fully understanding that the game is over for the human player. But because the end sequence popups that have failed due to a frozen interface, the player never confirms to stop the game processing in the background. This is how you can wait and save after a long time and see turns having been recorded for the playback long after things ended for you. I can't seem to isolate where or how the interface is freezing up but it's happening before the unit is even shown to capture the city, out in the who knows ocean of the code. Since the code continues unhindered and doesn't give any warnings to suggest where its taking place, (perhaps python errors might be logged?) I have no hints as to where or even why it's happening. You'd THINK that if the freezing up was due to the player losing the game then it would happen AFTER the city is shown to be captured, right? *sigh* Far too complicated for such a minor bug! I've asked for help from 45* as was suggested earlier. Shelved for now.

Still on track for our release date! Woohoo!

 

[Noriad2]

I'm a few SVN versions behind but last time I played there was an abundance of cultures, to the point that you could get an abundance of leaders. If you settle those in your military city, you can get an excessive amount of +xp. Nothing wrong with more cultures, it enriches the game, but it needs more balance.

My personal preferred solution would be to add more regions (split North American culture into North American and Central American, European into North Western European (Germanic), Eastern European (Slavic) and Southern European (Greek/Latin), Africa into Sub-Saharan and Northern African etc etc.) for more diverse games. But however it would be solved, this solution or any other solution would likely break a save game or at least mess things up considerably if you update SVN mid-game.

 

[Thunderbrd]

I'm a few SVN versions behind but last time I played there was an abundance of cultures, to the point that you could get an abundance of leaders. If you settle those in your military city, you can get an excessive amount of +xp. Nothing wrong with more cultures, it enriches the game, but it needs more balance.

My personal preferred solution would be to add more regions (split North American culture into North American and Central American, European into North Western European (Germanic), Eastern European (Slavic) and Southern European (Greek/Latin), Africa into Sub-Saharan and Northern African etc etc.) for more diverse games. But however it would be solved, this solution or any other solution would likely break a save game or at least mess things up considerably if you update SVN mid-game.

I agree with the issue and don't balk at the solution given but the solution I will implement through the Ideas project will be too large to implement within the span of what time we have remaining for v37 release, or any time soon really. If someone else wants to take this up as a personal project and can get it done within a month's time, cool.

 

[Thunderbrd]

Completed

• Issue with mapscripts and scenarios not loading, even if saved on current assets.
  
  
• Multiple issues with animal spawns. Review the mechanism and determine improved practices and then review the spawns themselves to implement.Looks like this is dialed in nicely now.
  
  
• Cargo Errors on SM - as reported: It happens when a unit attacks another land unit from a ship and prisoner of war is created on that ship. Consumed passenger space that this prisoner occupies never gets removed even when the prisoner is long gone from the ship. In time, when this repeats or when ship is upgraded to something with less cargo space, the result is ctd.
  -Should be resolved. Patched some gaps in logic, restructured auto-repair when a problem is found when validating, and added tracking notifications when running debugger to indicate when a problem still exists (even if it's getting fixed on validation.)
  
  
• What happened with "Routes_Upgrade" option in A_New_Dawn_GlobalDefines.xml?
  It's no longer working for me despite setting it to "1" in both My_Modules and Assets/XML.
  Is it being overwritten elsewhere, or has it been broken? (Evaluate and fix though I'm not sure what it's supposed to do.) Apparently: It used to be, and working perfectly, that to upgrade a route when the option was on, i.e set to 1, meant you only needed to put in the money and time MORE than the route already in place cost.
  So the already built route counted towards upgrading to the new route.
  Which no longer works. I'm pretty sure I found the underlying logic flaw that was causing this to be bugged - a couple of them. Next update should repair this function and set it to be the default.
  
  
• Look at Jaguars, bears, cheetahs, tigers. Mostly jaguars... might be a touch too tough.Spot reviewed and adjusted a few strengths there.
  
  
• review isQualifiedPromotionType(int i) - it's not coming up with a correct list.
  In game it says that outrigger units can get the extra movement movement in hills and forest promotions - so no it is not working in game. They can also get the move into mountains promotion and all the woodsman and equivalent promotions according to the pedia page.
  Apparently this is, at the least, a lack of domain access factors being taken into account.
• Tales and animals still able to reveal goody huts for the player. ugh. -Diagnosis: Use the tag for cannot explore.Should be good to go on the next DLL compile.
  
  
• Upon succeeding in a defensive withdraw, the unit loses any movement it may have left.This was a problem for simultaneous turns play where a unit would be frozen by forced movement then unable to react. Resolved in the coding by adding a bFree variable to the CvUnit::move function, setting it to false as a default and setting it to true in cases of forced defensive withdrawal. Next Commit will include the fix.
  
  
• Problem with the display of same tile visibility on final unit help hover
  -Should be resolved
  
  
• Animals still count towards upkeep.
  -Should be resolved (bug in the iCostModifierChange tag on UnitCombats and evaluation revealed a larger bug in that unitcombats were not being outprocessed on dying units. This was the cause of other accounting bugs taking place as well.)
  
  
• Always hostile needs to be on the Hidden nationality promotions that rams get. I don't think there's a tag for that so it should just be a part of the HN effect from promotions naturally IMO.
  -Resolved
  
  
• Check out the coding on deriving final anarchy rounds. Min 1 if base is 1 or higher needs to be enforced unless there is possibly a bigger problem yet.
• TXT_KEY issue on Insectoid player
  -Resolved
  
  
• From DH: As I said I have seen no effect at all from GAs. The research time does not go down, the time to build buildings/units does not change, the time to grow does not change.
  The only reason I go for them is the removal of anarchy.
  Note: I've confirmed that golden ages do increase the values of plots being worked. I would like to look at the rest of the coding influencing yields on golden ages - the tag that plays into that on traits will be using it and I want to be sure how it works.
  -Complete: He was correct that there is no base commerce or yield bonus under a golden age. Plots do improve during GAs and that's currently it. The next trait set will add some but we may benefit from a base +10% or +20% yields and commerces during a GA (probably best 10% to each) as a general rule. Therefore, this should perhaps be put up for discussion.
  
  
• Test out giving criminals the benefit of wild animals never seeing them by removing the massive bonus given to wild animals to see through disguise. Add a point of disguise visibility for all Humans and Neanderthals. This will make all humans and neanderthals capable of seeing Exile units one space away if they can also see through any camo. If the Exile takes even one promotion for disguise, only LE units will be able to see them and that will start to depend on how well promoted those LE units are at seeing through disguise. This will help criminals get through the wild, unimpeded, thus they should also get a -50% combat modifer against animals so they don't compete with the role of the hunters. But disguise is then easily beat by a LE unit with promos/buildups to see through disguise, which will then be necessary to overcome with camo, which until dogs, only hunters and scouts are good at and those tend to want to go out into the wild, where they will not see criminals due to the disguise invisibility. Might make things a bit more fun for those who are currently frustrated by the existing setup.*
  -Resolved except that I only gave humans and neanders 1 pt of SAME tile visibility on disguise.
  
  
• unshuffle status promos At some point it would be good to figure out how to split into a z-priority module for status promos - promotions in modules are still coming up after them despite the effort to put them all at the end of the core promo file. It's improved enough for now imo.
  
  
• complaints that the player (national) gold tallies aren't showing how we get to final totals.
  -Some extensive additional programming needed
  
  
• Animal units - review the aggression levels. We need to get some of them a little more willing to attack in many cases. Letting Toffer adjust as he sees fit here.Seems about right lately. Some perfecting is possible as we go from here but for now it's good I think.
  
  
• When you ambush defensively, there's really nothing to say that's what's happening. No alerts to say you got stealth factors in a combat. Nothing in the combat display helps to let you know either. Even as the designer I wonder if I'm getting stealth bonuses or not and that cannot be good for folks trying to understand what stealth combat modifiers and stealth strikes are and if they are being factored into the combat properly. The first strikes the combat help hover shows makes me think it may not be tallying correctly for the display.
  -Some extensive programming needed
• A group moves to a plot where there is a unit hidden with stealth defense on. The first unit in the group fails to move, and loses all movement points. The second then moves in and attacks and the rest of the group moves in.
  -Need to setup a case study
  Some further playtest will show if the situation is resolved in full but early and possibly partial diagnosis reveals that it had to do with units that had already attacked and could not attack again that round. Since ambush is only defense by proxy and for the sake of combat modifier bonuses but is kinda an attack as well, I changed things to allow units that were able to move but had fulfilled their attack(s) for the round to be able to 'attack' in this case.
  
  
• TXT_KEY issue with the Neanderthal Brute
• Criminal spy commands aren't working - figure out why and how to fix
  -Study the spy command programming. I suspect it will quickly become obvious.
  They are working... just a few reasons I didn't think they were. Have made some improvements to coding for criminals using these missions.
  
  
• This is odd, I started a new game and saw on turn 0 that there was a stack belonging to the beast NPC team standing close to my own starting units, this stack consisted of 8 stone throwers, 2 wanderers and 2 gatherer.
  When checking the world builder I found that predators, barbarians, neanderthals and creatures also had a stack like this, though neanderthals had the homo neanderthalensis unit instead of stone throwers. THis is the same that normal (non-NPC) AI get at start except they get two bands of homo sapiens as well. Inhibited these spawns for NPCs at the beginning of the game.
  
  
• Chance of battlefield promotions are opposite to what they should be, on attack at least.
  -Need to setup a case studyThe math checks out as spot on under close evaluation. I must have just had a few unlikely successes in a row that made me think something was off. But it's adding up exactly as intended now.
  
  
• The tag for group naming on spawns works but it becomes the only portion of the name tag when some text calls are made.
  -Reviewed but I can't see what needs to be adjusted here or why it doesn't work properly. Needs more study.Corrected. Now all that needs to happen is the hundred or so hours of work to update all animal unit definitions. I figure I'll gradually chip away at them from here.
  
  
• revolutions is bugged all buildings that increase/decrease revolt risk that should only affect the city there in affect all cities
  -Tag research and repair required. I've seen the problem in the code before. With some focus, I should now have the skill level to address this properly. If it's going to take some help from py guys I can at least identify where. The problem was that iRevIdxLocal and iRevIdxNational were not being employed. It was all going through iRevolutionIndexModifier which was just plugging into iRevIdxLocal in the code while giving an indication in the hover information that this applied to all cities, but it only applies to just the city that has the building. I have discontinued all usage of iRevolutionIndexModifier and changed it to iRevIdxLocal (that's what it's been counted as in code all this time anyhow) and corrected the message display. From here, if we wish to make the tag use national, use iRevIdxNational instead.
  
  
• Sometimes it takes forever to reassign specialists, it can take more than 10 seconds to reassign every single specialist, and since reassigning specialists and workers is most often a two step process that doubles the pain. Usually it is very slow in the beginning of a session, then anywhere between 15-minutes to several hours later it suddenly lightens up and the lag is gone. But some sessions the lag never goes away and very rarely it also happens that the lag isn't there in the beginning of a session and it can also return and disappear later seemingly without rhyme or reason.
  Also: review the AI regarding XP and unhappy/unhealth.*Didn't find any ways to speed this up but did find ways to improve evaluations of slaves vs other options.
  
  
• Turn back on Air unit combat animations. I think there will still be an issue with the ornithopter but that should be all that's left, if that even. We should be on the lookout for air unit missions causing crashes.
  
  
• Option out Ambush and Assassination and Stealth Strikes & Stealth Combat Modifiers. Arrest will need to remain core.
  -Extensive programming requiredDone. Option is called Without Warning.
  
  
• Great Doctors are travelling with hunting parties.
  
  
• Resolved Anarchy coding as desired but I'd like to now identify which civics should not have any anarchy. All have some the way it's currently setup and some categories don't seem right to have any anarchy still as well as some early types perhaps shouldn't.Joseph's on top of this task.
  
  
• Check out the scaling coding that's making the cave paintings cause the animal sacrifices to culture/research go OP. Determine how it can be made a bit softer or controlled by XML on a case by case basis somehow.* Well... I reviewed it. The modifiers are for gamespeed and map size but these are so... generic and apply to everything based on pure ratio values that makes me very reluctant to think it should be at all adjusted. Additionally, the generic programming this is wrapped up in is a maze of vague connectivities to the extent that I cannot be 100% sure that I'm working directly on the matter or influencing something else. AIAndy knows the mysteries of his own style of generic programming and while I can follow it, I'm never too confident in my tracking through the wilds of his design. Thus I'm feeling like I probably shouldn't risk any adjustments there as it could impact a number of things I don't expect it to. Were he here we could probably ask him to give us a simple conditional control dial.
  
  
• The tooltip for the Gaeroas - Briton Unique Unit - says it starts with Goad I, II and III but doesn't have those on building one. Not sure why. According to 'Pedia, Goad is available to Hunters, Canine, and Combatants, and the Gaeroas are Throwing Combatants. Actually, it occurs to me I've never seen Goad available for purchase for any unit, even though Goad I is available from Language tech. Possible that Goad isn't coming up as valid for some reason. I'm going to address this in the bugs and crashes thread because it was fairly recently posted there.
  
  
• Keep some features on the city plot until certain pop levels are reached or forever, depending on the feature. Caves, for example, would never disappear and could remain interesting for a lot to come down the line as well as bonuses for planting the city directly on caves potentially. Tag on Features: iPopDestroys (-1 is never, any other amount is the population of the city - 0 or 1 is immediately going to destroy the feature. Default 0.) done.
  
  
• Tech Quotes for the techs I've added.
  -Must find the time to do this!done.
  
  
• Review the math as its calculating regarding reduced unit upkeep from unitcombats. Possible bug as there's some funny behavior there. Some improvements could still be usefull in the future to limit a unit to only being able to reduce as much as its own cost. For now, the cost modifiers have been adjusted to try to avoid this taking place. Good enough for the time being.
  
  
• More Neanderthal units. They are showing to work. Maybe give the base Neanderthal unit a tech prereq that makes it necessary for Neanderthals to develop a little before they get a weapon-wielding version with that much strength. Initial set should be complete.
  
  
• Finish the animal group names for spawns. Done
  
  
• Reduce the overall spawn rate by about 10% and the naval spawn rate by another 10%. Done.

 

[Toffer90]

When the AI get healers, entertainers or lawmen from goody huts they just fortify them in the wild forever, never to move them again perhaps unless they get their culture to the tile the unit stands on

 

[Thunderbrd]

When the AI get healers, entertainers or lawmen from goody huts they just fortify them in the wild forever, never to move them again perhaps unless they get their culture to the tile the unit stands on

Eww... I wish that were an easy one. These 'simple' issues can so easily take up a huge amount of processing time. I'll take a look time permitting.

 

[Thunderbrd]

revolutions is bugged all buildings that increase/decrease revolt risk that should only affect the city there in affect all cities
-Tag research and repair required. I've seen the problem in the code before. With some focus, I should now have the skill level to address this properly. If it's going to take some help from py guys I can at least identify where. The problem was that iRevIdxLocal and iRevIdxNational were not being employed. It was all going through iRevolutionIndexModifier which was just plugging into iRevIdxLocal in the code while giving an indication in the hover information that this applied to all cities, but it only applies to just the city that has the building. I have discontinued all usage of iRevolutionIndexModifier and changed it to iRevIdxLocal (that's what it's been counted as in code all this time anyhow) and corrected the message display. From here, if we wish to make the tag use national, use iRevIdxNational instead.

This note is an important one to highlight for the team. Anyone working with buildings and Rev at any time should be aware of this. We should all look for rev tag usage that perhaps was better as a national modification than a local one as well so they can be converted when found.

 

[JosEPh_II]

you're just too dad gummed organized!

JosEPh

 

[Thunderbrd]

you're just too dad gummed organized!

JosEPh

It has helped me to get so much more done than I would have otherwise. It's motivating to have a list to check off!

 

[Thunderbrd]

Update/Request for assistance:

Regarding:
Crash - actually a freeze - when player is defeated.

-I'm currently admitting some defeat in my first attempts to solve this. I've learned a lot about the problem, it's simply a matter of the interface freezing. The game continues in the background, fully understanding that the game is over for the human player. But because the end sequence popups that have failed due to a frozen interface, the player never confirms to stop the game processing in the background. This is how you can wait and save after a long time and see turns having been recorded for the playback long after things ended for you. I can't seem to isolate where or how the interface is freezing up but it's happening before the unit is even shown to capture the city, out in the who knows ocean of the code. Since the code continues unhindered and doesn't give any warnings to suggest where its taking place, (perhaps python errors might be logged?) I have no hints as to where or even why it's happening. You'd THINK that if the freezing up was due to the player losing the game then it would happen AFTER the city is shown to be captured, right? *sigh* Far too complicated for such a minor bug! I've asked for help from 45* as was suggested earlier.

 

[Taxman66]

Have you thought of hust cicumventing the bug? You state that multiple turns are running in the background after player is defeated, right? At the end of each turn should be a victory check. Simply add another check for player defeat (or player has 0 cities?) and call the defeat routine. if that doesnt work the error must be in the defeat routine itself.

 

[Dancing Hoskuld]

Have you thought of hust cicumventing the bug? You state that multiple turns are running in the background after player is defeated, right? At the end of each turn should be a victory check. Simply add another check for player defeat (or player has 0 cities?) and call the defeat routine. if that doesnt work the error must be in the defeat routine itself.

The check is currently for zero cities and no unit capable of building a city. Something that would need to change if we are going to get Nomadic Start.

 

[Thunderbrd]

Have you thought of hust cicumventing the bug? You state that multiple turns are running in the background after player is defeated, right? At the end of each turn should be a victory check. Simply add another check for player defeat (or player has 0 cities?) and call the defeat routine. if that doesnt work the error must be in the defeat routine itself.

The end of game check already exists and its working. The end of game routine is running. In the code at least. Why the game continues to play on is because you have the option to allow it to do so and a popup gives you that choice in the end of game routine. The problem is that all of those end of game routine popups aren't being delivered to the player's user interface despite being properly called by the code. Therefore, this is not a problem in the code but rather a problem in the user interface that has become frozen at some point. Since the code continues unerrored and unabated, I can only assume this is happening in the exe or in python. It's out of my realm.

This is such a trivial problem for such a complex one. If you save the game and reload it after the UI has otherwise crashed (which it does allow you to do) you will get the end of game sequence firing properly as soon as the game is loaded.

The check is currently for zero cities and no unit capable of building a city. Something that would need to change if we are going to get Nomadic Start.

I've seen the line in the code that needs adjusting. The definition of a unit capable of building a city needs to be extended to the nomadic units when they are developed, even if they cannot immediately found a city. Won't be too difficult.

 

[Dancing Hoskuld]

I've seen the line in the code that needs adjusting. The definition of a unit capable of building a city needs to be extended to the nomadic units when they are developed, even if they cannot immediately found a city. Won't be too difficult.

It would be nice if it could be externalised to XML in some way just in case we end up with multiple types of cities and camps.

 

[Thunderbrd]

It would be nice if it could be externalised to XML in some way just in case we end up with multiple types of cities and camps.

I planned to provide units with a tag that would indicate that. That's all we should really need right?

 

[Thunderbrd]

When the AI get healers, entertainers or lawmen from goody huts they just fortify them in the wild forever, never to move them again perhaps unless they get their culture to the tile the unit stands on

I just looked into this. And I cannot see the problem. I'll have to see a case in a game to resolve this I think. It's possible that I already addressed it - I haven't seen the problem recently anyhow. I remember it being an issue...

In the code, it appears addressed so if that's not working it's a bigger issue in other areas in the code. Or I'm just stuck inside the thinking box and need to SEE it process through to see where a fracture in logic is occuring.

 

[Toffer90]

I just looked into this. And I cannot see the problem. I'll have to see a case in a game to resolve this I think. It's possible that I already addressed it - I haven't seen the problem recently anyhow. I remember it being an issue...

In the code, it appears addressed so if that's not working it's a bigger issue in other areas in the code. Or I'm just stuck inside the thinking box and need to SEE it process through to see where a fracture in logic is occuring.

Ok. will be on the lookout for a save example.

 

[Thunderbrd]

@Toffer90 &/Or DH:
Can one of you look into what's gone wrong with this mapscript? This is really not my realm:

• Remove or repair PerfectWorld mapscript
  -Maybe. DH warns there would be an issue to remove it. Repairing it is not in my skillset currently so would be more than I think I should commit to pre-release. Perhaps just ask the team to address this.

 

[Toffer90]

I have only an impression of PerfectWorld 2 and a lot of experience with PerfectMongoose, tried generating some PW1 maps once upon a time and quickly decided that PW2 & PM were better, later I decided to stick with PM.

Regarding repair or remove:
What are the pros and cons in PerfectWorld 1 VS PerfectWorld 2?

 

[Toffer90]

This is what happens on turn 0 when generating map with PW1

• Crash - actually a freeze - when player is defeated.
  -I'm currently admitting some defeat in my first attempts to solve this. I've learned a lot about the problem, it's simply a matter of the interface freezing. The game continues in the background, fully understanding that the game is over for the human player. But because the end sequence popups that have failed due to a frozen interface, the player never confirms to stop the game processing in the background. This is how you can wait and save after a long time and see turns having been recorded for the playback long after things ended for you. I can't seem to isolate where or how the interface is freezing up but it's happening before the unit is even shown to capture the city, out in the who knows ocean of the code. Since the code continues unhindered and doesn't give any warnings to suggest where its taking place, (perhaps python errors might be logged?) I have no hints as to where or even why it's happening. You'd THINK that if the freezing up was due to the player losing the game then it would happen AFTER the city is shown to be captured, right? *sigh* Far too complicated for such a minor bug! I've asked for help from 45* as was suggested earlier. Shelved for now.

Spoiler PyDbg.log :

PY:Player 0's alive status set to: 0
Rev - Israeli Empire are dead, 0 cities lost, 0 founded a city

PY:Player 1's alive status set to: 0
Rev - Roman Empire are dead, 0 cities lost, 0 founded a city

PY:Player 2's alive status set to: 0
Rev - Viking Empire are dead, 0 cities lost, 0 founded a city

PY:Player 4's alive status set to: 0
Rev - English Empire are dead, 0 cities lost, 0 founded a city

I'll have to analyze the starting plot finder routine to figure out what's wrong.