## News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

## Re-scaling Simutrans

Started by jamespetts, July 21, 2009, 11:23:54 PM

0 Members and 1 Guest are viewing this topic.

#### jamespetts

I had not considered a non-linear system, but wouldn't that break lots of other things, all of which assume that things are linear? Wouldn't that also be very confusing and unintuitive for players? Also, I wanted to use realistic values for comfort: the only way to get a reasonable balance without doing an unfeasably enormous amount of testing is to use real-world numbers. Using real numbers for comfort and journey time also makes it much easier for players to understand.

Further, wouldn't a non-linear scale for calculating journey times make a mess of the routing system that uses journey times to calculate the shortest route, causing it to favour excessively a larger number of short journeys over the same distance rather than a fewer number of longer ones?

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Spike

Quote from: jamespetts on July 23, 2009, 09:25:44 PM
Further, wouldn't a non-linear scale for calculating journey times make a mess of the routing system that uses journey times to calculate the shortest route, causing it to favour excessively a larger number of short journeys over the same distance rather than a fewer number of longer ones?

It would indeed. Thus I'd suggest to leave the time as it is now, but for your new formulas, don't use time as input but x^time or time^x ... I'm sure people can imagine that a double as long travel is less than half as comfortable?

#### jamespetts

Hajo,

I'm afraid that I don't quite understand, I'm sorry - could you elaborate? I must confess, I am no mathematician, and somewhat shaky on low-level programming...

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Spike

Maybe I just talked stupid ... if you need the comfort level in routing decisions, and it is not linear, it might be a problem indeed. I've been out of this for too long, but maybe someone who is more into it, can check if a non-linear scaling could help?

#### jamespetts

I don't need the comfort level in routing decisions at present (but I want to retain it as an option for the future), but I need the journey times in routing decisions, and also for calculating (1) whether the journey is so long that passengers won't bother travelling at all; (2) how important that comfort is (for calculating revenue); and (3) how important that speed is (for calculating the revenue). To make things comprehensible for players, I want the average speed displayed on the "average speed" graph to be on a commensurate scale to any reference to kilometres in the game.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Hanczar

I tried 4096x4096 512xcities 128xindustries with default city size equals 1600, and it took about 2 min on release build.
When I increase size of cities to 50000 on choice map, it took about 15 min to create ( ~50min on gprof build ).

Run on:
AMD 64bit 5200+ (2Cores), 4GB Ram
Ubuntu 9.04 32bit
Simutrans Experimental 5.1

Gprof output from 4096x4096 512xcities 128xindustries with median citizens per city 50000 below
Memory consumed by simutrans after creating map was 830 MB.

Profile contains:
1. starting simutrans ( ~30s)
2. creating map  ( ~50min)
3. about ~3min freeplay without user action
4. saving map (~2min)
5. game exit ( ~20 s )

`Flat profile:Each sample counts as 0.01 seconds.  %   cumulative   self              self     total           time   seconds   seconds    calls  Ks/call  Ks/call  name     13.00    117.11   117.11 549407190     0.00     0.00  stadt_t::bewerte_loc(koord, char const*, int) 10.64    212.96    95.85 364706243     0.00     0.00  karte_t::lookup(koord) const  6.85    274.68    61.72    14224     0.00     0.00  karte_t::sync_step(long, bool, bool)  5.14    321.02    46.34 3704417418     0.00     0.00  int_noise(long, long)  5.13    367.21    46.20 3983280983     0.00     0.00  karte_t::lookup_kartenboden(koord) const  4.85    410.87    43.65   237557     0.00     0.00  slist_tpl<weg_t*>::remove(weg_t* const&)  3.55    442.85    31.98  6996965     0.00     0.00  display_img_nc(short, short, short, unsigned short const*)  2.99    469.74    26.89 31000511     0.00     0.00  planquadrat_t::get_kartenboden() const  2.64    493.49    23.75 431849510     0.00     0.00  karte_t::ist_in_kartengrenzen(short, short) const  2.51    516.10    22.61   417116     0.00     0.00  bauplatz_mit_strasse_sucher_t::find_dist_next_special(koord) const  1.73    531.66    15.56 2424424730     0.00     0.00  ding_t::get_pos() const  1.24    542.81    11.14 24962556     0.00     0.00  stadt_t::baue()  1.04    552.19     9.38   967778     0.00     0.00  hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::put(sync_steppable*, sync_steppable*)  0.94    560.68     8.49 915996195     0.00     0.00  grund_t::get_hoehe() const  0.94    569.17     8.49 2637349483     0.00     0.00  operator==(koord const&, koord const&)  0.94    577.62     8.45 411601927     0.00     0.00  smoothed_noise(int, int)  0.90    585.75     8.12 606167970     0.00     0.00  simrand(unsigned int)  0.80    592.98     7.23 1392724500     0.00     0.00  grund_t::get_weg(waytype_t) const  0.78    600.02     7.04 320128882     0.00     0.00  ding_t::get_flag(ding_t::flag_values) const  0.77    607.00     6.98        2     0.00     0.38  karte_t::distribute_groundobjs_cities(int, short, short)  0.76    613.85     6.85 2349165751     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator++()  0.75    620.63     6.79 328759854     0.00     0.00  planquadrat_t::get_boden_in_hoehe(short) const  0.75    627.37     6.73 2349165751     0.00     0.00  koord_distance(koord3d, koord)  0.74    634.05     6.68      542     0.00     0.00  slist_tpl<koord>::at(unsigned int) const  0.71    640.46     6.41 330637814     0.00     0.00  karte_t::lookup(koord3d) const  0.71    646.83     6.37 313375935     0.00     0.00  fussgaenger_t::sync_step(long)  0.65    652.68     5.86 755799640     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::next()  0.63    658.34     5.65 210929037     0.00     0.00  grund_t::get_vmove(koord) const  0.60    663.71     5.38 16777215     0.00     0.00  planquadrat_t::rdwr(karte_t*, loadsave_t*, koord)  0.60    669.08     5.37 316523988     0.00     0.00  vehikel_basis_t::fahre_basis(unsigned int)  0.54    673.96     4.88 1126814832     0.00     0.00  grund_t::hat_weg(waytype_t) const  0.49    678.38     4.42  3085439     0.00     0.00  get_aus_liste(vector_tpl<haus_besch_t const*> const&, int, unsigned short, climate)  0.48    682.71     4.33 2755450246     0.00     0.00  koord::koord(short, short)  0.47    686.91     4.21  2396339     0.00     0.00  brueckenbauer_t::finde_ende(karte_t*, koord3d, koord, bruecke_besch_t const*, char const*&, bool)  0.45    690.96     4.04 102900481     0.00     0.00  interpolated_noise(double, double)  0.44    694.93     3.98 42030290     0.00     0.00  binary_heap_tpl<route_t::ANode*>::pop()  0.44    698.89     3.96 137476790     0.00     0.00  stadt_t::bewerte_pos(koord, char const*)  0.44    702.82     3.92 2349582813     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator!=(weighted_vector_tpl<gebaeude_t*>::const_iterator const&)  0.42    706.64     3.82      542     0.00     0.00  slist_tpl<koord>::remove(koord const&)  0.41    710.35     3.71 46569685     0.00     0.00  grund_t::calc_back_bild(signed char, signed char)  0.41    714.03     3.69 2349165737     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::const_iterator::operator*() const  0.39    717.56     3.53 58107946     0.00     0.00  pixcopy(unsigned short*, unsigned short const*, unsigned int)  0.38    720.95     3.39 203741444     0.00     0.00  karte_t::ist_in_kartengrenzen(koord) const  0.37    724.30     3.35     5442     0.00     0.00  wegbauer_t::intern_calc_route(vector_tpl<koord3d> const&, vector_tpl<koord3d> const&)  0.37    727.61     3.31 105455715     0.00     0.00  grund_t::get_neighbour(grund_t*&, waytype_t, koord) const  0.36    730.82     3.21 1162947311     0.00     0.00  koord3d::get_2d() const  0.34    733.88     3.06 113961692     0.00     0.00  planquadrat_t::get_boden_count() const  0.33    736.85     2.98 23772308     0.00     0.00  hashtable_tpl<char const*, groundobj_besch_t*, stringhash_t>::empty() const  0.32    739.76     2.91 326629625     0.00     0.00  hashtable_iterator_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::next()  0.29    742.34     2.58 2401002969     0.00     0.00  slist_tpl<hashtable_tpl<char const*, groundobj_besch_t*, stringhash_t>::node_t>::empty() const  0.28    744.90     2.56 394409010     0.00     0.00  karte_t::lookup_hgt(koord) const  0.27    747.34     2.44 680559013     0.00     0.00  route_t::ANode::operator<=(route_t::ANode) const  0.25    749.63     2.29 308512111     0.00     0.00  stadt_t::bewerte_strasse(koord, int, char const*)  0.25    751.89     2.27 561700816     0.00     0.00  simrand_plain()  0.23    753.97     2.07  1672401     0.00     0.00  weighted_vector_tpl<gebaeude_t*>::remove_at(unsigned int)  0.23    756.00     2.04        2     0.00     0.06  karte_t::cleanup_karte(int, int)  0.22    758.00     2.00 40583965     0.00     0.00  wegbauer_t::is_allowed_step(grund_t const*, grund_t const*, long*)  0.20    759.85     1.84   900162     0.00     0.00  MTgenerate()  0.20    761.67     1.82 507734363     0.00     0.00  haus_besch_t::is_allowed_climate(climate) const  0.19    763.38     1.71 15174334     0.00     0.00  karte_t::ist_platz_frei(koord, short, short, int*, climate_bits) const  0.18    765.02     1.65 50622775     0.00     0.00  karte_t::access(koord)  0.18    766.65     1.63 426771711     0.00     0.00  ptrhash_tpl<sync_steppable*>::comp(sync_steppable*, sync_steppable*)  0.18    768.28     1.63 342388308     0.00     0.00  koord3d::koord3d()  0.18    769.91     1.63 329983232     0.00     0.00  ding_t::set_flag(ding_t::flag_values)  0.18    771.53     1.61 454396529     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::get_current() const  0.18    773.12     1.59 546432400     0.00     0.00  karte_t::ist_in_gittergrenzen(short, short) const  0.17    774.68     1.56       91     0.00     0.00  setsimrand(unsigned int, unsigned int)  0.17    776.23     1.54   685454     0.00     0.00  display_img_wc(short, short, short, unsigned short const*)  0.17    777.75     1.53   967831     0.00     0.00  hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::remove(sync_steppable*)  0.17    779.27     1.52 600437204     0.00     0.00  operator==(koord const&, koord const&)  0.17    780.79     1.51 811692728     0.00     0.00  grund_t::get_grund_hang() const  0.17    782.29     1.50 16781312     0.00     0.00  planquadrat_t::~planquadrat_t()  0.17    783.78     1.50 298990603     0.00     0.00  slist_iterator_tpl<hashtable_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::node_t>::access_current()  0.16    785.25     1.47 50361612     0.00     0.00  karte_t::calc_natural_slope(koord) const  0.16    786.65     1.40 339770087     0.00     0.00  dingliste_t::bei(unsigned char) const  0.15    788.02     1.36 163078008     0.00     0.00  dingliste_t::get_top() const  0.15    789.38     1.35 44949134     0.00     0.00  binary_heap_tpl<route_t::ANode*>::insert(route_t::ANode*)  0.15    790.72     1.34 326615405     0.00     0.00  hashtable_iterator_tpl<sync_steppable*, sync_steppable*, ptrhash_tpl<sync_steppable*> >::get_current_value() const  0.15    792.06     1.34 27655731     0.00     0.00  hausbauer_t::get_special(int, haus_besch_t::utyp, unsigned short, bool, climate)  0.15    793.38     1.32 174228472     0.00     0.00  marker_t::ist_markiert(grund_t const*) const  0.15    794.70     1.31 17150081     0.00     0.00  perlin_noise_2D(double, double, double)  0.13    795.91     1.22 62590928     0.00     0.00  karte_t::max_hgt(koord) const  0.13    797.12     1.21 245128128     0.00     0.00  operator+(koord const&, koord const&)  0.13    798.33     1.21 804865381     0.00     0.00  boden_t::get_typ() const  0.13    799.52     1.20 594593471     0.00     0.00  slist_iterator_tpl<haus_besch_t const*>::next()  0.13    800.71     1.19 146899693     0.00     0.00  operator+(koord3d const&, koord const&)  0.13    801.88     1.18                             non-virtual thunk to fussgaenger_t::sync_step(long)  0.12    803.00     1.11 179042014     0.00     0.00  boden_t::ist_natur() const  0.12    804.11     1.11 34200191     0.00     0.00  freelist_t::gimme_node(unsigned int)  0.12    805.15     1.04    14227     0.00     0.00  karte_ansicht_t::display(bool)  0.11    806.17     1.02 414274897     0.00     0.00  grund_t::get_weg_hang() const  0.11    807.18     1.01 464087130     0.00     0.00  koord3d::koord3d(short, short, signed char)  0.11    808.20     1.01 16789631     0.00     0.00  karte_t::raise_clean(short, short, short)`

EDIT: profile result moved in code section

#### prissi

YOu took also quite a time to set everything, as simutrans spend more than in minute in sync_steps()? Im am surpirsed than 3 minutes of free running required nearly 30% of the total time.

#### jamespetts

So it seems that stadt_t::bewerte_loc(koord, char const*, int) is the culprit. The question is: are there any possible optimisations for this method?

Thank you very much, incidentally, Hanczar for running this test - very useful!

Edit: One possible optimisation that I have already spotted is to change the int argument to a uint16 - would this break anything?

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### jamespetts

How scaling is implemented

The new version 6.0 of Simutrans-Experimental now implements the new scale feature. The way that it works is that there is a setting in simuconf.tab (replacing the old "journey_time_multiplier_percent") called "distance_per_tile". This designates the number of meters that each tile represents, in multiples of 10. So, at the default of distance_per_tile=25, each tile represents 250m, or 1/4 of a kilometre. To use the scale from Simutrans Standard, one can simply set distance_per_tile=100, which is 1km/tile. To check the scale used in the particular game, one can use the map window and "show map scale", which will show the current scale in tiles per kilometre. This value is saved with saved games.

All of the following values from paksets are assumed to be in kilometres and are adjusted accordingly when the pakset is loaded to the appropriate per-tile values for internal use, the UI showing the per kilometre values where appropriate:

• Goods/passenger revenues
• Vehicle running costs (not the fixed maintenance)
• Way building costs
• Way maintenance costs
• Tunnel building costs
• Tunnel maintenance costs

Note that bridges are not subject to this scaling on purpose: the scale is more accurate when used with per tile values for bridges than for per kilometre values (bridges are hardly ever many kilometres long, and there would be insufficient granularity for bridge lengths).

Also, all distance based settings in simuconf.tab, such as those relating to the distance ranges of short, medium and long distance passengers, are now in kilometres and not tiles. They are stored internally as tiles, but read from the file as kilometres.

Thus, there is now automatic and accurate correlation between the speeds, the distances and the journey times, all of which use real-world figures and are calibrated with realistic values. There is a particular advantage of that, which is that, if fantastical values were used, an enormous amount of trial and error testing would be needed to ensure that they were calibrated correctly with one another. With every new set of values, the complexity of testing them all against each other would increase exponentially. Simutrans-Experimental introduces a great many new values that need calibrating, and it would be impracticable to test them all in that way. Using real-life values, however, one can just get real world data to calibrate them. One can obtain the real-life building costs of a kilometre of railway track and compare that to the real life cost of running a particular 'bus for one kilometre, or hauling a ton of coal for one kilometre.

Not only are real-world values easier to calibrate, but, if real-world values are used, it gives players who are new to Simutrans but know about real-life transportation the ability to use their actual knowledge to make sensible decisions in the game. People ought not have to learn a great deal of game-specific rules to play a simulation game: real life knowledge should suffice wherever possible. Similarly, if real-world values are used, players can learn about reality simply by playing the game, which makes playing rather more satisfying.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Isaac Eiland-Hall

How does this relate to, for example, city sizes? If I were to set distance_per_tile=24, I'd assume I'd need to quadruple the city populations to get the same effect?

#### jamespetts

Yes, you should indeed increase city sizes from what is the norm in Simutrans-Standard to get the balance right in Simutrans-Experimental with the distance_per_tile at a lower setting (including the default of 25). It does not necessarily have to be quardupled, however: if you increase the number of cities and do not disable the feature that will make cities more likely to spawn on lower grounds, you will often tend to get larger urban areas comprising a cluster of a number of individual towns and cities in some places, which is rather more realistic than having single large cities evenly spaced throughout the terrain.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Soldim

I have read this thread with some interest, since while I enjoy playing Simutrans, there is some features that are slightly unrealistic. A truck, and even most trains, do not need 2 km to get up to speed. And, living in a moderate sized European city, I think most people would think they'd die if they had to walk up to 1.5 km to the nearest bus-stop (I'd be good for them, but that's something else!). Hence, there's a slight scale issue

The post that made most sense to me is:

Quote from: prissi
Simutrans could have a 3D map with a 16x16 mesh on a single tile which could give 16 times larger maps wihtout loosing to much detail level, imho. But that is ratehr a new effort which would be only loosely built on Simutrans.

Fortunately, I am not a programmer, so I can have the most ridiculous ideas without having to feel guilty because it is not feasible; I was thinking about something among the lines described by Prissi, where a city tile would represent a certain distance, and a 'country-side' tile another distance. As long as cities are static, that would probably even be feasible, as soon as they start expanding I guess that's a programming challenge. Setting aside a certain amount of space for a city might be an option, but has of course other disadvantages.

The 16x16 mesh as proposed by Prissi would of course be ideal, but as I understand not too easy to implement with the current code (like my proposals are )

Regardless, keep up the great work!!

#### jamespetts

Ahh, it's not really feasible to have different distances in and out of cities: the inconsistencies in scale would lead to bizarre anomalies (a road/rail line going through a city would be much longer than one going around a city, even though the former is a straight line and the latter a detour, and so on). The 3d system is theoretically possible, but it would require an unimaginably enormous amount of effort, not just coding (although that would be gargantuan in itself), but re-doing all the thousands upon thousands of graphics from scratch.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Fabio

Quote from: jamespetts on July 29, 2009, 08:08:02 AM
The 3d system is theoretically possible, but it would require an unimaginably enormous amount of effort, not just coding (although that would be gargantuan in itself), but re-doing all the thousands upon thousands of graphics from scratch.

i would think of a mixed system, with the terrain full 3D (a very loose mesh, the tile grid), to save memory and adding more realistic reliefs. All the objects (with the possible exception of ways), instead, should be our beloved sprites. vehicles could then drive on the mesh in 8 views and buildings would need a 3D basement (like now on slopes).

#### Michael 'Cruzer'

Quote from: fabio on July 29, 2009, 09:41:55 AM
i would think of a mixed system, with the terrain full 3D (a very loose mesh, the tile grid), to save memory and adding more realistic reliefs. All the objects (with the possible exception of ways), instead, should be our beloved sprites. vehicles could then drive on the mesh in 8 views and buildings would need a 3D basement (like now on slopes).

With your 'mixed' system all streets, brigdes and tunnels have to redone too, because they depend on slopes!
Founder and Ex-Maintainer of pak192.comic. Provider of Simutrans Hosting rental service.

#### Fabio

still they are a smaller amount. and they could also be replaced by real 3D roads+texture, possibly using Timothy's algorithm for curves.

#### jamespetts

Fabio,

if you want to do all the coding and re-drawing for all the paksets, and/or can find people who can, be my guest... Even that suggestion would, at best, mean that, instead of being a very, very, very, very large amount of work, it would just be a very, very large amount of work. Coding and pakset building resources are currently very limited.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Fabio

well, we could have a "gradual" approach to this issue.

1) the terrain can be seen as a 3D mesh. a mesh could reproduce the current terrain: grid 1 tile * 1 tile and 1 in height. textures would apply depending on climate settings, plus shadows on-the-fly. no change to the appearance, so no need for changing graphics at all. terrain is (if possible) a single object, could this reduce the memory consumption?
terraforming only changes the nodes of the mesh.

2a) as a second step, in future, multiple heights could be allowed (half, doulbe, triple, etc.).
at this stage, only half height should imply new graphics and only for half heights (as for steeper slopes no roads would be allowed, maybe excepting powerlines).

2b) as another option, heights could be made freeform, this would imply completely new ways. but this step could never come.

in any case, the tile-based system wouldn't ever change, nor would buildings and vehicles.

#### jamespetts

It would still require more coding than available resources presently permit, unless you are able to increase those available resources...

(At present, the focus is on bug fixing, balancing and pakset production to get at least a working, balanced version with a fully compatible pakset released as a complete package).

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Fabio

being (at least at the first stage) player-transparent, we should also see the cost/benefits ratio, considering programming time as a cost and resource saving as a benefit. also being open to further development is a potential benefit.

for sure it's not (top) priority, but if the ratio is positive, it could be considered as a mid-long term investment.

#### jamespetts

If we find anyone capable of programming graphics to that level, willing to invest that much in the way of resources. Certainly, I wouldn't have a clue where to start graphics programming - my geometary is hopeless.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Spike

If you use OpenGL it will do all the geometry transformations for you. The world would be made of quads, that is the openGL equivalent of a tile, or maybe triangles, two of which can shape a tile.

#### TrainMith

My two cents...  If using OpenGL then the updating of the ground tile textures for seasonal changes would be shortened, due to the benefits of the graphics card memory and processor.  I honestly don't recall at the moment if unaccelerated OpenGL would take too great of a performance hit, though.

#### Spike

Unaccelerated OpenGL (I translate this to "software emulation" instead of using hardware to render) uses to be very slow. Linux users can test the Mesa library to get an idea of software OpenGL rendering speed.

But many systems should support OpenGL these days and if I ever make a 3D game I guess I'll use OpenGL. At least I got good results with C and Java OpenGL bindings.

#### Mazze

Hello together!

What I not yet completely understand: Is now "everything" (like speeds, distances, time, station coverage, vehicle size) in Simutrans-Experimental true to scale with this feature?
And if not, why not?

Greetings,

Mazze

#### jamespetts

Distances, revenues and costs scale in Simutrans-Experimental. It does not make any sense also to scale time by the same rate, as scaling everything equally would have no effect on anything, and would be pointless. Because distance, but not time, is scaled, speed cannot be fully scaled. Acceleration is, however, from Simutrans-Experimental 7.1 and onwards, scaled with the distance. Station coverage is not scaled because it needs to be customisable independently of the scale, and it would be confusing to specify such short distances in meters in simuconf.tab rather than tiles. However, the default setting of 3 tiles in Pak128.Britain-Ex's simuconf.tab takes into account the fact that the scale for Pak128.Britain-Ex is 250m/tile (or 4 tiles/km).

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### Mazze

#61
Thank you for your explanation. I was a long-time Simutrans player (quite some years ago already), I'm now coming back -- at least at the forum, not yet playing -- because of Simutrans-Experimental sounding that promising.

Maybe I quirked it a bit up when talking about "scaling time", but what I meant was, are trains -- when running at 100km/h -- travelling 100km in Simutrans in one fictional Simutrans-hour? And of course I know, that it does not make sense to have "1 fictional Simutrans-hour = 1 realtime hour", but if it was "1 fictional Simutrans-hour = 1/6th of a realtime hour" the factor in time would be 1 to 6, and the train travelling at 100km/h should go as far as 600km in one realtime hour. This would allow for more realistic scheduling and gameplay -- and the use of real-worls values instead of fictional ones.

I have two things I've thought of that are depending on my question above, and I'm sure, the second one was already denied earlier, but I just wanted to give it a short try here for Simutrans-Experimental:

*) Why don't we make station-coverage degrading the farther we get from the station? This could attract people near the station more, but would only attract some of those living further away. This would make up for a more realistic station planning and placement, which is not just build upon trying not to miss any tile, and every tile that you hit is a 100% hit. The coverage could also be depending on the station-type if this would resemble anything that makes sense, or on the length of the journey somebody wants to make (for a long journey, you are maybe more likely to accept a bit of a way than for a short inner-city ride).

*) When scale in Simutrans-Experimental is now true, and time is just representatively faster in a defined and maybe during gameplay changeable factor, it would be really attracting to me to have the option of schedules. This would include scheduling of not just arrival and departure times of trains or other vehicles, but also implicite planning of a station stop's occupation, trying to make good connections for important routes so that nobody has to wait too long for connecting lines, and the situation of vehicles being late. Of course it would make sense then, that passengers try to take a route which costs less time and money, depending on their connections.

For the first part of my post, I just wanted to be sure I understand the features and the work of relation of time and distance in Simutrans-Experimental correctly, for the second part, it is more something like a wishlist, and I wanted to contribute something to this great game I always liked very much already.

Have a good time,

Mazze

#### jamespetts

Mazze,

thank you for your interest in Simutrans-Experimental. Subject to the fact that there are, and always have been, two independent time scales in Simutrans (albeit standing in a fixed relationship to each other): the macro (passage of years for the purposes of billing and technological advancement); and the micro (the passage of hours, for the purpose of speeds, journey times and waiting times), the speeds and distances are all internally consistent at any scale, such that, at a speed of X km/h, a convoy will travel X km in one hour on the micro scale.

As to your suggestions, the former might be worth considering at some point (along with the possibility of different kinds of stops having different coverage radii), although adding new such features is not a high priority at present, as there are a number of playability issues and bugs that need to be ironed out, I need to help to make Pak128.Britain-Ex more complete. I shall bear it in mind for the future, however, if it can be implemented without overly degrading performance. One potential issue is how to represent this easily in a relatively simple GUI.

The second suggestion is more problematic, since introducing timetabling is likely to make playing Simutrans efficiently enormously difficult: real-life timetables require extraordinarily expensive and complex computer software to perfect, and, in the days before computers, skilled mathematicians had to spend days, weeks or months agonising over every detail. The complexity of the task increases exponentially with the complexity of the network, so that, for a network complexity of N1 and a timetable complexity of T1, a network complexity of N2 would produce a timetable complexity of N4, and a network complexity of N10 would produce a timetable complexity of T2,048.

Thank you for the suggestions, though: much appreciated. Do enjoy playing Simutrans-Experimental!

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### knotwork

Hi. I joined the forum because of this thread.

It touched upon so many points of interest.

As to the original concern regarding grouping transportation into distance and comfort classes with distance impacting comfort where I come from causes me to immediately consider what possibly could amount to a variant of the holographic universe concept, but thinking lines (map edges) could encode surfaces (neighboring maps) rather than (as in many holographic universe discussions) that surfaces could encode volumes.

Where I come from is the Galactic Milieu, in which probably the most "immediate" contemplated use of Simutrans or its ilk would be to pick some particular FreeCiv planet and designate some tile or tiles of that larger surrounding world to be "where" a particular Simutrans game supposedly is taking place.

So. Suppose you have a lovely set of long-distance vehicles but running a large enough Simutrans map for them to really "shine" is impractical. Enter the universe-at-large, that which lies beyond the borders of the map.

Could "neighbors" outside the map maybe even be treated ("simply"?) as Industries?

Maybe each "neighbor" industry could have an associated "comfort level typical out there in that direction at least if you use this neighbor industry to send folks there and hope they will return". Your ideal neighbor industry to supply with visitors would be one your travellers seem unlikely to prefer to coming back here, once they have gone "out there" and experienced how much more comfortable it is to come right back here than to travel around out there, find a job out there, emigrate out to there and so on, plus in order that this mechanic be worthwhile for tycoons "here" to "invest" travelers into it your comfortable travelers visiting "out there" could possibly serve as advertising to who-ever resides out there, luring them into trying your comfortable long distance transportation to come see how folks "here" live...

(In other words, it would be an industry that could send you back more folks than you deliver to it.)

Now as I said there was much of interest to me in this thread. Also it seemed to me as I read it "aha here seem to be the folks I should be communicating with here in Simutransia"; so I am hoping this will not be just a hit and run resurrection of a long-dead thread but, rather, a springboard onward into various interesting topics...

-MarkM-

#### freddyhayward

This thread (https://forum.simutrans.com/index.php/topic,19834.msg187280.html#msg187280) might be of interest to you.
Achieving the effect you describe would be quite difficult. Passengers currently respond to overall journey time rather than comfort, and trips between two locations are symmetrical - there is no concept of migration.

#### knotwork

Hmm. Am I to understand then that the features with reference to which James began this thread, "In short, to make the most out of Simutrans-Experimental features that use the absolute values of journey times (in particular, comfort, catering and journey time tolerance)", in particular comfort and catering, either did not in fact make it into Simutrans-Experimental or have since been phased out thereof?

The thread that you suggest seems to be located, by the forum category hierarchy shown near the top of page when viewing that thread, not to fall into a specifically non-experimental Simutrans section but given the primary title of the forum it is not yet clear to me whether the fact that it seems not to fall within the section specifically devoted to Simutrans-Experimental implies that it really ought not to refer to the Experimental offshoot.

In the bitcointalk forum from whence I also hail, talk of "altcoins" is verboten outside the altcoins section; bitcointalk is about the real thing and offshoots, known as altcoins, were so unwelcome that many folks objected even to their being provided their own "ghetto" within that exalted venue. My initial impression of this forum had been that talk of the Experimental offshoot was not that unwelcome outside its own section? The post you refer to definitely is interesting though for its reference to that which lies beyond the map.

The contemplated use, which brought me here, that I have in mind for any and all free open source games that I find (that actually work) specifically involves embedding them within a larger context; a "meta-game". Thus any means of interaction with that which lies beyond is necessarily of potential interest to me.

For a game along the lines of Simutrans, such embedding bids fair to offer a mechanism other than simple calendar date by which to determine the advent of new technologies, inasmuch as instances of such games need not necessarily be set in the past; a new technology could come into play beyond the map whose year of advent was not known when the Simutrans game began but which play at the larger scale determined does in fact become available.

-MarkM-

#### jamespetts

Welcome to the forums and thank you for your contribution. As you may have noted, Simutrans-Experimental was renamed to Simutrans-Extended in 2017, whereas the last post in this thread before your recent reply was 2010, which might explain the confusion as to the name.

In relation to comfort influenced routing, this has not yet been implemented as it has proven to be a very significant technical challenge, mainly arising out of the fact that implementations that would not give rise to anomalies would be liable increase computational load to an unacceptable extent. The greatest problem is that, for efficiency, the current system allows only one route between any given origin and destination pair, so it is not possible to have different passengers who prefer different levels of comfort to affect the routing choices. I had thought a year or two ago that it might be possible to have one set of routes that take into account comfort and one set that does not, so that some passengers might always prefer speed and others might prefer a balance of comfort and speed, but this was found to be impractical in light of the excessive time that refreshing the routing data already takes in large games.

In light of recent experience in the online game, where one player preserved open top railway carriages from the 1850s into at least the 1940s because they had a better capacity to weight ratio than their replacements, the topic of comfort influenced routing has been considered afresh recently, in particular, whether such anomalies as there may be from having all passengers use a mix of comfort and speed for routing (including that no passengers will take the fastest route in some cases, even if the comfort/speed balanced route is not within their journey time tolerance, whereas the fastest route is) will be less than the current anomalies described above. This might be achieved by using a combined comfort/speed metric and having journey time tolerances expressed in this metric. Comfort influenced routing would probably need to be optional given its potential capacity for anomalies.

As to the idea of integrating Simutrans-Extended and other games into a meta-game, that is very interesting in theory, but I am not sure how one might achieve it in practice.