Multi Feature Mod

AIAndy

Deity
Joined
Jun 8, 2011
Messages
3,428
The Multi Feature Mod I wrote months ago is now active on the SVN. Each plot can have any number of features and all of them are displayed as graphics. To keep backward compatibility there is still a main feature and the rest are secondary features. Not all effects of features work for secondary features yet and there are likely bugs so look out for them and report.
Old code uses setFeatureType which will set that as main feature and replace any previous main feature. Similar you use getFeatureType on the plot to get the main feature.

There are new access methods for code that should be aware of secondary features (they are usable from Python):
Code:
bool getHasFeature(FeatureTypes eFeature) const;
void setHasFeature(FeatureTypes eFeature, bool bHasFeature, int iVariety = -1);
int getNumFeatures() const;
FeatureTypes getFeatureByIndex(int index) const;
int getFeatureVariety(FeatureTypes eFeature) const;
void removeAllFeatures();
While the new code stores varieties, it is actually not possible to supply different varieties for the features on the same plot so only the variety of the main feature will be used and it is recommended not to use feature varieties.
The normal way to loop through all features on a plot is to use getNumFeatures and getFeatureByIndex which also includes the main feature.
setHasFeature always sets the feature as secondary. If you need to set a main feature, use setFeatureType (and mind that it replaces the old main feature).
 
Are you using a feature array to hold which features exist?
 
Two questions about this.

1. Does this mean that we could have "mixed terrain"? ie, we could have a plot be partially Jungle and partially Forest?

2. How does this work in terms of combat modifiers and build prereqs. If you had feature A and feature B on the same tile, would their defense modifiers (and any promotions that give them modifiers) stack or not?

Great work on this, hopefully all of the small bugs will soon be worked out. :goodjob:
 
This is going to be used primarily for weather correct? I don't see why we would need say a jungle and a forest on the same tile. Though I suppose an outcrop and forest could make sense.

I know what it was originally intended to be for, but as with everything in C2C, things usually get extended far beyond their original implementation. :)
 
This is going to be used primarily for weather correct? I don't see why we would need say a jungle and a forest on the same tile. Though I suppose an outcrop and forest could make sense.
It could be used for a lot of things, weather only one of them. Most of the stacking behavior of effects and what does what has not really been decided yet and I have forgotten some of the preliminary decisions I made when I implemented them months ago.

One option would be to add a feature to a highly polluted plot (needs some graphics) that reduces plot health or modifies yield similar to what the properties buildings do in cities (although to avoid too much graphics there should only be one active, like one feature for moderately high pollution, one for very high pollution).
 
Found a limitation of the multi feature mod:
Any tile art feature (in the art define TileArtType of other than TILE_ART_TYPE_NONE) or river art feature (in the art define bRiverArt of 1) can only be the main feature for proper display (otherwise it will not display correctly).
 
I guess by default that actually makes these extra features a great basis for traps.

But what about weather? Does that mean our weather effects cannot have graphics?
 
I guess by default that actually makes these extra features a great basis for traps.

But what about weather? Does that mean our weather effects cannot have graphics?
Eh, no, we can have graphics for all secondary features, they just can't be tile art or river art graphics. Most feature graphics are neither tile art nor river art (check the feature art define if you want to see which are which). Tile art and river art consists of several separate models, that are arranged on the plot depending on the rest of the stuff in the plot.
 
Ah. I see.

Curious... If we were to do a 'rivers down the center' style mod for C2C, would this multi-feature capability come in handy? We could possibly have larger rivers down the middle while tributaries or smaller rivers (not travel worthy but remains an effect on crossing) as the normal ones we have now, could branch off down the edges still. (But then, would this note on the graphics indicate it might not work or since it'd be a new graphic type entirely would it potentially get around the issue?)
 
Ah. I see.

Curious... If we were to do a 'rivers down the center' style mod for C2C, would this multi-feature capability come in handy? We could possibly have larger rivers down the middle while tributaries or smaller rivers (not travel worthy but remains an effect on crossing) as the normal ones we have now, could branch off down the edges still. (But then, would this note on the graphics indicate it might not work or since it'd be a new graphic type entirely would it potentially get around the issue?)
That would need some testing and there would need to be models to get from the center large rivers to the smaller rivers between tiles.
 
I have been busy working on the GeoRealism mod and I am posting an update today. I wanted to suggest something for this "multi-feature" mod that will conserve memory and processing.

I am not sure how you are managing to get the graphics engine to draw multiple features on a single plot but if you have that working, then I am going to suggest this:

lets limit the number of features to the number of "spheres" that exist within the geographic earth system. One feature per sphere. The five geologic spheres are (I slit the lithosphere into 2 parts):

1. Lithosphere (underground - for things like groundwater, etc)
2. Lithosphere (surface - for things like rock formations)
3. Hydrosphere (water sphere)
4. Biosphere (which would include vegetation features)
5. Atmosphere (for storms, hurricanes, etc...)

This would make it very compatible and easy to integrate into the GeoRealism component I am developing, conserve on memory (no more large feature arrays for every plot if that is how you are doing it), and conserve on processing (no more searching through arrays for the one you want).
4
 
I have been busy working on the GeoRealism mod and I am posting an update today. I wanted to suggest something for this "multi-feature" mod that will conserve memory and processing.

I am not sure how you are managing to get the graphics engine to draw multiple features on a single plot but if you have that working, then I am going to suggest this:

lets limit the number of features to the number of "spheres" that exist within the geographic earth system. One feature per sphere. The five geologic spheres are (I slit the lithosphere into 2 parts):

1. Lithosphere (underground - for things like groundwater, etc)
2. Lithosphere (surface - for things like rock formations)
3. Hydrosphere (water sphere)
4. Biosphere (which would include vegetation features)
5. Atmosphere (for storms, hurricanes, etc...)

This would make it very compatible and easy to integrate into the GeoRealism component I am developing, conserve on memory (no more large feature arrays for every plot if that is how you are doing it), and conserve on processing (no more searching through arrays for the one you want).
4
That would not save much of anything as it uses a std::vector that just stores the features that are on a specific plot so it won't get large anyway. No need for an artificial limit. Still, categorization of features (in the feature info XML) might help for some gameplay code.
 
That would not save much of anything as it uses a std::vector that just stores the features that are on a specific plot so it won't get large anyway.

Good to hear! Have you done that with any other unneeded arrays in the game's original programming?
 
Good to hear! Have you done that with any other unneeded arrays in the game's original programming?
Not a lot. The ones that would deserve it the most are also accessed from a lot of places and for that change to work properly you should also change the access pattern.
 
@primem0ver:

I think the current plan is to have underground/underwater stuff in it's own multiple map in the future, so you may not want to have the features categorized that way. I think we'll be able to categorize terrain, features, and resources by map in the future, so unless this is only for internal purposes during the map generation you may want to rethink the implementation of the five features idea.
 
@primem0ver:

I think the current plan is to have underground/underwater stuff in it's own multiple map in the future, so you may not want to have the features categorized that way. I think we'll be able to categorize terrain, features, and resources by map in the future, so unless this is only for internal purposes during the map generation you may want to rethink the implementation of the five features idea.
Neither underground nor underwater stuff has anything to do with the categories/spheres he posted (at least not in a way that would lead them to be placed on some different map).
 
Back
Top Bottom