Ket said:
The increadible expanding Log file...
xml.log is out of control, somehow it is just popping a few thousand lines of
"info type None not found, Current XML file is: Misc/Civ4TutorialInfos.xml"
It grows to about 12 megs a game and it seems to be constantly trying to load the tutorial... I dont call the tutorial anywhere.. I'm not sure why this is happening.. Any one have any ideas or where to look?
Typically, this error happens when getInfoTypeForString is called. Here's the code in the sdk:
Code:
int CvGlobals::getInfoTypeForString(const char* szType) const
{
FAssertMsg(szType, "null info type string");
InfosMap::const_iterator it = m_infosMap.find(szType);
if (it!=m_infosMap.end())
{
return it->second;
}
CvString szError;
[b]szError.Format("info type %s not found, Current XML file is: %s", szType, GC.getCurrentXMLFile().GetCString());[/b]
FAssertMsg(strcmp(szType, "NONE")==0, szError.c_str());
gDLL->logMsg("xml.log", szError);
return -1;
}
The reason that it shows "Civ4TutorialInfos.xml" as the current xml file is because Civ4TutorialInfos.xml is the LAST file loaded by Civ4 when loading the xml files. Even if you don't use the file in your mod, just like all XML files, the default found in the main assets directory will be loaded. Thus, whenever this function is called after the last XML file has been loaded (i.e. once the game has started), it will pop out the filename that was last loaded, which is the tutorial one. Don't worry, it's not trying to load multiple times, but because it was the last one loaded, every error that happens will show it as the "current" file (though truthfully it probably should say "last" file).
As for "None" not found, methinks this is a standard error (although it's more of a warning than an error). In fact, if you were to load a normal Civ4 game with logging enabled, you'd see those "None not found" errors all the same.
Sometimes, XML uses "NONE" or "None" to represent that there isn't any object that should be applied in the specific tag (for example, you might want to make a unit class with a default unit type of "NONE", although this is a horrible example and I wouldn't recommend doing it, but it was the first thing I thought of). When the getInfoTypeForString method is called with "NONE" or "None", it will return -1 and shoot out that warning message. In the example I used, if trying to find the default unit, it will get -1 as the unit type. Now, bad things happen if the code doesn't correctly handle what happens if they get -1 as a result of the getInfoTypeForString(). Many times, the case is handled correctly. Other times, it's not.
Using none is quite common. Just search through all the default XML files for "none". Every time you find it, there will be an "error" in the xml.log. The problem really starts if you use the gc.getInfoTypeForString function to search for something and it just happens to not be there... for example, in this python code:
Code:
eTech = gc.getInfoTypeForString("TECH_BIOL[b]I[/b]GY")
Well, that error is going to show up, because I mispelled biology, and there's no tech that has that name. However, you're probably going to figure this out anyway, when you get an error message when doing the code that typically follows code like I showed:
Code:
gc.getTechInfo(eTech).getCost()
Because getTechInfo(-1) returns none, you'll get an error. I'm not sure if I got all the function calls right, but hopefully you know what I mean.
So, there are two places where you should be worried. The first is in python scripts, where you should probably be checking to make sure to handle the case of getting -1 back from a getInfoTypeForString (although typically by then the script is going to be so messed up that at this point the best way of handling the problem might just be letting the error be shown so that you as a mod-creator know about it, and that users can report it).
The second is if you use it in XML. Here I'm not too sure of any good rule-of-thumbs, but I would follow the examples of others and if they put none for a certain field, it should be okay for you to do it for that field as well.
So, just because it's located in the xml.log, first off it doesn't necessarily mean it's XML, but second it doesn't necesarily mean that there's a problem.
