First of all, I'll quote myself:
But climates are limited. [...] So I'd like to propose something similar, but slightly different.
Just so it does not get lost in talking about climates, which are only the inspiration.
a new climate needs 65*14=910 images.
Why would a new climate need only 910 images? That confuses me. 65 comes from the slopes, but why 14 instead of 16 (1111 in binary)?
Furthermore, how do the transistions work? Since they are blends, I was under the impression that all of them were pre-created, which would mean you would have 65*16 transistions for each climate you want to blend to. And there are tiles with 3 climates on them as well. I'd understand if the 'lower' climate would just fill the tile and the 'upper' climate be blended over it, but that would require blending - transparency - something said not possible in Simutrans?
For pak128 that means approximately 8mb per climate, or 0.5mb per texture variant. For keeping 8 climates but having 4 variants that means an extra 12mb over present. Add 4 new climates with variants and that's an extra 36mb.
Yes, and it would be even bigger in pak192. Which is a problem if we are talking about more hardcoded climates which demand graphics in every pakset and have an actual effect (if only which kinds of buildings can be placed). But what I suggest is purely optional and has no gameplay effect, other than looking nice. Essentially, if you find out they slow your game, just delete the paks and your game should not functionally change at all.
Furthermore, you only need that much space if all possible graphics are used. More about that later.
climates operate with bitfields, which is why they are limited to 8 climates (3 bit).
I'll stop here to reiterate: It's not about additional climates, which I understand is bad, but rather an additional "ground texture" type of object which is placed above the ground texture. Thus, you do not need to add additional bits in the climate definitions.
The request is for a new object type with the following features:
1) can be placed on slopes
2) can be placed beneath any other object
3) can replace and be replaced by other objects of the same type
4) when placed, dragging creates a rectangular area with beginning and end tile as the corners
5) Is not displayed under buildings unless "needs_ground=1"
6) has access to the ribi-system
7) if no image is defined, gets destroyed on creation/cannot be placed (no warning)
How much additional space would that need? I am no programmer, I can't say, but I can logically deduce some things which might be completely wrong:
There already is a way to indicate that an object is positioned on a tile - that much is obvious. There is virtually no limit on how many objects there are in the game, since new ones can always be added to the pakset.
There can be multiple objects in one space. That is, there can be multiple trees in addition to a ground object, a way can be combined with a wayobject, station, and signals - with trams, you can even have road and tram, road-way-object and tram-way-object on the same tile.
Therefore, each "ground texture" tile should just be another object like any other, and indicating its existence on a tile should not take more space than any other object.
The object itself does not need a whole lot of space.
First, look at a tree: Never saw a tree older than 64, so I assume you have 6bits for age alone? Then, they have offset - no idea how exact that offset is, let's say 5bit per direction? 16bit in total per tree, about 3 trees per tile in a forest, thus each forst tile consuming 48bit? Is that a good guess?
a ground texture would only need to store it's ribis, which are 4bit. Sure, if you have a 4096*4096 map and every tile has such a ground texture placed on it, that would still be 8mb. So if space is a concern, don't do that. You wouldn't spawn tons of trees in such a scenario either, but that does not mean they have no place in the game
About the storage space the graphics need - number 7 of my list already indicates that not every slope needs a graphic. For example, gravel only needs those where rails could be, so you would only need 16*9 images.
But for the most part, pakset creators should probably be careful not to add too many such ground textures to the pakset and rather provide them as addon for those who want them. After all, "model railway" players are those who download a terabyte of mods and addons before starting cities skylines, so they can be expected to download addons to get what they want.