meters_per_tile for standard?

[Donald C.]

Simutrans extended has a meters_per_tile setting, which allows me to play in more detail, and makes underground subway feasible. I don't know why they still don't implement this into Simutrans standard.

I like having the cities in more detail, but I don't want to use extended because 1)it's not available in pak128.german, which I think is the most sophisticated pakset 2)the cities in extended are all in a weird rectangular shape, cutting off in a straight line.

One "resolution" is simply setting the median population per town to 12800, which is 8 times higher than default, to make the game build cities 8 times larger, which I currently do in pak128.german, but this will create too much passengers.

How difficult is it to implement it to standard?

[ceeac]

One "resolution" is simply setting the median population per town to 12800, which is 8 times higher than default, to make the game build cities 8 times larger, which I currently do in pak128.german, but this will create too much passengers.

You can lower "passenger_factor" in simuconf.tab, but this only works for passengers, not mail or freight.

[neroden]

FWIW, meters_per_tile is implemented wrong in extended (SIGH) and I've been planning to rewrite it for a decade.  I might try to get it into Standard AFTER the rewrite

[prissi]

I am not sure what metres per tile should do as the units are exactly used nowhere in the code. It does not make sense either as the scales of roads and buildings do not match with distances and passenger numbers.

[jamespetts]

Standard implicitly has a relationship between meters and tiles, as there is a consistent ratio between in-game time, in-game vehicle speed and the number of tiles that a vehicle passes in any given unit of in-game time at any given speed. Extended simply made this explicit and modifiable, and then added other systems that depend on the outputs from this relationship, such as journey time tolerances.

I think what Neroden envisages is a much more comprehensive rewrite of some quite fundamental systems to have a system that gives out rounded numbers and increases the extent to which this can be customised (perhaps by altering the speed with which vehicles move in the game depending on the chosen time-base). I can see the advantages of this approach (although a disadvantage would be that there would be more divergence from Standard code, making future merging more difficult - this does not necessarily outweigh the disadvantages, but is worth bearing in mind), but the work involved will be enormous, even for a skilled professional coder such as Neroden. It was certainly beyond what I was realistically able to do back in circa 2009 when I implemented the meters per tile setting - and we have been able to have good use out of journey time measurement related features in Extended ever since.

(In Extended, while the meters per tile system does not match with the visual scale, it is internally consistent and consistent with the actual in-game speeds of vehicles, so it is the basis for a workable and consistent simulation).

I should note, however, that, so far as I understand it, Standard has a different set of design goals to Extended, focussing on a simpler game-play style and traditional synthetic balancing (rather than the aim of Extended, which is to use balancing data from the real world), so the implementation of a feature such as an explicit relationship between time and distance may not suit the intended play style of Standard. Indeed, I do not think that there are any features in Standard that would make use of this relationship, as nothing in Standard measures journey times or allows set timetables, etc..

[prissi]

Standard has the bits per month setting which changes the relation of tile passed per game time. However, unless this is set to ridiculous high values, the distance in the game will be always too short.

[jamespetts]

Standard has the bits per month setting which changes the relation of tile passed per game time. However, unless this is set to ridiculous high values, the distance in the game will be always too short.

Yes - the game time in Standard is the long time scale measuring years and months. There is also another, shorter, implicit time scale in which vehicle movements are measured. This scale is made explicit in Extended and the relationship is set using the meters_per_tile parameter. Extended uses this explicit, short timescale in lots of ways that do not exist in Standard (such as passengers and goods choosing which route to take based on the quickest journey and journey time tolerances). Hence, the meters_per_tile setting makes sense in Extended, but there are no features in Standard for it to work with.