Terrain Art Defines?

[primem0ver]

I want to add more terrain types. Not plot types such as hills, mountains, etc because I know that isn't possible. I simply want to add more variety to the types of plots such as savannah, mud, etc...

I know where to add the terrain defines. However, the art is a problem. I cannot find the Art defines file for terrains. Is it possible to add Art defines for terrains in XML or even the database files?

 

[Nutty]

Just a couple concepts:
XML or SQL is how you get stuff into the Database or change existing stuff. They're different syntaxes to accomplish the same thing (though you can do more complicated manipulation with SQL syntax). For the most part (with the exception of the Localization database), you can't use Lua to update the database after a game is loaded.

Terrain is technically what you call "plot types." Features are what you're calling terrain. There are also FakeFeatures (rivers and lakes), Resources, Improvements, and Routes (roads and railroads).

All of these are Landmarks, and you'll find the art defines in ArtDefines_Landmarks.

I haven't tried to add TerrainTypes, so I don't know whether it's possible or not, but, yes, FeatureTypes can be added (with new art) with the caveat that most of them can't visibly be changed during the course of a game without having to save and reload the game to update the 3D map (though the tooltips and the Strategic View update properly).

The problem is adding your new features to the map. AssignStartingPlots.lua is a mess, and you'll be incompatible with other mods that edit it, but I think that's the only option for Features (as opposed to e.g., Resources, which could be adjusted after the fact). Note that there are a few threads that can be found that describe attempts to edit it that you might find useful.

 

[primem0ver]

Hello Nutty, thanks for responding.

Just a couple concepts:
XML or SQL is how you get stuff into the Database or change existing stuff. They're different syntaxes to accomplish the same thing (though you can do more complicated manipulation with SQL syntax)

Yeah... I did a lot of Civ IV modding so I know how to use the xml though the sql stuff is new.

Terrain is technically what you call "plot types." Features are what you're calling terrain. There are also FakeFeatures (rivers and lakes), Resources, Improvements, and Routes (roads and railroads).

Actually... no. I meant terrain types. There are the standard 4 terrain types that are also the 4 basic plot types. The PlotTypes enumeration that goes along with this is found in CvEnums.h for both Civ 4 and Civ 5.

TERRAIN_HILL
TERRAIN_MOUNTAIN
TERRAIN_COAST
TERRAIN_OCEAN

Then there are the rest of the terrain types which are overlays for hills and flat lands.

TERRAIN_GRASS
TERRAIN_PLAINS
TERRAIN_DESERT
TERRAIN_TUNDRA
TERRAIN_SNOW

I have discovered that CvEnums.h for Civ 5 has all these terrains explicitly enumerated. So are features. This is different from Civ 4 and presents a potential problem...

A plot can have both a terrain type assigned and a second terrain type IF AND ONLY IF one of the terrain types is marked with the "graphical only" tag set to true. (I am assuming that the terrain type for these is translated to a plot type by the executable)

All of these are Landmarks, and you'll find the art defines in ArtDefines_Landmarks.

The terrains are not defined in landmarks. After writing this I did discover they have a define in Art Defines located in the strategic view part of the database.

I haven't tried to add TerrainTypes, so I don't know whether it's possible or not, but, yes, FeatureTypes can be added (with new art) with the caveat that most of them can't visibly be changed during the course of a game without having to save and reload the game to update the 3D map (though the tooltips and the Strategic View update properly).

I am glad for this but do I need to make a dll change in order to handle the new feature types? I wonder because of the explicit layout of feature types in CvEnums.h. I may be able to turn some of my ideas for "terrains" into features but not all of them so I am still concerned with terrain types.

I haven't been able to find any examples but I am assuming that altering terrain types is similar to altering feature types except that there no art pieces that directly correspond to the names. Instead we have [TerrainType] folders and [TerrainType Hill] folders that contain sub folders America, Africa, Asia, and Europe. These have a bunch of dds's but I cant find where theses are referred to anywhere in the db files. If they are hard coded, then it may be impossible to create new terrains which severely hampers Civ 5's usability for my project (to implement a realistic terrain generator) and I probably wasted my money.

The problem is adding your new features to the map. AssignStartingPlots.lua is a mess, and you'll be incompatible with other mods that edit it, but I think that's the only option for Features (as opposed to e.g., Resources, which could be adjusted after the fact). Note that there are a few threads that can be found that describe attempts to edit it that you might find useful.

Hmm... well that means that I will need to combine any desired lua files that edit it. We will see about that later. I am not concerned with adding the terrains to the map because that will be hard coded by the generator.

 

[primem0ver]

I just noticed that features which are "wonders", (unique ones in particular) often have the same folder structure as terrains. So maybe they are moddable... I would just like to know for sure and know how. I can probably use any wonder mods as a starting point.

 

[Nutty]

I was talking about database nomenclature, where you're talking about C++ nomenclature. Your generator will be part of a DLL mod?

In any event, you're right that terrain appears to be hardcoded. Mud seemed like a feature to me (like marsh), though I guess Savannah is an alternative to plains/grassland.

I have an idea... Since you're making a DLL mod, maybe you can do something crazy with your generator so you can use a new class of "sub-terrains" where the art side sees it as, e.g., African grassland (using reskins where necessary), but you've otherwise differentiated it with your DLL so each continent + terrain can be assigned different stats.

 

[primem0ver]

I have an idea... Since you're making a DLL mod, maybe you can do something crazy with your generator so you can use a new class of "sub-terrains" where the art side sees it as, e.g., African grassland (using reskins where necessary), but you've otherwise differentiated it with your DLL so each continent + terrain can be assigned different stats.

You are on the right track in your post. Yes... it is a dll mod. And yes... it does what you are suggesting by design (I will explain below). However, I do not know how the "African" versus "American" etc... is differentiated. There don't appear to be any references to it in the XML or the database. I am brand new to Civ 5 and used to Civ 4.

As for how it will work, I came up with the basic model/framework a few years ago. The original thread regarding this project (which has been on hiatus for a couple years) is here, in the Caveman 2 Cosmos (Civ 4) mod project forum. I further explained/developed the approach to biomes and terrains here. Below is the basic idea of how "layering" terrains and features work to produce the biomes involved.

Basic Summary of Concepts
Terrains represent soil and micro-vegetation types.
Features represent any vegetation that is bigger than around 2 feet tall.

Soil types/Terrains (in non-scientific biome related terms)

1. Wet Grass (not very rich...but lots of foodstuffs in micro-vegetation such as berries etc...)
2. Boreal Grass (for moist arctic environments that have long winter season)*
3. Dry Grass - shorter (Basically plains. Average to good richness... but exists in semi-arid environments so not much rain).
4. Rocky (very little soil)
5. Forest Floor (plains like.... but has some green mixed in because of ferns and similar micro-vegetation. May need 2 types)
6. Jungle Floor (all "food" value comes from organic debris that litters the floor).
7. Volcanic soil (dark, extremely rich in food value).
8. Chaparral (has desert like micro-vegetation that exists in arid regions)
9. Savannah (Wet-dry region soil. Could use plains for this... and just add a new vegetation).*
10. Mollisol (similar to Savannah but more rich because dry seasons are less dry and wet seasons are less wet).
11. Mud (Has almost no food value because nutrients have been leeched by constant rains. Occurs when tropical rain forests (jungle) are torn down. I am guessing this is impossible to do in Civ V because terrains cannot be updated in game)*
12. Permafrost (basically tundra without any vegetation at all)*
13. Dunes - basically very dry desert

* may not need.

Vegetation Feature Types

1. Tall grass (2 different types)
2. Coniferous forest (aready exists.... but are their both evergreen and regular like in Civ 4?.... this would be the evergreen type)
3. Deciduous forest (already exists?)
4. Boreal forest (already exists? Do snow textures appear on northern evergreens?)
5. Sparse deciduous trees
6. Mixed forest (both evergreen and deciduous)
7. Jungle (already exists)
8. Swamp (basically the same as marsh... except with trees added. Can marsh and trees exist on the same plot?)

So... is this possible to implement using your suggestion (with reskins of existing terrain variety graphics) and adding features? Without any knowledge of how the terrain variety (sub-terrains) work, I would not know how to do this at the moment. One significant issue with sub-terrains though is that the different soil types have different yield values. So there would be far more than 5 different mixes of differing yield values. Can this be done?

 

[Nutty]

Interesting!

To be clear, the sub-terrain concept would be a new system that you'd implement in your DLL that'd basically move all of the terrain yield modifier stuff into another hierarchy (which I'm calling sub-terrain for want of a better word). From the yield point of view, terrains in and of themselves would become meaningless, but exist only for the sake of the graphic engine.
You're co-opting the continental art style system (which means all continents will now look the same), but that gives you 3 additional "slots" for each terrain type (i.e., up to 4 kinds of grassland, 4 kinds of plains, etc.). Of course this is only from the database's point of view. You can do whatever you want with what the user interface displays (so no one has to know that the Permafrost sub-terrain is actually just Asian tundra, or whatever).

 

[primem0ver]

So basically you are saying it would be possible to do... but I would be stuck with the 5 native yield amounts for the 5 terrain types. Changes would need to be based on features that exist on the tile.
Correct? Or is this wrong?

 

[Nutty]

Worst case you could make this work (potentially using Lua alone) by making adjustments after-the-fact, but in this case my idea is that you re-code the yield table lookups for terrain yields to look for a new sub-terrain table. The table also defines a relationship between the sub-terrain and a parent domain and continent art style.

EDIT: Actually, the yield stuff is all in child tables. I guess you can just redefine the foreign keys of those tables to point to the sub-terrain table instead...
EDIT #2: Though I imagine you'd still want to move the lookups for the other columns (FoundFreshWater, BuildModifier, etc.) to your new table for flexibility purposes.

 

[primem0ver]

Ok. I am not inclined to use LUA alone. I really don't know scripting languages that well and the algorithms used to figure out the map are way to complex to use LUA.

Another comment: the plan has always been to do the processing "after the fact" as you say. This project is already incredibly complex. I don't want to have to worry about actually creating the map itself and having to provide the variety of different types of maps that the map scripts do. The project relies on the possibility that I can grab the map just after it is created in lua and before it gets passed to whatever graphics code deals with it. That is when my code will execute and apply calculations that make the terrain more realistic.

So speaking of your suggestion.... I could get a way with doing that? Adding another XML file that defines subterrains and have the plot yields be returned from that table? That would be perfect.

I added XML files for several things in the Civ 4 mods I created but the integration of SQL and the database makes me uncertain about Civ 5. A few quick questions/comments on that topic:

1. Would the database engine import new XML files?
2. What about new tags? If I add tags to the current xml, would that create a problem? Or could the engine import the new tags?
3. I realize that if the answer to the both of the questions above is no, I can still import my own xml using an xml reading class like the one that existed in Civ 4.

 

[Nutty]

Adding data to the database is trivial by setting an Action in the mod's properties in ModBuddy (part of the SDK) to OnModActivated > UpdateDatabase for the .XML or .SQL file in question.
By tags I assume you mean adding columns to an existing database table? Also trivial, though you'd probably want to use SQLite syntax to use the ALTER command (same thing as above with setting a .SQL file OnModActivated > UpdateDatabase). The XML syntax doesn't have an equivalent.

Untangling the DLL's spaghetti code is the non-trivial step.

 

[primem0ver]

Untangling the DLL's spaghetti code is the non-trivial step.

Civ IV wasn't too bad though I don't know how they compare. The nice thing about this mod though is that only two things need to be "changed" in the current DLL. The rest is added/completely new.

1. A command that calls the new map algorithm needs to be inserted between the code that calls LUA (to create the map), and whatever comes next (presumably the step to initialize the graphics based on the map before beginning the game).
2. The code that formats the text shown for plot details/statistics.

 

[Nutty]

...and, of course,
3. Changing the database calls for the Terrains table to refer to your new sub-terrains table instead where necessary