Split cycledogg:terrain-essentials dependency; add remaining terrain mods

[noah-severyn]

Split out cycledogg:terrain-essentials into its own dependency package as its used across multiple terrain mods, including 3rd party ones not by cp (topically for sebamarynissen/simtropolis-channel/pull/302).

Added metadata for all remaining terrain mods included in the asset. However, all added terrains, except CPT Olympic, do not work correctly on installation due to their deep folder structure. An example extract is C:\Users\Administrator\Documents\SimCity 4\Plugins\170-terrain\cycledogg.canyonlands-terrain.canyonlands-beach-default-canyonlands-rock-canyonlands-water.3.0.sc4pac\@1-Canyonlands Terrain Mod\@0=CPT_No6 Canyonlands Terrain Controller_Default\CPT_No6_CanyonlandsTerrainController.dat, 286 chars. They work fine if all of the dat files are moved into the root \cycledogg.canyonlands-terrain... folder.

Not quite sure how to approach this. Remove the variants and opt for the flat install like Missouri Breaks? Or is there some way to ignore the folder structure and extract to the single root folder?

[memo33]

Thanks. Wasn't @timdmackey working on this, too?

1. In general, long paths shouldn't be a problem if you have null-45:startup-performance-optimization-dll installed. Does that not work for you?

2. Also, in general, when including files from different subfolders like

   assets:
   - assetId: id
     include:
     - /aaa/bbb/ccc/y.dat
     - /aaa/bbb/ccc/z.dat
     - /aaa/ddd/x.dat

   the common prefix aaa of all paths is removed, but the subfolder structure is preserved (to preserve load order), so after installing the package, the plugins folder will have these files:

   *.sc4pac/bbb/ccc/y.dat
   *.sc4pac/bbb/ccc/z.dat
   *.sc4pac/ddd/x.dat
   

   You can achieve a flat file structure using:

   assets:
   - assetId: id
     include:
     - /aaa/bbb/ccc/y.dat
     - /aaa/bbb/ccc/z.dat
   - assetId: id
     include:
     - /aaa/ddd/x.dat
   
   # which results in:
   # *.sc4pac/x.dat
   # *.sc4pac/y.dat
   # *.sc4pac/z.dat

   Here, both aaa/bbb/ccc and aaa/ddd are common prefixes that are stripped. For example, this is sometimes useful when a specific load order is required for the files within a package. (In the above examples, x.dat loads last or first, respectively.)

   This is exactly the approach I used for the Missouri Breaks package to ensure the Flora Patch z_LK_FloraTuningParameters_Seasonal_CP_MissouriBreaks.dat loads after the actual terrain mod files. The flat structure is not related to whether the package defines any variants.

3. The SC4E page doesn't mention anything about the Seasonal Flora Patch, so patching these terrain mods is still necessary, right? In a similar way as I've done for Missouri Breaks. Admittedly, this seems like a case where it makes sense to update the files on SC4E directly with the patch applied.

4. Your use of variants is quite different than for most of the currently existing terrain mods. I'm still undecided what's the best approach here, but there's no right or wrong with this. I like that your approach creates fewer packages, just one per terrain mod, which should make it easier for users to install these mods.

   One thing to be aware of, though, is that this prevents users from freely mixing-and-matching the CP terrain mods. For example, with the current approach, you couldn't install Columbus Terrain with, say, Olympic Beach, but users would have to opt for standalone beach mods. Perhaps, this is a feature though, as such combinations are rarely useful. I'd rather have a limited selection like this, than be able to select all the combinations, 95% of which are nonsensical. The documentation is also a bit unclear about how exactly the rock textures can be mixed with other CP mods or external rock mods (regarding the No5 and CPT_C_…Cliff… files).

5. I'd usually try to keep the variant values shorter, as they're part of the package folder name. So instead of e.g. beach: olympic-beach/other-beach, I'd use beach: olympic/other. Maybe this could become a linter rule in the future.

[UlisseWolf]

One of the problems I didn't write about in the complete metadata for CPT Terrain Mod is the complexity that comes into play, especially when there are Terrain Mods that require special installation procedures, otherwise they cause CTD.

For beaches and rocks, the best solution is to create a complete package, also because beaches are optional and only rock textures are necessary. However, even in this case, we can do a precise job because the various readme files indicate the recommended rock textures.

We can include rock textures in terrain mods. And finally, I was thinking of highlighting a conflict with Extended Terrain, as the DLL Mod allows you to use as many as four terrain controllers to simulate climate biomes and therefore requires a different set of texture

[timdmackey]

Posting my progress on this for reference: #139. This is still a first pass and I haven't tested at all, but you can at least see the approach I was taking. I'm away so likely won't be doing any sc4 work until at least next week.

At cursory glance my approach looks pretty much the same as @noah-severyn's.

A few notes:

• I copied @memo33's method of flattening the folder structure
• Also following memo, I applied the Flora Patch to each
• For variants, I went through the documentation and implemented variants for each of the recommended beach/cliff/water settings (I intended to allow for selecting "none" for each of these, but I don't think I finished implementing that).

[timdmackey]

I guess the alternative to using variants would be to define separate packages for terrain/beach/rocks/water, which would require the user to pick and choose the ones they want. If we went that way I think you'd want to include the recommended pairings in the descriptions.

This would mean 32 packages instead of 8, but with simpler definitions due to not needing variants.

[timdmackey]

And finally, I was thinking of highlighting a conflict with Extended Terrain, as the DLL Mod allows you to use as many as four terrain controllers to simulate climate biomes and therefore requires a different set of texture

Based on my current understanding of this mod, I think it would make sense to put the warning on the Extended Terrain mod since there aren't currently any terrain mods that support that DLL mod?

[UlisseWolf]

Based on my current understanding of this mod, I think it would make sense to put the warning on the Extended Terrain mod since there aren't currently any terrain mods that support that DLL mod?

Actually, there are already dependencies available to create a new Terrain mod using Extended Terrain.

https://www.sc4evermore.com/index.php/downloads/download/37-terrain-mods-and-tree-controllers/324-sc4d-lex-legacy-bsc-extended-cycledogg-terrain-mods-v1

https://www.sc4evermore.com/index.php/downloads/download/37-terrain-mods-and-tree-controllers/325-extended-berner-oberland-terrain-mod

These mods cannot be used simultaneously with the original mods due to IID conflicts.

[memo33]

Thanks for the feedback and the reference PR. The approach using a single package with multiple variants for each mod sounds like the way to go then.

Regarding the Extended Terrain DLL, my understanding was that it requires some user-end customization to assign the four styles at least, which cannot be done through sc4pac. Though, I don't know how it works in detail. I'd prefer not to deal with that added complexity in this channel, as switching between terrain mods without the DLL is not that hard and the metadata is already complex.

[UlisseWolf]

Regarding the Extended Terrain DLL, my understanding was that it requires some user-end customization to assign the four styles at least, which cannot be done through sc4pac. Though, I don't know how it works in detail. I'd prefer not to deal with that added complexity in this channel, as switching between terrain mods without the DLL is not that hard and the metadata is already complex.

In reality, Extended Terrain DLLs are monolithic, so there is no customization that the end user can do. Since the textures are predefined with IIDs, the modder must respect those specific IIDs.

[memo33]

In reality, Extended Terrain DLLs are monolithic, so there is no customization that the end user can do. Since the textures are predefined with IIDs, the modder must respect those specific IIDs.

Off-topic: If the DLL could work in a modular way such that each terrain mod could be used with or without the DLL, that would be helpful. Though, I reckon that's difficult due to IID conflicts, and there probably isn't a lot of demand for it anyway.

[noah-severyn]

I'm happy to use the work in your PR @timdmackey as it looks like you're a few steps ahead of me. :P The main differences I see are:

1. I would like to have CPT Terrain Essentials No3 and No4 Terrain Textures.dat pulled out into it's own dependency package, since it gets used by other terrain mods by other authors - ones by Tarkus and _marsh_ come to mind.
2. The thumbnails are pretty small and low res, so I also pulled in the images from Cori's Terrain Shoppe for a secondary larger picture

---

4. Your use of variants is quite different than for most of the currently existing terrain mods. I'm still undecided what's the best approach here, but there's no right or wrong with this. I like that your approach creates fewer packages, just one per terrain mod, which should make it easier for users to install these mods.

Yes, I think we vastly overestimate the number of people mixing and matching these kinds of things. I know the aim here is for a simpler experience, so that was my approach putting this together.

5. I'd usually try to keep the variant values shorter, as they're part of the package folder name. So instead of e.g. beach: olympic-beach/other-beach, I'd use beach: olympic/other. Maybe this could become a linter rule in the future.

Got it. I tend to be a little verbose sometimes. :)

[UlisseWolf]

Off-topic: If the DLL could work in a modular way such that each terrain mod could be used with or without the DLL, that would be helpful. Though, I reckon that's difficult due to IID conflicts, and there probably isn't a lot of demand for it anyway.

I'm waiting for an update to the Mod DLL, which should become somewhat modular, but only for examples related to weather simulation. But even in this case, there is the IID limitation factor, which must still be set in some way.