- Welcome to The International Simutrans Forum.
News:
Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.
Our Simutrans site. You can find everything about Simutrans from here.
Recent posts
#1
Simutrans-Extended bug reports / Re: Graph labels for "Seat-km"...
Last post by Matthew - Yesterday at 01:54:37 PMThank you for the bug report, kylofon, and welcome to the International Simutrans Forum!
This bug report is transferred from this GitHub Issue.
I've had a chance to properly look into this.
Firstly, I double-checked whether "seat-km" is actually the right term in English. Seat-km isn't a concept often used in discussions of railways. But it's very common in the analysis of commercial aviation, usually as "Available seat-km" e.g. this CAA report. The relevant Wikipedia article is actually on Available seat-miles. Looking through lots of relevant tables and pages in Terry Gourvish's British Railways 1948-73, I only found one example (p.109, "Total costs per seat-mile"), but one is enough to prove it's that seat-mile/seat-km is not just an aviation term and we are right to use it.
Secondly, I looked the code more closely. The localization key "Seat-km" is actually only used for the button label. This bug report is about the tooltip label, which is set at "pkm" in gui_chart.cc:
PAX_KM is declared within enum gui_chart_t::chart_suffix_t. Unfortunately for us, it's not only used for the label of these charts, but also for calculating the correct unit of these graphs, and the equivalent Player Ranking graph. So creating a new SEAT_KM identifier wouldn't be a 5-minute job unless you are already familiar with the graphing code, and right now I don't think we have any contributors who are.
And there's an additional complication. The text key is "pkm". What does the "p" stand for? Only two languages have localizations. The English localization interprets it as "pass[enger] km" but the Japanese localization uses "人km", which means "person/people km". That's much closer to "passengers", but perhaps it has just enough ambiguity to cover people who could travel (= seats) as well as passengers who do travel.
In my view "pass. km" is close enough and fixing it would take more time than it's worth, which is why the code was sensibly written this way, and so it's a WONTFIX.
This bug report is transferred from this GitHub Issue.
I've had a chance to properly look into this.
Firstly, I double-checked whether "seat-km" is actually the right term in English. Seat-km isn't a concept often used in discussions of railways. But it's very common in the analysis of commercial aviation, usually as "Available seat-km" e.g. this CAA report. The relevant Wikipedia article is actually on Available seat-miles. Looking through lots of relevant tables and pages in Terry Gourvish's British Railways 1948-73, I only found one example (p.109, "Total costs per seat-mile"), but one is enough to prove it's that seat-mile/seat-km is not just an aviation term and we are right to use it.
Secondly, I looked the code more closely. The localization key "Seat-km" is actually only used for the button label. This bug report is about the tooltip label, which is set at "pkm" in gui_chart.cc:
Code Select
case PAX_KM: new_curve.suffix = translator::translate("pkm"); break;PAX_KM is declared within enum gui_chart_t::chart_suffix_t. Unfortunately for us, it's not only used for the label of these charts, but also for calculating the correct unit of these graphs, and the equivalent Player Ranking graph. So creating a new SEAT_KM identifier wouldn't be a 5-minute job unless you are already familiar with the graphing code, and right now I don't think we have any contributors who are.
And there's an additional complication. The text key is "pkm". What does the "p" stand for? Only two languages have localizations. The English localization interprets it as "pass[enger] km" but the Japanese localization uses "人km", which means "person/people km". That's much closer to "passengers", but perhaps it has just enough ambiguity to cover people who could travel (= seats) as well as passengers who do travel.
In my view "pass. km" is close enough and fixing it would take more time than it's worth, which is why the code was sensibly written this way, and so it's a WONTFIX.
#2
Patches & Projects / Re: Two-ways signals
Last post by Nazalassa - May 01, 2026, 04:20:37 PMTurns out I accidentally broke dragging signals. This patch fixes it. Here is an updated two-way-signals-4.patch, which is two-way-signals-2.patch with bugfixes.
#3
Patches & Projects / Re: Two-ways signals
Last post by prissi - May 01, 2026, 01:08:01 PMDriving through a signal facing the other way is extremely rare in real life (outside of stations). I think for it should be a rare case for simutrans too and hence allowing for a single signal via GUI info is fine.
Alternatively, I could imagine a special signal that only works one way, si it is viually clear that this is single way.
I am still worried if this patch found all cases as the route search is backwards in find route.
Alternatively, I could imagine a special signal that only works one way, si it is viually clear that this is single way.
I am still worried if this patch found all cases as the route search is backwards in find route.
#4
Patches & Projects / Re: Two-ways signals
Last post by poppo - May 01, 2026, 07:47:54 AMI understand the condition of the number of platforms and convoys. thank you.
Anyway, in my opinion, it would be better to allow two-way traffic for all signal add-ons via the GUI (as two-ways-signals-2.patch).
Anyway, in my opinion, it would be better to allow two-way traffic for all signal add-ons via the GUI (as two-ways-signals-2.patch).
#5
Bug Reports / Re: Since r11798: bridges no l...
Last post by prissi - May 01, 2026, 04:23:41 AMIndeed, the check for ground looks wrong. In this case, the check is only done for the slopes, not the bridge itself. Submitted, thank you.
(Also that patch was full of the stupid reformating from MSVC, I really hate the current versions.)
(Also that patch was full of the stupid reformating from MSVC, I really hate the current versions.)
#6
Bug Reports / Since r11798: bridges no longe...
Last post by Nazalassa - April 30, 2026, 04:53:56 PMSteps to reproduce - Select a bridge which max speed is not that of any way (e.g the 100 km/h bridge of pak64). Build a bridge. Use the inspection tool on the middle of the bridge. The reported speed is incorrect.
Proposed fix: in src/simutrans/obj/bruecke.cc, line 200 is:
Code Select
if(desc->get_waytype()!=powerline_wt && gr->get_typ()==grund_t::boden) {
Removing the second condition (which was added in r11798) solves the bug:Code Select
if(desc->get_waytype()!=powerline_wt) {
though I cannot explain why. #7
Patches & Projects / Re: Two-ways signals
Last post by prissi - April 30, 2026, 01:35:47 PMYou cannot avoid a deadlock ever, as soon as a second train enters the section.
Longblock signals only work without deadlocks if there is never more than a single train in the single track section. So two platforms with longblock signals is a no go in any configuration, as the longblock signal from the entering side only checks one of the platforms and might not see a train on another one.
It can work with a situation when have an exit only longblock and an entry only choose as long as there are never more than two trains ever in this branch. Three train will deadlock, even with longblock and choose signals because a longblock signal stops checking at the last stop before reversing OR at any signal. So it will allow a third train to enter even if both platforms are occupied.
Longblock signals only work without deadlocks if there is never more than a single train in the single track section. So two platforms with longblock signals is a no go in any configuration, as the longblock signal from the entering side only checks one of the platforms and might not see a train on another one.
It can work with a situation when have an exit only longblock and an entry only choose as long as there are never more than two trains ever in this branch. Three train will deadlock, even with longblock and choose signals because a longblock signal stops checking at the last stop before reversing OR at any signal. So it will allow a third train to enter even if both platforms are occupied.
#8
Patches & Projects / Re: Two-ways signals
Last post by poppo - April 30, 2026, 12:37:30 PM-----[stop]----[stop]----|C>-<L|--[two-platform terminal with pre-signal]
like above situation, we cannot avoid deadlock in current version (without using departure time settings).
But if choose signal can only active for one-way, we can avoid this problem!
like above situation, we cannot avoid deadlock in current version (without using departure time settings).
But if choose signal can only active for one-way, we can avoid this problem!
#9
Patches & Projects / Re: Two-ways signals
Last post by prissi - April 30, 2026, 12:19:59 PMI do not see how a longblock signal would work together even with a one-directional choose signal. It will be impossible to determine if a route is free or not. Maybe the through route is free, because the train before chose another platform. But then the route is blocked as soon as it leaves, because the longblock signal only checks and not reserve the route.
#10
Patches & Projects / Re: Two-ways signals
Last post by poppo - April 30, 2026, 10:22:34 AMBy the way, for a single-track line, you can simply make a choose signal that allows traffic in both directions just before the station and a pre-signal on the platform.
However, since longblock signals cannot be used with choose signal in this case, the proposed feature would indeed improve practicality.
However, since longblock signals cannot be used with choose signal in this case, the proposed feature would indeed improve practicality.