Adding Terrain "Lake" [IMPLEMENTED]

[raystuttgart]

Hi guys,

some of you may know that Civ4Col does not have "Terrain Type Lake".
Lakes are not defined in XML but by logic checks in DLL.

The only things that can really be balanced in XML are

• size of "Lakes" before being considered "Ocean"
• Food Bonus compared to Ocean

That is it already. (All done by "Global Defines".)
Not even close to the possibilities we have with real Terrains.

------

So how does DLL currently determine "Lakes":
It is basically a "stupid size check of the water area".

Technically the Plots are still "Terrain Ocean" or "Terrain Coast".
They are just displayed to the Player as "Lake".

It uses this check mostly to determine Ocean or Lake:
gc.getMIN_WATER_SIZE_FOR_OCEAN()

------

Generally there is ro real reason that Civ4Col does not have a specific "Terrain Lake".
It is basically mostly laziness of the original programmers.

So well, we as WTP now again seem to have to implement and correct what Vanilla has not taken care of ...
Not like we are not yet used to it.

------

Advantages of having Lakes as Terrain in XML:
(And removing the "DLL hacks".)

1. XML balancing of Yields becomes possible
2. XML balancing of Bonus Ressources becomes possible
3. XML balancing of Movement Rules (e.g. Coastal Ships) becomes possible
4. XML balancing to allow e.g. "Piers" (bot not full Ports) at Lakes becomes possible
...
10. Lots of hardcoded DLL checks can be removed ...

It is even going to be more performant !
And it is even going to remove several small gameplay issues !

------

Disadvantages of having Lakes as Terrain in XML:
(And removing the "DLL hacks".)

1. Effort
2. Effort
3. Effort
4. Effort
...
10. Effort

Otherwise nothing ...

------

So what would need to be taken care of:

1. Creating the Terrain Graphics (incl. Button)
2. Creating the XML Terrain Configuration and adjusting DLL gameplay logic
3. Creating new Terrain Swap Logic (called by MapScripts) that swaps Ocean Plots (without Europe Access) into Lakes
4. Adjusting MapScripts to call new Terrain Logic after Water Areas are generated
5. Adjusting existing Maps to now also contain Lakes where they should
7. Adjusting all Balancing of Units, Promotions, Bonus Ressources, ...
6. Writing Colopedia entries for Terrain Lake

------

Comment of effort and risk:

This can not be compared to "Large Rivers" in terms of risk because it acts as purely Water.
(So the complexity and risk and is much lower.)

We have learned a lot from "Large Rivers" so we should also be faster.
(Effort will be much lower but still there is a lot of details to take care of.)

This is only about 25% of the complexity and effort we had for "Large Rivers".
This is still not a tiny feature and the team needs to work on it together.

The risk in this is neglectable for experienced programmers.
We know all we need to do this and have done it already before e.g. "Savannah" and "Large Rivers".

------

Benefit:

Well, "Lakes" will become XML friendly and easier to balance.
It will help non-programmers a lot.

We will be able to use all possibilities we have with other Terrains.
Currently we can do almost nothing special with "Lakes".

It will even become more performant beause dirty DLL hacks will get removed.
And it will also be less prone to gameplay issues.

------

Do you want to have it?
Is the team interested to work on this feature together?

------

Personal Comment:

The benefits are worth it and I would take responsibility and thus invest according effort.
If somebody else wants to take responsibility for this feature, I would gladly step back.

I will only work on this if the team also commits and really wants it.
I will need help with this or otherwise the efforts will be higher than my motivation.

------

If we work on this, let us do it NOW !
(Before any other new feature.)

Because we are already or still working on improving "Large Rivers".
e.g. the area logic improvements that @Nightinggale is planning.

I want to finally get Terrains finished before we start things that are higher in the architectural hierarchy.

 

[Nightinggale]

I kind of proposed this myself. It should be fairly obvious that I support it. In general I support changes, which removes hacks and/or make the code perform faster.

The only issue I have with the plan is to make the DLL assign lakes as that feels like a new hack. However for the time being, it beats the alternatives. Eventually we will hopefully get more control over map generation (like adding large rivers) and at that time we can consider getting rid of this new hack.


One thing, which comes to mind is bWater in building xml. I would like to replace that with a list of terrains, like

<RequiredTerrains>
    <eRequiredTerrain>TERRAIN_COAST</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_OCEAN</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_LARGE_RIVER</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_LAKE</eRequiredTerrain>
<RequiredTerrains>

This way it can be configured on a per building basis, making it more flexible with pure xml changes.

I would store this in an InfoArray and then add a function to CvPlot, which returns true if at least one of the terrains is present in a 3x3 area with the selected plot in the center. If the InfoArray is empty, return whatever is in a bool argument (in this case true). This will give us reusable code to check for terrain. It might even be a good idea to add an argument to tell scan radius (in this case 1). This way we can add another list to BuildingInfo, which scans colony radius, allowing unlocking buildings if a terrain is within the 5x5 catchment area (when using 2 plot colony radius).

The nice part about this is that the code isn't linked to water plots. We can reuse it for say an event trigger, which triggers next to TERRAIN_TUNDRA or whatever is needed.

I don't have any specific plans for this, but if we are going to change the rules for building buildings next to water anyway, I would like to make it work this way as it seems to be the way to future proof the xml layout to handle future ideas.

 

[Mr. ZorG]

I will update all the pre-made maps when this terrain type is added.

 

[ConjurerDragon]

Would lakes have to be smaller to be considered a lake <> ocean on smaller maps?
If you think e.g. of the Great Lakes and the St. Lorentz as a navigable "large" river - do we have Niagara Falls or would ships ship into the lakes ahistorically early?

 

[modmod]

Time for lakes.

7. Adjusting all Balancing of Units, Promotions, Bonus Ressources, ...

Why do you think needs this part?
The only thing come into mind: it can act similarly as the tiny rivers: eg. adds a small bonus for the plots sorrunding that. Well at least in case of deserts - irrigation/ small canals for crops.

Or did you meant by balancing just to remove salt water exclusive bonus res like:
whales, cod, seals, etc...
That needs off course.

I can imagine some new bonus res for lakes.
New yields ... that would be problematic.

 

[Nightinggale]

Would lakes have to be smaller to be considered a lake <> ocean on smaller maps?

Currently map size isn't considered and in the future I think the idea is to ignore size and check for access to Europe instead to tell lakes apart from oceans.

If you think e.g. of the Great Lakes and the St. Lorentz as a navigable "large" river - do we have Niagara Falls or would ships ship into the lakes ahistorically early?

Good question. I think that is more of a question regarding specific maps than this "engine" concept, but it's still an issue worth considering.

"ahistorically early"... unlocking more movement options with CivEffects... That might be tricky without slowing down the game. Also I feel like it's off topic for this thread.

New yields ... that would be problematic.

From a technical point of view, not really. From a gameplay perspective... not really sure it would add anything of value.

 

[modmod]

do we have Niagara Falls

If talking about extra plot (feature on large river?) types (finishing all plot types) there also can be large waterfalls.
Where sorrunding plots are either hills/ mountains.
Which off course should prevent travels beyond them by ships.
But it sounds troublesome for random maps.
Can it be added in that way where only used in historical maps, like RAR america gigantic (in worldbuilder)?

From a technical point of view, not really. From a gameplay perspective..

Meant the second one.

 

[Nightinggale]

Can it be added in that way where only used in historical maps, like RAR america gigantic (in worldbuilder)?

The answer to that is surprisingly simple: the random map will not include terrains it doesn't know about, hence why random maps currently lacks large rivers. If you want to add a waterfall terrain, then the answer is to simply not tell the map script about it and it won't include it.

I spot a bunch of issues with this, like how to determine the direction of the waterfall? If you say look for direction to the ocean, then we are back to the proposal of flow direction, something we decided not to do because it's actually quite hard to do in a way, which won't break due to people doing unexpected stuff in world builder. It quickly added up to become way too complex compared to the gains.

 

[raystuttgart]

I kind of proposed this myself.

True, I only considered it after reading your post.
(Never had the idea for such a concept before.)

It should be fairly obvious that I support it.

I never doubted that.
Still needed to ask the team.

In general I support changes, which removes hacks and/or make the code perform faster.

All technical aspects about this concept are great.
It is simply effort ...

The only issue I have with the plan is to make the DLL assign lakes as that feels like a new hack. However for the time being, it beats the alternatives. Eventually we will hopefully get more control over map generation (like adding large rivers) and at that time we can consider getting rid of this new hack.

What else should we do if there is no modder to support us with mapscripts ...
Once we have a team member that can properly handle mapscripts I will gladly remove it from the concept.

One thing, which comes to mind is bWater in building xml. I would like to replace that with a list of terrains, like

<RequiredTerrains>
    <eRequiredTerrain>TERRAIN_COAST</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_OCEAN</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_LARGE_RIVER</eRequiredTerrain>
    <eRequiredTerrain>TERRAIN_LAKE</eRequiredTerrain>
<RequiredTerrains>

This way it can be configured on a per building basis, making it more flexible with pure xml changes.

Sounds great.

We can reuse it for say an event trigger, which triggers next to TERRAIN_TUNDRA or whatever is needed.

Interesting.

---

All sounds good to me.
We can do a lot if we properly work together on a feature.

 

[modmod]

Let`s see - do I understand correctly or not:

This way it can be configured on a per building basis, making it more flexible with pure xml changes.

Edit:
Ok became clear.
Fine.
Yet then many buildings need to be re-done.
While most still remains true for most water tiles.
Hope all on the list as required means OR.

The nice part about this is that the code isn't linked to water plots. We can reuse it for say an event trigger, which triggers next to TERRAIN_TUNDRA or whatever is needed.

So along with other triggers it can also check if there is xy plot OR feature (or improvement?) type in a 3X3 or 5X5 radius from city center? (To start the event.)
Sounds very good.

 

[raystuttgart]

@Schmiddie
We need to get your opinion on this.
Do you like it and would you also support with Terrain graphics and Buttons?

 

[modmod]

I spot a bunch of issues with this, like how to determine the direction of the waterfall?

1. Terrain plots nearby.
If there are mountains and hills the direction will be toward the lesser height.
If there are plains only there should be no waterfall anyway, just where is a meaningfull difference in terrain height.

2. Simple flow - as it was with small rivers.
If player put them with bad direction (flow) simple corrects it with place them again with the right one.
What issue can occur from it - save irreal graphic if not corrected?

Edit:
3. Rivers (large and small) can have an (actually 3) extra data:
- starts: it`s origin which must be either near a hill/ mountain
- mid: normal river - but also includes when meets another ones
- estuary: where it meets the ocean or lake (also can be further specialized as delta/ funnel)
So then the flow will be always FROM start TO estuary.
Then a waterfall have a direction automatically TO estuary.

Oceans are no good. They can be close, or too far -> not determines where they meet with a river.
Also ocean can be not in connection with the river itself if that goes into a lake.

Yet the only usage I see here (with the direction of the waterfall) to prevent ships to travel more upwards if there is waterfall.

 

[raystuttgart]

Guys, please we discuss a concept about "Terrain Lake" here and not "Waterfalls".
For new ideas, please create new threads.

----

Nightinggale basically already gave the answer here:

I spot a bunch of issues with this, like how to determine the direction of the waterfall?

The effort to implement something like "Waterfalls" is outrageous considering the benefit.
And the performance impact to store a separate new attribute "direction" in all Plots is also not worth it.

Something like real "directions" simply does not exist in Terrains.
And I can not imagine that it will ever be implemented.

 

[modmod]

Guys, please we discuss a concept about "Terrain Lake" here and not "Waterfalls".
For new ideas, please create new threads.

If we work on this, let us do it NOW !
(Before any other new feature.)

Because we are already or still working on improving "Large Rivers".
e.g. the area logic improvements that @Nightinggale is planning.

I want to finally get Terrains finished before we start things that are higher in the architectural hierarchy.

So river connection with lakes (and from now different ocean), and get Terrains finished in a different topic?

 

[raystuttgart]

So river connection with lakes (and from now different ocean), and get Terrains finished in a different topic?

Something like "Waterfalls" will simply never exist.
It is technically too much trouble (effort, performance, Map Generation, ...) for too little benefit.

It will not make it into this concept for sure because modders like myself and @Nigthinggale can judge the techical problems with it.
Thus if you really want to have it, please create a new concept and maybe somebody is interested to implement it.

Here you already got a no from @Nightinggale.
He just formulated too nicely maybe, so it was hard to understand ...

I spot a bunch of issues with this, like how to determine the direction of the waterfall?

... something we decided not to do because it's actually quite hard to do in a way, which won't break

And you would 100% get the same answer from me. Basically this post.
I simply formulate a little bit more direct if an answer is explicitly requested.

----

Summary:

Please believe modders like @Nightinggale or myself if we say "there are technical issues".
There really is no point in doubting these things - because we are not lying.

The things you post here have nothing to do with the technical reality of Civ4Col modding.

But how much time should we spend to explain you why all of these things are incorrect assumptions or extreme effort or extremely bad for performance or extremely bad for AI or extremely bad due to causing side effects or extremely bad for MapGeneration or ...

Even if we tried to explain you, you would simply not understand.
Because to do so you would need to be able to programm Civ4Col DLL or really experienced in Civ4Col modding to discuss into such technical details.

----

Spoiler :

This here was why I was asking for a new thread:

What issue can occur from it - save irreal graphic if not corrected?

Doubting the technical judgmement of an absolute pro-modder is pointless.
Again, even if we fully tried to explain you would not understand.

Thus please simply accept the answer of a pro-modder like @Nightinggale.
Doubting it or insisting to continue the discussion will not change our opinion.

----

Sorry if this may sound unfriendly.
But I tend to give honest answers when I am asked.

You may think this is arrogant, but how should I teach you all the basics you would need to understand my explanations about "techical issues".
It took modders like @Nightinggale and myself many years and we were already programmers when we started.

In this thread - actually intended to really implement a feature - however I could not ignore.
And it would not even have been no problem if you would have accepted the answer already given by @Nightinggale.

Again Sorry, but I was really trying to "friendly ignore" your suggestions.
(Thus asking for the new thread to be created.)

 

[Nightinggale]

True, I only considered it after reading your post.
(Never had the idea for such a concept before.)

And I never considered it prior to writing that post in the bug report thread. There was a problem and I was brainstorming solutions and possible effects (positive or negative) of different solutions. Looks like I hit jackpot with this one. The more I think about it, the better it becomes.

 

[Schmiddie]

I do not see any real benefit of that. We should focus on more important features. I'm not against it, but I would not support regarding buttons or terrain graphics.

 

[modmod]

To be clear: Waterfalls not come from me/not was my idea, "nor a want it really much" category.
It came from another user, and from Nigara waterfall - which is cc. connection between lakes (large rivers?) via waterfall. -> Which was logical/ real in here.
And the topic is about distinguish lakes vs. ocean which both can be connected with rivers (or lakes can come from each other).

And as I get it: lakes come from a bug from the recent release which was about ship routes when ships (off course) cannot reach cities which were on inland "ocean" shores, which have no acess for "real oceans"/ Europe.
So also about routes which ships can/ cannot use, which again point to lakes, oceans, rivers, waterways (movement).

Something on the side as addon - not someones main wish.

BTW:
A comment (part) which is about: in ways considered in the past wold be difficult.
-> Sorry that DO NOT means a no for me.
It means: there were not yet a better approach which can solve it more easily.

If solution is still difficult with different approaches too. -> Ok, no problem, nothing "really wanted".

------
Hope it is the last one, when need to clarify something like this:

Please believe modders like @Nightinggale or myself if we say "there are technical issues".
There really is no point in doubting these things - because we are not lying.

Never come into mind: anyone is lying.
Nor that: any modder is not good in that they doing.

But for sure that is possible: previously not considered certain ways as a solution. Probably think about 50, and there is always chance there are some more which were not considered (never was on the desk before).
And you right, because I am NOT a programmer there is again a chance to find out something (possible solution) a programmer probably never considered. -> Happened in life (especially in cybersecurity there happens often).

If "possible solution" attempt not real/ possible with present engine -> sorry for that.
Still worth a try. Probably 100 not, 1 yes = one success.

So please:
1. Do not take things as an attack/ doubt of skills. -> Probably just a helping attempt.
So no need of counter"attack" reactions.
2. Do not consider supportive or brainstorming comment on something minor as "xy wants it very much for himself"/ wants a separate topic for some major stuff. -> It is often just something which came up in the way (which is in with connection with the main discussed), and simply can be an ok addon a "would be nice" OR like it was: worth a short think/ count with the possibility (because of waterways/ movement of ships).
Nothing major/ nothing deeply wanted/ nothing personal wish.
Even a major can fall into a would be nice, but not deeply care category.

There were already many false assumption -> counter-reaction.
Or the false assumption it is someones "personal".

 

[Ramstormp]

I have been messing a lot with the large river graphics to try to get me some muddy waters. Got everything but muddy waters so far, but some colors looked more riverish. It probably would be nice to have different water hues for different regions. Clear lakes in cold regions, murky lakes nearer the equator. (Same thing for the large rivers really.) I could give it a shot at making a lake button as well.

 

[raystuttgart]

Looks like I hit jackpot with this one.

You did actually hit the jackpot this time.

The more I think about it, the better it becomes.

I think so too.

I do not see any real benefit of that.

There is little benefit in it considering "current gameplay" ok.

But

1. It fits perfectly into the design and will solve many potential issues we have e.g. with Large Rivers
2. We can get rid of many really annoying issues in coding we had all these years
3. We can e.g easily avoid bugs similar to like @Raubwuerger reported
4. It will allow many options for further modding of "Lakes" (e.g. separate Bonus Ressources) ...
5. This will even improve performance of the mod

----

For me as a programmer and feature creator this idea of @Nightinggale is in fact much more brilliant than we first realized.
But I fully understand that for a graphical modder or a player it may seem boring ... (simply because you do not face the issues we programmers do).

----

I'm not against it, ...

Thanks.
It will really benefit us, believe me.

... but I would not support regarding buttons or terrain graphics

That is of course fully ok.
Nobody needs to work on something he is not interested.

----

We should focus on more important features.

That is the point.
This is really not a feature.

I am not interested that much in it for gameplay itself.
But I know how much trouble it can save us if we do it.

It is more of these:

• stability improvement (bugfixing and avoding bugs)
• performance improvement
  
• effort reduction (for future features)

----

So please forgive that I really think this is important.
(And I really want to improve stability and improvement first before adding a new feature.)