ce87aa0e09
The new braking curve below plans the stop at the signal itself unless the stopping point moves with it (in testing, trains stopped 0-3 m past the signal), so both go in one change. 1. The braking curve. The braking curve towards a lower speed or a stop assumed a constant deceleration from the present speed over the whole distance. A pneumatic brake does not work like that: - it acts on the state the train is in once it has applied; while the train is still speeding up (downhill), plan from the speed it will have reached by then, over the distance left by then; - cast iron blocks grip harder as the train slows, so a constant deceleration plan asks for too much at the start and then releases; follow the shape of the consist brake table (fBrake_a0/a1) over speed instead (shaped_braking_demand), over the distance left once the brake has had its fill time; - no power while the train is still above the speed it is braking for. IncBrake() only adds braking when the brake table says the present position is not enough. When the table overestimates the consist (see the previous rapid step fix, or a descent), the train keeps slowing too little with the handle held. After the full fill time with the handle unchanged, believe the train rather than the table (fBrakeHeldTime). When the AI asks for no braking and the train is still slowing down more than that, release. With the gentler plan above the demand eases off early, and without this a heavy freight train in G came to a stand a few hundred metres before a W4 with its brake still on (seen in testing). 2. The stopping window. In train running the final approach to a stop signal began at fMaxProximityDist (15-40 m, cargo 25-50 m), aimed at half of fMinProximityDist (10-15 m, cargo 20-25 m), and set VelDesired = 0, which asks for hard braking whatever the distance left. Where a train came to a stand depended on how it entered that phase: on the test sceneries anywhere from 1 to 45 m short of the signal on the flat and 25-42 m uphill for heavy freight. For train running only (a W4 stop point, shunting and coupling keep the old margins and the old final approach): - stop 8-15 m short of the signal whatever the length of the train, aim at the middle of that window (stopping_margin) both with the braking curve and in the final approach, and ask there only for what the distance left takes, following the consist brake table; - start the final approach 50 m out (cargo 60 m) whether the train is moving or standing; it used to be 15-40 m while moving and 50 m once stopped, and with the gentler final approach above a train that came to a stand between the two released to creep closer and, uphill, rolled back and tried again; - uphill, while the gradient alone would bring the train to a stand short of the window, keep it rolling at no more than the speed the gradient can take off by then, with power if needed; - uphill, put the train brake on as the train comes to a stand, keep it on while it stands, and apply it for real if the train rolls back. This is done at the very end of pick_optimal_speed(): the adjustments made before it assume a train moving forward and can raise the demand back to "no braking" (with the rule placed earlier, EMUs rolled back up to 90 m in testing). The EMU branch of control_braking_force() gets the "slipping back" condition the wagon branch has always had. 3. Known limitation. Heavy trains of wagons with the ESt3AL2 distributor (413S, 601W and alike) respond more slowly than the AI expects: with the present brake model the distributor fills the AL2 relay chamber, whose capacity is set to 2 in TNESt3::SetSize (Przekladniki[i]->CreateCap(i)), through orifices sized for about 1 l, so these wagons need 34 s to reach 95 % cylinder pressure in G against 21 s for a plain ESt3. On a 20 per mille descent an ET22 with 20 loaded 413S wagons overran the stop signal by up to 6.5 m in 6 of 24 runs at x20 with this change. With the relay chamber at 1 l and the release orifices at about 80 % of their diameter, as the author of the brake model suggested, none of them did (0 of 16).
MaSzyna - Railway vehicle simulator
Website · Report an issue · Community Discord · MaSzyna on Steam · MaSzyna on Epic Games Store
MaSzyna executable source code is licensed under the MPL 2.0 and comes with a large pack of free assets under a custom license.
Table of Contents
Getting Started
MaSzyna compiles and runs natively on Linux and Windows. Other platforms are not tested.
Heads-up
Our dev team is small; we keep improving the build process, but issues may still occur. If you get stuck, please ask on the official Discord server.
Prerequisites
For runtime requirements see Minimum Requirements.
1) Software (oldest tested in parentheses)
Note: MinGW is currently not supported.
2) Libraries (oldest tested in parentheses)
-
GLFW 3.x (3.2.1)
If a link error occurs, pass-DGLFW3_LIBRARIES="<path>"to CMake. -
GLM (0.9.9.0)
-
libserialport (0.1.1)
-
libsndfile (1.0.28)
-
LuaJIT (2.0.5)
-
GLEW (2.1.0)
-
libpng (1.6.34)
-
OpenAL (1.18.2)
-
pthread
-
Python 3.14 (64-bit; headers and import library required for embedding)
-
Asio (1.12)
3) Graphics API
- OpenGL 3.0 or newer
- DirectX 12 via NVRHI (optional, Windows only, for Better Renderer)
CMake flags
| Flag | Meaning |
|---|---|
-DCMAKE_BUILD_TYPE=Debug |
Debug build |
-DCMAKE_BUILD_TYPE=Release |
Release build |
-DCMAKE_BUILD_TYPE=RelWithDebInfo |
Release build with debug symbols |
-DWITH_BETTER_RENDERER=ON/OFF |
Enable/disable NVRHI-based renderer |
-DPython3_ROOT_DIR=<path> |
Root of the Python 3.14 install on Windows (python.exe, Lib, DLLs) for embed/copy steps; on Linux, optional if CMake picks the wrong interpreter |
Linux note:
WITH_BETTER_RENDERERuses DirectX 12 through NVRHI and is not supported on Linux.
Windows
Install Python 3.14 x64 from python.org and include the optional Python native development feature (headers and .lib for embedding). Pass -DPython3_ROOT_DIR="C:\Path\To\Python314" on the cmake line when you want the layout under that directory used for embedding and for copying Lib / DLLs next to the executable.
AppVeyor CI builds with the worker image’s preinstalled Python at C:/Python314-x64 (see appveyor.yml: -DPython3_ROOT_DIR=...).
# Clone repository with submodules
git clone --recursive https://github.com/MaSzyna-EU07/maszyna.git
cd maszyna
# Init vcpkg
call setup.bat
# Create directory for CMake build files
mkdir build
cd build
# Generate CMake project (replace %CONFIG% with Debug/Release/RelWithDebInfo)
cmake .. -G "Visual Studio 17 2022" -A x64 -DCMAKE_BUILD_TYPE=%CONFIG%
# Build (replace %CONFIG% accordingly)
cmake --build . --config %CONFIG% --parallel
Linux
# Install dependencies (Fedora/RHEL family)
sudo dnf install -y \
@development-tools \
cmake \
mesa-libGL-devel \
glew-devel \
glfw-devel \
python3.14-devel \
libpng-devel \
openal-soft-devel \
luajit-devel \
libserialport-devel \
libsndfile-devel \
gcc \
g++ \
wayland-devel \
wayland-protocols-devel \
libxkbcommon-devel
# Clone repository with submodules
git clone --recursive https://github.com/MaSzyna-EU07/maszyna.git
cd maszyna
# Create directory for CMake build files
mkdir build
cd build
# Generate Makefiles (NVRHI is not supported on Linux)
cmake .. -DWITH_BETTER_RENDERER=OFF
# Compile using all cores
make -j"$(nproc)"
Tip (Ubuntu/Debian): Package names differ; install equivalent
build-essential,libgl1-mesa-dev,libglew-dev,libglfw3-dev,python3.14-dev,libpng-dev,libopenal-dev,libluajit-5.1-dev,libserialport-dev,libsndfile1-dev, and Wayland/X11 dev packages as needed.
Installing
There is no make install yet. Copy the built executable to your MaSzyna installation manually.
-
Output directory:
./bin -
File name format:
eu07_YYYY-MM-DD_<commit>[_d]-
YYYY-MM-DD– build date -
<commit>– short commit hash -
_d– present in Debug builds
-
If you already have the MaSzyna assets, copy the executable to the install dir. Assets can be downloaded from eu07.pl.
Rainsted on Linux
If Rainsted (a third‑party starter) fails to detect the executable under Linux, you can create a small wrapper script named eu07.exe:
#!/bin/sh
./eu07 "$1" "$2" "$3" "$4" "$5"
If detection still fails, padding the file (with comments) up to ~1 MB may help.
Known Issues
-
GLFW linking – On some systems you must provide the GLFW library path explicitly with
-DGLFW3_LIBRARIES. -
X11/Wayland linking order – Linking order of X11 and related libs can matter.
-
NVRHI on Linux – The NVRHI/"Better Renderer" path targets DirectX 12 and is currently unsupported on Linux.
Support
-
Official Discord Server: https://discord.gg/qAh9ctWPQv
-
Project page: https://eu07.pl/
Minimum requirements
- OS: Windows 10 64-bit
- Processor: 2 core at least 2 GHz (e.g. Intel Core i3-2100 / AMD Athlon II X2)
- RAM: 6 GB RAM
- Graphics Card: supporting OpenGL 3.3 with at least 1GB VRAM
- 150 GB of free disk space
- Sound card supporting OpenAL with stereo
- Optional COM ports for custom control panel setups.
License
-
Source code: MPL 2.0
-
Assets: Custom license