That refers to how the icons are found that refer to the corporations. If you changed anything about this, you likely broke the reference indexing matching the corps to their icons. Check by opening the mod with your changes to see if the corporations have their correct icons. I think that's something you should be able to see in the pedia.
He changed TGA_RELIGIONS to GC.getTGA_RELIGIONS() if the macro TGA_RELIGIONS is recognized as a global within CvInfos.cpp then it wouldn't be a problem, though I'm not familiar enough with c++ data-structures to know either or.
I'm not all that familiar with their use either so as long as it works and the index remains stable, I'm cool. Thing is, it's not necessarily a good thing to make it dynamic which is why it's a very hard coded and fixed variable that establishes the beginning of the indexing.
Well, I don't know what it would matter then when the amount is still defined by GC.getTGA_RELIGIONS(). However, I thought that macros were defined at the time of compiling rather than inside the processing of game information on load. I suppose this sort would just be saying it's hardcoded to that definition whatever that definition is at the time, but it's a moot distinction so far as I can imagine. Such a change is basically a non-change entirely.
All icon types are given a range of indexes and if you put art outside that range in the tga files you'll cause odd problems potentially. It CAN be given more allocation but it's a pain to do. Seriously. It takes some intense work on some places I'd rather forget in the code. That said, probably eventually we'll need to give corps more slots to work with.
The icons were the only thing that did work
. It was problems with the buildings and units all going to the one corporation rather than to the ones they were defined to.
Hmm... not sure I know how that would happen but it's certainly an indexing issue. There's two index systems afoot there. One for the icons and another for references to the proper religion/corp.The icons were the only thing that did work
Not sure. It would not take to long to recreate though. At least the basics. I was trying out the idea of ancient cults basing them on those in Pie_at's mod.
The display of icons is all Python code. Although I didn't think to check the Global Defines XML to see if there was a lesser number used for a maximum number of corporations. Many of the limits used for arrays have been defined in there. Having it as big (or small) as needed helps with memory usage but if the actual number goes over the maximum defined in the XML it will cause problems. As we saw with the various OR/AND limits.
Unfortunately not
. Shouldn't be to hard to recreate. They were just modified Pie_At ones ie from his Ancient Europe mod. I'll try and get to it this weekend.
. I need to get fit enough for at least some social dance.
int CvPlayer::getCoastalAIInfluence()
{
int iInfluence = 0;
int iLoop;
int iNumCities = 0;
int iModifier = 0;
CvCity* pLoopCity;
for (pLoopCity = firstCity(&iLoop); pLoopCity != NULL; pLoopCity = nextCity(&iLoop))
{
if (pLoopCity->isCoastal(1))
{
iInfluence++;
}
iNumCities++;
}
iInfluence *= 100;
if (iModifier != 0)
{
iModifier = iInfluence/iNumCities;
}
iModifier += 50;
return std::max(0, iModifier);
}Good spot.
int CvPlayer::getCoastalAIInfluence()
{
int iInfluence = 0;
int iLoop;
int iNumCities = 0;
CvCity* pLoopCity;
for (pLoopCity = firstCity(&iLoop); pLoopCity != NULL; pLoopCity = nextCity(&iLoop))
{
if (pLoopCity->isCoastal(1)) iInfluence++;
iNumCities++;
}
if (iInfluence > 0)
{
return 50 + (100*iInfluence)/iNumCities; // iNumCities >= iInfluence > 0 = True
}
return 50;
}int CvPlayer::getCoastalAIInfluence()
{
int iInfluence = 0;
int iLoop;
int iNumCities = 0;
int iModifier = 0;
CvCity* pLoopCity;
for (pLoopCity = firstCity(&iLoop); pLoopCity != NULL; pLoopCity = nextCity(&iLoop))
{
if (pLoopCity->isCoastal(1))
{
iInfluence++;
}
iNumCities++;
}
iInfluence *= 100;
if (iNumCities!= 0)
{
iModifier = iInfluence/iNumCities;
}
iModifier += 50;
return std::max(0, iModifier);
}I'll have to check that too then. Seafaring should be using it on all versions of itself.
I was waiting for you to tell us how the test went. If it goes solid and everyone agrees we should use it, I'm happy to include it.
Nope... never had any indication that there was any time delay at all with this pinch method. Nothing ever mentioned it and it would be so insignificant on profiling runs that it doesn't become obvious. I'm not saying you're wrong, just that one calculation of anything isn't going to make for any kind of delay whatsoever - it's when you get thousands or millions or more calculations in a round that we tend to see delays. I don't think this is called often. That said, no reason not to make it cheaper in processing. So it's helpful to know there's a difference. As for the rest of this statement, given that it should be impossible to get less than 50, and the std::max command is slow, might as well just return iModifier.
