1. We have added a Gift Upgrades feature that allows you to gift an account upgrade to another member, just in time for the holiday season. You can see the gift option when going to the Account Upgrades screen, or on any user profile screen.
    Dismiss Notice

Trouble merging kmod and super forts

Discussion in 'Civ4 - SDK/Python' started by Lib.Spi't, Feb 23, 2013.

  1. Lib.Spi't

    Lib.Spi't Overlord of the Wasteland

    Joined:
    Feb 12, 2009
    Messages:
    3,690
    Location:
    UK
    here is the code, i moved the i value as you said

    Spoiler :
    Code:
    //if (bDoImprove)
    						if (bDoImprove && eBestTempBuild == NO_BUILD) // K-Mod
    						{
    							int iBestTempBuildValue = MAX_INT; // K-Mod
    							for (int iJ = 0; iJ < GC.getNumBuildInfos(); iJ++)
    							{
    								BuildTypes eBuild = ((BuildTypes)iJ);
    
    								//if (GC.getBuildInfo(eBuild).getImprovement() != NO_IMPROVEMENT)
    								{
    									//if (GC.getImprovementInfo((ImprovementTypes) GC.getBuildInfo(eBuild).getImprovement()).isImprovementBonusTrade(eNonObsoleteBonus) || (!pLoopPlot->isCityRadius() && GC.getImprovementInfo((ImprovementTypes) GC.getBuildInfo(eBuild).getImprovement()).isActsAsCity()))
    									if (kOwner.doesImprovementConnectBonus((ImprovementTypes)GC.getBuildInfo(eBuild).getImprovement(), eNonObsoleteBonus)) // K-Mod
    									{
    										if (canBuild(pLoopPlot, eBuild))
    										{
    											if ((pLoopPlot->getFeatureType() == NO_FEATURE) || !GC.getBuildInfo(eBuild).isFeatureRemove(pLoopPlot->getFeatureType()) || !kOwner.isOption(PLAYEROPTION_LEAVE_FORESTS))
    											{
    												// Super Forts begin *AI_worker* - this should better determine the value of a build than the original code
    												if(GC.getDefineINT("SUPER_FORTS_SAFE_BUILD") != 0)
    												{
    													int iValue;
    													iValue = GC.getBuildInfo(eBuild).getTime();
    													if(GC.getBuildInfo(eBuild).isKill())
    													{
    														iValue += 10000;
    													}
    													if(GC.getImprovementInfo((ImprovementTypes)GC.getBuildInfo(eBuild).getImprovement()).isActsAsCity())
    													{
    														iValue /= 10;
    													}
    												}
    												else // Original Code is used if SUPER_FORTS_SAFE_BUILD is turned off
    												{
    													iValue = 10000; // Original Code
    													iValue /= (GC.getBuildInfo(eBuild).getTime() + 1); // Original Code
    													// XXX feature production???
    												}
    												// Super Forts end
    												int iValue;
    												if (iValue < iBestTempBuildValue)
    												{
    													iBestTempBuildValue = iValue;
    													eBestTempBuild = eBuild;
    												}
    											}
    										}
    									}
    								}
    							}
    						}


    error still..
    Spoiler :
    1>CvUnitAI.cpp
    1>CvUnitAI.cpp(21237) : error C2065: 'iValue' : undeclared identifier
    1>CvUnitAI.cpp(21238) : error C3861: 'iValue': identifier not found, even with argument-dependent lookup
     
  2. Red Key

    Red Key Modder

    Joined:
    Sep 24, 2011
    Messages:
    396
    Gender:
    Male
    Location:
    USA
    Your code still does not match mine. Your first declaration of int iValue needs to be moved up a couple lines, and you should not have a second one.

     
  3. God-Emperor

    God-Emperor Deity

    Joined:
    Jul 18, 2009
    Messages:
    3,551
    Location:
    Texas
    First, you are declaring iValue in 2 different places. Don't do that. (There might be some situations where you want to do this. This is not one of them.)

    Second, when you declare a variable inside any level of "{}" it is only valid inside that "{}". This is called the "scope" of the variable. The first time it is declared is "too far in" - it is used at a scope that is outside where it is declared, after the "if/else" code ends. But you are also declaring it again after that. This second iValue is a completely different variable than the first one and it is not set to anything, so you are likely to end up with random junk when using an optimized release build (debug builds should set it to 0, optimized builds may very well just leave it set to whatever was already in the memory it allocated which may or may not be 0).

    You should declare it, just once, probably not much later than around where eBuild is declared just inside the "for" loop (although you could do it up inside one or more of the "if" statements, just not too far in like it is now). Alternatively you could declare it outside the loop around where the iBestTempBuildValue is declared. Some people prefer declaring it inside the loop, others outside. (I would prefer outside, actually - the optimization should cause it to only allocate it once when it is declared in the loop, but I prefer to make sure by not putting it inside the loop. Others prefer to put it in the loop because outside the context of the loop the variable is not useful, so they have the declaration placed where the scope of the variable only covers where it is used.)

    As an aside:
    Spoiler :

    I also have to wonder who wrote code that has a smaller value being the "best" value - most other places it prefers larger values. It also seems peculiar in what it is doing. In particular, the "super forts" version will prefer whichever is the quickest to build that doesn't kill the worker but does act as a city. If you have one that is significantly better a higher defensive bonus and higher air bomb defense) but takes longer to build, it probably won't pick it as the best (unless the dividing it by 10 makes it the same integer and it comes first in the file). The "Original Code" version preferred whichever one took the longest to build, regardless of other properties (again, ties after the integer division go to whichever was first in the file). Neither one of these seems very good (although the new one is slightly better, I suppose) as they don't ever really consider any of the actual defensive properties of the fort in determining its "value".
     
  4. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    Thank you, Red Key!

    After merging CvUnitAI::AI_bombardCity, it compiled OK but with a warning:

    cvunitai.cpp(15535) : warning C4715: 'CvUnitAI::AI_bombardCity' : not all control paths return a value

    note: line 15535 is the closing bracket of the function in my file

    What does it mean?
     
  5. Lib.Spi't

    Lib.Spi't Overlord of the Wasteland

    Joined:
    Feb 12, 2009
    Messages:
    3,690
    Location:
    UK
    GOAL!

    Thanks red for being patient with my ineptitude!

    I attached the finished file incase anyone wants it.

    Thanks for the explanation emperor I just wish I understood it properly :D
     

    Attached Files:

  6. Red Key

    Red Key Modder

    Joined:
    Sep 24, 2011
    Messages:
    396
    Gender:
    Male
    Location:
    USA
    That function is supposed to return true if something is bombarded and false if something wasn't. That warning is telling you that under certain conditions the function won't return anything which is a problem. Add "return false;" before the very last } of the AI_bombardCity function and it should be fixed.
     
  7. Red Key

    Red Key Modder

    Joined:
    Sep 24, 2011
    Messages:
    396
    Gender:
    Male
    Location:
    USA
    Yep whoever at Firaxis coded this considered the smallest value the best, and the only thing really considered is the build time. I've seen this same code in other places when determining what improvement to build. I've been considering taking my part out and just using the original code since that is the way things are done other places. There are other parts of the code where all an improvement's effects are properly considered like when determining the best thing to build near a city in AI_bestCityBuild.
     
  8. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    Thank you.

    EDIT: "return false;" added as per instruction. Merge OK - no more warning.
     
  9. zhongguo

    zhongguo Chieftain

    Joined:
    Apr 15, 2013
    Messages:
    19
    @isenchine
    Thank you for your endless efort here, wheter in combining PAE with K-Mod or K-Mod with Super Forts.
    Me and my small multiplayer team can't await to enjoy it. We currently play with K-Mod. We would like to play PAE too, but oss is killing us badly.
     
  10. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    Thank you, zhongguo and ... Welcome to CFC! :)

    Unfortunately, I have no experience in MP. I know that Karadoc is very keen to have his K-Mod Multi-Player. PAE is full of Python code and I have no idea what could cause OOS in MP.
     
  11. zhongguo

    zhongguo Chieftain

    Joined:
    Apr 15, 2013
    Messages:
    19
    It still will take a long time I guess until PIE's .dll will be optimized for MP purpose.
    However, what about K-Mod + SuperForts?
     
  12. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    As far as I know, it should be MP friendly.
     
  13. zhongguo

    zhongguo Chieftain

    Joined:
    Apr 15, 2013
    Messages:
    19
    So you already finished mixing these two mods?
     
  14. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    Yes and no. It's a complicated story.

    At one point of time, I did it for myself, for my mod, without succeeding in merging successfully cvunitai.cpp.

    Then came Lib.Spi't who had errors in merging (again in his own mod), K-Mod (not the latest version) with SuperForts (so this thread).

    In the end, thanks to the help of Red Key himself, he got it fixed, including cvunitai.cpp.

    In other words, no, sorry, we don't have a final cut of just K-Mod + SuperForts!...
     
  15. zhongguo

    zhongguo Chieftain

    Joined:
    Apr 15, 2013
    Messages:
    19
    Will you do it anyway? :help::yup:
     
  16. isenchine

    isenchine Empress

    Joined:
    Oct 18, 2010
    Messages:
    1,774
    Location:
    Brussels, Belgium
    Maybe I should, but not in the near future. I'm not promising anything right now but I will keep it in mind.
     

Share This Page