- Welcome to The International Simutrans Forum.
News:
Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.
The official on-line manual for Simutrans. Read and contribute.
Recent posts
#61
Patches & Projects / [Project] Native Language Supp...
Last post by victor_18993 - August 20, 2026, 05:33:06 AMI would like to start a broader Simutrans Standard project focused on native-language support.
The goal is not simply to check whether translations exist or whether Unicode characters can be displayed.
The objective is to verify that native users can actually use Simutrans naturally in their own language, including:
- native keyboard and IME input;
- composition and candidate selection where required;
- correct text rendering and font coverage;
- cursor movement, selection, Backspace and Delete;
- clipboard operations;
- station, line, convoy and other object names;
- Unicode save/load persistence;
- filenames where applicable;
- Squirrel/API string handling;
- multiplayer/chat paths where practical.
The recent Windows GDI IME investigation showed why this distinction matters.
In r12178, the Windows GDI backend was fixed because native IME handling had been suppressed. On current Windows this could not only hide the Japanese candidate window, but could also prevent Japanese text from being committed into Simutrans edit fields.
That made it clear that "the language is translated" and "the language is fully usable" are two different questions.
I therefore propose treating native-language support as a systematic Standard project.
Planned audit groups
--------------------
1. CJK
Japanese
Korean
Simplified Chinese
Traditional Chinese
This audit is already in progress.
It includes native IME composition, candidate windows, text commit, UTF-8 editing, fonts, persistence and backend comparison between Windows GDI and SDL2.
2. Cyrillic
Russian
Ukrainian
Belarusian
Bulgarian
Serbian
Macedonian
and representative Central Asian Cyrillic languages
This will also revisit historical reports concerning Russian/Cyrillic encoding, fonts and generated city names.
3. Hebrew / RTL
The next stage will investigate right-to-left and bidirectional text behaviour, mixed RTL/LTR strings, cursor movement, selection and combining characters.
4. Complex scripts
Arabic, Persian and related scripts would follow separately because they add contextual shaping and ligature requirements on top of RTL/BiDi.
Development approach
--------------------
This is intended to be an audit-and-fix project, not a large Unicode rewrite.
For each language family:
audit
->
reproducible compatibility matrix
->
individual confirmed defects
->
small independent patches
->
regression tests where possible
->
integration into Standard
A failure in Japanese input, Korean composition, a Cyrillic font, Hebrew BiDi handling, etc. should therefore become its own reviewable patch rather than being hidden inside one large internationalisation change.
The audits will also establish an acceptance contract for future platform backends. For example, an SDL3 backend should not be considered equivalent if it regresses native-language behaviour already working in GDI or SDL2.
Native-speaker feedback is particularly welcome.
If you currently use Simutrans in Japanese, Korean, Simplified or Traditional Chinese, Russian or another Cyrillic language, Hebrew, Arabic, Persian, or another non-Latin writing system, reports of input, editing, font, save/load or UI problems would be very useful.
The long-term objective is simple:
A native user should not feel that their language is only partially supported because Simutrans was originally developed around a different writing system.
The goal is not simply to check whether translations exist or whether Unicode characters can be displayed.
The objective is to verify that native users can actually use Simutrans naturally in their own language, including:
- native keyboard and IME input;
- composition and candidate selection where required;
- correct text rendering and font coverage;
- cursor movement, selection, Backspace and Delete;
- clipboard operations;
- station, line, convoy and other object names;
- Unicode save/load persistence;
- filenames where applicable;
- Squirrel/API string handling;
- multiplayer/chat paths where practical.
The recent Windows GDI IME investigation showed why this distinction matters.
In r12178, the Windows GDI backend was fixed because native IME handling had been suppressed. On current Windows this could not only hide the Japanese candidate window, but could also prevent Japanese text from being committed into Simutrans edit fields.
That made it clear that "the language is translated" and "the language is fully usable" are two different questions.
I therefore propose treating native-language support as a systematic Standard project.
Planned audit groups
--------------------
1. CJK
Japanese
Korean
Simplified Chinese
Traditional Chinese
This audit is already in progress.
It includes native IME composition, candidate windows, text commit, UTF-8 editing, fonts, persistence and backend comparison between Windows GDI and SDL2.
2. Cyrillic
Russian
Ukrainian
Belarusian
Bulgarian
Serbian
Macedonian
and representative Central Asian Cyrillic languages
This will also revisit historical reports concerning Russian/Cyrillic encoding, fonts and generated city names.
3. Hebrew / RTL
The next stage will investigate right-to-left and bidirectional text behaviour, mixed RTL/LTR strings, cursor movement, selection and combining characters.
4. Complex scripts
Arabic, Persian and related scripts would follow separately because they add contextual shaping and ligature requirements on top of RTL/BiDi.
Development approach
--------------------
This is intended to be an audit-and-fix project, not a large Unicode rewrite.
For each language family:
audit
->
reproducible compatibility matrix
->
individual confirmed defects
->
small independent patches
->
regression tests where possible
->
integration into Standard
A failure in Japanese input, Korean composition, a Cyrillic font, Hebrew BiDi handling, etc. should therefore become its own reviewable patch rather than being hidden inside one large internationalisation change.
The audits will also establish an acceptance contract for future platform backends. For example, an SDL3 backend should not be considered equivalent if it regresses native-language behaviour already working in GDI or SDL2.
Native-speaker feedback is particularly welcome.
If you currently use Simutrans in Japanese, Korean, Simplified or Traditional Chinese, Russian or another Cyrillic language, Hebrew, Arabic, Persian, or another non-Latin writing system, reports of input, editing, font, save/load or UI problems would be very useful.
The long-term objective is simple:
A native user should not feel that their language is only partially supported because Simutrans was originally developed around a different writing system.
#62
Incorporated Patches and Solved Bug Reports / [Fixed r12179] Mouse-wheel zoo...
Last post by victor_18993 - August 20, 2026, 05:01:29 AMFixed in SVN r12179.
There was a stale-position issue in mouse-wheel zoom after navigating through the minimap.
The minimap changes the main viewport position, but the world cursor position used by the zoom code could still refer to the location from before the minimap jump. As a result, the first mouse-wheel zoom could use that old tile as its anchor and unexpectedly move the viewport far away from the location selected on the minimap.
The wheel zoom now determines its anchor from the current mouse position instead.
Verified on current trunk:
- the original minimap -> close -> first wheel reproducer no longer jumps;
- normal mouse-wheel zoom keeps its existing behaviour;
- invalid/outside-map positions keep the previous guard behaviour;
- mouse-wheel handling inside the minimap is unchanged;
- full automated test suite: 286/286.
Integrated as:
r12179 — FIX: anchor mouse-wheel zoom on the tile under the mouse
This is a local UI/view correction only. There are no network, savegame or pak-format changes.
There was a stale-position issue in mouse-wheel zoom after navigating through the minimap.
The minimap changes the main viewport position, but the world cursor position used by the zoom code could still refer to the location from before the minimap jump. As a result, the first mouse-wheel zoom could use that old tile as its anchor and unexpectedly move the viewport far away from the location selected on the minimap.
The wheel zoom now determines its anchor from the current mouse position instead.
Verified on current trunk:
- the original minimap -> close -> first wheel reproducer no longer jumps;
- normal mouse-wheel zoom keeps its existing behaviour;
- invalid/outside-map positions keep the previous guard behaviour;
- mouse-wheel handling inside the minimap is unchanged;
- full automated test suite: 286/286.
Integrated as:
r12179 — FIX: anchor mouse-wheel zoom on the tile under the mouse
This is a local UI/view correction only. There are no network, savegame or pak-format changes.
#63
Incorporated Patches and Solved Bug Reports / Windows GDI IME: native JP/CJK...
Last post by victor_18993 - August 20, 2026, 02:36:18 AMFixed in SVN r12178.
The Windows GDI IME handling has been corrected.
The issue was caused by the Windows backend consuming WM_IME_SETCONTEXT without forwarding it to DefWindowProc. On current Windows 11 this not only suppressed the native JP/CJK candidate window, but could also prevent Japanese IME text from being committed into Simutrans edit fields.
The fix restores the native Windows IME handling while keeping the composition mask used by the older Windows 10 1809 workaround.
Verified before integration on current trunk:
- native Japanese candidate window is displayed and correctly positioned;
- Japanese text can be converted and committed correctly in multiple Simutrans dialogs;
- normal Latin keyboard input is unchanged;
- clipboard behaviour is unchanged;
- full automated test suite passes 286/286 before and after the fix.
Integrated as:
r12178 — FIX: restore native IME handling on Windows GDI
This change only affects the Windows GDI input backend. There are no savegame, network or pak-format changes.
The Windows GDI IME handling has been corrected.
The issue was caused by the Windows backend consuming WM_IME_SETCONTEXT without forwarding it to DefWindowProc. On current Windows 11 this not only suppressed the native JP/CJK candidate window, but could also prevent Japanese IME text from being committed into Simutrans edit fields.
The fix restores the native Windows IME handling while keeping the composition mask used by the older Windows 10 1809 workaround.
Verified before integration on current trunk:
- native Japanese candidate window is displayed and correctly positioned;
- Japanese text can be converted and committed correctly in multiple Simutrans dialogs;
- normal Latin keyboard input is unchanged;
- clipboard behaviour is unchanged;
- full automated test suite passes 286/286 before and after the fix.
Integrated as:
r12178 — FIX: restore native IME handling on Windows GDI
This change only affects the Windows GDI input backend. There are no savegame, network or pak-format changes.
#64
Randomness Lounge / Re: Rust implements an LLM (AI...
Last post by Yona-TYT - August 19, 2026, 10:25:36 PMRegarding AI, there's one particular topic I'd like to discuss: the anti-boot systems used by some forums.
The question is, do we really want to prohibit AI from accessing the information available on forums and wikis?
To be honest, I use AI extensively to research documentation on some complex Android development APIs, and I find it very useful for AI to have access to that information without much trouble.
I've encountered obstacles, for example, with OpenWrt, which, due to its anti-boot system, prevents Google's AI from analyzing its documentation.
Considering all of this, we should discuss this issue and whether a migration to a new forum is planned for the future (work in progress, "Made in Isaac 🫡").
The question is, do we really want to prohibit AI from accessing the information available on forums and wikis?
To be honest, I use AI extensively to research documentation on some complex Android development APIs, and I find it very useful for AI to have access to that information without much trouble.
I've encountered obstacles, for example, with OpenWrt, which, due to its anti-boot system, prevents Google's AI from analyzing its documentation.
Considering all of this, we should discuss this issue and whether a migration to a new forum is planned for the future (work in progress, "Made in Isaac 🫡").
#65
Incorporated Patches and Solved Bug Reports / Schedule editor can remain ope...
Last post by victor_18993 - August 19, 2026, 12:05:15 AMI found and fixed two related issues in the convoy schedule editor when starting a convoy from a depot.
If the Schedule tab was still open when pressing Start, the convoy could leave the depot while the editor remained open. Pending schedule changes could then be silently lost when that orphaned editor was later closed.
The orphaned editor also enabled a second, more serious issue: a late schedule-edit command could be processed after departure, leaving the convoy indefinitely in EDIT_SCHEDULE with no active editor left to clear that state.
The root cause was that several old destroy_win((ptrdiff_t)schedule) calls still referred to the former schedule_gui_t window identity. The current editor is the Schedule tab inside convoi_info_t, so those calls no longer closed the active editor.
The fix restores the intended lifecycle:
- when Start is pressed with an active schedule editor, the editor is closed first;
- closing it applies the pending schedule changes, matching the historical behaviour of the old schedule editor;
- the convoy is started only afterwards;
- depot_t::start_convoi() also contains the same safeguard for non-GUI start paths.
This removes the orphaned editor and structurally eliminates the EDIT_SCHEDULE freeze without adding a separate state-machine workaround.
Validation on trunk:
- 286/286 automated tests before and after
- 13/13 tested editing sessions applied exactly once
- 0 orphaned schedule editors
- 0 stale editing sessions
- 0 EDIT_SCHEDULE freezes
- starting without an open editor remains unchanged
- normal schedule editing remains unchanged
- no savegame, network protocol or checksum changes
- 4 files, +23/-15
The historical SVN implementation was also checked: closing the old schedule editor applied the schedule, so applying pending changes before Start restores the previous behaviour rather than introducing a new semantic.
The fix has now been integrated into the official trunk as:
r12174 — FIX: close convoy schedule editor before starting from depot
If the Schedule tab was still open when pressing Start, the convoy could leave the depot while the editor remained open. Pending schedule changes could then be silently lost when that orphaned editor was later closed.
The orphaned editor also enabled a second, more serious issue: a late schedule-edit command could be processed after departure, leaving the convoy indefinitely in EDIT_SCHEDULE with no active editor left to clear that state.
The root cause was that several old destroy_win((ptrdiff_t)schedule) calls still referred to the former schedule_gui_t window identity. The current editor is the Schedule tab inside convoi_info_t, so those calls no longer closed the active editor.
The fix restores the intended lifecycle:
- when Start is pressed with an active schedule editor, the editor is closed first;
- closing it applies the pending schedule changes, matching the historical behaviour of the old schedule editor;
- the convoy is started only afterwards;
- depot_t::start_convoi() also contains the same safeguard for non-GUI start paths.
This removes the orphaned editor and structurally eliminates the EDIT_SCHEDULE freeze without adding a separate state-machine workaround.
Validation on trunk:
- 286/286 automated tests before and after
- 13/13 tested editing sessions applied exactly once
- 0 orphaned schedule editors
- 0 stale editing sessions
- 0 EDIT_SCHEDULE freezes
- starting without an open editor remains unchanged
- normal schedule editing remains unchanged
- no savegame, network protocol or checksum changes
- 4 files, +23/-15
The historical SVN implementation was also checked: closing the old schedule editor applied the schedule, so applying pending changes before Start restores the previous behaviour rather than introducing a new semantic.
The fix has now been integrated into the official trunk as:
r12174 — FIX: close convoy schedule editor before starting from depot
#66
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Václav - August 18, 2026, 08:56:00 PMThanks. So, it seems I like rather prepare two versions. One will be with non-transparent glasses. And one without them. So, there will be four houses.
And plays with transparent FrontImage is postponed, for now.
And plays with transparent FrontImage is postponed, for now.
#67
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Sylph (Leartin) - August 18, 2026, 08:50:02 PMThe coords are the same.
I used a lot of offsets in P192C - this means you can have frontimages higher up. I don't think that's enough for these buildings, but often you might have windows that fit in a single squaee if you move them
I used a lot of offsets in P192C - this means you can have frontimages higher up. I don't think that's enough for these buildings, but often you might have windows that fit in a single squaee if you move them
#68
Patches & Projects / Re: [PATCH] Vehicle-specific s...
Last post by maxim13 - August 18, 2026, 07:55:31 PMI have attached the SVN patch prepared against trunk revision r12173.
vehicle-speed-bonus-svn-r12173.diff
vehicle-speed-bonus-svn-r12173.diff
#69
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by prissi - August 18, 2026, 07:44:37 PMYou could use a larger pak size. I think one radio tower in pak96.comic or pak192.comic used this.
#70
Simutrans Help Center / Re: Cityhouses with FrontImage
Last post by Václav - August 18, 2026, 05:29:52 PMQuote from: Sylph (Leartin) on August 18, 2026, 04:50:30 PMIIRC, citybuildings only support frontimages at ground level.Oh, no. It would explain why those glasses appear only on few bottom floors.
What about coords? Are they the same like in case of BackImage or different?
Quote from: Sylph (Leartin) on August 18, 2026, 04:50:30 PMAlso, I'm just on the phone and can't check, but don't you lose transparency because of the blueish background? You don't need that, just have it transparent.Yes, I used blue background - and after its removing it became transparent. But however, I will have to play with transparency, itself, because even if glasses became transparent, they don't light at night.