What's the difference between the following lines of python code? :

[Maniac]

iFungalTower = gc.getInfoTypeForString('UNIT_FUNGAL_TOWER')

or

iFungalTower = CvUtil.findInfoTypeNum(gc.getUnitInfo,gc.getNumUnitInfos(),'UNIT_FUNGAL_TOWER')


Any advantage in using either?

 

[Sto]

I'm not sure , but the way CvUtil.findInfoTypeNum is implemented looks like made for tests . Like if an info type can be defined as None is the xml , but return -1 with CvUtil.findInfoTypeNum instead of a value>-1 if you use gc.getInfoTypeForString('NONE') in a loop . I don't see any other reason . But that's just a guess .

Tcho !

Edit : The other reason is the PyAssert for debugging that tell you if you try to get a type with a string not recognized . But a thing i don't understand is the 2 first arguments that have no use . Looks like this function has been changed . Perhaps , if you want to change something with python ?? (store two different XML type and return either one or the other when you call the function with a personal key)

 

[Maniac]

Hmm, I don't really understand what you're saying. I guess I'll just remember it doesn't really matter all that much.

Reason I asked is because Jon Shafer always uses the complicated method instead of using getInfoTypeForString.

 

[Sto]

I will try to be more clear even if i don't understand also this function since it acts like gc.getInfoTypeForString :

def findInfoTypeNum(infoGetter, numInfos, typeStr):
	if (typeStr == 'NONE'):
		return -1
	idx = gc.getInfoTypeForString(typeStr)
	pyAssert(idx != -1, "Can't find type enum for type tag %s" %(typeStr,))
	return idx

_ if typeStr == 'NONE' return -1 . What the use of that ? test a blank xml ?

_ pyAssert(idx != -1, "Can't find type enum for type tag %s" %(typeStr,)) .
If you have a huge MOD , you can debug it with if you change xml , python calls (synthax errors) . I've seen two errors in FFH2 that would have been fixed very quick with this debug . An unit removed still called in python . A synthax error in a string type .

_ Another reason would be to create an evolution MOD (but the creator can make this function as well by itself ) . A simple example , you spawn units in a scenario , but in function of some condition you want to return unit_a ,b or c . You can do that here calling it with "GET_UNIT_EVENTA" that will return the index of "UNIT_A" , "UNIT_B" or "UNIT_C". If you have a huge number of infos to store , collapse them in this function is great instead of spreading some conditions all over your code ... but i don't think this is the first aim of this function .

Still wondering the use of the 2 first arguments . Perhaps this function was used to built up BtS and change after !?

Tcho !

 

[Zebra 9]

I have often wondered why they did this. I think that maybe they where going to have a more precise search mechanism and dropped it. I guess that if you wanted to do a good job with your coding use the CvUtil.findInfoTypeNum (you can change this one but not the gc.getInfoTypeForString) and pass None for the 2 redundant args.

 

[Sto]

Perhaps , they would like to do something like that for performance ... and abandon it after .

def findInfoTypeNum(infoGetter, numInfos, typeStr):
	if (typeStr == 'NONE'):
		return -1
	for idx in range(numInfos) :
                if infoGetter(idx).getType() == typeStr :
                        return idx
	idx = gc.getInfoTypeForString(typeStr)
	pyAssert(idx != -1, "Can't find type enum for type tag %s" %(typeStr,))
	return idx