Assert failed, have never seen this, help

Afforess said:

CvEnums are were all the Strings are hardcoded to return specific values.

Click to expand...

emperorfool said:

There must be a call to setInfoTypeForString(char*, int) or something. Just pass in "NONE" and -1.

Click to expand...

I don't understand how Afforess' suggestion would prevent the "info type NONE not found" messsage. I agree with EmperorFool's suggestion. The message is printed when looking up the string "NONE" and failing to find it in the global hash underneath getInfoTypeForString. I do not see how changing enums will address this at all.

What I don't know exactly is where to put the call to setInfoTypeForString, or if this call exists. It needs to happen early in initialization, before any xml is read.

The function which EF theorizes about would be: CvGlobals::setInfoTypeFromString

The mildly odd thing is that NONE shouldn't cause issues, Firaxis solved it the way that I would have:


So if you use a blank or NONE, there should be no problem

Wait.... I see it now, if you use NONE or a blank, there is no ASSERT, but there IS a log entry. So just place that log entry in an IF statement containing the same logic as the assert and these errors are no longer an issue.

One thing I am curious about is that I thought that the NO_PROMOTION and other enums which are not loaded from the XML were loaded into the lookup hash, but they are not. Thus doing a getInfoTypeForString("NO_PROMOTION") would give an error (in both log and assert), even though it is a valid enum. As well as trying to do that on any of the hardcoded enums (except those like GameOptions which are also XML entities), like the ButtonPopups.

So what Afforess suggests actually wouldn't work for this particular case, because the enums aren't utilized. You can use EF's approach to insert an extra item in your InfoMap (which may or may not have side-effects), or you can just add an IF which blocks the log entry if it bugs you.

davidlallen said:

I don't understand how Afforess' suggestion would prevent the "info type NONE not found" messsage. I agree with EmperorFool's suggestion. The message is printed when looking up the string "NONE" and failing to find it in the global hash underneath getInfoTypeForString. I do not see how changing enums will address this at all.

What I don't know exactly is where to put the call to setInfoTypeForString, or if this call exists. It needs to happen early in initialization, before any xml is read.

Click to expand...

Eh, you guys are right.

SetInfoTypeForString exists, and is in CvGlobals, but it only is called in CvXMLLoadUtilitySet and CvGlobals. And I don't understand really whats happening in either call.

xienwolf said:

Thus doing a getInfoTypeForString("NO_PROMOTION") would give an error (in both log and assert)

Click to expand...

I think Afforess may be a little confused about the relationship between enums and strings, but I don't think any sdk code ever uses gITFS to lookup the values like NO_PROMOTION. The values like NO_PROMOTION are enums, you just use them as-is.

or you can just add an IF which blocks the log entry if it bugs you.

Click to expand...

That seems a much safer solution.

davidlallen said:

I think Afforess may be a little confused about the relationship between enums and strings, but I don't think any sdk code ever uses gITFS to lookup the values like NO_PROMOTION. The values like NO_PROMOTION are enums, you just use them as-is.

Click to expand...

Well, the enums are the only place I saw things like NO_TECH defined... I didn't know about the Infomap.

Afforess said:

SetInfoTypeForString exists, and is in CvGlobals, but it only is called in CvXMLLoadUtilitySet and CvGlobals. And I don't understand really whats happening in either call.

Click to expand...

Sorry if part of this seems obvious, but strings and enums are different. Let me pick WorldSizeTypes as an example, it is the first simple one I noticed in cvenums.h.

WORLDSIZE_DUEL is an int, technically it is a subclass of int, with value 0.

"WORLDSIZE_DUEL" is a string.

If I have a string "WORLDSIZE_DUEL" which I suspect is a name that the sdk should recognize, I call gITFS on the string. Now, how is the sdk supposed to know that this string corresponds to the int 0? It is because during initialization, *set* ITFS was called to associate this string with this int. This association is stored in a hash table, probably the best technical name for this is a "global symbol table". During initialization, thousands of calls to sITFS are made to fill up this global symbol table. This is a convenience, because the sdk is often handed strings which need to be quickly converted into ints if the string is recognized.

I am not sure if that helps, but by themselves, enums have no string value. It is only through the global symbol table underneath gITFS that you can convert strings into their related ints. This table is filled up by calls to sITFS somewhere during early initialization.

Here's what I thought the problem was:

1. XML file has NONE for a field that should hold a PromotionTypes string.
2. XMLLoadUtillitySet.cpp uses getInfoTypeForString() to look up NONE.
3. getInfoTypeForString() doesn't find NONE, so it logs an error.

If that's not what's happening please explain. If it is, you need to put "NONE" into the data structure that getInfoTypeForString() uses to have any effect. Adding new constants to CvEnums.h will not affect that data structure.

Adding an if statment does it. From xienwolf's sample, I added this statememt right before the line about logging:
It makes the XML log a LOT cleaner, which will come in handy if I ever need to use it. I'm surprised Firaxis didn't already do something like this, seeing as it's so easy once you know where in the code to put it.

EmperorFool said:

Here's what I thought the problem was.

Click to expand...

Please re-read xienwolf's post above, which gives the alternate (preferred) solution.

Yes, ignore my previous post. I wrote it before seeing the second page. I'll add the solution from xienwolf to BULL.