General DLL programming questions

[Thunderbrd]

It would probably be double counting the modifiers from everyone on the team, based on that code, but even then that's nothing like -3% to -50% unless you have HUGE teams.

This could be much more involved that what you're pointing at alone. Test it from all kinds of angles. This isn't the only application of that changeCommerceRateModifier function. Hit it from another angle and see if it causes the same inappropriate result.

 

[ls612]

It would probably be double counting the modifiers from everyone on the team, based on that code, but even then that's nothing like -3% to -50% unless you have HUGE teams.

This could be much more involved that what you're pointing at alone. Test it from all kinds of angles. This isn't the only application of that changeCommerceRateModifier function. Hit it from another angle and see if it causes the same inappropriate result.

I have 3 vassals, so one would expect -24% from that. At any rate, I did some more looking and all of the other applications of changeCommerceRateModifier are worded in the same way and the current applications are working properly under the debugger. I'm stuck as to what is happening, but to start how would I make it not double-count team members? Add it onto the player?

Edit: I've also removed the modifiers from the XML for now until this gets fixed.

 

[Koshling]

OK. I am still trying to figure out how this could be off by so much. Could it somehow be double-counting the modifiers from everyone on a team? Because that code looks fine to me (excepting that there should probably be a check to make sure that the commerce modifier isn't 0, but that wouldn't cause this problem).

I don't know. Watch it under the debugger with breakpoints of the modifier that ends up wrong being changes and see what is changing it.

 

[Thunderbrd]

Well... in reviewing the code there once more, it doesn't look like its doubling up for every team member. It's in CvTeam because it's derived from a Tech but is only establishing it once for the rest of the team members (and vassals aren't part of your Team btw... teams share the same tech progress.)

Could it be somehow flawed in the load process in the Info file?

 

[ls612]

Could it be somehow flawed in the load process in the Info file?

No, the arrays are fine. I'll do as Koshling suggested (tomorrow) and figure out where the numbers are going wrong. And I also need to set aside some time in the near future to learn to debug effectively, I clearly can't do that now.

 

[ls612]

I have a simple (I hope) question, how do you return the terrain or feature type of the plot a unit is on (or even better, its index)?

 

[Koshling]

I have a simple (I hope) question, how do you return the terrain or feature type of the plot a unit is on (or even better, its index)?

pUnit->plot()->getFeatureType() [or getTerrainType()]

of course, depending on context you should maybe check that plot() isn't NULL first, since units in delayed death state will have a NULL plot.

 

[ls612]

pUnit->plot()->getFeatureType() [or getTerrainType()]

of course, depending on context you should maybe check that plot() isn't NULL first, since units in delayed death state will have a NULL plot.

How do I return the index there though? I know that I can use getFeatureTypeByIndex to get the featuretype if I know the index, but I'd like to get the index of the feature type.

 

[Koshling]

How do I return the index there though? I know that I can use getFeatureTypeByIndex to get the featuretype if I know the index, but I'd like to get the index of the feature type.

Oh I see, you mean for the multi-feature mod? (the index isn't used except with multiple features). I'm not sure in that case - AIAndy is your man for that aspect. However, why do you care what it's index is? (the index is just a way to enumerate the set)

 

[ls612]

Oh I see, you mean for the multi-feature mod? (the index isn't used except with multiple features). I'm not sure in that case - AIAndy is your man for that aspect. However, why do you care what it's index is? (the index is just a way to enumerate the set)

Yeah, that is what I'm concerned about. Terrains should be fine, but I don't want this to go crash when we start using multiple features.

As for what I'm doing I set up the array as an entry in the TerrainKeyedInfo and FeatureKeyedInfo, and want to say something like this

TerrainTypes pTerrain = plot()->getTerrainType();

if (getTerrainWorkPercent(pTerrain) != 0) 
    //Do Something useful

But I need to get that to play nice for features with the Multi-Feature mod.

 

[Koshling]

Yeah, that is what I'm concerned about. Terrains should be fine, but I don't want this to go crash when we start using multiple features.

As for what I'm doing I set up the array as an entry in the TerrainKeyedInfo and FeatureKeyedInfo, and want to say something like this

TerrainTypes pTerrain = plot()->getTerrainType();

if (getTerrainWorkPercent(pTerrain) != 0) 
    //Do Something useful

But I need to get that to play nice for features with the Multi-Feature mod.

for(iI = 0; iI < GC.getNumFeatureTypes(); iI++)
{
    if ( plot()->getHasFeature((FeatureTypes)iI) )
    {
        // do something useful
    }
}

 

[ls612]

for(iI = 0; iI < GC.getNumFeatureTypes(); iI++)
{
    if ( plot()->getHasFeature((FeatureTypes)iI) )
    {
        // do something useful
    }
}

Thanks. But I don't need to do taht for terrains, I can leave it like I wrote above, correct?

 

[Koshling]

Thanks. But I don't need to do taht for terrains, I can leave it like I wrote above, correct?

For terrains, yes, since you cannot have multiple terrains per plot.

 

[AIAndy]

for(iI = 0; iI < GC.getNumFeatureTypes(); iI++)
{
    if ( plot()->getHasFeature((FeatureTypes)iI) )
    {
        // do something useful
    }
}

Far more efficient this way:

CvPlot* pPlot = plot();
for (int i=0; i < pPlot->getNumFeatures(); i++)
{
  FeatureTypes eFeature = pPlot->getFeatureByIndex(i);
  // do something useful
}

 

[Koshling]

Far more efficient this way:

CvPlot* pPlot = plot();
for (int i=0; i < pPlot->getNumFeatures(); i++)
{
  FeatureTypes eFeature = pPlot->getFeatureByIndex(i);
  // do something useful
}

Definitely. I hadn't spotted the method to retrieve by index.

 

[ls612]

@Koshling:

I've implemented rudimentary AI for the Promotion modifiers to work speed for terrains and features. However, I noticed that all of the evaluations in promotionvalue for terrain and feature-related stuff were not at all based on how much of a terrain you have in your civ. Are there any functions that could be used to count the number of plots with terrain or feature iI? Would it be hard to make such a function?

 

[Koshling]

@Koshling:

I've implemented rudimentary AI for the Promotion modifiers to work speed for terrains and features. However, I noticed that all of the evaluations in promotionvalue for terrain and feature-related stuff were not at all based on how much of a terrain you have in your civ. Are there any functions that could be used to count the number of plots with terrain or feature iI? Would it be hard to make such a function?

See the code in CvUnitAI::AI_genericUnitValueTimes100() which does do those evaluations. I wrote that routine while TB was working extensively on the combat mod so I didn't want to mess with AI_promotionValue() at the time as we'd have clashed. It was always intended that AI_promotionValue() would have similar code, but we forgot to actually port it over when TB was done with the combat mod changes. Please feel free to do so

Note - AI_genericUnitValue() is used to evaluate how much an extant unit is actually worth during evaluation of combat results (i.e. - whether it's worth losing one set of units for another set of enemy kills).

 

[ls612]

See the code in CvUnitAI::AI_genericUnitValueTimes100() which does do those evaluations. I wrote that routine while TB was working extensively on the combat mod so I didn't want to mess with AI_promotionValue() at the time as we'd have clashed. It was always intended that AI_promotionValue() would have similar code, but we forgot to actually port it over when TB was done with the combat mod changes. Please feel free to do so

Note - AI_genericUnitValue() is used to evaluate how much an extant unit is actually worth during evaluation of combat results (i.e. - whether it's worth losing one set of units for another set of enemy kills).

OK, I think I'll just spin that code off into a new function entirely and call it in both methods.

 

[Dancing Hoskuld]

One question that has bugged me is this idea of "plots in your city". Currently vicinity does not take into account which plots are within your cultural borders letting you build buildings which, in theory, you don't have the resources for. Eg if you have a new city and the tar pit is two plots away from the city and outside your cultural boundaries you still have access to it.

Edit I think it uses work radius. This is OK if the plot is in your cultural border as you want those two cities to have the common plots to count for both cities.

 

[Koshling]

One question that has bugged me is this idea of "plots in your city". Currently vicinity does not take into account which plots are within your cultural borders letting you build buildings which, in theory, you don't have the resources for. Eg if you have a new city and the tar pit is two plots away from the city and outside your cultural boundaries you still have access to it.

Edit I think it uses work radius. This is OK if the plot is in your cultural border as you want those two cities to have the common plots to count for both cities.

Correct - it does use work radius. Would you like me to also make it check for ownership?