C2C - Weather Discussion

That would be interesting to have "weather features" such as ...

- Thunderstorms
- Tornadoes
- Hurricanes
- Sand Storms
- Blizzards
- Wildfires
- Locust
- Floods
- Alien Fungi ;)

All these sound good. It would be nice to see some temporary changes on the map to spice things up. The Wildfires and Alien Fungi are of particular interest because they could be addressed by units. Locust too I suppose.

On the ocean, you could even have a Red Tide and Oil Spills.
 
I remember the mod Fall from Heaven that had blizzard that travelled across the map and turned tiles into tundra or snow.
In Fall from Haven 2 there are events like very cold winter or very dry summer changing some tiles into other forms of terrain for few rounds.
Also in the vanilla game theres an effect of climate change caused by nuclear war.

It all could be merged into something resembling a weather system.

Its just a thought that if such weather events would last few rounds it would be pretty unrealistic for a storm or blizzard to travel across the globe for, say, 200 years. Its not a Jupiter after all :P
 
If 'the modders' are pushing back the start age of the mod to 20,000 BC then I believe that was the end of a mini Ice Age. The Fall from Heaven II Mod scaled back and transformed Ice features year to year I believe and It could possibly be ported to C2C, as well as implemented for seasonal changes and weather patterns. Several mods have implemented this as a 'Winter mod' including the
World History Mod development thread- Kevinman4404 -
http://forums.civfanatics.com/showthread.php?t=262780
Global warming is just the reverse I believe and could also be used as a spring season or El Nino type weather effect.

this is why I created the
Integrating Mods - Incorporating / Exploring Ideas from other mods, thread
http://forums.civfanatics.com/showthread.php?t=439576
so we can track mod components and ideas for future integration.

It really thing it would be interesting to see weather patterns move across the landscape and affect unit strategy.
Winters can stop an army cold!
 
200,000, not 20,000. Though, ice age scripting would still be incredibly useful, of course. Seasonal changes don't really work, unfortunately, given that it takes a long time even in the slowest game speeds to reach a point where turns last 6 months or less. On top of that, there's the difference between the different hemispheres. It only gets worse if you aren't using an Earthlike map, since at least on an Earthlike map you can fudge it by saying Australia/the South Pacific and South America are hot all year round anyway.
 
Looks like Kevinman4400 solved some of the problems with weather, including rain, and changing seasons. The growing/receding ice (wintermod) alone should be looked at; he says he got it working)
Check out his mod work.

http://forums.civfanatics.com/showthread.php?t=233586

PLANNED FEATURES IN UPCOMING MAP RELEASE:

New, highly accurate 255x166 world map~ This map uses a projectionless interpretation of the world, to give near-perfect proportions. However, the Pacific ocean is shrunk to about the size of the Atlantic ocean (and the Aleutian islands are faked). I believe this to be a worthy sacrifice.
New terrains~ All the existing terrains plus fertile and arid plains, wasteland (semi-desert), thinsoil (between tundra and grassland), marsh, and more.
New and modified resources~ 80 to 85 resources in total, and modifications to existing resources. Each will have detailed yields and, if applicable, a purpose.
Wintermod~ Simulates seasonal snowcover, to give a disadvantage to Northern civs, especially before modern times. Also includes Icemod, which simulates the advance and retreat of the ice packs.
Summermod~ Simulates seasons along major desert rivers (ie the Nile), like how flood plains work in real life.
Floodmod~ Simulates flooding along major river outlets, marshes, etc.
Disasters~ Active volcanoes, disaster events, flood events, etc. etc.
Domestication~ A domestication idea for any modders who decide to use my map. These work like techs. You will have to give each to the civ to first really domesticate/use that resource (ie Sumeria/wheat or Olmec/maize).

He posted a screenshot, showing rain working on the map,
and said he would release his incredible map soon.
I recommend people check it out and tell the modders what you think.

This guy would be a great occasional teammate. His vision and flurry of activity is amazing and in sync with C2C. Please let him know he is invited and wanted.

Merry Christmas Everyone!!!!
 
Forgive my ignorance, but how precisely would the seasonal cycles work? Leaving aside issues of how the game engine would handle ice ages and global warming periods, would the seasonal system only start once game intervals reduced to months? How would spring, autumn and the monsoon season be handled? Would the seasons vary based on the hemisphere (I believe Mr. Hydromancerx has come up with a method of handling animal spawns by hemisphere, both north/south and west/east, so it should be theoretically possible).

I'm all in favor of such ideas (especially the new Earth map), but I think it would be good if we could lay down how these things are mechanically implemented and thus how easily they can be integrated into C2C's framework.
 
Not sure. It would have to be periodic.
I like the idea of storms being a strategic factor in the movement of units.
It would bring a nice balance to the game. I also like the idea of a storm front moving across the map.
Weather could make the survival game a lot more interesting in the Prehistoric Era.
Anyone have more ideas how to make this work?
 
Remove the year counter so it can be a simple abstraction of time? Then the weather/time factor would not be an issue
 
Not sure. It would have to be periodic.
I like the idea of storms being a strategic factor in the movement of units.
It would bring a nice balance to the game. I also like the idea of a storm front moving across the map.
Weather could make the survival game a lot more interesting in the Prehistoric Era.
Anyone have more ideas how to make this work?

Well I think one method was making weather units or something. Mainly because you cannot have weather like the hurricanes on land because it is a terrain feature and you cannot have 2 terrain features in one spot.
 
I'm curious about this coding and how it works. AIAndy, could you give us a bit of an explenation on exactly what you're enabling for us? Will we have two distinct layers of features to work with or will we have a second, weather specific layer? Will forests grow into spaces that already have jungles? Will we have new tags to manipulate and be manipulated by the overlapping feature layers? What are the parameters we're working with here?
 
I'm curious about this coding and how it works. AIAndy, could you give us a bit of an explenation on exactly what you're enabling for us? Will we have two distinct layers of features to work with or will we have a second, weather specific layer?
Neither nor. With that code change you can have any number of features on the same plot (like you can have any numbers of promotions on a unit or any number of buildings in a city).

Will forests grow into spaces that already have jungles?
We probably want new tags to prevent that or add some new mechanisms that govern how the growing works.

Will we have new tags to manipulate and be manipulated by the overlapping feature layers? What are the parameters we're working with here?
Instead of using kPlot.setFeatureType(FEATURE_FOREST) (which still works and works like previously, setting a kind of main feature and replacing the old main feature) you can now use kPlot.setHasFeature(FEATURE_FOREST, true) and if you use that while there is previously jungle on the tile then now you have both forest and jungle.
What we use that for is up to us now. Any code parts that still use getFeatureType will only see the main feature (added by using setFeatureType). To check if there is a specific feature on the plot you can use kPlot.getHasFeature(FEATURE_FOREST) but you can also loop through the features with kPlot.getNumFeatures() and kPlot.getFeatureByIndex(i).
 
If we're putting weather in as features, is it possible then to destroy a storm by building a farm? Or do those tags that remove features on certain actions apply only to one layer or any of a specified set of possible tags?

It might be interesting to allow for multiple forests/types of terrain to overlap. This could explain overgrowth or really thick conditions. But I can also see some inconsistencies that might create. Still, tall grass in a forest sounds reasonable, as does a forest overlapping another forest (just greater density). But there'd NEED to be a limit that doesn't then mess with other TYPES of layers. Maybe we just need to define our current terrain features as Terrain feature-types and establish a limit of 2 to exist in any one space.
 
If we're putting weather in as features, is it possible then to destroy a storm by building a farm? Or do those tags that remove features on certain actions apply only to one layer or any of a specified set of possible tags?
Builds that remove features only apply to the "main" feature, the one set by setFeatureType. If you use setHasFeature instead, then it will not be destroyed.
 
So we have the Primary layer, so to speak, and extras that may exist in the same space as well. So we really can't have terrain overlapping because it would end up causing inconsistencies such as a farm not destroying a forest or tall grass because that forest or tall grass is in the extras. This would still work for its intended function anyhow.
 
So we have the Primary layer, so to speak, and extras that may exist in the same space as well. So we really can't have terrain overlapping because it would end up causing inconsistencies such as a farm not destroying a forest or tall grass because that forest or tall grass is in the extras. This would still work for its intended function anyhow.
In the end we have to decide how we want it to function and then change the behavior of the code to fit that. Currently the tags specify a build as removing features or as not removing features. If we only want specific features removed we need to adapt the tags for the builds.
 
In the end we have to decide how we want it to function and then change the behavior of the code to fit that. Currently the tags specify a build as removing features or as not removing features. If we only want specific features removed we need to adapt the tags for the builds.

I am hoping to be able to use this for shipwrecks, since I can't do in in a "good" way currently.

Shipwrecks may occur when one or more ships sink in a plot due to storms or attacks. They should not be removed when you build a fishing fleet or other improvement. They may be removed when you explore them after "deep sea exploration" or they may become a tourist attraction.

Which... OK as I was typing I realised that improvements can have adjustments with features so if I have a fish resource with a fishing fleet and a dive wreck (after explored ship wreck) then I can give the improvement both extra food and commerce from the extra feature. Which reminds me that a fishing fleet should get bonuses if built on a kelp bed - something we are not doing at present.
 
Repeating suggestion from another thread (per rightfuture's request) that the End of Ice Age function from FFH2 be used for nuclear winter/comet collision/whatnot.
 
Back
Top Bottom