second type of hill or peak

[keldath]

hi,

is it possible to create a second type or a hill terrain?
with the ability to change this new types height? just like you can change the hills and peaks in the terraininfo.xml?

this is for dune wars, and of course every other mod.

can anyone help?


thanks!

 

[EmperorFool]

There are four terrain types: water, flatland, hills, peak. I expect you could add a fifth, but there are a lot of places in the code where I've seen isHills() and isPeak(), and you'll need to add code in many of those places (at least inspect them all) to handle your new type.

 

[keldath]

mm figured that much,

im now coder,

but its probably a long long complicated work to add a fifth huh?


thanks for the answer.

 

[EmperorFool]

I think it depends on how you want it to act. If you want a new type that acts like a hill 95% of the time with only a different elevation, you may be able to get by having isHills() return true for both terrain types (hills and your new one). Can you be more specific about your needs?

 

[keldath]

well,

my need is having another elvated terrain feature, thats all basically,

so, i can have different heights for 2 set of hills.

its for dune wars, i wanna "decorate" the terrain with a different elevated terrain,
right now we are using mountains as "hills",
and hills, for sunken terrain, so having another set of higher hill/mountain can add to the terrain.

 

[EmperorFool]

Well, since these new hills won't act like your current hills (sunken terrain) you may have trouble. You could create a duplicate peak with a lower elevation though. It would be considered a peak by the game for other checks, and you'll need to search the SDK for places that use TERRAIN_PEAK specifically instead of CvPlot::isPeak().

 

[keldath]

humm..


say i go through the sdk, where i see a hill code i duplicate it to - hill2,

will taht create a second hill?

 

[EmperorFool]

I don't know, but here's how I would figure that out.

1. Find out everywhere that PLOT_HILLS is used. This is the constant that states that a CvPlot is a Hill.

In Visual Studio, open CvEnum.h and find PLOT_HILLS. Right-click it and select Find All References.

cvenums.h(680): PLOT_HILLS,
cvgame.cpp(1193): pLoopPlot->setPlotType(PLOT_HILLS);
cvgame.cpp(1938): pLoopPlot->setPlotType(PLOT_HILLS, false, true);         
cvplot.cpp(4777): return (getPlotType() == PLOT_HILLS);
cyenumsinterface.cpp(494): .value("PLOT_HILLS", PLOT_HILLS)

Good, only five and the first one is the line we're looking at, and the last one just exposes the constant to Python. That leaves just three places to check for this step. The fourth one looks suspiciously like the entire implementation of CvPlot::isHills(). I'll let you check out the other two.

2. Do the same thing for CvPlot::isHills(). This produces 44 hits in the SDK code. I'm not going to paste them here because a) you can do this yourself and b) VS makes you copy them one-by-one (way to be awesome MS).

For each of these you need to figure out what to do. Don't call it Hills2! DFIHSI would make a better name. Okay, maybe not DFIHSI, but how about PLOT_SUNKEN? Instead of using HILLS for your sunken and HILLS2 for your hills, just make a new type for sunken terrain. I know, I'm totally brilliant!

Let's take a look at one example from the returned references list: CvPlot::seeThroughLevel(). You could amend it like this:

int CvPlot::seeThroughLevel() const
{
	int iLevel;

	FAssertMsg(getTerrainType() != NO_TERRAIN, "TerrainType is not assigned a valid value");

	iLevel = GC.getTerrainInfo(getTerrainType()).getSeeThroughLevel();

	if (getFeatureType() != NO_FEATURE)
	{
		iLevel += GC.getFeatureInfo(getFeatureType()).getSeeThroughChange();
	}

	if (isPeak())
	{
		iLevel += GC.getPEAK_SEE_THROUGH_CHANGE();
	}

	if (isHills())
	{
		iLevel += GC.getHILLS_SEE_THROUGH_CHANGE();
	}

[B][COLOR="Red"]	if (isSunken())
	{
		iLevel += GC.getSUNKEN_SEE_THROUGH_CHANGE();
	}[/COLOR][/B]

	if (isWater())
	{
		iLevel += GC.getSEAWATER_SEE_FROM_CHANGE();
	}

	return iLevel;
}

 

[hachejay]

i know this is an old post, but did anyone ever have any success with creating a new plot type? i've been trying something similiar for Civ4Col here http://forums.civfanatics.com/showthread.php?t=410289 and I can't seem to get it to work. Is is definately possible to define new plot types at all does anyone know?

 

[KJ Jansson]

I am not a professional programmer and not even a fan-programmer. Therefore, I beg your pardon if I say nonsense.

I guess the problem of "second type of peak" can be solved in Python when you start your game.

The logic in this case, perhaps such.

Let's take a point (X, Y)

- if point (X,Y) is TERRAIN_PEAK

AND

- if at least 3 (for instance) neighbouring tiles is also TERRAIN_PEAK

THEN

point (X,Y) is TERRAIN_HIGH_PEAK.

For TERRAIN_HIGH_PEAK should be
- a special graphics ART_DEF_TERRAIN_HIGH_PEAK in CIV4ArtDefines_Terrain.xml
- some features of TERRAIN_HIGH_PEAK in CIV4TerrainInfos.xml, for instance

			<bImpassable>1</bImpassable>

- a short description of TERRAIN_HIGH_PEAK in ...XML/TEXT/ directory.

Here you have no problems "how high a peak". Your HIGH_PEAK just has a new and different graphic and a new feature as Impassable for units.

Here there is a lot of high quality professional programmers who help you realize this method, if this idea is not full nonsence, of course.

 

[hachejay]

I do see what youre getting at, but the problem with defining the new mountain as a TERRAIN_PEAK not a PLOT_PEAK is that the ART_DEF_TERRAIN_PEAK file only contains art information about the texture, so it would still look pretty much like a mountain.

Defining a feature to go on it is a good idea, like maybe a FEATURE_ICE_CAP or something which could have a model that kinda hackerily extends the mountains or something, and then make it impassable. I could certainly do that.

As for creating new plot types my searches for any references in the XML, Python or SDK to the heightmaps have fallen short, so methinks for now I'm gonna have to give up, and find other sneaky ways around it!

 

[phungus420]

Plot types (not terrain types) are explicitly loaded into CvEnums, and referenced in the dll as these explicit enum values. This is why there is very specific behavior regarding peaks. If you are going to add a new plot type this will need to be reflected in CvEnums, CyEnumsInterface, and CvPlot, as well as the XML stuff you add to terrainInfos in the XML. Looking at the code, you may also need to tweak the function setPlotType in CvPlot to ensure your new enum type is used for this new plot type; but it may very well take care of itself (not sure and I don't feel look looking at that function's code any more in depth).

 

[hachejay]

i can create the new plot type fine:



The problem is that nowhere in the sdk does it seem to link references to plot types and height maps, so the new plot type, while functioning correctly, appears no different to PLOT_LAND, as you can see in the screenshot.

I've looked at the setPlotType function, but I didn't need to alter it to get a plot working as above, and nowhere in it does it seem to reference any plot types other than water or coast at all. I've also searched other things referenced in the function to see if they lead on to plot types elsewhere but they don't seem to to me.