I have been working on a new feature in the last few days:
regions. This is a system that allows parts of the map to be defined as separate regions with their own names. Currently, this affects:
(1) town names;
(2) street/stop names;
(3) what city buildings may be built; and
(4) what industries may be built.
It is theoretically possible to add other things affected by region, but I am not sure whether anything else can be added without an unfeasibly large amount of work at present, for me at least.
Regions are defined in simuconf.tab. Here is the simuconf.tab entry for Pak128.Britain-Ex, which now has regions defined:
################################## Region settings #################################
# Regions are defined as stacked rectangles on the map. Each region of a higher number overrides
# each region of a lower number in so far as they overlap.
#
# For each region definition, specify the upper left and lower right points of the rectangle either
# in absolute numbers or in percentages. The numbers are specified: x,y. x = east/west; y = north/south.
# 0,0 is the upper left corner.
#
# NOTE: Region 0 will always be the base region and will by default cover the whole map save
# in so far as other regions are defined. There can be a maximum of 16 regions in total.
region_name[0] = Albion
region_upper_left_percent[0] = 0,0
region_lower_right_percent[0] = 100,100
region_name[1] = Northumberland
region_upper_left_percent[1] = 0,0
region_lower_right_percent[1] = 100,50
region_name[2] = Caledonia
region_upper_left_percent[2] = 0,0
region_lower_right_percent[2] = 100,25
region_name[3] = Cambria
region_upper_left_percent[3] = 0,35
region_lower_right_percent[3] = 25,65
region_name[4] = Kernow
region_upper_left_percent[4] = 0,65
region_lower_right_percent[4] = 20,100
region_name[5] = Erin
region_upper_left_percent[5] = 0,0
region_lower_right_percent[5] = 25,35
As will be seen, regions are a simple system of overlapping rectangles. Any more sophisticated system would have been too labour intensive for me to have coded within a reasonable amount of time, and this system suffices for its intended purpose.
For defining regional city and street/stop names using a city or street list, just add
- to the end of the filename immediately before the _[language] part: for example, citylist[1]_en.txt for the English language citylist for region no. 1 or streetlist[2]_fr.txt for the French language street/stop list for region no. 2. Where no region specific list be defined, the base list (i.e. that without any number in square brackets) will be used.
For using town name fragments as used by Pak128.Britain-Ex, there is a limitation (imported from Standard) in that the fragments only work in the base en.tab and not in the pakset en.tab. Aside from that, the same principle applies: the region number is added in square brackets after the fragment definition, and, where no region specific fragments be defined, the base fragments (without a number in square brackets) are used. Here is an example of some town name beginnings from region 1:
# Region 1: Northumberland
#
%0_CITY_SYLL[1]
Thirl
%1_CITY_SYLL[1]
By
%2_CITY_SYLL[1]
Hawn
%3_CITY_SYLL[1]
Aiden
%4_CITY_SYLL[1]
Kirk
Here are some screenshots of regional names in Pak128.Britain-Ex:
(http://bridgewater-brunel.me.uk/screenshots/caledonian-names.png)
(http://bridgewater-brunel.me.uk/screenshots/cambrian-names.png)
To restrict industries or city buildings to certain regions, just use "regions=" and then a list of the region numbers. For example, iron ore mines in Pak128.Britain-Ex now have the following:
regions=1,2,3
This means that they can only be built in regions 1, 2 and 3, being Northumberland, Caledonia and Cambria. If no regions= datum be specified, the building or industry will be able to be built in any region.
This should also work with attractions, but I have not yet tested this with attractions.
One of the main purposes of introducing this feature is to improve industry balance by allowing inter-regional and unidirectional flows of goods. So far in Pak128.Britain-Ex, the following industries have been region restricted:
(1) coal mines (Cambria, Northumberland);
(2) iron ore mines (Cambria, Northumberland, Caledonia); and
(3) orchards (Albion, Kernow).
Additionally, two city buildings (the two "pasture" industrial city buildings from the early years) have been restricted so as not to appear in Albion.
To aid this feature, a new .dat file parameter for industries has been introduced: max_distance_to_supplier. This works in the same way as max_distance_to_consumer (value: kilometres) but in reverse. There is one further difference: if the consumer industry should be built in a region in which no producer industry for on of its input goods can be built at the current point in the timeline, then it will ignore the max_distance_to_supplier value for each input goods type to which that applies. This allows industry chains to be created which require local supply when the industry type can be found nearby, but which allows for long-distance shipping in other cases.
It would be splendid to have more regional produce in the future in Pak128.Britain-Ex, such as whiskey (Caledonia and Erin), or tin (Kernow), but this would require substantial work in creating industry graphics and, in the case of bulk goods such as tin ore, adjusting every single vehicle with different graphics for different sorts of bulk load, which would be a large task even if existing graphics be re-used. If anyone is interested in doing this work, please let me know.
I had experimented briefly with altering the map generation settings (mountain height and roughness) based on region, but, as might be anticipated, this produced unreasonably harsh cut-offs and is thus unusable without a huge amount more work which I am not in a position to prioritise at present:
(http://bridgewater-brunel.me.uk/screenshots/regions-landscape.png)
However, if anyone else would like to work on this, this would be helpful. This project, although potentially complex in some ways, is very self-contained, and will not require mastry of the arcane and byzantine reaches of the decades old Simutrans codebase in the way that some other projects might.
The title got me hpyed, not going to lie. Having regions would be a great thing to have in standard as well.
Would changing the ground texture based on the region be one of these things that take large amounts of work to be implemented?
Just out of curiosity:
Do you want the landscape to be dependent on the region, or do you want the region to be dependent on the landscape?
Also, where can I find the code for the generation of the regions and the landscape?
Thank you for your interest in this feature.
I am not sure about changing the ground texture with regions, as I know very little about the code for setting ground textures in the first place; I have generally not worked on the graphics code in the time that I have been developing Simutrans-Extended, focussing instead on the simulation code. It would thus probably take me a considerable time to learn about the graphics code just in order to know how much work that it would be to change this.
However, do you really want to change the ground texture depending on the region? Regions are, as the last graphic in the post above shows, simply rectangles with hard edges. Thus, any system which had ground textures changing with regions would have a straight line along the boundary between one region and the next, which would look very odd. Unlike other things such as map roughness, mountain height or climate, there would be no way of feathering this (at least, not without drawing a truly vast number of transition tiles or coding a whole new alpha blending system and then very carefully producing ground textures to work with this, which would be a gargantuan amount of work).
What would probably work better is a system of changing the relationship between climate and height per region (and possibly also the snow line, too). This could in principle be feathered along region boundaries by using a probability of any given tile having one either of the two possible climates, although doing this properly would be a very large amount of work so as not to create an odd looking patchwork of individual tiles of different climates on region boundaries. Making more use of the climates system is certainly one possible advantage of regions if they could be developed more.
As to the landscape: because regions are defined as rectangles, with the current definition of regions, the only way of making there be a relaitonship between regions and the landscape is to have the landscape follow the regions rather than the other way around. Doing it the other way round would be likely to be much more complex and require a ground-up rewrite of the region system to something vastly more complex than I have implemented so far. Because of the rectangular nature of regions, there would need to be some sort of feathering of the landscape at the borders if there were to be any region based landscape influence.
I should note that I have deliberately implemented regions in this way so as to be a lightweight implementation, since I do not have time in light of other priorities for any more sophisticated implementation, and it is better to have a workable but basic implementation of this than none at all. There are no doubt better ways of implementing regions, but those would all take orders of magnitude longer than implementing this method, and this method is certainly better than no method, especially for reasons of industry balance.
As to the location of the code for regions, it is found in various places; for landscape purposes, you need not worry about its implementation in buildings/industries, but you will want to look at the various region functions at the bottom of simworld.cc as well as the settings for regions in settings.cc. The landscape generation code is also in simworld.cc: see in particular the method with this signature:
sint32 karte_t::perlin_hoehe(settings_t const* const sets, koord k, koord const size, sint32 map_size_max)
I have just pushed my commented out abortive attempt at region based landscape influence (giving rise to the harsh borders in the image above), so you can see in basic terms how this works.
I am currently investigating whether it is feasible to have region influenced city placement density, which should at least not have the hard border of the landscapes.
I had rather expected to whitelist/blacklist objects from regions rather than the other way round, as objects are pak-hardcoded, whilst regions are not.
In any case, this sounds interessting.
I do not think changing textures, including indirect texture changes like changing the climate heights in relation to regions is a good idea, as these are simply rectangular. So any visualisation based on regions will look rather artificial and boring.
Such a system would be great, but I guess a more natural and sophiscated region system would be required for these to work well.
Just my opinion. I don't want to stop anyone from being hyped and the rather simple region system is still interessting.
How about allowing different languages to be used for different region's stop names?
Thinking about the Wienna-Budapest-Krakow scenario.
Quote from: Vladki on June 08, 2020, 11:50:28 PM
How about allowing different languages to be used for different region's stop names?
Thinking about the Wienna-Budapest-Krakow scenario.
You can do this by specifying different stop name lists for each region as described above.
The current system of stop names depending on a user's local language rather than the language of the place being simulated is a curious one, and I suspect comes from Simutrans historically having an amorphous central European setting with pak.64 and pak.128. This is less apposite with more modern paksets which tend to be more geographically specific.
However, overhauling the whole system of the relationship between town and stop names and a user's local language was outside the scope of my work on this feature, and would need not only extensive work but detailed consultation. It is not a priority given that the same effect can be achieved with current features.
Will anything happen to existing older savegames if I run them in a newer version that has this? Will coal mines still be where they were? I just am afraid my current save will mess up when I get a new version as I've not been aware of this update till today.
Quote from: BuildTheBuilder on June 20, 2020, 05:56:46 PM
Will anything happen to existing older savegames if I run them in a newer version that has this? Will coal mines still be where they were? I just am afraid my current save will mess up when I get a new version as I've not been aware of this update till today.
The region definitions are saved with the saved games - existing saved games will continue unaffected and will have no regions defined.
Is it possible to have an existing savegame somehow use regions though?
Quote from: BuildTheBuilder on June 20, 2020, 06:13:57 PM
Is it possible to have an existing savegame somehow use regions though?
You would have to use the setting to allow the pakset to override saved game settings.
How would the regions be created then? I hope it won't make my coal industries in some region where coal mines can't be present, and if it does, I hope they won't be broken.
Quote from: Freahk on June 07, 2020, 12:34:33 AMWhat would probably work better is a system of changing the relationship between climate and height per region (and possibly also the snow line, too). This could in principle be feathered along region boundaries by using a probability of any given tile having one either of the two possible climates, although doing this properly would be a very large amount of work so as not to create an odd looking patchwork of individual tiles of different climates on region boundaries. Making more use of the climates system is certainly one possible advantage of regions if they could be developed more.
This is exactly what I had in mind when I read about this feature. Along with the Same Height Multiple Climates mod that is being worked on in Standard it looks as though we are moving towards a structure in which climate no longer relates exclusively to height which will be a very valuable feature for larger-country and continent scale maps.
Very excited to try this out, even without a climate relationship. The ability to customize industries by region, especially agricultural and extractive industries, would be a fantastic addition to the game.
Where did you find that quote?
I am quite sure I never wrote this.
Imho the regions feature in its current form is simple and powerful but not a good starting point for region based climates.
@Freahk: Sorry, I was quoting James. Don't know why your name came up. I probably messed up something.
Maybe not the ideal method of creating climate based regions, but I'll take anything vs what we have now.
Quote from: BuildTheBuilder on June 20, 2020, 06:21:49 PM
How would the regions be created then? I hope it won't make my coal industries in some region where coal mines can't be present, and if it does, I hope they won't be broken.
Have a look at the simuconf.tab settings in the latest version of the pakset for the default region configurations. No existing industries in a saved game will be broken by the regions feature, as it only affects newly placed industries.
Awesome! Regions can be very interesting, they can add a lot of value to the game.
I think having regions other then climates is more realistic anyway. I just might incorporate it into my American pakset.
Quote from: Ranran on October 29, 2020, 12:49:22 PM
I worked on adding "allowed region" info to the EDIT dialog.
I think we should add "Ignore region" as well, but I haven't done that so far because it's a lot of work compared to just adding a display.
By the way, I have a question.
It seems that no regional settings have been added to the tree. Is this intended?
I had not thought of adding regional settings to trees. Would this be useful, do people think? It is not likely to be a priority for a while, however.
I thought that regions should be used for things that cannot be ruled by climate. Typically the presence of mines or other natural resources. Or cultural differences - style of buildings, brewery vs. distillery
I have noticed some projects to change climates not only by altitude (height) but also latitude (north-south) and humidity (wind direction, mountains, seas). I don't know what is the state of those projects, but they should nicely work for islands like Japan, even without using regions. Imho trees and agriculture (farms, orchards, forests) should be ruled only by climate.
If there is the prospect of a more sophisticated climate system, then it is probably sensible to keep trees decoupled from regions, as regions are intended to represent areas delineated by human activity rather than by physical characteristics.
I don't know I think it's a good idea. Let's take the U.S. for example. A chestnut oak tree that grows in the Hudson Valley of Upstate New York will be different from the ones growing in the Appalachian Mountain region of Alabama. It's the same tree but one might turn red in the fall while the other might just turn brown and lose its leaves. Same here out west. We have an oak tree in our front yard that has turned yellow even though this is the High Desert Great Basin. So having regions, you can have one Oak tree but have it turn different colors depending on where it is.
That "one same" oak tree behaves differently, because it's in different climates isn't it?
Technically it's different objects with different graphics and different climates, isn't it?
Might be there are too few climates to represent this properly in simutrans, but I don't think using regions here does really work well.
No, Appalachia still has a temperate climate. In the game, New York would also have a temperate climate (we cannot do humid continental climates in Simutrans), but that's not my point. My point is that trees will have different colors in autumn depending on where they are.
You can call the climates whatever you want. But the number of climates is limited. Different trees (and their colors in autumn) are definitely a climate related thing.
I have a question about regions - are they saved in the game? It seems that vienna-budapest-krakow map is only Albion all over, and Stephenson-siemens has no regions at all?
If they are saved in the game - is there a way to change them? Or at least to show them on map?
The region settings are, I believe, saved with the game. If I recall correctly, the only way to impose regions on an old game is to use the advanced settings dialogue to re-load settings from one of the files;
Quote from: jamespetts on January 08, 2021, 11:16:55 PM
If I recall correctly, the only way to impose regions on an old game is to use the advanced settings dialogue to re-load settings from one of the files;
I tried that: advanced settings, click on simuconf.tab, save, load and crash: FATAL ERROR: planquadrat_t::rdwr() - Error while loading game: Unknown ground type '7'
Aborting program execution ...
Quote from: Vladki on January 08, 2021, 11:30:15 PM
I tried that: advanced settings, click on simuconf.tab, save, load and crash: FATAL ERROR: planquadrat_t::rdwr() - Error while loading game: Unknown ground type '7'
Aborting program execution ...
May I ask you to post a bug report in that case?
Quote from: Vladki on January 08, 2021, 11:30:15 PM
I tried that: advanced settings, click on simuconf.tab, save, load and crash: FATAL ERROR: planquadrat_t::rdwr() - Error while loading game: Unknown ground type '7'
Aborting program execution ...
Has anybody managed to get this to work now or is it still broken? I got this same error when trying to update my pre-regions save, which is all Albion. The game is now trying to build Coal-Fired Power Plants everywhere only to remove them at the end of the month because it can't place a mine. I can't even fix this by placing them by hand, as the Public Service doesn't have the ability to ignore regions like it does climates.
Quote from: Ranran on June 22, 2021, 10:00:22 PM
I created a "ignore regions" option which is similar to the ignore climatic setting.
You can test it in the following branch:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/ignore-regions
However, this branch is a fork of the branch I include from my standard as it was a hassle to conflict and test.
Please check after the incorporationg from the standard is completed or at the same time.
Although I can't compile from source, what seemed to work for me in the default build was changing the savegame version from 120.7 to 120.4 (in a clone of my main save). Now I've got some Cambria and Kernow on the map. Will this impact the stability of the save in other ways?
Edit: OK, turns out the regions HAD appeared in my save all along without changing the version. It was just a few isolated bits of land that weren't Albion, so I didn't notice, and they didn't have the right climate for a coal mine to be built.
Quote from: Ranran on June 22, 2021, 10:00:22 PM
I created a "ignore regions" option which is similar to the ignore climatic setting.
You can test it in the following branch:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/ignore-regions
However, this branch is a fork of the branch I include from my standard as it was a hassle to conflict and test.
Please check after the incorporationg from the standard is completed or at the same time.
An interesting option! I will have a look at that after the deployment of the merge from standard work and we have had a chance to assess whether that is working well.
Ranran -- Very nice! Could regions in that minimap be colour-coded, similar to route colours in the "Networks" view?
It would certainly make the pakset a whole lot easier to know where the regions are on a map instead of searching for them manually clicking the landscape.