Mountain yields

[lordrune]

First of all! -> I don't like Erebus mapscript and I dislike it's bundling with FfH as much as I dislike the bundling of Internet Explorer with windows!

Second of all, I said a low percentage. Very low if required.

I used to play Erebus a lot - it was entertaining although I appreciated the balance concerns - until I discovered Tectonics maps, and since then, I haven't really looked back. The variety in the terrain is just great, and the desert/jungle/plains/etc. areas in the map are more blended.

Mind you, there are still stages in Tectonics maps where I can see working peaks as an option, as well. Again, a very low percentage of times, but enough that I'd support putting the option in, in recognition of flavour and assuming it's not a really difficult change to do.

But I'm not really keen on the idea of changing an impassable tile to a passable one by levelling peaks.

 

[the_fish]

The only map that features enough peaks so that a city could actually work more than 1 or 2 is erebus. And the only civ this would affect would be the Khazad (The Luchuirp being open skyers and all that lore stuff). And said civ already starts with a plethora of plains hills in the given mapscript which are better than mountains, so this really wouldn't help them too much. So, it would only have a bareley perceptible effect on one civ on one map, and said civ will most likeley fail on said map anyway because of the crapulent starts on that map. No other map has a mountain density large enough for this feature to matter. So don't delude yourself. You are talking about a change for 1 map type and 1 civ. Unless you want mountain tile yeilds to be better than regular tile yields, which will never happen for balance reasons.

Let me get this straight. You're saying that either the change will have no impact, or it will be unbalanced and detrimental to the game? The proposed ideas have finely adjustable parameters - there is no sharp threshold between 'terrible'/'overpowered'. Don't delude yourself.

Much of what else I'd say has already been said by others (this is a balance issue, can't modmod change without DLL access), and I'd like to reiterate my reasoning for this being included in the main mod (post #126).

I'd also like to mention that the Luchuirp aren't necessarily "open-skyers" as you claim: they used to be, before the Age of Ice, but to survive that they learnt how to live underground for a long time (hence the similar "dwarf" mechanics). They aren't as suited to mining peaks as the Khazad are, but they are similar enough that the mechanic should apply to them as well (possibly with a reduced yield, but this is flavour>>gameplay).

 

[Jabie]

Personally I'd give the Khazad +2 Hammer on Mountains and leave it at that, but only if they needed a boost. If the Khazad are consistently underperforming because their start position is too close to mountains, this ought to help them out a little.

 

[PotatoOverdose]

Let me get this straight. You're saying that either the change will have no impact, or it will be unbalanced and detrimental to the game? The proposed ideas have finely adjustable parameters - there is no sharp threshold between 'terrible'/'overpowered'. Don't delude yourself.

Much of what else I'd say has already been said by others (this is a balance issue, can't modmod change without DLL access), and I'd like to reiterate my reasoning for this being included in the main mod (post #126).

I'd also like to mention that the Luchuirp aren't necessarily "open-skyers" as you claim: they used to be, before the Age of Ice, but to survive that they learnt how to live underground for a long time (hence the similar "dwarf" mechanics). They aren't as suited to mining peaks as the Khazad are, but they are similar enough that the mechanic should apply to them as well (possibly with a reduced yield, but this is flavour>>gameplay).

If you make mountain yields too good, you would create a balance issue. If you make them mediocre or average they would do nothing in most cases, including erebus where the dwarves suffer from a lack of food, not production. So there is a sharp threshhold, let's not jump the gun ok? To be clear, let me ask this: What kind of yields are you hoping for, specifically? That is assuming this change, that will only affect one (possibly 2) civs on only one mapscript(that comes with the mod, we can make modmods to high heaven that do whatever we want) that has enough mountainous terrain for there to be a noticeable difference, actually ever makes it into the mod.

 

[Luckmann]

[...]

I'd also like to mention that the Luchuirp aren't necessarily "open-skyers" as you claim: they used to be, before the Age of Ice, but to survive that they learnt how to live underground for a long time (hence the similar "dwarf" mechanics). They aren't as suited to mining peaks as the Khazad are, but they are similar enough that the mechanic should apply to them as well (possibly with a reduced yield, but this is flavour>>gameplay).

1 for Luchiurp, 2 for Khazad, +1 for everyone with Arete.

 

[the_fish]

If you make mountain yields too good, you would create a balance issue. If you make them mediocre or average they would do nothing in most cases, including erebus where the dwarves suffer from a lack of food, not production. So there is a sharp threshhold, let's not jump the gun ok? To be clear, let me ask this: What kind of yields are you hoping for, specifically? That is assuming this change, that will only affect one (possibly 2) civs on only one mapscript(that comes with the mod, we can make modmods to high heaven that do whatever we want) that has enough mountainous terrain for there to be a noticeable difference, actually ever makes it into the mod.

If by 'balance issue' you mean 'something significant that would need to be balanced' instead of 'unbalancing', then I agree with you. Sorry if I misinterpreted you. However, if you DID mean the latter, then you're mathematically wrong (about the sharp threshold).

The aim on the yield is to remove the disincentive of dwarves settling near peaks. It's not to provide an advantage for them doing so. A good way of doing this would be to let them treat peaks like hills - they're impassable, so cannot be improved with mines, so I suggested the 'cottage mine' idea to simulate this. Flavour implied that there would be no food bonus from peaks, hence:

Peak: 1, after n* turns worked get a mine on the tile (+2, or +3 with Arete)

(*lets say n=10, for now. The number can be easily tweaked)

This idea was suggested well before the whole thing with the Erebus mapscript came up - the argument didn't hinge on that, so you should stop attacking it as a supposed 'weak point'.

A "noticeable difference" doesn't necessarily mean 'unbalancing'. Letting all peaks within Khazad borders transform into hills would be noticeable, but not unbalancing (it's still just a hill). The above proposal keeps the impassibility in return for a 'worse hill'. It will be useful in a fair number of situations, across all mapscripts.

(I sketched a possible implementation of the idea a few pages back, for anyone who's interested (post #105)

EDIT: Agree with Jules.it below, and adding clarifications/additions:
- only Khazad/Luchuirp can work peaks, no matter the religion/civics/improvements on the peak.
- peaks should only be workable past a certain tech (say, Mining/Engineering).
- the mine is a regular mine: it gets bonuses from Arete and Blasting Powder, and counts for the Khazad worldspell.

-----

@ Luckmann: that's another fairly well balanced proposal, only it's useless for the Luchuirp before Arete and useless for all other civs even WITH Arete. Remove the 'all civs' thing from the Arete bonus and it begins to look better.

 

[Jules.lt]

This sounds great.
It can be done with invisible improvements, but if we eventually got a peak with a little mine on its flank it would also look great

A few thoughts:
- I would still allow it at a later tech than mining, so it doesn't become an alternative to building workers. Say engineering and/or Arete?
- I don't like the idea of allowing it to non-dwarf civs under Arete. It would be like allowing improved forests with GoN
- Don't forget the +1 at gunpowder; it will be competing for your citizens against normal mined hills which get this bonus

 

[Luckmann]

[...]
@ Luckmann: that's another fairly well balanced proposal, only it's useless for the Luchuirp before Arete and useless for all other civs even WITH Arete. Remove the 'all civs' thing from the Arete bonus and it begins to look better.

The point is to keep it fairly useless to everyone but Luchiurp with Arete and the Khazad. It's just to make it a little bit less useless, doing it more for flavour than anything else.

Edit: Just to be clear on something, I'm not with the 'Req: Engineering' at all, since I want this primarily for flavour reasons. It'd feel awkward for me to demand something based on flavour, and then have them somehow 'forget' their "lore", just to somehow have a re-epiphany when Engineering is researched.

 

[WarKirby]

Edit: Just to be clear on something, I'm not with the 'Req: Engineering' at all, since I want this primarily for flavour reasons. It'd feel awkward for me to demand something based on flavour, and then have them somehow 'forget' their "lore", just to somehow have a re-epiphany when Engineering is researched.

You have a point here. I suppose it would make sense to be able to work peaks before engineering, but engineering should significantly improve the benefits, then. It represents a new pinnacle of dwarven achievement.

 

[Jules.lt]

They start out not knowing how to mine hills. And peaks are more complicated, since other civs can't do it...

And you don't want to open too many possibilities too early.

 

[Luckmann]

They start out not knowing how to mine hills. And peaks are more complicated, since other civs can't do it...

And you don't want to open too many possibilities too early.

Of course they can mine hills. Anyone can mine hills.
They can't, however, build mines.

The argument would go the same for the dwarves. The Luchiurp would get a 1 yield because of their ancient connection to the underworld and the mountains, while the Khazad would get 2 because they actually came out of 'dem der hills' so recently, still adept at everything that comes with that life.

 

[Ranos]

The point is to keep it fairly useless to everyone but Luchiurp with Arete and the Khazad. It's just to make it a little bit less useless, doing it more for flavour than anything else.

Edit: Just to be clear on something, I'm not with the 'Req: Engineering' at all, since I want this primarily for flavour reasons. It'd feel awkward for me to demand something based on flavour, and then have them somehow 'forget' their "lore", just to somehow have a re-epiphany when Engineering is researched.

Since the Dwarves would more than likely research engineering long before they really needed the peaks, it wouldn't make much of a difference.

Of course they can mine hills. Anyone can mine hills.
They can't, however, build mines.

The argument would go the same for the dwarves. The Luchiurp would get a 1 yield because of their ancient connection to the underworld and the mountains, while the Khazad would get 2 because they actually came out of 'dem der hills' so recently, still adept at everything that comes with that life.

Building a "mine" improvement is mining the hill in the Civ game. No civs, including the dwarves have to have the right tech before they can start doing this.

After all of the various arguements, I think I agree that it shouldn't be done. The main arguement for it is based on flavor. Adding workable peaks in just doesn't add enough to the game to make it be worthwhile.

 

[MagisterCultuum]

What would be the argument against removing the SDK block that prevents them from being worked even if they are given yields by modmoder though?

 

[Jet]

Peak: ... a mine on the tile ...

Putting aside the exact mechanics and balance, the part of this I like (because it's cool) is the possibility of discovering resources on peak tiles, especially with Earth mana.

I don't like the idea of allowing it to non-dwarf civs under Arete. It would be like allowing improved forests with GoN

If you're talking balance, your comparison isn't good. If we're talking peaks with around 3 hammers and nothing else, the latter is much stronger than the former.

 

[Valkrionn]

What would be the argument against removing the SDK block that prevents them from being worked even if they are given yields by modmoder though?

I'd like the block removed, even if the workable mountains themselves never make it into the game. Would allow modmods to incorporate the mechanic, and then the argument is over.... Those who are for it can download the modmod, those who dislike it don't have to.

 

[Ahwaric]

What would be the argument against removing the SDK block that prevents them from being worked even if they are given yields by modmoder though?

Tried it. With the block removed, all peak tiles get yelds of the base terrain. Far from desirable effect.
I think it should be coupled with the same modification mechanics as hills have.
But still, I think peaks are less influenced by climate, or rather, they all have simillar harsh climate.
I picture mountain yelds as independant from what is on the surface (everything comes from mining).
So I decided to put the block back and give Khazad a special trait (imported from Sanguo Mod, renamed Expert miners) that gives 1 food 3 hammers and 1 commerce.
I think that while Luirchup learned some of the underhome lore, I think it is not enough. Plus I do not want to add another trait for them ATM.
I picture Arete as perfection in craft (a bit of Nantosuelta added to Kilmorph religion), so it does not need to give mining bonuses.
1 or 2 hammers proposed would still be not enough (especially if not upgradeable durnig the game) to make the tiles worthwhile.

If anyone wants to try it, I have released it as a part of patch c for my mod.

 

[Keeper_GFA]

What would be the argument against removing the SDK block that prevents them from being worked even if they are given yields by modmoder though?

Can't you work peaks if they get yields somehow? I seem to remember being able to work a peak that spawned mushrooms.

 

[MagisterCultuum]

I'm pretty sure the block prevents the tiles from being assigned yields when the map spawns, but they can still be worked if they gain yields though events, ading resources/improvements in worldbuilder, etc.


C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword\Mods\Fall from Heaven 2\Assets\XML\Terrain\CIV4YieldInfos.xml:

<?xml version="1.0"?>
<!-- edited with XMLSPY v2004 rel. 2 U (http://www.xmlspy.com) by Jesse Smith (Firaxis Games) -->
<!-- Sid Meier's Civilization 4 -->
<!-- Copyright Firaxis Games 2005 -->
<!-- -->
<!-- Yield Infos -->
<Civ4YieldInfos xmlns="x-schema:CIV4TerrainSchema.xml">
	<YieldInfos>
		<YieldInfo>
			<Type>YIELD_FOOD</Type>
			<Description>TXT_KEY_YIELD_FOOD</Description>
			<iHillsChange>-1</iHillsChange>[B]
			<iPeakChange>0</iPeakChange>[/B]
			<iLakeChange>1</iLakeChange>
			<iCityChange>0</iCityChange>
			<iPopulationChangeOffset>0</iPopulationChangeOffset>
			<iPopulationChangeDivisor>0</iPopulationChangeDivisor>
			<iMinCity>2</iMinCity>
			<iTradeModifier>0</iTradeModifier>
			<iGoldenAgeYield>0</iGoldenAgeYield>
			<iGoldenAgeYieldThreshold>0</iGoldenAgeYieldThreshold>
			<iAIWeightPercent>100</iAIWeightPercent>
			<ColorType>COLOR_YIELD_FOOD</ColorType>
			<SymbolPaths>
				<SymbolPath>Art/Interface/Symbols/Food/Food01.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Food/Food02.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Food/Food03.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Food/Food04.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Food/Food05.nif</SymbolPath>
			</SymbolPaths>
		</YieldInfo>
		<YieldInfo>
			<Type>YIELD_PRODUCTION</Type>
			<Description>TXT_KEY_YIELD_PRODUCTION</Description>
			<iHillsChange>1</iHillsChange>[B]
			<iPeakChange>0</iPeakChange>[/B]
			<iLakeChange>0</iLakeChange>
			<iCityChange>0</iCityChange>
			<iPopulationChangeOffset>0</iPopulationChangeOffset>
			<iPopulationChangeDivisor>0</iPopulationChangeDivisor>
			<iMinCity>1</iMinCity>
			<iTradeModifier>0</iTradeModifier>
			<iGoldenAgeYield>1</iGoldenAgeYield>
			<iGoldenAgeYieldThreshold>1</iGoldenAgeYieldThreshold>
			<iAIWeightPercent>110</iAIWeightPercent>
			<ColorType>COLOR_YIELD_PRODUCTION</ColorType>
			<SymbolPaths>
				<SymbolPath>Art/Interface/Symbols/Production/Production01.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Production/Production02.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Production/Production03.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Production/Production04.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Production/Production05.nif</SymbolPath>
			</SymbolPaths>
		</YieldInfo>
		<YieldInfo>
			<Type>YIELD_COMMERCE</Type>
			<Description>TXT_KEY_YIELD_COMMERCE</Description>
			<iHillsChange>0</iHillsChange>[B]
			<iPeakChange>0</iPeakChange>[/B]
			<iLakeChange>0</iLakeChange>
			<iCityChange>0</iCityChange>
			<iPopulationChangeOffset>0</iPopulationChangeOffset>
			<iPopulationChangeDivisor>0</iPopulationChangeDivisor>
			<iMinCity>1</iMinCity>
			<iTradeModifier>100</iTradeModifier>
			<iGoldenAgeYield>1</iGoldenAgeYield>
			<iGoldenAgeYieldThreshold>1</iGoldenAgeYieldThreshold>
			<iAIWeightPercent>80</iAIWeightPercent>
			<ColorType>COLOR_YIELD_COMMERCE</ColorType>
			<SymbolPaths>
				<SymbolPath>Art/Interface/Symbols/Commerce/Commerce01.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Commerce/Commerce02.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Commerce/Commerce03.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Commerce/Commerce04.nif</SymbolPath>
				<SymbolPath>Art/Interface/Symbols/Commerce/Commerce05.nif</SymbolPath>
			</SymbolPaths>
		</YieldInfo>
	</YieldInfos>
</Civ4YieldInfos>

It should not be hard to put negative numbers in the <iPeakChange> category to prevent peaks from getting yields. This would work the same way as Hills, it it were not blocked elsewhere.

 

[the_fish]

It should not be hard to put negative numbers in the <iPeakChange> category to prevent peaks from getting yields. This would work the same way as Hills, it it were not blocked elsewhere.

For civ-specific yield adjustments, is this taken into account before or after the adjustments for terrain? (and is there a floor of 0?)

If the block were removed, and the Peak values you highlighted were set to -5/-5/-5, would the standard implementation for Khazad +1 give 0/1/0 or 0/0/0?

 

[Keeper_GFA]

Do you have the code for the supposed block? Is the block only to prevent the terrain under a peak from giving it's yields? So a grassland peak doesn't give 2 food. This might not prevent techs or improvements (if any were possible) from providing tile yields to peaks.