- Welcome to The International Simutrans Forum.
News:
.Recent posts
#91
Forum / Re: Tutorial Underground railw...
Last post by wipi35 - August 17, 2026, 07:52:46 AMMission accomplished, tnx again!
#92
Patches & Projects / [PATCH] Vehicle-specific speed...
Last post by maxim13 - August 17, 2026, 07:24:50 AMHello,
I would like to propose a new optional mechanism that gives pakset authors more precise control over vehicle revenue balancing.
Pull request: [simutrans/simutrans#15](https://github.com/simutrans/simutrans/pull/15)
Direct patch: [pull request patch](https://github.com/simutrans/simutrans/pull/15.patch)
## Motivation
The current speed bonus uses a common timeline reference speed for all vehicles of the same waytype. This makes it difficult for a pakset author to balance vehicles intended for different roles. For example, an urban bus and an intercity coach use the same road reference speed even though they are expected to operate under very different conditions.
This is particularly visible in pak128 after the year 2000. Roads in large cities commonly have a speed limit of about 50 km/h, while the timeline reference speed continues to rise. As a result, buses, trams, trolleybuses and urban mail vehicles can run nearly fully loaded and still receive too little revenue to cover their operating costs.
This creates an undesirable gameplay incentive: players are encouraged to replace ordinary surface transport with high-speed tunnels or elevated routes simply to make urban transport economically viable. Such infrastructure should remain a valid choice, but it should not be practically mandatory.
Changing the reference speed globally for all road or track vehicles would be too coarse because it would also affect intercity and high-speed vehicles. The proposed mechanism lets the pakset author balance each vehicle according to its intended role.
## Proposed DAT parameters
The patch adds two optional parameters to vehicle definitions:
```text
speed_bonus_reference_percent=100
speed_bonus_max_percent=0
```
`speed_bonus_reference_percent` defines the vehicle's fare reference speed as a percentage of the current timeline reference speed for its waytype. The default value `100` leaves the existing reference speed unchanged.
`speed_bonus_max_percent` defines an upper limit on the payment factor produced by the speed bonus calculation. The default value `0` means that there is no vehicle-specific cap. The existing global lower limit, `bonus_basefactor`, continues to apply as before.
For example, an urban bus could use:
```text
speed_bonus_reference_percent=50
speed_bonus_max_percent=70
```
Its fare would then be calculated against half of the normal road reference speed for the current period. The second value prevents the vehicle from receiving an unintended high-speed payment if it is used on a much faster route.
The engine does not assign these values automatically. Selecting appropriate values remains the responsibility of the pakset author.
## Multi-vehicle and articulated convoys
The parameters belong to the vehicle that actually carries the goods, passengers or mail. Revenue for the contents of each vehicle is calculated using that vehicle's own descriptor.
Therefore:
- a locomotive carrying no cargo does not affect the fare of its carriages;
- different passenger or freight cars in the same convoy may use different values;
- one section of an articulated vehicle does not impose its values on the other sections;
- the total revenue of a mixed convoy is the sum of the results calculated for its individual carrying vehicles.
## Backward compatibility
The default values `100/0` preserve the previous behaviour:
- vehicles without the new parameters use the existing revenue calculation;
- existing version 13 vehicle pak objects continue to load and receive the default values;
- existing `speedbonus.tab` values and `bonus_basefactor` keep their current semantics;
- existing saved games require no migration because these values belong to vehicle descriptors in the pakset, not to vehicle instances in the savegame.
MakeObj writes vehicle descriptor version 14 to store the two new `uint16` values. Simutrans reads both versions 13 and 14. As usual for a new pak object version, version 14 vehicle objects produced by the new MakeObj are not expected to work with older Simutrans versions.
## User interface and scripting
For vehicles with non-default values, the depot, vehicle list and convoy details display:
```text
Fare reference speed: 50% of era speed
Maximum speed payment: 70%
```
These lines are hidden for vehicles using `100/0`, so existing paksets do not gain additional UI clutter.
The values are also exposed through the Squirrel vehicle descriptor API. The existing legacy revenue API remains available, while a vehicle-aware revenue calculation can be requested when a vehicle descriptor is available.
The patch includes documentation of the new DAT parameters.
## Validation
- Simutrans and MakeObj build successfully on macOS.
- The branch is rebased on the current master.
- All 284 automated Simutrans Standard scenario tests pass.
- The automated integration test builds a version 14 vehicle object with `50/70`, verifies increased revenue at an urban speed and verifies the payment cap at high speed.
- A default-value test verifies that `100/0` produces the legacy revenue result.
I also performed a local pak128 gameplay experiment using buses with equal capacity and operating costs on a well-loaded route limited to 50 km/h:
- the vehicle with the legacy calculation earned approximately 100 currency units per month and was deeply unprofitable;
- the vehicle using `50/70` earned more than 400 currency units per month and became profitable;
- an articulated bus with `50/70` on one 25-passenger section and default values on another 25-passenger section produced an intermediate result and remained slightly unprofitable.
The articulated vehicle result provides an additional practical check that each carrying section uses its own parameters.
These experimental values are not proposed as final pak128 balancing values. They were used only to validate the mechanism and the direction of the revenue change. Actual pakset balancing would be discussed separately after the engine feature is accepted.
## Scope
This patch provides a balancing mechanism only. It does not:
- rebalance any existing pakset;
- automatically classify vehicles as urban, intercity or high-speed;
- change existing vehicle speed, capacity or operating-cost values;
- replace the existing speed bonus system;
- require existing vehicle DAT files to define the new parameters;
- add a translation for only one language.
I would appreciate feedback on the overall concept, parameter names, default values, user-interface wording and implementation.
I would like to propose a new optional mechanism that gives pakset authors more precise control over vehicle revenue balancing.
Pull request: [simutrans/simutrans#15](https://github.com/simutrans/simutrans/pull/15)
Direct patch: [pull request patch](https://github.com/simutrans/simutrans/pull/15.patch)
## Motivation
The current speed bonus uses a common timeline reference speed for all vehicles of the same waytype. This makes it difficult for a pakset author to balance vehicles intended for different roles. For example, an urban bus and an intercity coach use the same road reference speed even though they are expected to operate under very different conditions.
This is particularly visible in pak128 after the year 2000. Roads in large cities commonly have a speed limit of about 50 km/h, while the timeline reference speed continues to rise. As a result, buses, trams, trolleybuses and urban mail vehicles can run nearly fully loaded and still receive too little revenue to cover their operating costs.
This creates an undesirable gameplay incentive: players are encouraged to replace ordinary surface transport with high-speed tunnels or elevated routes simply to make urban transport economically viable. Such infrastructure should remain a valid choice, but it should not be practically mandatory.
Changing the reference speed globally for all road or track vehicles would be too coarse because it would also affect intercity and high-speed vehicles. The proposed mechanism lets the pakset author balance each vehicle according to its intended role.
## Proposed DAT parameters
The patch adds two optional parameters to vehicle definitions:
```text
speed_bonus_reference_percent=100
speed_bonus_max_percent=0
```
`speed_bonus_reference_percent` defines the vehicle's fare reference speed as a percentage of the current timeline reference speed for its waytype. The default value `100` leaves the existing reference speed unchanged.
`speed_bonus_max_percent` defines an upper limit on the payment factor produced by the speed bonus calculation. The default value `0` means that there is no vehicle-specific cap. The existing global lower limit, `bonus_basefactor`, continues to apply as before.
For example, an urban bus could use:
```text
speed_bonus_reference_percent=50
speed_bonus_max_percent=70
```
Its fare would then be calculated against half of the normal road reference speed for the current period. The second value prevents the vehicle from receiving an unintended high-speed payment if it is used on a much faster route.
The engine does not assign these values automatically. Selecting appropriate values remains the responsibility of the pakset author.
## Multi-vehicle and articulated convoys
The parameters belong to the vehicle that actually carries the goods, passengers or mail. Revenue for the contents of each vehicle is calculated using that vehicle's own descriptor.
Therefore:
- a locomotive carrying no cargo does not affect the fare of its carriages;
- different passenger or freight cars in the same convoy may use different values;
- one section of an articulated vehicle does not impose its values on the other sections;
- the total revenue of a mixed convoy is the sum of the results calculated for its individual carrying vehicles.
## Backward compatibility
The default values `100/0` preserve the previous behaviour:
- vehicles without the new parameters use the existing revenue calculation;
- existing version 13 vehicle pak objects continue to load and receive the default values;
- existing `speedbonus.tab` values and `bonus_basefactor` keep their current semantics;
- existing saved games require no migration because these values belong to vehicle descriptors in the pakset, not to vehicle instances in the savegame.
MakeObj writes vehicle descriptor version 14 to store the two new `uint16` values. Simutrans reads both versions 13 and 14. As usual for a new pak object version, version 14 vehicle objects produced by the new MakeObj are not expected to work with older Simutrans versions.
## User interface and scripting
For vehicles with non-default values, the depot, vehicle list and convoy details display:
```text
Fare reference speed: 50% of era speed
Maximum speed payment: 70%
```
These lines are hidden for vehicles using `100/0`, so existing paksets do not gain additional UI clutter.
The values are also exposed through the Squirrel vehicle descriptor API. The existing legacy revenue API remains available, while a vehicle-aware revenue calculation can be requested when a vehicle descriptor is available.
The patch includes documentation of the new DAT parameters.
## Validation
- Simutrans and MakeObj build successfully on macOS.
- The branch is rebased on the current master.
- All 284 automated Simutrans Standard scenario tests pass.
- The automated integration test builds a version 14 vehicle object with `50/70`, verifies increased revenue at an urban speed and verifies the payment cap at high speed.
- A default-value test verifies that `100/0` produces the legacy revenue result.
I also performed a local pak128 gameplay experiment using buses with equal capacity and operating costs on a well-loaded route limited to 50 km/h:
- the vehicle with the legacy calculation earned approximately 100 currency units per month and was deeply unprofitable;
- the vehicle using `50/70` earned more than 400 currency units per month and became profitable;
- an articulated bus with `50/70` on one 25-passenger section and default values on another 25-passenger section produced an intermediate result and remained slightly unprofitable.
The articulated vehicle result provides an additional practical check that each carrying section uses its own parameters.
These experimental values are not proposed as final pak128 balancing values. They were used only to validate the mechanism and the direction of the revenue change. Actual pakset balancing would be discussed separately after the engine feature is accepted.
## Scope
This patch provides a balancing mechanism only. It does not:
- rebalance any existing pakset;
- automatically classify vehicles as urban, intercity or high-speed;
- change existing vehicle speed, capacity or operating-cost values;
- replace the existing speed bonus system;
- require existing vehicle DAT files to define the new parameters;
- add a translation for only one language.
I would appreciate feedback on the overall concept, parameter names, default values, user-interface wording and implementation.
#93
Extension Requests / Re: Wish: Diagonal graphics fo...
Last post by makie - August 17, 2026, 07:02:27 AMOf course not, that requires the program change discussed above for drive on left. That is precisely why I haven't been able to test it.
Haven't you already received tons of error messages from makeobj?
Haven't you already received tons of error messages from makeobj?
#94
Technical Documentation / Re: Simutrans Squirrel 3.2 — S...
Last post by Andarix - August 17, 2026, 06:24:19 AM #95
Technical Documentation / Re: Simutrans Squirrel 3.2 — S...
Last post by victor_18993 - August 17, 2026, 12:51:54 AMUpdated attachment uploaded.
The Squirrel 3.2 documentation package now includes English, Spanish, German and Japanese, with a standardized international localization structure.
English remains the canonical technical source; Spanish is human-reviewed, while German and Japanese are clearly marked as AI-assisted translations pending human review.
The package also includes XLIFF, TMX and shared terminology data, so future translations can follow the same workflow and the documentation can be converted more easily for use in the Simutrans wikis and other publication formats.
The Squirrel 3.2 documentation package now includes English, Spanish, German and Japanese, with a standardized international localization structure.
English remains the canonical technical source; Spanish is human-reviewed, while German and Japanese are clearly marked as AI-assisted translations pending human review.
The package also includes XLIFF, TMX and shared terminology data, so future translations can follow the same workflow and the documentation can be converted more easily for use in the Simutrans wikis and other publication formats.
#96
Technical Documentation / Simutrans Squirrel 3.2 — Scrip...
Last post by victor_18993 - August 16, 2026, 09:09:31 PMThe Squirrel 3.2 migration for Simutrans Standard is now complete, and I have prepared a public developer reference covering the migration and its compatibility implications.
The runtime changes were integrated in trunk in r12165–r12168, with r12168 completing the accompanying documentation.
The main point for scenario and AI authors is that this is a Squirrel runtime update, not a redesign of the Simutrans Script API.
The migration was deliberately implemented so that the existing public Script API remains stable:
The documentation also covers:
A Spanish version has also been prepared from the reviewed Spanish documentation integrated with the migration.
This documentation applies to Simutrans Standard builds containing r12168 or later.
I hope this is useful both for people maintaining existing scripts and for future developers working on the Simutrans scripting layer.
The runtime changes were integrated in trunk in r12165–r12168, with r12168 completing the accompanying documentation.
The main point for scenario and AI authors is that this is a Squirrel runtime update, not a redesign of the Simutrans Script API.
The migration was deliberately implemented so that the existing public Script API remains stable:
- no registered Script API function was added, removed or renamed by the runtime migration;
- no public parameter list or default-argument behaviour changed;
- existing compatible scenarios and AI scripts should not require wholesale rewrites;
- old savegames containing script state were explicitly tested;
- no pakset changes are required.
The documentation also covers:
- the Squirrel 3.2 runtime provenance;
- the internal C++ embedding changes;
- the Code Select
sq_getinstanceup()adaptation; - Code Select
bindenvsupport; - the new Code Select
table.mapfunctionality; - compatibility guidance for scenario and AI authors;
- examples;
- Script API stability checks;
- migration validation results;
- the relevant SVN revisions.
- 284/284 full regression tests;
- 10/10 VM-specific tests;
- 2/2 orphan tests;
- no new Squirrel errors.
A Spanish version has also been prepared from the reviewed Spanish documentation integrated with the migration.
This documentation applies to Simutrans Standard builds containing r12168 or later.
I hope this is useful both for people maintaining existing scripts and for future developers working on the Simutrans scripting layer.
#97
Extension Requests / Re: Wish: Diagonal graphics fo...
Last post by prissi - August 16, 2026, 08:13:57 PMSomehow neither on diagonals nor on straight tiles I seen a sign appearing. Unluckily, I had not more time to test this today.
#98
Incorporated Patches and Solved Bug Reports / Re: Assertion failure when run...
Last post by victor_18993 - August 16, 2026, 05:10:48 PMThis issue has now been fixed and integrated into the official trunk as r12169.
The problem was in the way-building terraforming validation: the validator could reason from the original position while the execution path had already mutated the tile height. There was also a retry path in
Both cases are now covered by the same invariant: every route state returned by
The final fix was validated from a fresh checkout of trunk:
The problem was in the way-building terraforming validation: the validator could reason from the original position while the execution path had already mutated the tile height. There was also a retry path in
Code Select
calc_route() that could return a route containing terraforming decisions before running the final slope validation.Both cases are now covered by the same invariant: every route state returned by
Code Select
calc_route() is validated against the position/state described by the caller before it can be built.The final fix was validated from a fresh checkout of trunk:
- Debug: 284/284
- RelWithDebInfo: 284/284
- Release: 284/284
- targeted regression tests: 12/12
- assertions: 0
- FATAL: 0
- no new Squirrel or engine errors attributable to the fix
#99
Extension Requests / Re: Wish: Diagonal graphics fo...
Last post by makie - August 16, 2026, 04:17:22 PMI created the "autobahn" traffic signs for pak128, including diagonal, frontimage and left-hand traffic.
https://makie.de/p128_sign_road_autobahn.zip
I created it carefully, but since I can't test it, there might be errors. The positions of the straight sections aren't optimal; I left them as they were originally.
Attention: The program normally decides whether it draw as backimage or frontimage.
If the pak provide frontimage then "image" must drawn as backimage. Independent of the program logic.
That might be nonsensical for vertical diagonals, but I use it to position the graphics on the left and right independently.
Should set "offset_left=0" automatically if graphics provided for "drive on left"?
https://makie.de/p128_sign_road_autobahn.zip
I created it carefully, but since I can't test it, there might be errors. The positions of the straight sections aren't optimal; I left them as they were originally.
Attention: The program normally decides whether it draw as backimage or frontimage.
If the pak provide frontimage then "image" must drawn as backimage. Independent of the program logic.
That might be nonsensical for vertical diagonals, but I use it to position the graphics on the left and right independently.
Should set "offset_left=0" automatically if graphics provided for "drive on left"?
#100
Patches & Projects / Re: Modernisation of the Squir...
Last post by victor_18993 - August 16, 2026, 04:12:44 PMSquirrel 3.2 has now been integrated into the official Simutrans trunk.
The runtime migration was committed in three independently tested revisions, followed by a separate documentation commit:
Results:
With this, the Squirrel 3.2 migration is complete and the post-integration validation is green.
The runtime migration was committed in three independently tested revisions, followed by a separate documentation commit:
- r12165 — instance lookup API update
- r12166 — Code Select
bindenvsupport update - r12167 — remaining Squirrel 3.2 runtime reconciliation
- r12168 — migration and compatibility documentation
Results:
- full registered test suite: 284/284 passed
- Squirrel VM regression: 10/10
- orphan tests: 2/2
- no new Squirrel errors, assertions or fatal errors
- public Simutrans Script API unchanged
- compatibility testing for the shipped scripted AIs and old-runtime saves already passed in the previous migration campaign
- English and Spanish migration/compatibility documentation included
With this, the Squirrel 3.2 migration is complete and the post-integration validation is green.