The International Simutrans Forum

 

Author Topic: Simutrans and Simutrans Experimental relation  (Read 9659 times)

0 Members and 1 Guest are viewing this topic.

Offline EnternalD

  • *
  • Posts: 33
Simutrans and Simutrans Experimental relation
« on: November 19, 2011, 01:28:39 PM »
As I know Simutrans Exp. branch has been created to incorporate changes that was never considered to add to mainline Simutrans. As Simutrans progress, would some Simutrans experimental features ever come Standard?
Or they always be Simutrans and Simutrans 1.5, never to exchange features from Exp->Standard ?
While economical model in Simutrans experimental would broke everything, some less radical changes could be incorporated, specifically those who do not require radical pak hacking (even then some switches could be ignored if pak does not propose these).
In example replace vehicle dialog would be awesome feature to have even without ability to purchase locomotive upgrades.
Also minor gameplay alter also wouldn't hurt: locomotive turning time, or loading time would be new mini challenge to network planing even without only one locomotive turning time and one loading time per tonne (independent from carriage or locomotive type to prevent need for massive pak reworking).
Well if Simutrans experimental is going ever to supersede Simutrans standard, then it is clear that porting back features would be waste of effort and time.

So how two projects are related and what is future of the Experimental?

P.S. Please don't understand this thread as feature request or blame, I'm just wondering about SimEXP's future.

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 9622
  • Languages: De,EN,JP
Re: Simutrans and Simutrans Experimental relation
« Reply #1 on: November 19, 2011, 09:00:23 PM »
The vehicle upgrade dialogue was not added for several reasons; most of it that usually the updated is with a lesser number of vehicles or longer trains and then also would require track changes.

The turning times and so on are not significant for the transport simulation and rather additional annoying. Basing the loading time on the amount of goods loaded: Is possible, but again would not change gameplay. In order to keep gameplay simple and focussed on transport, in simutrans standard those are left away.

Some stuff might be implemented for standard too, like weight limits for bridges and ways or an additional fixed maintenance per month. The routing of standard will change so goods prefer connections with better service (this has already progressed a lot). But those two codes are no so far away all those will be done rather be new implementation than by backporting.

Offline Severous

  • *
  • Posts: 377
Re: Simutrans and Simutrans Experimental relation
« Reply #2 on: November 19, 2011, 09:09:15 PM »
The very name 'experimental' suggests things are being tried out..tested..that its not yet ready for full release.  Is that the case?  I saw experimental 2 years ago and its still 'experimental'. 

As EnternalD asked..'what is the future of the Experimental'?  Might it be released as a stable 'advanced' version of Simutrans?

Offline VS

  • Senior Plumber (Devotee)
  • Devotee
  • *
  • Posts: 4855
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Re: Simutrans and Simutrans Experimental relation
« Reply #3 on: November 19, 2011, 10:56:44 PM »
Here we're getting to the more nasty aspects of std/exp... The following will be very subjective, but hopefully also give some insight into the relationship to someone who "came later".

Originally, exp. started as a version with all the rejected patches. Thus, there is a deep political divide in the sense that lots of what constitutes exp. won't be merged back at all. Thus, it cannot really un-become "experimental".

At this point, the names are just labels. Perhaps more accurate names would be "conservative" and "all-inclusive" (although that is likely subjectively biased). Still, perhaps even better way to describe the two would be as projects driven to visions of prissi and James, respectively. These are different and the paths divergent...

I think there will be certain things loosely copied to std. now and then, but compared to the bulk of differences, not really an important amount.

Neither of the two will go away, unless something happens to people in charge.

That's how I see it.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #4 on: November 20, 2011, 12:45:37 AM »
Simutrans-Experimental is a fork of Simutrans, intended to provide a more in-depth simulation of the economic and operational aspects of transport. The name "Experimental" comes from a time very early in the development when I was just experimenting with new features. I do plan for it to change its name one day to "Simutrans-Extended", which I hope that both current Experimental players and Standard developers will agree is an accurate description (in the sense that it contains many things not in Standard; the desirability of those things is a matter apart), but I should like for it to become more mature before I do that, especially in the realm of economic balancing, which still needs some work. Experimental is still somewhat work in progress, although it is perfectly playable in its present state.

Dealing briefly with some of the specific aspects raised by Prissi: the vehicle replacer code (originally written by Isidoro) actually deals with the issue of replacing smaller vehicles with bigger ones and thus needing fewer, by allowing players to skip certain replacements, or replace a larger number of convoys with a fewer number; in any event, in many (indeed, in my experience, most) cases, one replaces convoys with more or less the same number of new ones.

Reversing times, I believe, are important for a transport simulation, as they are an important differentiator of different types of vehicles, especially rail-type vehicles: a tank locomotive can turn more quickly than a tender locomotive, but tank locomotives weigh more and tend to be less powerful: a multiple unit can turn around much more quickly than a locomotive hauled train, but is less flexible, and early multiple units were not suitable for long-distance running, and so forth. The turnaround speed is important in conditions of intensive service, and, in Experimental, timing matters a great deal, because the shortest overall journey time (including waiting time) determines the route that passengers/goods take, and passengers/goods have a maximum journey time tolerance, which means that more frequent, faster services can obtain significantly more market share. This incentivises players to make their networks more efficient in realistic ways.

Of course, these do make Simutrans less simple, and, for those who prefer a simpler play experience, Standard is still available; indeed, the consequence of the forked development is that players now have a choice between the simpler Standard and the more in depth Experimental. Because of the divergence of the codebase to which Prissi refers, Experimental features do not tend to be backported, but experience with Experimental has informed some new Standard features, and may well continue to do so.

As to the future of Experimental, in the short term, I am currently working on the release of the next version, 10.4, which has unfortunately been delayed by a bug in the calculation of revenue that I have had some difficulty tracking down. This new version should, when released, be compatible with Timothy's new online listings server, allow player colours to be saved and transmitted over the network, allow players to charge other players for travelling over their ways on the basis of a proportion of revenue (in Standard, the options are by proportion of running costs or proportion of way/way object maintenance costs or some combination of the two), allow players to allow or deny access for other players to their networks, to enable joining of networks without the use of the public player, optionally prevent any player other than the public player from making stops or ways public, and returning convoys with no route to a depot automatically after a period of time (to avoid logjams in semi-unattended multiplayer games, which would be more likely in cases where access rights are withdrawn). Subsequent near future versions will include an updated means for calculatng revenue (based on different rates for different distances) and a physical model for braking (written by Bernd Gabriel), which will differentiate between different types of vehicles' braking force, which will substantially affect the performance of such vehicles in practice. In the longer term, see here for a list of planned projects.
« Last Edit: November 20, 2011, 12:53:42 AM by jamespetts »

Offline missingpiece

  • *
  • Posts: 100
  • Languages: DE, PT, EN, FR
Re: Simutrans and Simutrans Experimental relation
« Reply #5 on: January 28, 2012, 08:31:33 AM »
Thanks for the explanations - they precisely answered my question, too.
Experimental is still somewhat work in progress, although it is perfectly playable in its present state.
So with experimental not (any longer) being the test bed of features but a playable fork with its own intensions, would "experimental" not merrit of its mentioning on the simutrans.com website ?

Offline Spike

  • *
  • Posts: 1361
  • First Simutrans Developer and Graphics Artist
Re: Simutrans and Simutrans Experimental relation
« Reply #6 on: January 28, 2012, 12:39:11 PM »
I'd like to call "Standard" "Simutrans classic", and keep if needed replace "experimental" with "progressive", but "extended" makes it sound much like the normal version would be missing something. I'm pretty sure that Prissi does not think it is missing something, so we should avoid this connotation, and try to find words that explain that experimental is more aggressive on new features, but not make "classic" appear to be lacking.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #7 on: January 28, 2012, 12:49:50 PM »
Hmm - I'm not sure about "progressive", as it has connotations of left-wing politics! One of the advantages of "extended" is that it begins with the same two letters as "Experimental", which would help to make it easier to remember. The idea attempting to be conveyed is that this version has things that Standard doesn't have - whether the game is better with them or without them is a matter of preference. Is there another word, I wonder, that carries that implication?

Offline Spike

  • *
  • Posts: 1361
  • First Simutrans Developer and Graphics Artist
Re: Simutrans and Simutrans Experimental relation
« Reply #8 on: January 28, 2012, 05:38:59 PM »
I've been thinking about this for a while, and came to another example, how to make fork names "politically correct"

There was a game named "Dungeon Crawl" - ascii based dungeon exploration/hack&slash game. Development stalled for a while, and then was picked up (by I believe another group of people) again, and the successor now is called "Dungeon Crawl Stone Soup". While this might be silly, it avoid the better/worse judgement. The old one is "Dungeon Crawl", the new one "Dungeon Crawl Stone Soup". And it's about as hard to digest as stone soup  ;)

No idea if this is a good example, but it came to my mind when I was thinking about useful words. How about "Simutrans Iron Bite" :D

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #9 on: January 28, 2012, 05:48:03 PM »
Hmm, interesting idea. I do prefer a name that explains the difference, though, and doesn't leave users wondering what it means. I took the view that "extended" means "more", but not necessarily "better". I'd be interested in other people's views on this, however.

Offline wlindley us

  • Devotee
  • *
  • Posts: 981
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Simutrans and Simutrans Experimental relation
« Reply #10 on: January 28, 2012, 05:58:24 PM »
"Simutrans Standard" and "Simutrans Extended" seem difficult to improve.  As long as it's not "Simutrans Extreme Edition" (ugh).

Would it be desirable to recode makeobj so that pak authors can create a single pakset that works for either edition, with makeobj choosing the correct options or factors for whichever version you specify?  It sure would be nice to have just one repository from which both Pak128.Britain and Pak128.Britain-Experimental could be created.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #11 on: January 28, 2012, 06:07:09 PM »
Hmm - could this not be done with makefiles or scripts rather than by altering Makeobj?

Offline VS

  • Senior Plumber (Devotee)
  • Devotee
  • *
  • Posts: 4855
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Re: Simutrans and Simutrans Experimental relation
« Reply #12 on: January 28, 2012, 07:29:08 PM »
You could add a set of keys that have some unique prefix (creating a de facto namespace), are recognized only by experimental makeobj, and that override these with standard names. A quick and stupid hypothetical example:

Code: [Select]
obj=vehicle
waytype=track
engine=diesel
speed = 60
power = 600
gear = 150

exp-gear = 100
power_curve = shunter

So, here's a shunter loco that appears weak with standard's formula (thus the gear), and experimental cures that with some advanced parameter. But the gear should be default then, and is overridden by exp-gear.

The implementation would just retrieve a parameter and then overwrite that with another, if present. Actually, since these are picked by a string name, you could even build this overriding into the retrieval function, which would return the already overridden value. With the same prefix everywhere, this would be pretty much automagical - exp-image[...], exp-weight, exp-obj :P

edit: For other readers, lines that are not recognized by makeobj are ignored, so a dat file using unknown parameters could still be used by both versions of makeobj. This means that standard would not have to change anything.
« Last Edit: January 28, 2012, 07:37:15 PM by VS »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #13 on: January 28, 2012, 08:06:05 PM »
Hmm - this looks as though it would be rather a lot of work, when there are other more pressing priorities at present.

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 9622
  • Languages: De,EN,JP
Re: Simutrans and Simutrans Experimental relation
« Reply #14 on: January 28, 2012, 09:43:50 PM »
Ok, since this can of worms was opened:

Until simutrans-exp can load most of my savegames without crashing at loading time, I will still call it experimental. Due to the optimisations of Knightly, the routing is not more time consuming than standard. But sim-exp still has several memory leaks (during one hour fast forward it consumed nearly 400 MB extra. Not sure if this is fixed; but it must be fixed for a server.) I posted those bugs a while ago. In a recent test sim-exp still crashed often only loading random old games.

The completely unphysical behaviour of curves and slopes puts me also off. A single slope is almost not noticed, while a curve is worse. In reality, a train does not care about curves until it is faster tahn 140 km/h, and the same is true for cars.

And a novice with sim-exp will see options like "city cluster size" in the starting screen, and for many languages there is no translation. If those points are addressed, then go extended. But before I feel experimental with sim-exp, sorry.

Seeing Hajo so pricky with standard, I really wonder about those "praises" here.

And just a last personal comment from my side: I feel like experimental leeches my work: I spent countless evenings on fixing bugs and adding new UI or other features, which are taken over and then praised for experimental while taken granted for standard. I know that open source works this way, but I can still complain ...

That is all I have to say to this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #15 on: January 28, 2012, 10:34:45 PM »
I do plan to retain the name "Experimental" until it is more polished than it is now. Balancing is my priority for this year, although any identified significant bugs will always come first. Prissi, you mention memory leaks and errors loading games from Standard; may I ask how long ago that you tested for memory leaks? I have not noticed any in recent versions. The server ran for days on end with memory consumption increasing only very slightly, in line with the additions being made to players' networks. Until reading your post above, I had not tried to open Standard games recently (most players will generally use either Standard or Experimental or both, so I do not tend to get reports when people have difficulty in opening Standard games with Experimental, as people do not usually try). I had not had any bug reports in this respect, but have now found and fixed two bugs which affected the opening of older saved games, which fixes will be available in the next release, 10.8. Perhaps you could re-test with this new version and let me know how you get on?

The behaviour with gradients has been changed recently - have you tested the gradients issue in the last 6 months or so? I did try to make hill climbing more realistic, following the earlier difficulties of single tile gradients having little effect. As to corners, may I ask why you say that trains do not care about angles of curves below 140km/h (87.5mph)? There are plenty of corner-related speed restrictions of less (in some cases, much less) than that all over the UK rail network.

As to the translations - Giuseppe is doing a Stirling job with the Italian translations. It's rather a shame that we don't currently have other active translators for Experimental, but I'm rather hoping that this will change in the future.

I don't think that it's entirely fair to say that Experimental "leeches" your work - all of your work is very, very much appreciated: Simutrans (Standard or Experimental) would not be what it is without your tireless contributions. I do try to make sure that you are properly credited (most of the credits from Standard are retained in the opening dialogue, and the Standard credits are shown before the Experimental credits in the rolling section). I'm not sure what else that can be done in that respect, but I am open to suggestions.

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 9622
  • Languages: De,EN,JP
Re: Simutrans and Simutrans Experimental relation
« Reply #16 on: January 28, 2012, 10:55:07 PM »
Speed restrictions for cornering only is for corners well below 1000 m for freight trains (traveling typically 80 km/h). The speed limits for conering comes actuallly exactly because corners (on rails) were built for that speeds (i.e. the tilt of the tracks) so a stopped gods train could start without car toppling inwards. Thus for speeds below 100 km/h corner radius does not matter.

(And friction: For rails corner almost make not impact at all, at least if it is not 250 m radius or so.) As simutrans has 1km/tile, corner should have nearly no impact for rail. The relatively small impact in standard is there for gaming reasons to reward straight tracks, and for high speed, where the impact is higher.

But I have not tested sim-exp very throughly of course in the last time. I just noticed the crashes in 10.5, which somehow of course made comparison difficult. But I still strongly recommend doing valgrind on experimental. Just use a virtual machine with a Linux under windows.

About the leeching: Do not take this personally. It is inherent with open source and forking that some work is one way. And I did not let this interfere with me giving advice, as you know.

Offline Spike

  • *
  • Posts: 1361
  • First Simutrans Developer and Graphics Artist
Re: Simutrans and Simutrans Experimental relation
« Reply #17 on: January 28, 2012, 11:26:55 PM »
Seeing Hajo so pricky with standard, I really wonder about those "praises" here.

*looks all innocent*

Actually I thought it's good to have a playground for the ideas which do not go into standard, regardless how good or bad the quality of the result is. I see it as "experimental", and therefore I do not care so much about the quality, but to explore and see which ideas might work and which don't.

Simutrans Standard is the _standard_ though. It is (should be) tried first by new players, and IMO should deliver a rock solid experience, particularly for people who are all new to such games. So I'm very picky there, since I want that new players get a good impression of Simutrans, the best possible.

I guess this can come across as being biased or unfair - I judge differently, but just because I see different purposes in the two development lines. It's not meant in a bad sense. Prissi, I'm sorry if it appeard that I'm too picky with standard, and too sloppy with experimental. I didn't want to make standard appear bad or so, just want to have it as good as possible.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #18 on: January 28, 2012, 11:57:38 PM »
Hmm, I don't think that you're right about curve radii - see here for a technical document from 1998 containing precise mathematical formulae for the calculation of speed limits from curve radii, and see here for a more non-technical discussion of the relationship in the context of route creation for Microsoft Train Simulator.

Offline isidoro

  • Devotee
  • *
  • Posts: 1130
Re: Simutrans and Simutrans Experimental relation
« Reply #19 on: January 29, 2012, 02:36:35 AM »
My 2 cents about this:  when working on an free software program/project one should not be concerned about what I'm given in return for what I give.  If that is important, one should not go free in the first place.

Maybe you don't get help in return for your very project, but you get a lot of other software you use in return, so that should be fixed once and for all.

Keeping a fork synced with the main trunk is not easy either.  Some people have complained that translations break their patches...  Imagine what happens when you have an entire fork and some changes are done to trunk...  It's not a question of knowing how to program and making my own version, it is a lot, lot of work.  Having two active versions of Simutrans is, no doubt, good news.

And the same goes to people devoted to the Standard version too.  It's a lot of work and the best proof that they are succeeding is that the project is alive after so many years...

I would do no better in both cases.  That's for sure.


Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Simutrans and Simutrans Experimental relation
« Reply #20 on: January 29, 2012, 03:02:12 AM »
Quote
I'd like to call "Standard" "Simutrans classic", and keep if needed replace "experimental" with "progressive", but "extended" makes it sound much like the normal version would be missing something.

It could be quite confusing, as the term experimental is so well known and much posted about. I'd suggest to stick with something very similar sounding.

May i suggest a different, and i think less boring, approach to the naming?
Simutrans -- James' Experiment

experimental fits what is done there quite well, it is only missleading through the open-source context, where future versions of software are called experimental. their features should appear in trunk later on. Experimental is also very much, and i'm sure the many contributors won't mind me saying so, James' project. He initiated, develops and maintains it. It very much is simutrans, as it is not only based on it, but all new features are inherited from there and it would not be stable in any way without Prissi and the other devs.

Experimental, unlike extended also allows the project to be rough around the edges, have flaws and inconsitencies. Those are greatly helping to push it forward. The stability comes from Simutrans (standard) [which should not renamed -- it is the main game!] While i want success for experimental, i don't think it would be good if too many inexperienced players would come to it. Simutrans veterans will try it, some will like it, others not. That provides a more suitable playerbase for it. (A playerbase that doesn't complain too much or asks too many 'stupid' questions) [well that was practically what Hajo said]
« Last Edit: January 29, 2012, 03:13:36 AM by sdog »

Offline missingpiece

  • *
  • Posts: 100
  • Languages: DE, PT, EN, FR
Re: Simutrans and Simutrans Experimental relation
« Reply #21 on: January 29, 2012, 06:21:33 AM »
I would find it unfortunate if -- due to competition, incompatibility, or conflict -- features tried out in experimental and found to be helpful and or challenging in a fun way, would not find their way back into the standard game. I hope the fork is "healthy" in that sense and does not drain too much developer power off the main game code.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #22 on: January 29, 2012, 11:01:16 AM »
Keeping a fork synced with the main trunk is not easy either.

You're telling me! It can take ages to merge in the new changes, although it is usually very worthwhile to incorporate the Standard developers' latest imrpovements (I am particularly looking forward to Prissi's latest city building algorithm).

I am very much hoping that what is now called "Experimental" will not always be rough around the edges - it is certainly not planned to be. I should not want the name to reflect a status that I hope will not be permanent.

Online prissi

  • Developer
  • Administrator
  • *
  • Posts: 9622
  • Languages: De,EN,JP
Re: Simutrans and Simutrans Experimental relation
« Reply #23 on: January 29, 2012, 08:18:50 PM »
The documents formula is not even correct, as it produces a speed in mm ???

But maximum cant was 200mm (written somewhere before) which gives a permissible speed of
58km/h at 200m radius, 91km/h at 500 and 130km/h at 1000m radius. Thus a rectangular bend in Simutrans shoudl be still good for 130 km/h.

But this the is permission of the tracks. The engines does not need much more power, especially when compared to even slight gradient.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #24 on: January 29, 2012, 09:50:17 PM »
I can't comment on the accuracy of the calculations in the documents - I suspect that your ability to resolve complex equations is far above mine!

One thing to remember about Experimental, however, is that the scale is adjustable, and that the default scale is 250m/tile, rather than the 1000m/tile for Standard. Using the default scale, a 90 degree corner could not be more than a 250m radius, and might reasonably be interpreted as being less than that if the track is not laid efficiently.

I do agree about the engines not needing more power: the whole way that it is set up in Experimental is based on a speed limit, not additional drag (I think that older versions of Standard added friction to a corner to act as a penalty, and this can still be done optionally in Experimental by a setting in simuconf.tab).

Incidentally, I omitted to remark in relation to this:

Quote
About the leeching: Do not take this personally. It is inherent with open source and forking that some work is one way. And I did not let this interfere with me giving advice, as you know.

...that the advice is always very much appreciated. 

Offline EnternalD

  • *
  • Posts: 33
Re: Simutrans and Simutrans Experimental relation
« Reply #25 on: January 30, 2012, 12:27:22 PM »
The documents formula is not even correct, as it produces a speed in mm ???

But maximum cant was 200mm (written somewhere before) which gives a permissible speed of
58km/h at 200m radius, 91km/h at 500 and 130km/h at 1000m radius. Thus a rectangular bend in Simutrans shoudl be still good for 130 km/h.

But this the is permission of the tracks. The engines does not need much more power, especially when compared to even slight gradient.

You can't say it is totally mm, because 11,82 is Constant, probably which has differences between units dimensions taken in account (yes I hate it too, when someone just throws away units and leaves just dimensionless constant, when it should have dimension - regulation organisations likes that, even if it undermine physics logic and creates many inconsistencies).

As JPetts noted above simexp has different scale (it seems that in Standard GUI there is no any reference to scale, nor it really affects gameplay, apart from numbers in generic tiles and relative speed to the tiles in km, so it could have any penalty, but I may be wrong). However there are few questions:
Does Simutrans experimental takes in account sections of diagonal rails and lets, in example 3 sections of rail to run at native speed over 130 or does not take 45 degrees turns in account at all (like in standard where all turns are treated somewhat same)?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19031
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans and Simutrans Experimental relation
« Reply #26 on: January 30, 2012, 10:30:00 PM »
In Experimental, the speed limit is based on the overall angle turned over a given distance, which distance is set in simuconf.tab, and varies with the speed of the convoy.