primem0ver
Emperor
This may be something I should post in a general form but for now I think it is most appropriate here since we have a large number of developments underway.
IMPORTANT NOTE: This will be a rather technical discussion mainly for SDK modders.
During my work in on the GeoRealism mod (and in previous work on other mods) I have wondered why Firaxis didn't propose a way of consolidating XML by putting info classes into temporary groups for the purpose of quickly and easily assigning values without the inordinate amount of XML we find in the info files.
For example, my current need in the GeoRealism mod is to associate the odds a vegetation type (and a bedrock/geography type) have to produce a particular bonus. Given the amount of bonuses in this mod, using the traditional Civ XML/Info method this would take a LOT of unnecessary XML since the odds for groups of bonuses are the same. Traditionally I would have to define those odds for each and every bonus. I can't use bonus classes to get the job done since the purpose for bonus classes is significantly different.
What's more is that any info class used to group infos would only need to exist at XML loading time since their purpose is to streamline associating a particular info class (such as bonuses in the example) with a certain piece of data (such as odds in the example) and linking that association to a second info class (such as vegetation types in the above example).
So I am proposing a new generic base class to be used in the SDK's CvInfo.h and CvInfo.cpp files. There will also be an associated enumeration for handling derived types that will also be defined in the CvInfo.h file since there is no need to use it anywhere else.
The CvVolatileInfo class (so named because it is temporary) is an abstract base class that cannot be instantiated since each instance needs to be associated with a specific reference class (which is controlled for using the enumeration). This class will meet the following criteria.
*NOTE: INFO_VECTOR is a struct with two integer fields: iInfoID and iData
The details of the class structure and how it can be used will be kept in the following two posts.
Below is are some examples that show how this class would save coding time, coding space (and therefore loading time), and in the long run modding time (because when you add a new info type it only need be modified in one place rather in multiple lists).
Here is a sample section of a file based on the CvVolatileInfo (keep in mind that the class developer must override the read(...) function which allows for customizing tag names even though they will be read into the same basic structures/variables).
When the above file is loaded, it will access every vegetation on the "SpawnVegetations" list and make an "spawn odds entry" for each bonus on the "Bonuses" list.
There are two ways the above information could have been coded without the Volatile classes. Either within the CIV4VegetationInfos.xml file or within the CIV4BonusInfos.xml file. Theoretically, this could be done with the Volatile info files as well. One would just have to simply reverse the lists. The first, single depth list would be a list of vegetations and the second a list of bonuses to apply the values too. Please pay attention to the comments in each file because they explain the repetition that would be involved and how the above file avoids that repetition.
1. Here is an example of what one would have to have originally done to the CIV4VegetationInfos.xml file.
2. Here is how it would need to be without the volatile info class if one used the Bonus Info file:
IMPORTANT NOTE: This will be a rather technical discussion mainly for SDK modders.
During my work in on the GeoRealism mod (and in previous work on other mods) I have wondered why Firaxis didn't propose a way of consolidating XML by putting info classes into temporary groups for the purpose of quickly and easily assigning values without the inordinate amount of XML we find in the info files.
For example, my current need in the GeoRealism mod is to associate the odds a vegetation type (and a bedrock/geography type) have to produce a particular bonus. Given the amount of bonuses in this mod, using the traditional Civ XML/Info method this would take a LOT of unnecessary XML since the odds for groups of bonuses are the same. Traditionally I would have to define those odds for each and every bonus. I can't use bonus classes to get the job done since the purpose for bonus classes is significantly different.
What's more is that any info class used to group infos would only need to exist at XML loading time since their purpose is to streamline associating a particular info class (such as bonuses in the example) with a certain piece of data (such as odds in the example) and linking that association to a second info class (such as vegetation types in the above example).
So I am proposing a new generic base class to be used in the SDK's CvInfo.h and CvInfo.cpp files. There will also be an associated enumeration for handling derived types that will also be defined in the CvInfo.h file since there is no need to use it anywhere else.
The CvVolatileInfo class (so named because it is temporary) is an abstract base class that cannot be instantiated since each instance needs to be associated with a specific reference class (which is controlled for using the enumeration). This class will meet the following criteria.
- Derived classes are associated with a specific reference class (a class derived from CvInfoBase).
- It associates items in the reference class with a common set of values used by the Info class which makes use of the Specific CvVolatileInfo class (which I will refer to as the "source" class).
- The reference info class items are grouped in a std::vector<int> called "infoIndexes"
- The source class/data value pairs are stored in a std::vector<INFO_VECTOR>* called "infoMatrix"
- Requires the derived class to define the read() function which will allow the use of personalized (derived class specific) XML tags even though these tags will still fill the generic values within the CvVolatileInfo base class.
- Instances are disposable and will (should be) be removed from memory when all XML has been loaded.
*NOTE: INFO_VECTOR is a struct with two integer fields: iInfoID and iData
The details of the class structure and how it can be used will be kept in the following two posts.
Below is are some examples that show how this class would save coding time, coding space (and therefore loading time), and in the long run modding time (because when you add a new info type it only need be modified in one place rather in multiple lists).
Here is a sample section of a file based on the CvVolatileInfo (keep in mind that the class developer must override the read(...) function which allows for customizing tag names even though they will be read into the same basic structures/variables).
Spoiler :
When the above file is loaded, it will access every vegetation on the "SpawnVegetations" list and make an "spawn odds entry" for each bonus on the "Bonuses" list.
There are two ways the above information could have been coded without the Volatile classes. Either within the CIV4VegetationInfos.xml file or within the CIV4BonusInfos.xml file. Theoretically, this could be done with the Volatile info files as well. One would just have to simply reverse the lists. The first, single depth list would be a list of vegetations and the second a list of bonuses to apply the values too. Please pay attention to the comments in each file because they explain the repetition that would be involved and how the above file avoids that repetition.
1. Here is an example of what one would have to have originally done to the CIV4VegetationInfos.xml file.
Spoiler :
2. Here is how it would need to be without the volatile info class if one used the Bonus Info file:
Spoiler :
