Hello everyone, As we're now into Phase 3 of the core development work, our focus has turned to some long standing issues. This afternoon, around 2pm, we'll be pushing out the next Public Beta build for your attention. Please post your feedback relating only to the build version 78.1a here. If you wish to discuss things not relating to this beta, please use the other forums. What's Included/Changed Here's an outline of what we're providing in this update: Fix to prevent trains sliding when parked on a hill. Train physics are now paused when trains are stopped on slopes with brakes applied and the simulation is not producing any output forces. Fix for not being able to add trains to portals. Partial fix for some cases of invisible trains passing by when the player is stationary. Fix for asserts in 2D map due to incorrect return value in comparison operation (when sorting map elements with same x or y values). Fix to allow the Shapeviewer Preview in the Blueprint Editor to use the same resolution as set in-game for windowed resolutions. Added check to prevent flooding of Lua message passing that could cause a hang/crash loading or restoring from save in some scenarios with particular signal scripts. A warning is printed to logmate when the flood limit is reached. XML files from Steam Workshop that fail to load now cause the installation to abort, rather than leaving corrupt XML files installed. Fix for headlight flare rendering. Also implemented dynamic flare culling, to mitigate issues when large numbers of flares impact the framerate. Revert recent change of float->double precision for simulation time / time of day to address issues with some weather expansions. The input mapper now changes when switching cabs in a consist with multiple rail vehicle types. Removed old and no longer used installer files (dotNet, VC redist, dx, xinput, OpenAL) from the installation folder. Reduced logmate output spam for script performance warnings. Warnings are now only printed every 10 seconds. Cleaned up cab camera set height code to remove possible floating point errors. In some situations, we were not able to find and fully fix some issues as they are much more complex than first thought. But, in all cases, there are notable improvements overall so, it was worth compiling these into the latest build and putting it out there for players. There is likely to be some tweaking needed as we move forward so be on the lookout for undesirable behaviour, particularly related to situations where signals are failing to work properly on routes. As always, we're interested in your feedback and any problems you're finding. Best, Steve
First three are pretty major and much appreciated Developers (including RSC) may need to check handbrake set up does not cause derailment when decoupling on a hill.
Does the crawl fix on hills also apply when on level ground? I've always found when you stop with the brakes on, the train will just slowly creep forward/back so will that also apply there or is it just specifically for de/inclines?
Thanks for another great update to TSC. After the last beta went public, I've managed to export most stuff with Blueprint Editor 64-bit. But if I export any animation (IA) the game will crash. This error is still present in the latest beta. If needed I can upload the animation and/or provide any logs. All my animations are made in Blender and works if exported with the default Blueprint Editor.
Signalling issue: AP MML London to Bedford - scenario APSWEP 2O46 This signal must be tabbed now - which is wrong. It worked before. 5 minutes into the scenario. All following signals must also be tabbed. There's a service in front, seems the block clear messages don't arrive. Kind of reversed RSSLO signal problem
The same with JT MML service 1C00 07:25 Sheffield to S:t Pancras. All signals red and have to be tabbed. When I went back to a stable version it worked as expected.
Installscript.vdf needs a cleanup, as the following parts are distributed via the Steam Common Redistributables, these lines are obsolete as the files do not exist anymore. Also, RailWorks\setup_audio.bat is still present in the core depot. Please remove. The empty folders on the right hand side should also be removed from the depot. Is the distributed PhysX software still required? On the left hand side, this is what Steam installs. Probably TS relies on the supplied version, fair enough.
One thing I noticed it that the Command Line window from AP's SWEP doesn't appear any more on startup. Normally, you see it flashing shortly before the splash logo appears. (Yes I've installed the WeatherEP to the Beta.) It is called by their modified startup script RailWorks\dev\scripts\EngineScript.lua, which itself calls Assets\AP\WeatherEP\Script/weather.out Is this blocked?
This would appear to broken once again, scenario timings if an FPS Lock is enabled through launch options - this was a most unexpected and most welcome fix under v77.6b. A backwards step, I do hope a compromise can be accomdated. (Post edited after some quiet reflection).
No need for emotions, the Beta participation is voluntary. Just test and report findings, and things will be fixed.
Take it from me, I have plenty of beta experience and know the score. I also know that reporting an issue does not automatically result in a fix. No emotion.
Changes that are released for testing in the Alpha and Beta will be reverted if proven unsuccessful - don't worry. That's the whole idea of the public beta, and it was good they introduced it after years of just pushing out updates to the public stable branch.
I see it here and also the same window when you run a scenario that uses the AP SWEP Weather track marker. The command line window doesn't appear on top of anything else that may be occupying the same part of the screen so it's easily missed.
I know. I'm an experienced beta tester and have released hundreds of patches too. Not sure what this has to do with the fear of a step backwards being permanent though. So far, Steve has addressed all feedback in the beta threads. Which is the purpose of the beta. I just did not fully understand the relation between scenario timings, FPS lock and the quoted floating point reversion, maybe I need an example scenario for reproducing.
Apply an FPS lock of 30. (-FPSLimit=30). Compile a scenario with a start time of 2100 for example, with fully timetabled stations stops. Run the scenario, watch the disparity between HUD clock and station timings.
Will check that. Do you think it is related to float/double precision? Just I can understand - you're saying reverting this will affect scenario timings? As you're experienced, you're aware of the deviating ETA time resulting from a mismatch between manually set ETAs and performance percentage which I've empirically proven? Just want to understand the relation to simulation time precision here, and where was FPS lock mentioned in the changelog, I still don't understand how it relates to what you've quoted. The best way would be to compile a scenario and run it under both the beta and the stable version for getting results to works with.
This is exactly what I've done. I'm seeing different behaviour of the dispatcher between the stable version and beta - with an FPS lock of 30. I don't purport to know the full ins and outs of this, I can only relate my experiences given what little I do know and knowledge of how this has also affected other users. FPS lock is not mentioned in the changelog, but it is a factor when it comes to simulation time. A player who I worked with in the past summed it up nicely. They referred to it as the 'two clocks bug', where the time on the HUD seems to be at odds with the internal clock that the dispatcher is using to manage the scenario, and the deviation between the two increases as the scenario progresses, more so the later in the day that a scenario is set. They had an FPS lock in place. With the lock removed, the disparity between the 'two clocks' was minimised. In summary with an FPS lock in place, with the stable version I am seeing much more reliable and predictable dispatcher performance. On trying the beta it has reverted to behaving as outlined above. The crucial change point between the two being the revertion of changes made to simulation timing. EDIT: You could be forgiven for thinking why not just remove the FPS lock? There can be many reasons why a player may have one in place, in my case I find it provides a smoother experience. As said previously, I sincerely hope the DTG team can arrive at a compromise.
rfletcher72 Just to make sure, I take it we are talking about this issue, which I dissected in that thread: TL;DR: Don't adjust the arrival times manually. Use percentage field. https://forums.dovetailgames.com/th...-and-issues-with-eta.71022/page-2#post-670185 If that's related to what you mean, I don't think it can be changed as it lies in the dispatcher core and would probably break almost all scenarios existing.
No it isn't that issue. My issue isn't with how ETA is arrived at in the scenario editor, it's how the dispatcher handles the timetable in game - when an FPS lock is in play. Whatever part of the core controls this, a change was made in the stable build that did not break existing scenarios (the World would have been on fire if it did lol). That change has now been reversed in the beta build, as outlined above.
I am seeing reports of broken signals on Rail-Sim.de So it seems to be a very consistent bug in the new beta.
Hello dear fans of this game. I activated this Beta Update and noticed that the light signals no longer indicate the correct color. When the line sector is free, the game gives me the red color even though I have no train in front of me. I did not encounter any other problems after this beta update. Thank you
Great to see that updates are still being pushed. I was hoping to see a bit more of direction in this update after your previous article. Are multicore and graphics support updates still completely out of the scope of the updates because of breaking backwards compability or is DTG looking into fixing the current version and then building upon that version with a stable and expirimental branch?
It would be great to see graphical updated improvements and multicore support. I think this should be done in the form of an experimental branch, incase it doesn't work successfully. This is my first time participating in the public beta. I reverted back to the vanilla game without mods and I noticed on one of the old routes like Northeast Corridor, there were lots of red signal errors, causing me to pass almost every signal at danger
Trying to test signal behaviour on a semaphore route - Error (CTD) on trying to run a QD on my route (ECML/Cambs) - one of my usual test runs - Kings Cross Fast North 1954 using my A1 with 10 coaches : Code: 2024/07/01 17:43:55.291 - [Streaming] - Trace D:\RGBuild\CoreRelease\Code\Libs\Heracles\Engine\Hc1Draw\cShapeAnimationController.cpp : 1301 = FATAL: Failed to allocate 17 WorldSpaceNodeMatrixAdjusters in AllocateWorkingMatrixArrays, with freebytes = 266, freecount = 110189 Full logfile attached.
on both ap signals and just trains modern signals all display red on all routs with no valid reason (ie blocking train force red marker incoming/outgoing service) even in quick drive
I can also confirm the turntable bug. After driving on to the turntable and rotating, the locomotive will not turn with the turntable deck. Feather River Canyon Enhanced.
Would like to report that the signal bug (all red) extends to NZTS Workshops' Midland Line: Springfield to Aickens as well. Signal will clear to green (though they should already be green) when TAB is pressed, but only when the loco is mere metres from the signal.
In the Beta Version 78.1a. The use of turntables is broken. The turntables revolve as normal, but the Loco's on them do not revolve. then it derails and the sim crashes. Reverting to version 77.6b solves the problem.
The turntable crash is imho related to the crawling fix. Without physics being active when stationary, the loco cannot follow the rotating track and naturally derails. Might have to think twice if the sometimes micro creeping player loco on grades is something we can live with...
You can use the turntable if you release the brakes first. On some of my trains I need to be above 1.5bar to stop the creep, others at just 0.7bar.
I can confirm that this version introduced signaling issues with the US Northeast Corridor routes. I investigated myself after receiving an Open NEC bug report this morning. Try New York-New Haven scenario #1 ("66 Northeast Regional to New Haven: Part One"). On beta, the first signal when leaving the East River tunnel is at Danger. On stable, it's Clear.
You can do anything in the beta that you can do in the stable public release, however I wouldn't recommend route editing with it because it could cause unforeseen issues. Best not to treat beta builds as the new latest greatest version, treat them as a testing bed, so test route building and editing in the beta by all means but don't use it for actual projects, it could potentially cause you many headaches.
It's purely for people willing to test and file bug reports, not for "just" playing or creating content (unless you want to test the editor for malfunctions of course, which is always helpful).
In the Railworks folder Tools folder x64 application Serz.exe does not work if you want to edit bin file
That's probably a separate version from the standalone serz and serz64 in the root folder (not supposed to be used manually - probably it's being called by x64\BlueprintEditor2.exe)
