Multi Feature Mod

[ls612]

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).

I'm confused then. I thought he wanted to add underground features and underwater features and then add those to maps with his SDK map generator. If this is just an internal representation of the map building process then yes, you are correct. However, I am unsure as to what exactly he wants to do.

 

[Hydromancerx]

@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.

Well underground/underwater maps would be influenced by the surface map. Such as where oceans are the seabed would be. Where land is the crust would be. Where volcanoes were placed then magma chambers would be under them. Likewise where caves are placed on the surface cave tunnels would be connected under. Other stuff like caverns, water tables, cold seeps, sea trenches, etc would be generated like surface map features do. Same goes for any underground/underwater resources.

 

[primem0ver]

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).

Well... in a sense you are both right. The underground map can show the groundwater that exists (but wouldn't necessarily be visible) on the land map. However, AIAndy's vectors make this point moot from the above ground sense.

 

[primem0ver]

Well underground/underwater maps would be influenced by the surface map. Such as where oceans are the seabed would be. Where land is the crust would be. Where volcanoes were placed then magma chambers would be under them. Likewise where caves are placed on the surface cave tunnels would be connected under. Other stuff like caverns, water tables, cold seeps, sea trenches, etc would be generated like surface map features do. Same goes for any underground/underwater resources.

This is fairly accurate. The generator will focus on all layers for its own tracking and calculation purposes but those layers are in a sense kept separate from maps of layers. The only layer that will be directly affected (at least for now) is the surface layer.

However, as the layers feature evolves, the data generated by the engine can be used to construct the underground map as well. In the end Hydro is correct... the two maps will correspond to each other with features from the lower map being the cause (or effect) of the surface map.

 

[Thunderbrd]

This is fairly accurate. The generator will focus on all layers for its own tracking and calculation purposes but those layers are in a sense kept separate from maps of layers. The only layer that will be directly affected (at least for now) is the surface layer.

However, as the layers feature evolves, the data generated by the engine can be used to construct the underground map as well. In the end Hydro is correct... the two maps will correspond to each other with features from the lower map being the cause (or effect) of the surface map.

So that would make it easy for us to generate our first multi-map then Upon which, all tests can be run. We can design portal methods (cave entrances to subterrainean) and directly corresponding movement from one map to the other (subs submerging to lower waters). And developing the ability to HOLD that information as a second map and refer to it graphically and separately and containing what's happening on it within the understanding of the game engine.

 

[Hydromancerx]

So that would make it easy for us to generate our first multi-map then Upon which, all tests can be run. We can design portal methods (cave entrances to subterrainean) and directly corresponding movement from one map to the other (subs submerging to lower waters). And developing the ability to HOLD that information as a second map and refer to it graphically and separately and containing what's happening on it within the understanding of the game engine.

Ironically we do not have the graphics for it. The image I posted was mostly Photoshoped or used other tiles (ex. Mars terrain for Magma).

- Pic1
- Pic2

 

[primem0ver]

Pic 2 is much more accurate in terms of what it should look like. I am a bit curious what a brine pool is...?

 

[Hydromancerx]

Pic 2 is much more accurate in terms of what it should look like. I am a bit curious what a brine pool is...?

http://en.wikipedia.org/wiki/Brine_pool

A Brine Pool is a place with super salty water that sinks to the bottom of the ocean and appears like an underwater lake.



This image is underwater. Above is normal ocean water and below is super salty water that is 4 or 5 times saltier than normal sea water.

 

[ls612]

So that would make it easy for us to generate our first multi-map then Upon which, all tests can be run. We can design portal methods (cave entrances to subterrainean) and directly corresponding movement from one map to the other (subs submerging to lower waters). And developing the ability to HOLD that information as a second map and refer to it graphically and separately and containing what's happening on it within the understanding of the game engine.

Or harder to make that our first multi-map. Because it uses a completely new system of map generation AND it would have to be very closely tied to an existing map, I suspect it would be more complex to have underground as our first multi-map, as opposed to the moon or Mars, which can just be made from a mapscript independently of whatever is in the Earth map. That and I really want to have the Galactic Era stuff added, so I personally would also vote against Underground as the first new map.

 

[Nimek]

Personaly i dont like underground map idea. It sounds like a tale not a something real that you will able to build undergroun city (joutney to the center of the earth?)

Also i see a lot of programming issues
- tile improvements like geothermal factory should be placed on both maps what when you have undergroun city ongeothermal factory above.
- underground nuke explode what effects to surface
- border share
- attack from undergrund to surface
- AI teaching
- moving units bettween maps. Goto calculations
- messages system for undergroun events (auto switch map or not)
-

It will cost a lot of work and it will be endless work that can be put on galactic era and better ideas of current game system development.

 

[Libertalia]

Personally i don't like underground map idea. It sounds like a tale not a something real that you will able to build underground city (journey to the center of the earth?)

Sorry to contradict but it's not only tales in Turkey they have build/dig some underground cities. The most famous is Derinkuyu it's an ancient multi-level underground city. With its five floors extending to a depth of approximately 60 m, it was large enough to shelter approximately 20,000 people together with their livestock and food stores. It is the largest excavated underground city in Turkey and is one of several underground complexes found across Cappadocia.
more on wiki http://en.wikipedia.org/wiki/Derinkuyu_Underground_City

 

[Thunderbrd]

There's also a network of caverns and tunnels, many of which having perfectly smoothed out and squared walls indicating significant improvements by dwelling denizens, that is so extensive it makes the Subterrainea of South America a literal swiss cheese. The Brazilian army attempted to map them all out and gave up after their soldiers found the system so endless they simply could not bring enough resources with them to complete the journey to wherever the extent of the system led to.

I guess South America had all that gold from some kind of ancient or prehistoric mining activities. And the signs are clear throughout all continents that many early habitations of man stretched deep under the earth.

Now... that said, I can concede on ls612's point about priorities. However, IF it makes it EASIER to make that our first multi-map, consider that its also the first one that players would encounter and utilize during any given game, therefore it would affect all eras, particularly once submarines come into play.

Those points about how many issues it brings up in coding are all good points to consider but many overlap into other multi-map considerations too. And nothing there seemed toooo tough to solve.

 

[ls612]

There's also a network of caverns and tunnels, many of which having perfectly smoothed out and squared walls indicating significant improvements by dwelling denizens, that is so extensive it makes the Subterrainea of South America a literal swiss cheese. The Brazilian army attempted to map them all out and gave up after their soldiers found the system so endless they simply could not bring enough resources with them to complete the journey to wherever the extent of the system led to.

I guess South America had all that gold from some kind of ancient or prehistoric mining activities. And the signs are clear throughout all continents that many early habitations of man stretched deep under the earth.

Now... that said, I can concede on ls612's point about priorities. However, IF it makes it EASIER to make that our first multi-map, consider that its also the first one that players would encounter and utilize during any given game, therefore it would affect all eras, particularly once submarines come into play.

Those points about how many issues it brings up in coding are all good points to consider but many overlap into other multi-map considerations too. And nothing there seemed toooo tough to solve.

And even if there was no historical subterranean inhabitation, we can always make it possible in the future eras. I see no reason why you couldn't have mining colonies a thousand miles down by the mid TH era.

 

[Dancing Hoskuld]

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):

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).

I am assuming that the following will remove a particular feature from the plot

		if pPlot.getHasFeature(iFeatureType):
			plot.setHasFeature(iFeatureType, False)

 

[Thunderbrd]

I would think that would work, yes. Perhaps.

Probably better if you:
"If you need to set a main feature, use setFeatureType (and mind that it replaces the old main feature)."

The secondary features are not graphically displaying yet so I don't think they are used much. But if you wanted to and were working with an 'invisible' secondary feature in the first place then setHasFeature would work. I believe your check of getHasFeature should still work to properly filter the function though.

However, setFeatureType needs a feature so it's setFeatureType(FeatureTypes eFeature, int iVariety = -1)

You don't have the ability to set it false so what you'd do is set it to -1 (the value of NO_FEATURE). That would remove any existing 'primary' feature, replacing it with NO_FEATURE.

 

[raxo2222]

I saw this in Modders Documentation. It sounds like nice thing.

Is it even implemented?

 

[Dancing Hoskuld]

It is/was but it caused some graphical glitches so we didn't use it. At the time we did not have a graphics person to fix the problems either.

 

[Thunderbrd]

It isn't now. I disabled it a while back due to some crashes it was causing and yes, the graphics were sometimes an issue. It could be turned back on but without the graphics for additional features it's hard to say if it would be truly useful for us.

 

[pepper2000]

I had no idea about this. Even if secondary features have no graphics but just textual display, it sounds like the system could be used as a small amount of general purpose data on plots, which would be very useful in implementing the hyperspace exploration system I have been thinking about.

 

[Thunderbrd]

I had no idea about this. Even if secondary features have no graphics but just textual display, it sounds like the system could be used as a small amount of general purpose data on plots, which would be very useful in implementing the hyperspace exploration system I have been thinking about.

Wouldn't be terribly difficult to reinstate then. And I'm probably fully capable of debugging the crash it created that caused it to be turned off. Can't say I can get to it RIGHT away though.