Large Rivers (trying to make an old dream come true) [IMPLEMENTED]

[<Nexus>]

Found it meanwhile

 

[raystuttgart]

@Zeta Nexus
I attached the last version I got from Ramkhamhaeng.
It is the same one as you can download from here.

The Problem with his solution is, that it is extremely complicated.
It is way too complicated to be used for automatic map generation.

It does not simply work like a "Terrain" you can just place with normal Wolrdbuilder or generate by MapScript.
It is more like a "River" that has to be drawn manually by using a special "Python GUI".

Thus I am really not sure if it will help us at all.
Might be wrong here too.

Maybe we should really try to create new "normal Terrain graphics" for Large Rivers instead.
Using "Coast Terrain graphics" and trying to adapt them might be a start.

Summary:

For our purposes I think we need to get graphics that work like "normal Terrain graphics".
We cannot have graphics that players need to place manually with a special GUI after map creation.

 

[raystuttgart]

To simplify my idea to create "Large River Graphics":
(By using "Coast Graphics" as a blueprint)

Check this here:

C:\games\Colonization\Assets\Art\Terrain\Textures

Please also check this here:
(We could use almost the same for "Terrain Large River")

        <TerrainArtInfo>
            <Type>ART_DEF_TERRAIN_COAST</Type>
            <Path>Art/Terrain/Textures/CoastBLEND.dds</Path>
            <Grid>Art/Terrain/Textures/CoastGRIDS.dds</Grid>
            <Detail>Art/Terrain/Textures/CoastDetail.dds</Detail>
            <Button>,Art/Interface/Buttons/BaseTerrain_TerrainFeatures_Atlas.dds,1,1</Button>
            <LayerOrder>50</LayerOrder>
            <TerrainGroup>TERRAIN_GROUP_COAST</TerrainGroup>
            <TextureBlend01>1,180 5,270 9,180  13,270 17,180 21,270 26,270</TextureBlend01>
            <TextureBlend02>1,270 5,0   9,270  13,0   17,270 21,0   26,0</TextureBlend02>
            <TextureBlend04>1,0   5,90  9,0    13,90  17,0   21,90  26,90</TextureBlend04>
            <TextureBlend08>1,90  5,180 9,90   13,180 17,90  21,180 26,180</TextureBlend08>
            <TextureBlend03>3,0   7,180 11,0   15,180 19,0   23,180 27,0   31,180</TextureBlend03>
            <TextureBlend06>3,90  7,270 11,90  15,270 19,90  23,270 27,90  31,270</TextureBlend06>
            <TextureBlend12>3,180 7,0   11,180 15,0   19,180 23,0   27,180 31,0</TextureBlend12>
            <TextureBlend09>3,270 7,90  11,270 15,90  19,270 23,90  27,270 31,90</TextureBlend09>
            <TextureBlend07>4,0   8,270 12,0   16,270 20,0   24,270 28,0   32,270</TextureBlend07>
            <TextureBlend14>4,90  8,0   12,90  16,0   20,90  24,0   28,90  32,0</TextureBlend14>
            <TextureBlend13>4,180 8,90  12,180 16,90  20,180 24,90  28,180 32,90</TextureBlend13>
            <TextureBlend11>4,270 8,180 12,270 16,180 20,270 24,180 28,270 32,180</TextureBlend11>
            <TextureBlend10>2,0   6,90  10,0   14,90  18,0   22,90  </TextureBlend10>
            <TextureBlend05>2,90  6,0   10,90  14,0   18,90  22,0   </TextureBlend05>
            <TextureBlend15>29,0 </TextureBlend15>
        </TerrainArtInfo>

---------

Just in case you are wondering about TERRAIN_GROUP_COAST:
It is referenced in DLL and I think it is used in the exe for the graphics engine.

Since I think it is used in the exe, I would not touch it.
(Meaning not rename it and not add a new one in DLL).

But I think we could use the same entry for our "Large Rivers".
All we need to do is to adjust the Blend, Grind and Detail.

---------

Large Rivers need to be a bit "thiner" than 1 Plot Water
(And maybe the colour could be a bit greener.)

In there are files

• CoastBLEND.dds
• CoastGRIDS.dds
• CoastDetail.dds

If we use this we could make "LargeRiverGRIDS.dds", "LargeRiverBLEND.dds" and LargeRiversDetail.dds
Basically the main change needed would be to have more Land overlaps in there and slightly change the colour.

---------

Of course we also need a button.
(For Colopedia and WorldBuilder)

----------

In the end we would simply get a folder we could add to our mod:
C:\games\Colonization\Mods\We.The.People\Assets\Art\Terrain\LargeRivers
(Or we copy the files directly into \Terrain)

----------

Could we worth a try, even if the "Large River" may not look just as perfectly chaotic as the current "normal rivers".
(They would be straighter but that might even have the positive effect that Ship movement would look better.)

It would however be easy to use in manual MapCreation and MapGeneration by MapScripts

Also it should allow 2 very important aspects to look relatively nicely.

1. "Normal Rivers" flowing into "Large Rivers"
2. "Large Rivers" flowing into Oceans or Lakes (actually Coast Terrain)

And by doing it like that it should also be really easy to use by other mods.
(They would need our DLL changes as well of course - especially since TerrainTypes are hardcoded in DLL.)

----------

What do you guys think?
(I am not a graphics specialist and just throwing out ideas.)

Once it is approved I can start building a "prototype" in a new branch.
(Since I do not have the final graphics yet, I would just use the current "Coast graphics" and rename them.)

The "prototype" would sever the purpose to allow graphical modders to work and test comfortably by using WorldBuilder and all "Folder and XML structure" would already be setup.
(Also I could already start coding first DLL logic for the final feature.)

However I first want to know if this concept idea could work good enough.
(Otherwise I would waste my efforts.)

----------

Actually I wonder why it has never been done like this?

Considering programming it is not that difficult (even thought the details e.g. for AI are a lot of effort and ensuring good performance is also not trivial).
And the graphical changes needed also seem to be relatively limited (even though it still needs somebody talented and skilled to make it look really good).

Yes, adjusting MapScripts for this feature will become a challenge, but I guess we will solve that as well.
And manually adjusting all the existing maps will be a pain in the ***.

But it is by far not the most difficult concept ever implemented.
So I most have forgotten something ...

 

[raystuttgart]

Edit, I just checked and saw that @Ramkhamhaeng had just done basically the same.

But the rest of his concept seems to have been implemented for mods that use "Python" only.
Thus most of it might not be necessary for us.

I attached his files which I mentioned above.
(Maybe they can still be improved a bit.)

Here is also the XML of the TerrainArtDef:

He has however left out "TERRAIN_GROUP_COAST" which I think is a bad idea for our purposes.
I think the graphic engine uses it to know how place the different Blends.
(So maybe still better stick with the blueprint of "ART_DEF_TERRAIN_COAST".)

Spoiler :

                <TerrainArtInfo>
                        <Type>ART_DEF_TERRAIN_RIVER</Type>
                        <Path>Art/Terrain/Textures/RiverBLEND.dds</Path>
                        <Grid>Art/Terrain/Textures/RiverGrids.dds</Grid>
                        <Detail>Art/Terrain/Textures/RiverDetail.dds</Detail>
                        <Button>,Art/Interface/Buttons/BaseTerrain/Coast.dds,Art/Interface/Buttons/BaseTerrain_TerrainFeatures_Atlas.dds,1,1</Button>
                        <LayerOrder>50</LayerOrder>
                        <AlphaShader>0</AlphaShader>
                        <TextureBlend01>1,180 5,270 9,180  13,270 17,180 21,270 26,270</TextureBlend01>
                        <TextureBlend02>1,270 5,0   9,270  13,0   17,270 21,0   26,0</TextureBlend02>
                        <TextureBlend04>1,0   5,90  9,0    13,90  17,0   21,90  26,90</TextureBlend04>
                        <TextureBlend08>1,90  5,180 9,90   13,180 17,90  21,180 26,180</TextureBlend08>
                        <TextureBlend03>3,0   7,180 11,0   15,180 19,0   23,180 27,0   31,180</TextureBlend03>
                        <TextureBlend06>3,90  7,270 11,90  15,270 19,90  23,270 27,90  31,270</TextureBlend06>
                        <TextureBlend12>3,180 7,0   11,180 15,0   19,180 23,0   27,180 31,0</TextureBlend12>
                        <TextureBlend09>3,270 7,90  11,270 15,90  19,270 23,90  27,270 31,90</TextureBlend09>
                        <TextureBlend07>4,0   8,270 12,0   16,270 20,0   24,270 28,0   32,270</TextureBlend07>
                        <TextureBlend14>4,90  8,0   12,90  16,0   20,90  24,0   28,90  32,0</TextureBlend14>
                        <TextureBlend13>4,180 8,90  12,180 16,90  20,180 24,90  28,180 32,90</TextureBlend13>
                        <TextureBlend11>4,270 8,180 12,270 16,180 20,270 24,180 28,270 32,180</TextureBlend11>
                        <TextureBlend10>2,0   6,90  10,0   14,90  18,0   22,90  </TextureBlend10>
                        <TextureBlend05>2,90  6,0   10,90  14,0   18,90  22,0   </TextureBlend05>
                        <TextureBlend15>29,0 </TextureBlend15>
                </TerrainArtInfo>

By the way:

He had also added a Terrain "River Ford".
Not sure if we should use this or if it should better be a TerrainFeature.

 

[Nightinggale]

He had also added a Terrain "River Ford".
Not sure if we should use this or if it should better be a TerrainFeature.

The answer to that one lies in CvUnit::canMoveInto() and Cvplot::movementCost(). Both are performance critical meaning the decision to be to use whatever will be expected to perform the best. No, I did not examine those two functions closely enough to provide an answer right now. We might also consider proposal 270, which has to do with boosting performance of canMoveInto() by building a cache in each unit and plot.

 

[raystuttgart]

Well, we just need to give it a try and work from there.

I will probably set up the first prototype this weekend by creating a new branch.
It will make it easier for everybody that wants to work on this - because the basic structure will already be there.

And no, I am not expecting this to be finished after 2 weeks - this will probably keep me busy for quite a while.
(Especially adjusting the Maps and MapScripts will become annoying ...)

It seems to be one of the most wanted features ever and I also would like to have it.
(I had also promised to implement it - or at least try to.)

 

[<Nexus>]

Maybe we should really try to create new "normal Terrain graphics" for Large Rivers instead.
Using "Coast Terrain graphics" and trying to adapt them might be a start.

That was my initial idea too.
However, let me check those river graphics too...

EDIT:
Checked it and found nothing I could make use of, so I will start with altering coastal graphics.
...tomorrow

 

[raystuttgart]

@Zeta Nexus
Did you check the attachment here?

It already contains DDS for Blend, Grid and Detalis.
(They are already in the ZIP Ramkhamhaeng had sent me.)

Maybe they can be used as a starting base.
(But if you can create better Blend, Grid and Details it would be great.)

Since you are the graphical modder, of course please choose the solution that works best for you.

I am just exited to get a new toy to play with.
I love fiddling around with challenging features like this.

 

[raystuttgart]

Reminder to myself:

In void CvMapGenerator::setPlotTypes a new small logic may be needed to assure that PLOT_LARGE_RIVER and TERRAIN_LARGE_RIVER always match.
(After having been placed by Worldbuilder or Map Generation.)

Similar for void CvPlot::setPlotType.

Currently this might also change back Large Rivers to Coasts until the new PLOT_LARGE_RIVER introduced.
(One of the reasons, why Large Rivers and Oceans / Coast need a different PlotType.)

Spoiler :

void CvMapGenerator::setPlotTypes(const int* paiPlotTypes)
{
   CvPlot* pLoopPlot;
   int iNumPlots;

   iNumPlots = GC.getMapINLINE().numPlotsINLINE();

   for (int iI = 0; iI < iNumPlots; iI++)
   {
       gDLL->callUpdater();
       GC.getMapINLINE().plotByIndexINLINE(iI)->setPlotType(((PlotTypes)(paiPlotTypes[iI])), false, false);
   }

   GC.getMapINLINE().recalculateAreas();

   for (int iI = 0; iI < iNumPlots; iI++)
   {
       gDLL->callUpdater();
       pLoopPlot = GC.getMapINLINE().plotByIndexINLINE(iI);

       if (pLoopPlot->isWater())
       {
           if (pLoopPlot->isAdjacentToLand())
           {
               pLoopPlot->setTerrainType(((TerrainTypes)(GC.getDefineINT("SHALLOW_WATER_TERRAIN"))), false, false);
           }
           else
           {
               pLoopPlot->setTerrainType(((TerrainTypes)(GC.getDefineINT("DEEP_WATER_TERRAIN"))), false, false);
           }
       }
   }
}

------
See SHALLOW_WATER_TERRAIN vs. DEEP_WATER_TERRAIN

Might need a GlobalDefine LARGE_RIVER_TERRAIN.
(Would add some more flexibility.)

    <Define>
       <DefineName>LARGE_RIVER_TERRAIN</DefineName>
       <DefineTextVal>TERRAIN_LARGE_RIVER</DefineTextVal>
   </Define>

 

[<Nexus>]

Okay, I have started to work on it.
This is what I have achieved with an hour of work (original vs. my change).


Of course it is far from finished...

 

[raystuttgart]

Looks good, I really like it so far.

 

[Nightinggale]

He had also added a Terrain "River Ford".
Not sure if we should use this or if it should better be a TerrainFeature.

Thinking about this, I will say it should likely be a feature. The reason is we can make promotions provide half movement cost in certain features (used for forests). By making "River Ford" a feature, we can make a promotion, which makes a unit twice as fast when crossing rivers. If we should do it is another question as it's related to game balance, but for now I think we should stick to the technical solution, which allows the creation of the promotion.

 

[raystuttgart]

I created a button for Large Rivers (WorldBuilder and Colopedia).

It is not perfect but it is all I can achieve with my limited skills.
If anybody wants to create a better button I really do not mind.

The atlas for our Terrain / Plot graphics is here by the way:
...\Assets\Art\interface\buttons

Since the forum - for whatever reason - does not allow to attach dds.
I uploaded a .png of it.

 

[raystuttgart]

By making "River Ford" a feature, we can make a promotion, which makes a unit twice as fast when crossing rivers.

We could also create promotions with Combat Modifiers or whatever.
But I checked XML and it would work for both Terrains and Features.

But somehow my feeling tells me that "Fords" should better be a Feature.
They do not occur often enough to be important enough for a separate Terrain.
(Terrains have more options for balancing and do not need to be hardcoded in DLL.)

For Map Generation it will most likely be better and less work as well.

 

[raystuttgart]

I am currently thinking to code a function to "automatically identify" Coast Plots (or Ocean Plots) that should better be Large River Plots.
(Similarly to the logic that automatically identifies Ocean Terrain that needs to be Coast Terrain.)

--------

This identifies Water Plots that need to become Coast Terrain:

if (pLoopPlot->isWater())
+
if (pLoopPlot->isAdjacentToLand())

--------

This could identify Water Plots that need to become Large River Terrain / Plots:

if (pLoopPlot->isWater())
+
if (pLoopPlot->hasJust2AdjacentPlotsOfTerrainCoastOrLargeRiverButNoAdjacentOceanAndIsNoLake())

Do not worry, the function will not be called that way in the end.
It will most likely be called "isBetterLargeRiverPlot".

--------

So the logic is:
Plot is Water Plot + Plot is no Lake + Plot has no Ocean Terrain adjacent + Sum of (Coast Plots + Large Rivers Plots) adjacent exactly 2
--> It is actually a Large River (and needs to be changed)

@Nightinggale
Do I have a logical error in my thinking?
If no, MapScripts and adjusting Maps will become much much easier, because DLL logic will make the automatic conversion of Terrrains / Plots to Large Rivers (Plots and Terrains) whenever necessary.
(Just as it already does for converting Ocean Terrain to Coast Terrain.)

Just my thoughts to myself:

Spoiler :

Edit:
I already figured out that it does not work.
Otherwise it will make the middle of a very thin lake (of 3 Plots) a Large River Plot, which is stupid.

Edit 2:
Ha, I just gave the answer to myself.
I can simply check that it is no Lake in my function!
It should work that way!

 

[Nightinggale]

Auto detection of coast->river

Naturally it can be done. The question is how? I would say that the idea of two plots sounds good, but they should be opposite, like 4+6, 1+9, 2+8 or similar (keypad directions obviously). I would also say it should make "plotgroups" of river candidates. If the plotgroup exceeds X plots, then it turns into a river. That way we can avoid 1 plot rivers. Ideally this should be two settings, one for rivers and one for canals as in each end has access to ocean. We can simplify this to say it's a river if it's next to another plot, which will be a river if it's not alone, but I kind of like the idea of being able to set a min length of rivers.

I wonder what to do about areas. If an island is split in two by a river with fords, then will it be one or two areas? This is actually a problem because each plot can only have one area with the current code. The problem with ignoring areas is that there is a potential shortcut to performance boost in it. If a land unit is on a plot of area 5 and it tries to move to area 6, then because they are different areas, we do not need to check the map. It has to use a ship to get there. If they are both area 5, then there is a land path. Same with water. Somehow fords should have one land and one water area.

I added plotgroups to Medieval Conquest and it's a simplified version of the BTS plotgroups. It creates a list of plots connected by road (anything other than NO_ROUTE). Checking the plotgroup ID of two plots (ints) will then tell if they are connected by road without searching the map. Luckily I made plotgroups a standalone file, meaning moving it shouldn't be that difficult. If we are clever, we can use the same code for both roads and rivers.

EDIT:
Writing this makes me wonder if it would make sense to make fords a type of route. That would allow road based plotgroups to connect across fords with no added code. Alternatively since fords are fixed, adding the feature will then add a new route as well to the same plot.

 

[raystuttgart]

There are actually only a couple for possibilities for identifiying "Large Rivers" by its adjacent plots.
(But again, as written above, I need to check more conditions.)

The center is always Middle (on Keypad: 5).
The possibilities below that I need to check for the the adjacent plots:

• N+S (on Keypad: 8+2) --> River flows straight vertical
  
• W + E (on Keypad: 4+6) --> River flows straight horizontal
  
• S+E (on Keypad: 2+6) --> River makes an South-East turn
  
• S+W (on Keypad: 2+4) --> River makes an South-West turn
  
• N+E (on Keypad: 8+6) --> River makes an North-East turn
  
• N+W (on Keypad: 8+4) --> River makes an South-West turn

If there are more than those 2 (of those) adjacent plots being Water, it is not a Large River Plot anymore.
(It is already a Plot in a small lake or at the coast or in the ocean.)

 

[raystuttgart]

I am also reconsidering other parts of my design right now.
(e.g. the movement restrictions)

But first I need to set up the prototype, then I can start experimenting and see how it feels.

 

[JohnDay]

Hello raystuttgart,

you know the work of Ramkhamhaeng on this (Large Rivers)? Please take a look at the threat in the german forum:

https://www.civforum.de/showthread.php?97957-Beschiffbare-Fl%FCsse

Maybee you both could help each other with this. I would love it.

Greetings John

 

[<Nexus>]

There are actually only a couple for possibilities for identifiying "Large Rivers" by its adjacent plots.
(But again, as written above, I need to check more conditions.)

The center is always Middle (on Keypad: 5).
The possibilities below that I need to check for the the adjacent plots:

• N+S (on Keypad: 8+2) --> River flows straight vertical
  
• W + E (on Keypad: 4+6) --> River flows straight horizontal
  
• S+E (on Keypad: 2+6) --> River makes an South-East turn
  
• S+W (on Keypad: 2+4) --> River makes an South-West turn
  
• N+E (on Keypad: 8+6) --> River makes an North-East turn
  
• N+W (on Keypad: 8+4) --> River makes an South-West turn

If there are more than those 2 (of those) adjacent plots being Water, it is not a Large River Plot anymore.
(It is already a Plot in a small lake or at the coast or in the ocean.)

What if two large rivers join into one? That means at least one plot with three neighboring LR plots.