Have you seen this thread covering the list of launch parameters, giving useful debugging information? https://forums.dovetailgames.com/th...-current-obsolete-incorrect-or-missing.74961/
Quick Drive Consist Editor - Option to toggle Loads on/off Currently, there's no option to toggle loads for freight cars that allow it (via Cargo child objects) in the consist editor. This must be manually done by editing ConsistTemplates.bin and setting the "Loaded" flag accordingly (0/1).
Wouldn't mind taking Spikee's suggestion a stage further and have the same loaded/unloaded apply to passenger rolling stock too, would be great for ESM's and such, though it would require a lot more work in adding the passenger model to the Cargo child objects, and of course done in such a way so that it didn't break existing scenarios not utilising the passenger model this way.
Nothing to break in QD. But the stock must be set up for it, the toggle in the consist editor is a simple thing. For example, Smokebox, Milepost or G-TraX use separate loaded and empty versions of freight cars for the simple reason of having different simulation.bins for each, simulating the lower brake weight if loaded. I think Michael Stephan (GreatNortherner) also uses separate passenger and empty carriage blueprints, so a switch would not be of use here. But it makes sense for hoppers, doublestacks, flatcars and such. Every piece of stock you can load/unload in the game. (I've gotten so used to editing ConsistTemplates.bin myself already....)
Make full Scenery Density the default ...could avoid those reports of missing scenery. Make it a standard. If someone (and it should be a really small minority of players) needs lower scenery, they should reduce it by themselves.
And add a little popup if you reduce it (or a hover message like with the brightness "This only works in fullscreen blah blah" but a popup would be better) stating that "Some scenery items like individual buildings may not appear if the scenery density is reduced")
In quickdrive it would be nice to have the start and end points of the line easier to find rather than being alphabetically arranged, or maybe a mini map showing the names of the stations which are at either end of the line.
TrainSim-Steve Hi, I follow every update on the recent work on TSC and as a SW developer myself, I totally understand, agree and appreciate the general approach you are taking. I think, you are on the right track (haha). However, as of the latest Beta, I (still) have the following main pain-points which are, thus, my improvement suggestions. Sorted highest severity first: OOM. About 50% of the time, I rage-quit or run out of free time before I can even start a ride. Of course, I have tons (~550GB) of 3rd party content in place, a lot of copy-paste-overwriting and other horrible things happening and so it's not your responsibility, that my TSC runs flawlessly. ^^ BUT it is absolutely impossible to debug or even identify what is causing the (BTW sometimes non-deterministic) OOMs at the moment, since there is no information whatsoever. For a game like TSC (with its vast 3rd party market) it is imperative, that as much info as possible about a crash is provided to the user, so that - at least - one can remove the problematic content and distinguish crashes caused by 3rd party content from crashes caused by the game itself. Dispatcher. I like to create elaborate scenarios with a lot of AI trains, running on real schedules with real train formations. This is a lot of work and I roughly finish only 50% of the scenarios, because at some point, the dispatcher breaks and the scenario is LOVE*ed. Of course I always have backups of my scenarios in multiple revisions, but the amount of time and effort I put into these scenarios is simply too much, that I would re-create even parts of it, because the dispatcher broke along the way. Performance. Running on an 12600K, 3060Ti and 32GB DDR5 I am lucky to achieve 30fps out of town with fewer objects on the tile (ok, 4K resolution, but still..). In town ~22fps. Everything below 30fps really hurts my eyes TBH. I don't expect 100fps, it's an ancient game after all, but 40+ would really solidify the experience. AA and CPU single-core usage being the bottlenecks as far as I can tell. Everything else, like UI, tile loading hick-ups, and so on is also subject to improvement, but does not break the core gameplay / experience IMO. Cheers
No flight simmers here ? I own two throttle quadrants and another USB controller with switches and buttons. To support them in TSC, an external tool has to be used. Maybe TSC would integrade USB controller support some day as in my opinion, controlling a train by levers, switches and buttons is more immersive as by mouse and keyboard.
My intention wasn't to get usage of USB controllers more complex but more simple. Other simulators support USB controllers out of the box, calibration has to be done by Windows, so the applicaton has to map levers (axis), switches (on-off permanent position) and buttons (short on-off) to functions. The old RailDriver is very expensive, only usable for rail simulation and has - as far as I know - a proprietary interface. So the question is: why not support generic USB controllers out of the box ?
This is completely unrelated to most of the discussion and is a pretty niche thing, but I am going to keep on asking every where I can until I see it implemented.... a core sim Lua function to fetch the orientation of a placed railway vehicle. This data is stored in the consist information (isFlipped) else the sim wouldn't know which way around to render a vehicle in a consist and they'd all be forward. What I am asking for is a method of getting that information for the specific vehicle in the vehicles lua script. Mainly because of the type of couplers I use, but also because I have seen a surprisingly large amount of other content that needs to do something different if its running flipped. At the moment the detection can only be achieved by pinging off a consist message from each vehicle and having some vehicle in the consist echo them back to the vehicles that then check if they got their ping back again - which is quite performance taxing, even if limited to only when the consist length is changing. This method also means static consists in yards etc cannot check their orientations (generally the loco is used to echo the pings back, so no loco, no return ping).
Definitely a core game issue. It takes too many resources (building hrs for the creator as well as computing power for the player) to create and run a world that has all of that I mentioned.
Another thought, what really lets TSC down today is the exceptionally low resolution terrain textures. The 8m grid is.... manageable if not ideal, but the 256x256px limit to terrain textures really shows the sims limitations, especially against the high quality 2k or 4k textures most developers now use for rolling stock. Adding higher res terrain texturing would go a long way to adding extra longevity to the sim, perhaps a flag could be added to the route properties xml so developers could toggle hi res terrain textures on if they are being used or something, to save issues with existing routes, textures, etc.
Would this not limit some players with lower end systems in running TSC? Maybe making a switch to toggle SD or HD on the fly so you don't divorce a player group. Remember granting access to a broad range of players keeps the game alive and developers a reason to stay making content. The bottom line is making TSC profitable to stay active.
It'd need to be an exceptionally ancient PC for it to be a problem I suspect - but part of my suggestion for having it flagged in Route Properties is to negate this - there would be a line where newer content supported it and older content remained on 256x256 unless the developer went in and changed it over. I can't think of any game in the last decade that uses such low terrain texture resolution, so if the PC is capable of playing games other than TSC, it should be capable of higher resolution terrain. It woudn't even need to be much, even doubling it to 512x512 would bring a marked increase in appearance, especially if bump map could be included. Some optimisation of terrain texture instancing may be required, but I'd expect that to be part of any change to how terrain textures are handled.
The main issue I see with the terrain topology resolution is where do the original topology maps come from? The free ones have a very low resolution. It would be great to be able to "terraform" an overlay( as in replacing the 8x8 squares with high resolution 0.5m tiles) so as to create proper embankments/cuttings, etc without having to resort to lofts. Then the overlaid terrain would be easier to populate with vegetation. Something like this would probably need a second terrain library that is read before the standard one to collect the high resolution data first.
Menu / UI / Startup time and the Scenario Database overhaul I do have a rough idea which I'm still investigating for the UI to improve startup time. This is just about how it should work, getting rid of the obsolete and outdated Flash-based UI is another thing to tackle later on (or at the same time...) The main idea is to present you with a route selection screen first - using a new cache file which only scans the RouteProperties.xml[DisplayName] plus the RouteInformation\image.png - not scenarios yet, where you select your route and only then the game loads up a separate smaller SDBCache.bin only containing these route's scenarios (if a cache is needed for that at all is to be investigated). The current layout has always been to present you with every scenario available in a sortable list, so the SDBCache.bin is needed. (And takes time, in my case it must create a cache for the menu handler including all information on stock, weather, etc for 8,000 scenarios) Optionally you could proceed to the classic "Drive" menu from the route selection, it could be renamed as "Scenarios" and would only update the global SDBCache from there on. I'm in favour of that procedure generally, to only access content for the selected route, which could mean very smooth and fluid menu action. I think most players will go for a specific route they want to play, so it would make sense to have that route selection as a quick start before the whole scenario database cache gets processed unnecessarily. When I start TS to play on Feather River Canyon - why would I need the game to gather all other route's scenarios information for that session? The idea of the SDBCache.bin was great and perfect at the time it was introduced, but for many players their collection has grown massively so we need to think about handling the amount of scenario information differently (whilst staying backward compatible, but that should not be an issue here, as it's a pure core thing and doesn't require reworking DLC content as the contents are not defined in the DLC itself (unlike TSW uplugin manifests)) Note: Actually RS and RW handled that in a similar way, instead of a cache there was a "Scenarios.xml" in each route folder which was just all today's ScenarioProperties.xml collated in one file. We can't go back to that exact system - the scenario folder structure should not be changed, but the idea of a having a per-route scenario cache (or super quick random access method) seems interesting to me.
There is one singular case which is more of a search function: the search. I have a list of workshop subscriptions but don't necessarily know the route involved. So I just search for GWD270, for example. While you are correct about the startup, the menus themselves are an isolated issue. There was one singular time when the grid was filled fast, in the first x64 version. It reminds me of the following, really bad code: foreach (scenario in Cache.Scenarios) { var gridScenario = GridMapper.Convert(scenario); Grid.Scenarios.Add(gridScenario); } The preferred solution is: Grid.Scenarios.AddRange(Scenarios.Select(s => GridMapper.Convert(s))); With the grid / scenarios being an observable, it means every single addition is going to trigger a whole refresh. I don't know the exact math value but it grows exponentially (1 + 2 + 3 + 4... => 1, 3, 6, 10 == n*(n+1)/2). This is an easy basic method for small sets, but with large amounts of data it spirals out of control. Now, the first x64 may have simply paused observing, which is often a solution but probably caused a side effect as with the introduction of the - very important and useful - official / workshop filter, it was reverted. Ultimately, if the component is old (pre-net2, I've seen such code last year), the practical workaround is to indeed build a master-detail view where the number of elements is limited. It exists, within the Build menu, Scenarios tab.
Modding and Steam verification - clean separation of files For the purpose of TS not deleting user content modifications after a full Steam Verification (see verify_cache_key file deletion on TS startup), I am suggesting adding another search path to the core engine. Make users put their mods in a second folder structure in the user's "Documents" folder, such as "Documents\MyGames\RailWorks\Assets\...." The game would normally browse the content and load found files on top of the original content. That would keep the game folders clean and not delete players' mods after a verification. Would also help tech support, as individual Asset folders would be the same on each installation. Additionally, add an option to the game to "Enable mods" which would activate loading data from that path. Troubleshooting would be very easy then. Also, players can easily backup custom content without backing up original content which can always be retrieved back from Steam.
Hi Spikee, Not sure that this would work for many mods that have to sit in the same folder structure as the original in order to reference textures etc?
Why not? For the game engine, the path is the same, as the loading routine merges the paths. Same as in ETS2. I can put a "def\map_data.sii" in the Documents\ETS2\mod folder that references another file in the original .scs archive. It's no different than what happens already with ap files, which the loader makes transparent for the game, that's why they can have any name. The "mounting point" the game is working with is the Assets subfolders. That can be composed of different paths. First load RailWorks\Assets - then load mod\Assets and merge them in memory. (And TS only uses relative paths, you'll never see "RailWorks" in any blueprint)
Sounds interesting. I guess this is something that DTG would need to do and cannot be done by us at the 'frontend'?
Yes, this thread is for DTG I don't see any technical challenge, as adding another mounting point would only be a frontend/loader thing, as all paths are relative from there on.. A GeoPcDx in Documents\RailWorks\Assets\DTG\Pegnitztalbahn could refer to a texture in steamapps\common\RailWorks\Assets\DTG\Pegnitztalbahn, as the game does not distinguish between both parts which are accessed and superimposed onto another with Documents having higher priority. It only sees one Assets folder. And with a single click in the options, you can revert to vanilla (For troubleshooting and screenshot contest). Your AP EPs like weather would be moved to Documents, not actually overwriting files in RailSimulatorCore - only overwriting them on loading in memory. (like external mods are loaded onto .ap contents and merged in memory.) Edit: Want to add that the "mod" path should be freely selectable, not everyone wants to use their system C: drive.
World Editor - Show Provider and Product path for selected objects An issue I've come across often is when searching for a specific missing asset, clicking the milk bottle (or my replacement in the example), I do not see the full path of the asset, it's relative to the Product folder, not the Assets folder. To get the full path needed for googling asset providers, I must look up the scenery tile as shown at the bottom, unserz it and search for the asset name given. Solution: Put another textfield in the selected object flyout that shows Provider\Product name. Example, a nice freeware route (SFM Torino), asset hunting phase The selected missing asset shows as "Buildings~RI Torre Elettrica~RI palo 3 fili.xml". I have no idea which asset pack it's located in. I had to look up the scenery tile xml to learn that I needed to look for "Rotabili Italiani\Scenery" where this object is supposed to be in. Which I quickly found on the net. An additional textbox containing the Provider information is much required in the flyout. I expect this to be an easy implementation as all data is available and flyout Dialogs (.dlg) can be changed easily by DTG. It would be great to have the same information when doubleclicking rolling stock in Scenario Editor - asset path, there's enough space in the flyout left. (Note that TSTools is not 100% reliable, it did not report these as missing. So I'm doing my visual checks) P.S. Nothing more frustrating as looking for an asset that comes in that "Developer\Addon" folder where people forgot to personalize their source folder and it's a collection from all sorts of authors now.
Add a Lua command for retrieving current location coordinates The highly disputed ATS Class 745 uses a questionable way of integrating scenario independent Announcements by having the user run an external exe, and installing a lot of core windows function dlls to the plugins folder, which can rightfully be seen as a high security risk and malware backdoor. The game knows where you are, so give developers a simple set of commands to query the current coordinates via Lua script - allowing location based announcements without trigger markers - a huge step forward.
I'm wondering if this is already achievable: You can interact with a DLL from a Lua script using LuaJIT. So you could use the Raildriver.dll to retreive the coordinates. The question is, can this be done within Train Simulator as well?
According to a dev, there is no way to access the coordinates ingame currently without external .dlls. It should be a standard TS Lua command, e.g. GetPlayerLocation(). TS can send the data out via its RailDriver API but not directly to itself it seems. There'd long be scenario independent announcements, as this could be put into the engine script, as opposed to marker based scenario scripts.
Using Lua would certainly be preferable. However since Raildriver.dll is provided by TSC itself, there are no security concerns when accessing it via Lua. Additionally, if it's possible to retrieve the coordinates of AI trains, this could unlock a myriad of possibilities.
Additionally, I'm forwarding these from a dev There's a couple of other things the Lua API would need to be ideal: A function to return the route UUID A function to return the scenario UUID A function to return the next stopping point A function to return the distance to next stop (as shown on the HUD)
Have windowed and borderless drop down lists recognise and display the exact same resolution combinations that the fullscreen drop down list shows
Further to this, and I don't know how possible/practical it is, but some warning if a selected screen resolution is not going to work (or a reversion to the previous, working setting) would be appreciated too.
Apologies if this request has been issued already, but I'd like to see a physics update, more specifically with regards to starting long heavy trains on a grade i.e. Shasta MT route is almost impossible to start at Dunsmir on just a 1% grade with the stock consists. Plenty of HP/T and yet sometimes even (unrealistically) in notch8 and sander on, the trains just go out of control backwards. NOTE: this isn't route specific, it's just grades in general (even slight ones) seem harder than what they should to get started
This is rolling stock thats been poorly configured. A lot of stock out there is just plain not set-up correctly in its blueprints, its not the physics engine itself at fault.
Could also be missing coupler slack making a hill start impossible. The old DTG Min/Max/TargetDistance = 0 buckeye issue. Add to this the wrong traction cutoff cylinder pressure in the simulation blueprints, making it impossible to power against the brakes on some engines. Agree with savvnz - it's not the game but how the stock is configured. Can be fixed
With a real loco you can apply power with the brakes applied so the loco takes up the slack as the brakes are release. Difficult to do a Hill Start in TSC when power is not applied until the brakes are fully released.
If I may, I would suggest to create a LUA call that would allow player to send a message to signal. It is important because now it is impossible to create a shunting path. There are signalisation systems out there using different lights for allowed / disallowed shunting (white / blue for example) and for normal trains (classic green / red states / yellow / flashing yellow states). All these can be attached on one signal, depending on its complexity. This would allow player with one button press send message to a nearest signal which would light up proper light, not "normal" green (if path would be clear of course)
The ability to change the color of the F5 HUD. Unless I'm mistaken, it doesn't seem possible at the moment. Richard.
It is possible to reskin the HUD and various reskins were available on UKTS. If I knew how to I'd make one myself.
\RailWorks\data\textures\frontend 2013_DrivingInt_steam_Extra.tga DrivingInt_diesel.tga DrivingInt_dieselbg.tga DrivingInt_electric.tga DrivingInt_steam.tga Those are the files I edited for my personal HUD changes, there may be others in that folder but that's all I changed for my requirements
Thank you but I'm speaking about HUD F5 only. I only drive steam locos like Bossman, Meshtools, Victory Work and so on... All the information you need to manage these locos is displayed on the F5 HUD. Unfortunately, the chosen color causes problems when displayed on a clear sky, for example. Ideally, I'd like to be able to change the color to red, or something more contrasting with the background. Richard.
Oh you mean the text values in the top left, I hardly ever drive steam so I'll be honest I forgot all about that HUD option, I don't know how to change that sorry.
