The International Simutrans Forum

 

Author Topic: Introducing regions  (Read 1251 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Introducing regions
« on: June 06, 2020, 10:20:54 PM »
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:

Code: [Select]
################################## 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:

Code: [Select]
# 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:





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:

Code: [Select]
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:



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.

Offline Flemmbrav

  • Devotee
  • *
  • Posts: 215
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Introducing regions
« Reply #1 on: June 06, 2020, 11:07:51 PM »
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?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introducing regions
« Reply #2 on: June 07, 2020, 12:18:46 AM »
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:

Code: [Select]
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.

Online Freahk

  • Devotee
  • *
  • Posts: 1325
  • Languages: DE, EN
Re: Introducing regions
« Reply #3 on: June 07, 2020, 12:34:33 AM »
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.
« Last Edit: June 07, 2020, 12:45:56 AM by Freahk »

Offline Vladki

  • Devotee
  • *
  • Posts: 3448
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Introducing regions
« Reply #4 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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introducing regions
« Reply #5 on: June 08, 2020, 11:57:08 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.

Offline BuildTheBuilder

  • *
  • Posts: 12
Re: Introducing regions
« Reply #6 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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introducing regions
« Reply #7 on: June 20, 2020, 06:08:16 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.

Offline BuildTheBuilder

  • *
  • Posts: 12
Re: Introducing regions
« Reply #8 on: June 20, 2020, 06:13:57 PM »
Is it possible to have an existing savegame somehow use regions though?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introducing regions
« Reply #9 on: June 20, 2020, 06:18:22 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.

Offline BuildTheBuilder

  • *
  • Posts: 12
Re: Introducing regions
« Reply #10 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.

Offline Andyh

  • *
  • Posts: 103
Re: Introducing regions
« Reply #11 on: June 20, 2020, 07:18:17 PM »

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.

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.

Online Freahk

  • Devotee
  • *
  • Posts: 1325
  • Languages: DE, EN
Re: Introducing regions
« Reply #12 on: June 20, 2020, 07:41:17 PM »
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.

Offline Andyh

  • *
  • Posts: 103
Re: Introducing regions
« Reply #13 on: June 20, 2020, 08:15:53 PM »
@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.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 20274
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Introducing regions
« Reply #14 on: June 22, 2020, 12:58:32 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.

Offline Roboron

  • Devotee
  • *
  • Posts: 154
    • Las Gal├ícticas Aventuras de Komoyo Diga
  • Languages: ES, EN
Re: Introducing regions
« Reply #15 on: June 22, 2020, 03:53:16 PM »
Awesome! Regions can be very interesting, they can add a lot of value to the game.

Offline TheRoadmaster1996

  • *
  • Posts: 249
  • Languages: EN, some ES
Re: Introducing regions
« Reply #16 on: June 27, 2020, 05:03:28 PM »
I think having regions other then climates is more realistic anyway. I just might incorporate it into my American pakset.

Offline Ranran

  • Devotee
  • *
  • Posts: 1219
  • Languages: ja
Re: Introducing regions
« Reply #17 on: September 12, 2020, 02:14:40 AM »
Regional division seems to be very convenient. Thank you for the implementation. :thumbsup:
For your information, I have added a regional sort to some lists along with GUI overhaul.