@Koshling, if you think it is reasonable, I can start looking seriously on those IDInfo-s. But when I would start to code, I will require to no one touch the parts directly connected with ids. From details, I would like to know, does the engine communicate with us by pairs - player's id, object's id and the structure of IDInfo is fixed. Or rather by IDInfo-s and it take them from us, so we can set the structure as we want? Or the communication goes though Python and we can totally manipulate everything?When seeing all those "Exposed to python"-s, have some feelings about that. But maybe there are some mysterious paths impossible to be seen by mere mortals.
Btw, wouldn't be wise to switch the topic of the thread to "Spam, development talks and eventually Single Player bugs and crashes - After the 13th of August 2013"? Or in the last resort to open a thread for development?![]()
Let's open a development thread.
You're welcome to experiment with trying to find a better replacement for the IDInfo's, but I would caution that they are pretty deeply embedded throughout the code, and not always in nicely encapsulated ways I suspect. In particular:
1) They ARE used in the API to the game engine (e.g. - see CvDLLInterfaceIFaceBase.h), so they would need some sort of an adapter wherever those interfaces are used. It is **possible** that the game engine only uses them opaquely and just hands them back (so no adapter would be needed), but I have no evidence to support that, and frankly I doubt it.
2) They ARE passed to Python in a few APIs (e.g. - CyGetCity() in CyGameCoreUtils.cpp)
3) In order to retain save game compatibility you'll have to dehydrate/re-hydrate whatever structure you change it to a compatible format in the read/write routines used on persisted objects
4) Pointers are not reliable across turns (or even within turns across processing of different units sometimes) - if you went to something pointer-based, you'd have to reference count or (more probably) indirect via some sort of handle that can be reliably cleaned up on unit/city destruction
I would question the motivation for doing this, given the scale of changes that will likely be required - profiling doesn't suggest that it's a major overhead (though it's admittedly widespread and granular enough that it might no be obvious from profiles). However, I have no issues with (and indeed would encourage) you experimenting, since I could be proven wrong and a new pair of eyes and hands (and a new brain!) is always welcome.