ETS2LA: a plugin platform for self-driving in the truck simulators

What the project is and where the documentation lives

ETS2LA aims to finally bring self-driving technology to SCS Software's Truck Simulators, and the README is clear about what kind of project it is: a plugin based interface program for ETS2 and ATS, with the topic tags naming American Truck Simulator, Euro Truck Simulator 2 and self-driving.

The README is mostly a signpost, which is sensible for a project this size. There is a download link to the latest release with installation instructions, a Discord community, a website for troubleshooting and help, and developer documentation at docs.ets2la.com.

The README also flags its own staleness, which is worth repeating because it is unusual and useful. The website link carries the note that it is out of date with the current version, while the docs link is where the knowledge base actually lives. For a project that changes several times a month, having two documentation sites with different currency is a trap, and the README points at the current one.

The support path is a FAQ on the website, and if the question is not there the Discord support channel is the fallback, with the promise that common questions get added to the FAQ.

The release cadence is visible in the tags. The recent releases are v2026.10.5180 from 2026-10-17, v2026.10.5159 from 2026-10-15 and v2026.10.5146 from 2026-10-13, and the version strings are dated and numbered rather than semantic, which is a strong signal of a project that ships continuously to match a game that also updates continuously.

The game data extraction and the map parsing

The acknowledgements section is short and it explains the two dependencies that everything else rests on.

TruckLib is credited as the project used to extract the game files, and the README says this version of ETS2LA is fundamentally linked to TruckLib. That is the honest way to put it: the project does not parse the game's assets itself, it depends on a separate extraction library, and that dependency is a submodule in the repository, sitting alongside a .gitmodules file.

The second dependency is on ts-map and the maps repository, credited for their help and examples in parsing SCS map files and rendering a usable map. So the route data comes from the game's own map files, parsed into something the driving stack can navigate, rather than from a hand-drawn route or a separate map format.

Those two dependencies are what make the difference between this and a scripted follower. A driving plugin needs to know where the roads are and where the truck is, and both of those come out of the game rather than out of an external dataset.

The third acknowledgement is to SCS Software themselves, for making the simulators in the first place, and the project links their site. The relationship is the ordinary one for a modding project: the simulator is the platform, and this is a third-party program that reads it.

The twenty-project solution and what each area does

The repository root lists the solution and the projects inside it, and the naming tells you how the system is decomposed.

There is ETS2LA.Backend, which is the part that does the work, and ETS2LA.Controls, which is the part that decides what the truck should do. The split between sensing and acting is the classic one, and having it as two projects rather than one is the kind of separation that lets a plugin author work on one without touching the other.

Then there are the supporting layers. ETS2LA.Game deals with the game itself, ETS2LA.State holds the shared state, and ETS2LA.Shared holds what both sides need. ETS2LA.UI and ETS2LA.Overlay are the user interface and the on-screen overlay, and ETS2LA.Settings and ETS2LA.Logging and ETS2LA.Notifications cover configuration, diagnostics and user alerts.

Three of the directories are worth singling out. ETS2LA.Telemetry suggests instrumentation of the simulation, and ETS2LA.Audio suggests sound handling. ETS2LA.ML is the interesting one, since it means the project has a machine learning component rather than a rule-based follower, and the ETS2LA.Translations directory holds the localisation files.

There is also ETS2LA.Networking, which points at a networking layer for talking to external services, and ETS2LA.Audio for the sound side. The Windows build scripts come in pairs, publish.bat and publish.sh, and the Velopack scripts velopack.bat and velopack.sh, which is the update and packaging framework the project uses for its releases. There is a dotnet-tools.json at the root for the local .NET tools.

The primary language in the repository metadata is HTML, which is presumably a measurement artefact of the web interface and the overlay, while the release tags are named ETS2LA C#, which is the actual implementation language.

Building it, running the tools and working on translations

The developer section is clearly marked as being for developers, with a note that a normal user should use the information above it.

The build requirements are .NET 10 from Microsoft and Bun, which is the JavaScript runtime used for the front end. You clone the repository, open the solution file in an IDE, and the project comes prepackaged with VSCode tasks for Windows and Linux. The C# Dev Kit extension is recommended, with the note that other IDEs should have their own equivalent. Two commands prepare the toolchain, dotnet restore and dotnet tool restore, run in the root of the repository, and then running it depends on the IDE, with F5 in VSCode being the common case.

The translation workflow is a case study in how not to break a localisation system, and the warning is emphatic. Weblate commits translations every so often, usually within a few hours, but to test a translation immediately there is a specific sequence. In Weblate you click your language, then at the top you click Files and choose Download original translation files as ZIP file. You copy the language code .po file from the localisation folder inside the ZIP into the matching path in your local project, and then build, and your new translations are included.

The warning is that you must not upload those files back to Weblate. You can edit the files locally and, if you want a change to land upstream, edit the text manually in Weblate. The stated reason is that uploading translation files can and will break credits, and will also cause the loss of some translations. That is a specific and credible failure mode, since the automatic commit pipeline and a manual upload will conflict, and losing translator credits is the kind of damage a project cannot undo.

Where ETS2LA is the wrong choice

The first limitation is the scope. Everything here is scoped to a simulator, and the interface between the program and the game is a data extraction library reading the game's files. That is a very different proposition from a real vehicle, and any expectation that the techniques transfer directly is misplaced, because the difficult part in a real vehicle is perception of an unstructured world rather than parsing a map file.

The second is the coupling to TruckLib. The README says this version is fundamentally linked to it, and that is a hard dependency on another project's extraction logic staying compatible with a game that updates regularly. When the game changes its file formats, the breakage lands in the extraction layer, and the project has no control over that.

The third is the size of the codebase for a plugin author. Twenty projects means a plugin has to find the right seam, and the relevant seams are the controls, the state and the game interface. A project that wanted a single button to do a thing on the highway would find this heavy.

The fourth is the release pressure. The tags show releases on consecutive days in October 2026, and the version numbers embed the date. That is a reasonable way to ship against a moving target, and it also means a plugin pinned to a specific ETS2LA build will break when the game updates and the project has to chase it. The README's own note that the website is out of date with the current version is a symptom of the same pressure.

The fifth is the game rules question. This is a third-party program that drives a vehicle in a game, and the simulator's own rules about automated driving are the project owner's to set. The README does not address it, and a user installing a driving plugin should find out what the platform permits before relying on it.

ETS2LA compared with a scripted follower and with a general driving stack

The comparison with a simple scripted route follower is the first one, and the difference in approach is between following a fixed path and perceiving the world. A route follower needs the map and a lane list, and it produces a vehicle that drives well on a highway and fails at a junction, because the decision of which exit to take is not in the plan. A stack that reads the game state, holds a model of the surroundings and plans against it is a different category of thing, and the project structure reflects that with a separate controls project, a state project and a machine learning project.

The second comparison is with a general autonomous driving stack, and the difference is that this one is a plugin rather than a system. There is no sensor abstraction, because the sensors are the game's own state, and no simulation harness, because the game is the simulation. In exchange you get a working environment with physics, traffic and a map, which is a genuinely useful research bed, and the ability to write plugins against it.

The third comparison is with the other modding ecosystems for the simulators. There are map and truck mods, and there are the official telemetry and SDK surfaces the simulator provides. This project sits above the official surface, using file extraction rather than a supported API, which is what makes it possible to do things the official surface does not expose, and also what makes it fragile.

The fourth is with writing your own plugin from scratch. The README says the developer documentation is where to start if you want to work on ETS2LA or plugins, which suggests the plugin API is the intended extension point. For a developer who wants one behaviour, a single plugin against this platform is much less work than reimplementing the extraction, the map rendering and the state handling.

Licence, community and what to check before you install or build it

The licence field on the repository records GPL-3.0, with a LICENSE.txt file at the root. GPL is the usual choice for a modding project that reads another program's data files, and it is also the licence that means a derived project has to publish its source, which for a plugin ecosystem is a reasonable norm.

The project is not archived and the last push was on 2026-10-18, so it is being worked on, with the newest release from two days before that.

The community is the Discord, which the README names for talking to the developers and for support, and the contributing guide is CONTRIBUTING.md, which the README asks people to read before opening a pull request. There is an AGENTS.md and a CLAUDE.md at the root as well, which are the current convention for agent instructions in a repository, alongside a .cnb.yml for a Chinese build service and a .vscode/ directory with the tasks the build instructions refer to.

Four things to check before you commit to it.

Which version of ETS2LA you need, since the project ships continuously and the plugins you find are written against a particular build.

Whether the game allows it. This is a third-party program that drives a vehicle in someone else's game, and the platform owner's rules govern that, and nothing in the repository speaks to it.

Whether you want the plugin platform or the whole application, because the download link is for the full program while the developer documentation is for the platform, and they are different audiences with different expectations of what you do next.

And, if you are going to build it, the toolchain. .NET 10 and Bun, two restores before anything runs, and an IDE with the right extension. The docs site is the place to check whether that has changed since this README was written.

Editorial conclusion

ETS2LA suits a developer who wants to write plugins for an autonomous driving stack in a truck simulator, or a player who wants to install a ready-made driving assistant, and who is comfortable with .NET and a game that is still being updated. It is the wrong tool for anyone expecting a real vehicle, since the entire project is scoped to a simulator, and the wrong choice if you need the interface to be a thin add-on, because the scope covers a backend, telemetry, a machine learning project and a notifications pipeline. Before you start, read the developer documentation at docs.ets2la.com rather than the website, which the README itself flags as out of date with the current version.

Frequently asked questions

Official sources

1. ETS2LA/ETS2LA on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases