The International Simutrans Forum

 

Author Topic: Track types  (Read 3257 times)

0 Members and 1 Guest are viewing this topic.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2715
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Track types
« Reply #35 on: April 24, 2019, 07:54:12 PM »
Please keep in mind that the end result must be easily understandable to players, who did not study railway building and operation on technical university.

Most of what is required could be done by having wider selection of track types in pakset.
- high speed track (>200 km/h), up to 20 t/axle, very high maintenance, medium durability
- medium speed track (120-160), 25 t/axle, medium maintenance, high durability
- low cost track (<60), 22/t axle, low maintenance, low durability

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Track types
« Reply #36 on: April 25, 2019, 10:18:20 AM »
Please keep in mind that the end result must be easily understandable to players, who did not study railway building and operation on technical university.
Yes, I agree with that point.

I think that the display of the "Way wear factor" is for that purpose. It can be confirmed in the depot.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Track types
« Reply #37 on: April 28, 2019, 04:39:42 PM »
Thank you all for your thoughts on this issue.

We have to distinguish two separate matters, I think: first of all, whether it is necessary or desirable to have a new algorithm that dynamically calculates wear based on the actual speed of passing vehicles, and, secondly, if not, to what extent that having lower speed, lower maintenance cost railway lines with a high maximum axle loading is necessary for pakset balance and how to calibrate this if so. There is also the question of modifying the UI for downgrading ways.

Dynamic calculation of wear

This would require a very substantial coding effort and would have to wait its turn among a very long list of higher priority tasks. It would be many, many, many years (>5, possibly >10) before such a feature would be the highest priority feature for me to develop given the current rate of development. There are higher priority features that have been planned since circa 2011 that have yet to be implemented. It would also require a very, very large amount of pakset work, as the way wear characteristics of every single vehicle and every single way in the pakset would have to be meticulously recalibrated according to a system that would be radically different to the system that we have now, which was developed in 2014. This may also take over a year of work in and of itself, depending on the implementation method.

It is essential for me to exercise the strictest discipline in prioritising development tasks, and for anything that is not a critical bug to wait its turn in the long list. At present, it is difficult to imagine that anything other than a critical bug fix will have a higher priority for my coding time than the following features until all of them are completed:

(1) vehicle entropy, maintenance, overhauls and related scheduling features (which come as a set, already under development, but which development has been halted since early 2018 to focus on bug fixing);
(2) inflation (without which work cannot start on pakset balance, which is critical); and
(3) town growth, industry demand/supply development management, land value calculation and player rental income from land (which will also need to be developed together as a set).

Other features which are likely to be of high priority (but lower than the three above), some of which have been planned for many years, include:

(1) car parking (including park and ride simulation);
(2) overseas destinations (without which long-distance travel and importing/exporting of goods is not possible); and
(3) comfort based routing.

Those features are likely to be of higher priority for my time than adding a dynamic component to way wear. They are likely in combination to take a very great many years of my time unless some very substantial coding assistance is received in respect of them soon.

If anyone else would like to work on this, please let me know, and we can discuss in more detail how it might be implemented. This would require some very careful thought and a detailed examination of some of the things already discussed in this thread. However, if Simutrans-Extended is going to reach a state within any reasonable period where things will be at least reasonably well balanced, I will not be able to prioritise this feature for my own coding work for an extremely long time.


Additional railway track types for the pakset without changing the algorithm

This is sufficiently straightforward that it can be done within a much shorter timescale, but it needs careful numerical calibration: it will detract from, rather than add to, the accuracy of the balance in the pakset if numerical values for lower cost, lower speed track with high axle loads should be added without any idea of whether those values have any meaningful relationship to real world values.

For the purposes of balancing this pakset, unlike for the code where one has to consider the international perspective and what will work well with all the Simutrans-Extended paksets (such as the Japanese pakset, the Swedish pakset, the Czech pakset, etc.), for pakset balancing in Pak128.Britain-Ex, it is necessary to focus on specifically UK practice.

The existing track speeds are based on the premise, which I believe to be correct for UK practice, that good main line track from the era when the fastest lines did not have a fixed speed limit (no doubt because the fastest trains could not go as fast as the track was capable of dealing with) was considered to be 100mph (that is, circa 160km/h), and that, when line speeds were increased to 110mph (175km/h) and 125mph (200km/h) in the 1970s, it was then found that track laid and maintained to a higher standard, and therefore at higher cost, was necessary for this purpose.

I am not aware of any data points for any speed lower than 160km/h that are not contaminated by the line having a low speed due to curvature and/or signalling restrictions. Even though the costs in the pakset are not balanced yet, the speed, axle load and durability of the ways are at least intended to be fully balanced, so any new track type added in order to improve the balance will have to be based on real data. The data that I will need are the weight of the rail used in lb/yard or kg/m (as this information is given in the GUI, and is used to calculate the maximum axle load) and the maximum speed of the track (taking out of account signalling and curvature restrictions). Without stripping out restrictions based on curvature and signalling (and other lineside safety matters, such as ungated level crossings, etc.), there will be no way of controlling for whether the lower line speed is referable to the quality of track itself, or whether track to that standard laid straight with good signalling would be quite capable of permitting trains to travel at up to 160km/h.

One other thing to bear in mind is that the code as it is currently written does allow vehicles to use ways for which they are too heavy, provided that they are within a certain margin of the weight limit, but at a much reduced speed. This does affect durability, however, as the way wear factor is based on the axle loading and the wear capacity of the rail is based on its weight, from which the axle load is calculated.

As to the meaning of track durability, it is intended to be the durability of the whole way, not specifically the rails themselves. The research that I conducted in 2014 when implementing this feature initially did not suggest that any distinction between the track, sleepers and ballast was significant enough to be worth simulating separately (taking into account that regular maintenance on the whole way is modelled by the maintenance cost in any event and that durability is referable only to renewals).

Modifying the UI for downgrading ways

As with the additional track types, a simple change to the UI is not a significant new feature and will not have to wait years (but that would not be so of a complex change or a change which introduces any new type of UI element or behaviour not already present in Simutrans).

Do I understand from what has been discussed before that a dialogue explaining to the player why attempting to lay one way over another is considered a downgrade, and inviting the player to try again using the CTRL key if he/she really wants to proceed would be helpful in this regard? If so, then this would probably be easy to implement.

Edit: Incidentally, one other balance related thought occurs to me: the current state of the balance of the pakset, I believe ultimately derived from the Standard pakset Pak.128, is one in which the ratio of maintenance cost to capital cost is extremely high compared to reality. I wonder whether the apparent importance of track maintained to a lower standard for lower speed use is likely to reduce significantly when full balance is completed and the maintenance cost is greatly reduced in proportion to the capital cost?

Offline thegamer7893 england

  • *
  • Posts: 796
  • Languages: EN
Re: Track types
« Reply #38 on: August 11, 2019, 10:19:19 AM »
Please keep in mind that the end result must be easily understandable to players, who did not study railway building and operation on technical university.

Most of what is required could be done by having wider selection of track types in pakset.
- high speed track (>200 km/h), up to 20 t/axle, very high maintenance, medium durability
- medium speed track (120-160), 25 t/axle, medium maintenance, high durability
- low cost track (<60), 22/t axle, low maintenance, low durability

This sounds like something which I would favour to be in the game as although this will be technically hard to implement, it would be easy pickings when it comes to what type of track you are going to use to build/upgrade a line with/to.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Track types
« Reply #39 on: August 11, 2019, 03:41:22 PM »
This sounds like something which I would favour to be in the game as although this will be technically hard to implement, it would be easy pickings when it comes to what type of track you are going to use to build/upgrade a line with/to.

You will need to read my post immediately above (i.e. of the 28th of April): I will need real world research data (with all the specific information to which I refer in that post: look under the second heading) to be able to implement this. I am not aware of any at present. Are you?

Offline thegamer7893 england

  • *
  • Posts: 796
  • Languages: EN
Re: Track types
« Reply #40 on: August 11, 2019, 07:28:28 PM »
You will need to read my post immediately above (i.e. of the 28th of April): I will need real world research data (with all the specific information to which I refer in that post: look under the second heading) to be able to implement this. I am not aware of any at present. Are you?

Tbh no.