new dat file entry: region

[prissi]

I propose that all new data files for paks get an try region:
Could be the country code it,de,us,uk,fr,jp, ... or a regions "Europe", "Scandinavia", "Asia", "USA", "East European", ...

with the country list given in the simuconf.tab

Then, in the new world dialogue, there would be an entry for region settings taken from the paksets (if there is any country-specific infrastructure/buildings) and also a sector in the depot (and narrowing down choices there).

[Flemmbrav]

Fancy thing!
Pak192.Comic will love that feature!

Bonus for a future thing where regions will be distributed on the map as well.


One thing that's on my mind here is that the average player might think that you could just play the game in any given region.

We have a lot of objects post 1920, but not much from before that time. Even though we've set the preset starting year to 1960, we have had complains from people starting the pakset in 1835 and wondering why there's not a lot going on.

I wonder if it's possible to have some kind of indicator, on which regions to solely play on, and which might be better fit as just an addition.


In plus it may be a good idea to allow multiple regions / countries to avoid multiples of especially factories. While I'd love to have certain factories regionalized, I see some of them fitting multiple, but not all regions, imagine a wine yard, that really does not fit in for DE, but may fit for ES, FR and IT, while the DE version will look different.

[prissi]

I think one should have regions like south_europe, middle_europe and list of countries. I think the entries in the data file would be saved as strings and parsed on load.

Or maybe just a list of countries, where the player can then select more than one?

One could even handle essential objects like climates and factories. If there is no matching factory, take one from another region.

[Leartin]

Suppose the intention is to only mark specific objects to make them excludable, with a consistent core of objects that always exist.
In that case, a better solution would be to have addon-subfolders and an easy ingame way to choose which of the addons you want to activate. If you sort your addon-folders by regions, you get the proposed effect, while also allowing versatility of use (sorting addons differently) plus avoiding loading tons of objects that are irrelevant for the game you are playing. Which could be especially relevant if such a system encourages creators to expand on existing paksets, rather than forking their own regional variants, meaning either the pakset gets bigger or it's addons anyway.


Suppose the intention is to mark all objects, so there is no common core. Now you run into the trouble we already have with climates, but worse since it affects all objects. You mention a fallback for taking factories from other regions, but how would the game even know that the "Austria" region does not offer a train wagon for bulk, or - if it could - that it isn't intentional since a region might focus on a different mode of transport, or not have a need for bulk on it's own?
We get the opposite problems with functionally duplicated objects. Say each region provides it's own array of tracks with the same speed, which only differ visually, for example the safe-distance-markings at switches (Grenzmarke). Which is a natural expectations - if I play in Austria, why wouldn't there be Austrian slabs instead of German pegs? But if both regions are active, both types of tracks together clutter the menu meaninglessly.

How would the system work with addons? You suggest the list of available regions stems from a simuconf.tab - I don't think addons could expand on that list. Paksets of course wouldn't define regions that are meaningless for their content.



I think for this to work properly, we need something completely different: Inheritance in paks.
Suppose we define a range of objects as the paksets core. Everything a pakset needs to be viable - the extent can vary per pakset.
Then, we have regional objects, which may or may not inherit from those core objects and extend them (aka. replace some values, most importantly name and graphics definition).
Now, we may have a "50km/h german track" and a "50km/h austrian track", but we know both extend "50km/h track" from the paksets core.
First of all, when a player now picks a single region, we can restrict to only objects from that region, but for any core object that has no regional implementation, the core object is also loaded.
If a player picks several regions, such that several objects extend the same core object, we can use that to shrink the menus. Simply only a single icon per implementation, with a way to switch between them. Besides regions, this also simplifies how it's already done eg. for signals in p192c.

Given that you can overwrite any value during inheritance, you can have two completely different objects with no overlapping values fill the generally same slot defined by a core object, eg. "narrow gauge locomotive for goods in era 3".

Probably a lot more programming work than just adding a new datfile entry, but I think it would be quite meaningful, both on it's own, but especially in regards to this change.



Also: I wish Simutrans could check which factory chains are completable and not attempt to build impossible ones. I understand that it's not feasable for climates, since it's hard to establish what's possible, but with regions it should be easy enough.

[makie]

For Pak128.german I see no use for it.

[prissi]

Unless one does Austria too ...

[Leartin]

For Pak128.german I see no use for it.

I don't doubt it. But neighbouring countries might very well think that p128g is the best base for their own pakset, since a lot of objects could overlap.

The 'classic' approach is to fork the pakset, delete what you don't want and add new stuff.
The 'new' approach could be to get the same effect via this region setting. Ideally, the creator of the 'Austria' region (to use prissis example) could even be a pak team member.

[ceeac]

The 'classic' approach is to fork the pakset, delete what you don't want and add new stuff.
The 'new' approach could be to get the same effect via this region setting. Ideally, the creator of the 'Austria' region (to use prissis example) could even be a pak team member.

So you're thinking of something like a mod package manager? One could use Squirrel scripting at load time to disable existing objects, or maybe even add new ones, similar to this:
https://wiki.factorio.com/Tutorial:Modding_tutorial/Gangsir#How_Factorio_loads_mods

But that is definitely a non-trivial project.

[prissi]

I think not at pak loading time but when the game is loaded/started and even later in the depot window (which would also remove a lot of entries ... ) Just with the default to the creation. And even regions could have their own setting, like the climates. I mean pak128.German uses climates to have the different regions of Germany. But it could use (which this system) also regional setting using its own strings for regions.

pak128 could have regions with country settings instead. Of course, a long term project.