17
0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-11-09 11:22:25 +01:00
pwarszawski 92bd7ef827 AI braking: hold the speed on a descent
Two changes that only work together: the first on its own lets a heavy
freight train brake less on a descent than it needs (in testing an
ET42 with 30 loaded wagons overran the stop signal by 16-48 m at 20 per
mille), the second makes the hold on a descent what it should be.

The comparison that decides whether the AI may skip its reaction time
between two brake steps stays on the brake-only demand, as before: it
is about how much brake is asked for, and a heavy train in G approaching
a stop on a descent needs its brake built up at once. Compared in the
resultant frame, that train built up its brake one step per reaction
time and overran the signal (16 copies of the ET42 train, x20:
22 of 32 overruns with the comparison moved, 0 of 48 with it kept).

1. Compare the measured deceleration in the same frame.

Going downhill, adjust_desired_speed_for_current_speed() subtracts the
gravity component from AccDesired, so that IncBrake() sizes the handle
position for what the brake alone has to deliver. control_braking_force()
then compares that brake-only value with AbsAccS, which is the resultant
acceleration and already contains the gravity. On a 20 per mille descent
the two differ by about 0.2 m/s2, so the AI asked for more braking than
the target needed and then released, and repeated that.

Keep the subtracted part in fAccDesiredGravity and add it back wherever
AccDesired is compared with AbsAccS. It is zero everywhere else (flat,
uphill, braking test), so the behaviour there does not change.

2. Hold the speed with one continuous law.

On a descent the AI looks ahead to decide whether it will exceed the
target speed. The look-ahead was (1 - a0) * 30 / 3.6 s, a few seconds,
while a pneumatic brake in G takes tens of seconds to apply or to
release; the AI therefore acted on an estimate the train had already
left behind. The demand then jumped between the braking threshold above
the target and a lerp towards full acceleration below it, and with the
brake that slow this turned into long alternating applications and
releases.

- look ahead for half the brake application time while the train is
  speeding up and half the release time while it is slowing down
  (brake_response_horizon), never less than before;
- use one law on both sides of the target, proportional to the
  predicted difference, and hold a band just below the limit that widens
  with the gradient (pneumatic up to 3 km/h, EP/electric up to 1.5 km/h);
- once below a lower limit ahead, hold that limit instead of speeding up
  towards the line speed and braking again.
2026-09-28 15:45:10 +02:00
2026-09-14 22:51:33 +02:00
2026-09-14 21:11:08 +02:00
2025-03-09 15:36:11 +01:00
2026-06-17 01:19:59 +02:00
2026-07-25 12:59:54 +02:00
2025-03-09 15:36:11 +01:00
2026-09-14 22:51:33 +02:00
2026-04-19 04:15:25 +02:00
2017-10-28 19:21:37 +02:00
2025-11-16 19:00:38 +01:00
2025-09-19 17:53:46 +02:00
2026-03-14 20:51:11 +01:00
2015-04-03 21:58:35 +08:00
2026-04-01 20:10:33 +02:00
2026-08-19 14:50:28 +02:00
2026-05-11 18:21:12 +02:00
2025-09-09 16:46:12 +02:00
2026-02-25 08:30:20 +01:00
2025-03-09 15:36:11 +01:00
2021-02-13 18:32:19 +01:00
2019-07-09 22:09:37 +02:00

Repo banner

MaSzyna - Railway vehicle simulator

Website · Report an issue · Community Discord · MaSzyna on Steam · MaSzyna on Epic Games Store

Discord Github Actions Quality gate Sonar cloud violations License: MPL 2.0 Last commit Open issues Pull requests GitHub stars GitHub forks C++ Windows Linux OpenGL

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)

  • CMake (3.0)

  • make

  • A C++ compiler with C++20 support:

    • Windows: Visual Studio 2022

    • Linux: GCC (12.3.1)

Note: MinGW is currently not supported.

2) Libraries (oldest tested in parentheses)

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_RENDERER uses 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

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

Languages
C++ 64.3%
C 33%
HLSL 1.4%
GLSL 0.6%
Python 0.4%
Other 0.3%