The IDs are just a pair of numbers, one to indicate the player, a second as a unique ID for the object (City, unit...)
Honestly, IDInfo doesn't NEED to be understood, you use it in the precise format you just saw and it does the job it is meant to do. But if you are curious about it, IDInfo is a Struct (something you will rarely have to play with, but if you get complicated with what you add you might eventually want to know how to use).
Code:
struct DllExport IDInfo
{
IDInfo(PlayerTypes eOwner=NO_PLAYER, int iID=FFreeList::INVALID_INDEX) : eOwner(eOwner), iID(iID) {}
PlayerTypes eOwner;
int iID;
bool operator== (const IDInfo& info) const
{
return (eOwner == info.eOwner && iID == info.iID);
}
void reset()
{
eOwner = NO_PLAYER;
iID = FFreeList::INVALID_INDEX;
}
};
Structs are mini-files with their own defined rules. In this case, you declare it with a PlayerTypes item, and an Integer. The PlayerType becomes the eOwner variable, and the integer becomes the iID. The only inbuilt tool is a comparison and a reset function, primarily it just exists as a container to use for lookup tables to find pointers. I've never actually had a class in any Object oriented language, but I am relatively certain that the main reason this is required is because while we COULD store the pointers when we save the game, and it would take up the same space as a single integer, it points to a place in memory, so when the game is loaded in the future, it is quite likely located in a new memory space, thus the pointer is now invalid, so must be relocated/targetted. So by storing integer identifiers, we can look up appropriate pointers when required (which would be any time that we are not 100% certain that the preceding functions have done so themselves since the last time that the game was loaded).
The actual lookup happens in:
Code:
CvCity* getCity(IDInfo city)
{
if ((city.eOwner >= 0) && city.eOwner < MAX_PLAYERS)
{
return (GET_PLAYER((PlayerTypes)city.eOwner).getCity(city.iID));
}
return NULL;
}
So you see it loops over all players, fetches the player fresh (GET_PLAYER), checks if it is a match, and then has the player search his stored city ID values for a match.
Typically there is joy to be found in releasing a ModComp, so I'd say go for it. The best releases are things you did for yourself, as then you are less upset if it appears that nobody else is using it at all.
I was trying to call function isCity
Weird... 
It ended to CvCity* getCity(IDInfo city) in CvGameCoreUtils.cpp. I don't actually even know what the IDs are and do so that's why I asked. Do you know any good tutorial about them?
Mayby next thing I'll do is to add some tags to promotion witch alter the ranged bombard. BTW, phungus420 called this a "modcomp", but I never dreamed of releasing this. Should I do it?
