jeroezie

Since the song of the thyristors is the real life sound, I can only argue that is in fact the natural sound... So not having the, albeit annoying, singing thyristors is unnatural / producing faked sounds. But I do understand, that for a lot of players, it is prefarable. That is why I advocate for an opt out of the real but annoting thyristor sound. On the other hand, I am already getting somewhat used to it and I start to fibd it less annoying. If you aks me, under no surcubstance, the real sound should be opt in. But an opt put, let the player decide for her/himself.

Patch 1.5 changelog Added a container and tank wagon only trainset (120 and 100 km/h vmax respectively); Slight adjustments of existing trainsets so the weight and length variations fit well together with the additions; Removed towed locomotives from the rear of the 'fast' cargo trains; Improved ČD163 options (for example: different list of loco's to choose from for the passenger carriages set); Improved weather and added snowstorm weather; Improved randomised bot trains and the library for it; Again tweaked the timetable a very little; Minor bugfixes and adjustments to the scenario; Improved bot trains around scenario ending. The file can be downloaded at the first post or automatically via the steam workshop.

They have very high realism standards. And they seem unwilling to break their realism quality standards. Usually that works in our favour, big time. For example, when the improve lighting, weather or train physics. They could have opted to simply leave it as is, it was good enough. But they wanted it to be better. Only, in this case, the 'good' realistic way of doing things, is not seen as the optimal result by a big part of the community. So I do think, that it would be better, if their was an opt out of the high realism in this regard, so you can choose to have a reduced engine humm in the CD163. Why they are silent on this complaint of a large part of the community, other than pointing out that this is actually realistic and thus not a mistake or bug, I do not know.

"Baa's not buzzes." This is literally the funniest thing I have read this year! Even with heavy freights you can tactically switch the first engine in and out. When you drive at a constant speed low speed for a prolonged time, you can switch out the front one, as soon as you have reached the desired speed. This greatly recuses the (...) annoying noise when driving long distances with low speed and when shunting.

The brake releaser do only work on the locomotives brakes. With old stock, like EU08, EP08 etc. this drains air from a very slow filling reservoir, so the effect will last long. On more modern stock such as Br 186 and dragon locomotives, it drains the locomotives brakes only when being actually pressed. The brake assimilation increased the brake line pressure from 5,0 bar to 5,4 bar. This is to deal with pressure differences in the brake pipe. It will also ensure all triple valves (this valve translates the brake pipe pressure to cylinder pressure that goes to the actual brakes) have an adequate pipe pressure, so they release the brake full, even if they are overcharged (for example by a previous pressure spike). The brake assimilation or fill position, depending on the locomotive, does use a higher pressure and/or a bigger 'hole' in the brake leaver, to fill the brake pipe, so it is a much faster process and filling it only using drive/release position. But you have to be careful to NOT overcharge the triple valves.

I noticed, that if you are in the external camera mode, default keybind 2, so you can take a look at your whole train, you can cause a bug when dragging the dev menu's around. Noticed in next branch, build 31/01/2026 - 16:31. Steps to reproduce: Go to the external/fly camera mode, so you have a good view of both the train and surroundings; Open dev menu mode (default keybind F8) and open any of the menu's; Click on the [ ] icon, in the upper left corner of any dev menu (right of the X button), such as but not limited too LUA developer or TS developer; Drag the title bar of any menu around (while in external camera mode); Not only the menu moves around, but the camera too, resulting in the bug; You can go to another camera mode, such as driver seat or alongside the vehicles and the camera will behave normally; If you enter external / fly cam again, the camera view will remain distorted. For those who find it easy to understand in an graphical way, see the picture, in red an example of a menu to drag around while in the camera mode the problem is.

O the whole train gets mirrored? Now I understand the issue. It is indeed a real problem instead of a detail, like I mistakenly thought.

You could not change cabins again?

Walk to the other cab. As long as it is not a double pendolino, its not that big of an issue.

What rolling stock are you driving? I made the mistake once, with the new CD163, to keep the passive drive enabeled.

The later made or remate scenario's allow to pick a season and time (choosing any hour of the day). This should result in plenty of options. Only downside, this part of the code is very hard to understand for new lua programmers. I did not even try to add it to my scenario's.

It would be very cool, if we could pull the air. If the braje releaser handels on the wagons or carriaged actually worked, it would be evdn better (and a good reason for the driver to not overcharge the brake, even when one can pull the air). Very handy for the Ty2 too.

No the didpatchers work in a very very different way. In SP, you have to script them manually from signal to signal. Despawning trains is not as easy as it sounds. They have to be loaded in, so close to the player. You can run the command (needs manual scrpiting too) to despawn when they are far from the player, but they will remain in an simplified state intil the player is near again. And when you do despawn a train, you have to make sure to do it in an apropriate location, otherwise you live behind a partly driven off route in a switch, causing the virtual dispatcher to get stuck. The whole world is simply operated in a very different way.

The screenfhot and data/log are fron after coupling and manually flipping the radio spiltter to B cabin, so radio is workable agin.

I do not think, sich a thing is possible. The dispatchers work in such a different way. Spawning of trains works different too. And a home pc could never deal with a server full of trains.

Last time I attempted to spawn bot driven trains with reversed wagons, it was pretty fun too. Turn out, in bot driven trains, all wagons will go the 'pretend' forwards. But they don't seem to get the massage, they are flipped. So the train will pull itself apart because the wagons will move in opposite directions. But that was a longggggggg time ago.

While standing with a single loco in the deport, I was unable to reproduce the bug. But it got interesting as soon as I coupled up the the wagons after shunting: when I got back in the cab after coupling, the radio green light was unlit, before getting out of the cab, it was lit up. Setting the reverser forwards or backwards had no effect on the radio light. Changing the radio signal splitter cabin from A to B got the radio working again. I am unsure, what data vale, you are referring to. If you need more information from me, please describe it better. I will attach entire Vehicle I/O and log file, as after coupling, where the radio only works with the spiller on B cab. If I can help with gathering more info, please let me know, I am happy to help. vehicle IO after coupling.txt SimRail_log_2026-01-28_18-26-48.txt

The paperwork is usually based on avarages, and on dry weather with good grip on the rails. So it could be, that you cant keep speed fully uphill. My personal (non fact based) advise: take the paperwork with a grain of salt!

The bug is present in my Lazy to Katowicd cargo scenario. I dont know for sure out of my head, but I probaly do spawn ut reversed. I have only a light signal in the vack and I find them easy to referance compared ti findtrack. I could swap it of course for a track referance. If you like to try see the bug in the scenario, you can find it here: https://steamcommunity.com/sharedfiles/filedetails/?id=3628486286&searchtext= or Make sure to pick one of the first Ty2 loco's, the thirt option spawns the other way around (so you drive the cargo train tender first, which is kinda strange). Personally I have the impression (but no facts to prove it at all) that spawning vshicels reversed can mess around with more things. Might you have any ideas/info on that?

This does sound great. But in singleplayer, the virtual dispatcher works in a very very different way then the AI dispatchers in multiplayer. I do think, that it is very unrealistic to make it work. It would be so much work to recreate the multiplayer server in an dingleplayer environment.

When you raise the pantographs with a CD163 locomotive, the overhead voltage appears on the meter, almost instantly after turning the raise pantograph switch. It voltage is shown/available long before the pantograph(s) make contact with the overhead wires. Build 24/01/2026 - 21:58.

I have the wiki page with cold start instruction opened, othetwise I am lost to. I reccomed to keep it around. Link: https://wiki.simrail.eu/Vehicles/Poland/Trains/Locomotives/71E

This is onw of the oldest scenario's in the game. It was made before bot trains where possible at all. Recently, all scenario's in the old code format, JSON, where remade into LUA code. They are working on making more improvements to them, so they should get bot trains. At the moment, having all old scenario's runnimg without bugs is the priorety for the game update. Meanwhile, try one of the later made scenario's, they have bot trains. Most player made scebarios, have bots as well, and dirscibe this on the forum and steam workshop page, before you have to diwnload and try the scenario.

Maybe their would have been less confusion, if the true meaning of the R*, as volume setting, is widespread. It could be included in the tutorial. Maybe an idea to add to the wiki @Moooritz?

I understand. I don't think it is worthwhile to rewrite a lot of code. It is only a tiny bug, its more a cosmetic thing then a real issue. Thanks for the reply.