We catch up with Senior Producer Steve Dark to get an update on development ready for the launch of Train Simulator Classic 2024. Read More Here : https://live.dovetailgames.com/live.../article/train-simulator-classic-dev-update-4 Patch Notes : https://forums.dovetailgames.com/th...classic-2024-patch-notes-21st-may-2024.81593/ Live Stream (7pm UK Time) :
It's an interesting read. The funny part is, some code showcases certain rules that were expected by some senior programmers at a place I worked earlier, such as defining and preparing all variables at the start of procedures because that's how it's properly done. One thing I would consider is whether it's worth parallelizing Render and Update. It may require duplicating state (so that it doesn't change while rendering, see also: immutable) but might be a benefit overall. It can be optional or even dynamic. (I can get into details if you want me to.) Another thing is to involve and trust a select group of community members to provide content fixes. Just small things like scenario timetables, relocating stray stock, flipping locomotives, fixing references, supplying missing parameters, following up on core changes. Some of these can be opinionated (e.g. I prefer elastic couplers over slacky ones) but most issues we have is content.
We probably will have to fix content for sure. It would be very helpful to have a utility to go through all the Assets, and error check them, correcting paths or Misspellings etc, or missing textures and the likes.
Don’t know what to think yet. I think i feel slightly sad that we wont get further optimisations on multicore level. I was hoping for that. No “unleashing the power of TS” after all.
Can't help but feel disappointed too mate. It's all definitely possible. It's probably just not worth it commercially.
Non multicore seems to be because of the constraints we the users added. No change to functionality or sound. Once we add these restrictions in we cut change off at the knees. Does TSC want to cater for all of the old DLC or do we want something different. Sadly I do not believe we can have both. Also sadly it feels like TSW is not meeting the need of the user base. Long routes which are easily editable. I would be happier with a quicker loading application. Multiple routes/DLCs seem to easily constipate the whole front end of the TSC experience. Once the scenario is running I can easily live with what I have after having leveraged enhancement executables (e.g. AP products). Respectfully
Two modes would be nice. 1) New, multi-core, all bells and whistles. 2) Legacy support That'll do me.
I have test this update and nothing have changed! Same bad performance and the same issues! So don't expect anything if you didn't test it already!
Yeah, it is mostly fringe stuff and silver linings, all these updates. At least the 64 bits is a bit more stable and the most grave memory allocation errors are perhaps of the past now? When will 32 bits be dropped, or is this also 'breaking the unbreakable'? We need some sort of OpenRailworks model, where the present DLC will be rendered on a new game engine ... But given how OpenRails has stalled, or at least is showing hardly any progress (because it is essentially a team of volunteers), the commercial chances of a Railworks Mk II are probably nil. With TSW not turning out what I expected it to be, TSC is still my DTG product of choice.
Does anyone have an url to that live stream ? Some time later . . . . found it ---> https://www.youtube.com/watch?v=hBap51fGKvw
It depends.... In this forum i have not a large overview about the amount of people they experience better performance
happy they updated the sliverlinging 3d cloud system and hoping that version 6.42 is not last and maybe move to version 7 if the software can support it in future. phase 3 seem to have list of stuff that need to be fix in period of time all worked out. so we'll look forward to phase 4 in future.
I´ve got the feeling loading times are reduced and the UI is a little less stuttery than before the update today. Anyone else can confirm this?
Patch notes says: "The FPS limit now defaults to 60fps (as opposed to 30fps). This limit is now enforced during menus and pause screens in all cases (no matter what command line option is used) to reduce uncapped frame rates and excessive CPU usage whilst browsing the menus, especially with some Ryzen CPUs." Thank you for fixing this, you guys were literally cooking my 7800x3D . The temporary Windows power plan solution worked at least.
Having read through and seen where the issues lie around actual updates like multithreading, it seems the concern is it breaking content. As a content developer, I'd rather it break the content and improve the game - though I can see those that have spent many thousands on DLC being less thrilled with this idea. To my mind TSC should remain TSC (no year) and be closed off, no future updates and a new TS (no C) created that does the multi-threading etc stuff. I'd even pay for it. I'd even pre-order it. Some compatibility checks could be run on the existing DLC library and stuff that works made available to the new edition and I am sure a number of developers would alter their content to make it work. But this is a bit pie-in-the-sky, as I dont see even a paid version of TS with multi-threading being made available.
I agree with savvnz. Leave TSC as TSC for backwards compatibility Then make the potentially DLC breaking improvements to a new version called TS or something. That way people can keep their existing DLC content, and 3rd party devs and test their content for the new improved version of TS and release patches for that if required as lost of the things requiring fixing will be script or audio issues. I too would preorder a new version of TS even in a beta form, that has multitasking updates, new menu and an updated DX version. It sucks having a powerful CPU and GPU and only getting 20fps at 1080p and my hardware is barely out of power saving mode.
If multi-thread TSC was a new paid option, locking down the current TSC as-is and leaving it available, I'd poll the community in some way and likely do both. TSC and TSW both have their advantages and disadvantages over one another.
Of course DTG knows exactly what to do and what the community wants . . . . . . . . . . making it a good business case is what is difficult.
Read the developer notes on the subject of multithreading. They have given up on distributing the things that really matters on more cores/unloading it to the gpu.
I would guess it all depends on how their new marketing strategy evolves. If suddenly there is a draw to the new TSC Subscription (ATS similarities) then the new income may spur some extra development. If it is a flop then why plough any money into it. Remember the new owners are reasonably recent and bought DTG to make money.
I dont see anything in the dev notes that they have hit a rock. Its the Old Scaleform interface that needs replacing. Im pretty sure it slows things down. Some of the older track and other lofts also slow it down as well.
From the article: “Unfortunately, parallelisation and multi-core support on a complete level is too risky to implement.” “We will need to timebox this work (a way of saying we need to set some limits to avoid costs spiralling out of control)” Even though the first quote is about multithreading and the second is about bugfixing, read between the lines. It wont happen because of costs. Phase two (the one that would have counted) is over. Phase three will only address some bugs. This was the chance for TS and the ball was dropped. There wont be another go at this.
Hi, thanks for fixing the Control/Alt/delete issue in the latest core update. Any ideas when the missing text on the main loading screen will be fixed. Thanks Fred
I have the proper one myself. I assume one of these files is broken on your system - these were updated this week: RailWorks\data\textures\frontend\ui_splash_railsim.tga RailWorks\data\textures\frontend\ui_splash_railsim_Chinese.tga RailWorks\data\textures\frontend\loading_external.jpg RailWorks\data\textures\frontend\loading_external.tga RailWorks\data\textures\frontend\TSC_BG.tga RailWorks\data\scaleform\RS_2013_MenuSystemMaster.swf There are 76 files in my frontend folder so it's possible something else is missing.
I would love to have some additional information. What exactly 'breaks'? The entire simulation? Just a couple of things? Certain older add-ons? Also, I do agree with the people above, multiple versions would be great. We can have legacy support and a new version both at the same time. You have released such a nice video about the 15th birthday of Train Simulator and writing a new chapter in its history would be great. Also, if you no longer want / have the funding to do this, please just tell us and don't throw bones. We can handle it. Currently the update did not do much for me personally, I hope that there will be more work on the OOM errors we still got. I believe that attempts are made to fix things, and I hope DTG will continue to do so in the near future. I don't really care about new features, if the old engine works fine on modern hardware and also utilizes it properly we'll have a good base to develop our stuff on in the future. I've read the article with much interest and even though I do not have sufficient knowledge about programming, everything was great to read and understand. I would love more of this in the future. - Koplopermau
Did the development team sort out the "double clock" issue? I might be lucky but during my recent runs on Hamburg-Hannover, upon stopping the clock and the ETA was exactly the same. If so, thank you. It's much nicer for everyone to be able to stick to a timetable when seeing the actual time.
I don't think this will change, as the risk of breaking hundreds of scenarios is too big and testing all that would require tremendous amount of time - as possible side effects could occur late in a scenario. Overtakings could be affected also. As demonstrated in another thread, it can be avoided by correct scenario design. If the performance percentage matches the scheduled arrival time, you won't see this effect. If you change the calculated times manually by a large amount, the mismatch happens. So if you set a timed stop, at 75%, and the editor calculates e.g. 13:47:34 and you change it to 13:50:00, you'll get a 2.5 minutes deviation. Correct procedure would be to lower percentage to e.g. 70% until you get the desired time. So imho the best way would be to put this as a guideline into the official dev docs, and make scenario builders aware that the percentage is what the game works with, and the arrival times it suggets based on that should not be changed (13:45:52 to 13:46:00 for aesthetics are not problematic).
Hi DTG when are you going to fix train simulator classic 2024 in tools the manuals don't work you click it nothing happens.
When I click it opens my browser as follows Choose your language and you should find a plethora of manuals in this folder. Respectfully
It don't do that with me i got to manually go to the folder to view it i was trying to find about signals but didn't see anything.