Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

[JosEPh_II]

Upgrading units is now impossibly high see this post. https://forums.civfanatics.com/thre...r-city-lost-units.627485/page-6#post-15022071

It's where I posted about upgrading a slinger in a snail GS Immortal game costing 417. The cost of upgrading that same slinger to archer is now 830. It doubled! SVN 9887 is current SVN for that game and this is 5 turns After a Re-Calc.

 

[raxo2222]

I think you may be right that the fly in the ointment still is adding an extra 100 here. This was brought in as a solution from elsewhere and may have applied there but doesn't here.


Yes. It's an original bit of the process that I left as an aftereffect modifier.

These tags are meant to hold a default of 100.

Hmm so this explains my surprise.

I'm just surprised, that despite four production cost modifiers being <=100 (BuildingProduction 80%, Normal being 100%, Prehistoric being 70% and Settler being 60%) final cost of saddler (107) is higher than defined cost of it (92).

And what happens if imodifier becomes exactly 0?

  int iProductionNeeded;

   iProductionNeeded = GC.getBuildingInfo(eBuilding).getProductionCost();

   iProductionNeeded *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getConstructPercent();
   iProductionNeeded /= 100;

   int iModifier = (GC.getHandicapInfo(getHandicapType()).getConstructPercent() - 100);
   iModifier += GC.getDefineINT("BUILDING_PRODUCTION_PERCENT") - 100;
   iModifier += (GC.getEraInfo(getCurrentEra()).getConstructPercent() - 100);
   iModifier += 100;

    if (iModifier < 0)
    {
        iModifier = (-1 * iModifier + 100);
        iProductionNeeded = iProductionNeeded * 100 / iModifier;
    }
    else if (iModifier > 0)
    {
        iProductionNeeded *= 100 + iModifier;
        iProductionNeeded /= 100;
    }

   if (!isHuman() && !isNPC())
   {
       if (isWorldWonderClass((BuildingClassTypes)(GC.getBuildingInfo(eBuilding).getBuildingClassType())))
       {
           iProductionNeeded *= GC.getHandicapInfo(GC.getGameINLINE().getHandicapType()).getAIWorldConstructPercent();
           iProductionNeeded /= 100;
       }
       else
       {
           iProductionNeeded *= GC.getHandicapInfo(GC.getGameINLINE().getHandicapType()).getAIConstructPercent();
           iProductionNeeded /= 100;
       }

       iProductionNeeded *= std::max(0, ((GC.getHandicapInfo(GC.getGameINLINE().getHandicapType()).getAIPerEraModifier() * getCurrentEra()) + 100));
       iProductionNeeded /= 100;
   }


   return std::max(1, iProductionNeeded);

Changing that to:

    else if (iModifier >= 0)
    {
        iProductionNeeded *= 100 + iModifier;
        iProductionNeeded /= 100;
    }

Then will be fine with iModifier being 0, as this part will accept iModifier equal to 0 and proceed as if nothing happened.
This way you won't leave black hole in your code
It may be not needed, but that looks safer

 

[Noriad2]

Also, I accidentally left combat graphics on, and stone thrower is throwing pink blobs instead of rocks at a bird to its northeast during combat.

 

[flabbert]

just had a partisan turn into this when selected

 

[Thunderbrd]

And what happens if imodifier becomes exactly 0?

HAH! Great spot! Should be <= 0 in the IF statement.

Upgrading units is now impossibly high see this post. https://forums.civfanatics.com/thre...r-city-lost-units.627485/page-6#post-15022071

It's where I posted about upgrading a slinger in a snail GS Immortal game costing 417. The cost of upgrading that same slinger to archer is now 830. It doubled! SVN 9887 is current SVN for that game and this is 5 turns After a Re-Calc.

A couple more math issues are being addressed. Check that again after the next DLL commit. I probably need to also assign the unit production globals to the unit upgrade coding if it doesn't automatically take the functions under discussion and improvement into account, which I think it does but I'll review that before I send up the next DLL to the SVN.

 

[Thunderbrd]

@All: You don't have to help with identifying all the individual art issues - we missed a couple FPKs and it takes forever to pack these things from scratch so just be patient on that.

 

[Raledon]

Then will be fine with iModifier being 0, as this part will accept iModifier equal to 0 and procced as if nothing happened.
This way you won't leave black hole in your code

I think it was intentional.
If imodifier is set to 0, we don't really want to change the cost, so keep it as is. Otherwise, go on.
EDIT: if you want to do it anyway, better change the check to a simple else, instead of else if.

I think you may be right that the fly in the ointment still is adding an extra 100 here. This was brought in as a solution from elsewhere and may have applied there but doesn't here.

These tags are meant to hold a default of 100.

I think that the "iModifier += 100;" is not supposed to be there, at all.
In such a case:
With default 100 in all of them, we get the same iproduction regardless of the route we go in the if(modifier><=0). Going to the first if, second if or neither will yield iproduction, as expected to happen. In addition, it matches Joseph's upgrade costs quite well (cost doubled).

 

[raxo2222]

HAH! Great spot! Should be <= 0 in the IF statement.

A couple more math issues are being addressed. Check that again after the next DLL commit. I probably need to also assign the unit production globals to the unit upgrade coding if it doesn't automatically take the functions under discussion and improvement into account, which I think it does but I'll review that before I send up the next DLL to the SVN.

if (iModifier <= 0)
    {
        iModifier = (-1 * iModifier + 100);
        iProductionNeeded = iProductionNeeded * 100 / iModifier;
    }

Sending imodifier = 0 to this IF part would end up in small explosion, as you would divide it by 0
In "else if" part there is no division by imodifier

Lets simulate building costing 1000 hammers, and all four building cost modifiers being 100.

  int iProductionNeeded;

   iProductionNeeded = GC.getBuildingInfo(eBuilding).getProductionCost(); 1000H

   iProductionNeeded *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getConstructPercent(); 1000H*100 = 100 000H
   iProductionNeeded /= 100; 100 000H/100 = 1000H

   int iModifier = (GC.getHandicapInfo(getHandicapType()).getConstructPercent() - 100); 100 - 100 = 0
   iModifier += GC.getDefineINT("BUILDING_PRODUCTION_PERCENT") - 100; 0 + 100 - 100 = 0
   iModifier += (GC.getEraInfo(getCurrentEra()).getConstructPercent() - 100); 0 + 100 - 100 = 0
   iModifier += 100; 0 +100 = 100

    if (iModifier < 0)
    {
        iModifier = (-1 * iModifier + 100);
        iProductionNeeded = iProductionNeeded * 100 / iModifier;
    }
    else if (iModifier > 0)
    {
        iProductionNeeded *= 100 + iModifier; 1000H*(100 + 100) = 200 000H
        iProductionNeeded /= 100; 200 000H/100 = 2000H
    }

   return std::max(1, iProductionNeeded);

Final cost: 2000 hammers, going out of this station.

 

[Thunderbrd]

Also, units have become a lot more expensive compared to buildings. 152 hammers for a wanderer, 381 hammers for a tracker, while stone tools workshop is only 100 and LL monte verde is 200. Is this WAD or bug?
(nightmare/large map/snail speed/svn 9887)

yep... a unique bug in the xml on nightmare. Resolved on next commit.

 

[Raledon]

1: if (iModifier <= 0)
    {
2:        iModifier = (-1 * iModifier + 100);
3:        iProductionNeeded = iProductionNeeded * 100 / iModifier;
    }

Sending imodifier = 0 to this IF part would end up in small explosion, as you would divide it by 0
In "else if" part there is no division by imodifier

[added lines in quote]
#1: iModifier=0
#2: iModifier=0+100=100
#3 iProductionNeeded=iProductionNeeded*100/100=iProductionNeeded
seems fine to me. The issue is in case iModifierenters the if with value of 100, which should mean +100% production needed. 100 is not <=0, so we are fine on this point.

 

[raxo2222]

[added lines in quote]
#1: iModifier=0
#2: iModifier=0+100=100
#3 iProductionNeeded=iProductionNeeded*100/100=iProductionNeeded
seems fine to me. The issue is in case iModifierenters the if with value of 100, which should mean +100% production needed. 100 is not <=0, so we are fine on this point.

At least I had fun with trying to divide by 0

Also that iModifier += 100; isn't needed as according to calculations.
Cost got doubled.

 

[Thunderbrd]

I think it was intentional.
If imodifier is set to 0, we don't really want to change the cost, so keep it as is. Otherwise, go on.
EDIT: if you want to do it anyway, better change the check to a simple else, instead of else if.



I think that the "iModifier += 100;" is not supposed to be there, at all.
In such a case:
With default 100 in all of them, we get the same iproduction regardless of the route we go in the if(modifier><=0). Going to the first if, second if or neither will yield iproduction, as expected to happen. In addition, it matches Joseph's upgrade costs quite well (cost doubled).

You're correct. Thanks for the insights!

(I'm LOVING this team work! Thanks for not judging me for my extremely mistake prone math skills!)

 

[JosEPh_II]

You're correct. Thanks for the insights!

(I'm LOVING this team work! Thanks for not judging me for my extremely mistake prone math skills!)

Oh crap I didn't get it posted fast enough! Now I can't verbally you over it. Dag nabbit!

 

[raxo2222]

Two things went unnoticed during this hectic bug hunt:
There are 3 buildings with misapplied star icon - Virotherapy clinic, Civilized Jewelers (unneded golden star icon, as these normal buildings) and Dali Treater&Museum WW (no golden star on building icon).

Also Team Projects should get same treatment in handicap infos:
Their tag for cost modification is: iCreatePercent
AI already uses tag: AIiCreatePercent in handicap infos.

 

[Thunderbrd]

There are 3 buildings with misapplied star icon - Virotherapy clinic, Civilized Jewelers (unneded golden star icon, as these normal buildings) and Dali Treater&Museum WW (no golden star on building icon).

Noticed. Whisperr left quite a few in the futuristic side of buildings. She wanted to get the original artwork from Pepper before trying to address those if he has them. I realize Civilized Jewelers we might just have to go searching for the art as it's probably not his button originally either.

Also Team Projects should get same treatment in handicap infos:

I'm not bothering with the extra tag but I AM fixing the calculations to include the iconstructpercent tag and adapting to the new math methods. I did overlook it initially. Really don't see the point to having a whole new tag for those.

 

[Raledon]

You're correct. Thanks for the insights!

(I'm LOVING this team work! Thanks for not judging me for my extremely mistake prone math skills!)

Haha, no problem.
Today I had an issue at work not much better- I accidently wrote "source - target" instead of "target - source" (coordinates). Took me a few hours to find that this was the root of the bug. These kind of things happen to everyone, I was just lucky to be a fresh pair of eyes to notice it.

 

[raxo2222]

Noticed. Whisperr left quite a few in the futuristic side of buildings. She wanted to get the original artwork from Pepper before trying to address those if he has them. I realize Civilized Jewelers we might just have to go searching for the art as it's probably not his button originally either.

Virotherapy clinic (Information era) is placed in general buildings xml, not peppers module.
Dali Theater World wonder is Modern era, placed in main wonderbuilding xml file.
These buildings seems to be core ones.

I'm not bothering with the extra tag but I AM fixing the calculations to include the iconstructpercent tag and adapting to the new math methods. I did overlook it initially. Really don't see the point to having a whole new tag for those.

So team project cost won't be affected by difficulty level?
Team Projects have their own tag for cost modification.
Or you are going to replace Team Project cost modifying tag [icreatepercent] with standard building cost modifier [iconstructpercent] tag?

 

[JosEPh_II]

So team project cost won't be affected by difficulty level?
Team Projects have their own tag for cost modification.
Or you are going to replace Team Project cost modifying tag [icreatepercent] with standard building cost modifier [iconstructpercent] tag?

Why would he do this? This would just create confusion.

 

[Thunderbrd]

Why would he do this? This would just create confusion.

It can but once I looked at it, we ALWAYS keep the iConstructionPercent and iCreatePercent tags at the same values. So it just makes sense to have iConstructionPercent apply where you'd expect an iCreatePercent tag to apply in the final formulas.

Why anyone ever setup the projects differently in this regard is beyond me. If it's a problem for you, I CAN add another tag. I just didn't really feel it was necessary, do you?

 

[raxo2222]

Why would he do this? This would just create confusion.

Well I'm asking what hes going to do with Team Project unique tag. [icreatepercent]
For now team project cost is unaffected by difficulty for players.