The possibility to copy and paste contents of consist spawnpoints, and page two of aI spawnpoints. The possibility to add stops in qd scenarios. The posibility to do simple shunt in qd. Like starting up a loco, shunt to the train, couple to it and then drive to the destination. And a graphic one. Paint hills/mountains with satelite images, imagine how realistic and beautiful alpine routes will become. Double draw distance.
I think this would have copyright issues from Google / Bing / etc sadly (I've seen it mentioned a long time ago) - although if you meant just terrain paint based on it - then of course that's different .
Look at this video at the 14 minute mark. This is msfs. No idea how they do this but the realism on distant terrain is stunning.
True but MSFS = Microsoft, they own bing I'm not disputing that it wouldn't look good, I just meant more it would have potential issues (copyright as mentioned) and also perhaps memory, I mean would be nice to see of course though
Yes, hopefully it is a just a case of creating an app that calculates the change of radius (& cant) between the two points and makes the transition seamlessly.
One More Suggestion from my Side Please Update HUD With Signal Status So if we Are In Passenger View We don't have to go out To see signal is Green or Red.
I will have to say that if implemented, it should be optional. What fun is it sitting in the cab and knowing the signals in advance? On the vast majority of railways, knowing the signals in advance would not reflect the reality.
Hi Kim Apologies for replying on an unrelated question to the above, (but think it was mentioned earlier in the thread) but was wondering if your Page 2 not loading issue in QD AI Consist Editor has been sorted in the latest TSC update? Tried a few routes that did not work previously and they seem to be ok after the update (for the 4 or 5 AI consists I was able to set up)? Would be interested to hear how you are getting on with resolving?
You are right but some time user get bored in cabview because in cabview you even can't hear coaches track sound but in india coaches sounds are more enjoyable rather than sitting in cabview. That's why i gave this suggestion.
As an addition to the posts earlier in the thread regarding the menu, going back to the system that TS2014 had where pressing 'drive' would give you the different scenario types to choose from, and then clicking one of those would load the list. Currently clicking drive will always load the career scenario list, which means if you don't want to play a career scenario you will need to load scenario lists at least twice, wasting time. Earlier on there was an interesting suggestion to load the game directly into a scenario via a command line. That could be expanded upon by TS having a fourth launch option, a launcher which would allow you to change the settings, go into the editor or start a scenario without actually having to launch the game in the traditional way. The Utilities app could also be implemented into this launcher. As for Utilities, when lots of RPK and RWP files are installed or your Assets and Content folders are very large, the programme becomes unusably slow. Some sort of cache would be helpful. For packages, it could save a list of all of the packages installed and their details. For the Assets and Content folders, it could keep a list of every route and asset folder, but not their contents - these would be loaded only when the user clicks on them to see the files.
It could be an automatic thing. Away from the cab and the signal status shows. But to me the perfect solution would be that the train became automatically selfdriving when you wanted it. Hit a keycommand. Then you were free to go in the passenger cabins, stand on a hill and watch it go by etc. And when you wanted it, you could take over driving again.
YES The bug has been fixed in the latest update. So nice creating without fearing the work could never be finished.
You could just watch the AI trains externally (most scenarios have them), now getting to sit in an AI train would be a nice feature.
Some US locomotives have in-cab signaling and there are a few that replicate this in TSC. This can be used in the game if it is scripted properly. This is a link to the PRR Duplex cab view (from DSGDRR) on Horseshoe Curve. https://postimg.cc/gallery/TWbw6B6
Have the ability to relinquish control of one driven train to acquire control of another driven train in any scenario.
In Italy we have the SCMT system, essentially a repeater of the status of the next signal. It has been simulated in some locomotives.
Yup. Fun to drive with. But you also still have light signals, and the driver drives on a combination of SCMT and still watching the signals.
Suggestion affecting Career scenarios: Making changes to a scenario or affected stock Simulation.bins triggers an "anti-cheat" message which is confusing for many players. The "Failed to load tracks.bin/scenario.bin" error (which can be cancelled by (F2+Cancel)). This makes it very hard for developers to release patches, as the scenarios are tied to HighScore and Achievements via their GUID, and an MD5 checksum check. For example when I patch the Saluda Grade locos to be able to correctly power against the brakes for a hill start, I need to edit the loco's simulation.bin. As this is considered cheating (you could make your loco more powerful and have super brakes), it triggers the error message then. Probably the reason HIS cannot patch Saluda Grade without "breaking" the scenarios. So, as this is a non-competitive Single Player game and the HighScores are pretty meaningless (as they are capped at 1000 points and there's thousands of players occupying Rank #1), I think the Pros outweigh the Cons here so: Remove these error messages from the code completely. (Reason for this suggestion is also the SFSJ UP Mission Bay Hauler scenario, which I have fixed, but it will scare the player due to this error message (scenario plays fine though and will trigger the Achievement) Fixed scenario - message shows regardless of using original MD5 or modified scenario.bin's MD5 - because the scenario.bin HAS a different checksum as data has changed EDIT: I have just found a way to suppress this when editing official Career scenarios. Scenario Fix is on the way!
Having seen plenty of discussion about dodgy 3rd party assets still breaking the game now that the core has been fixed, plus comments about assets assumed to be trusted when loaded, maybe there should be an "asset verification tool" added into the blueprint editor so dud assets can't be created (ideally with a detailed description of why the asset fails). This tool could also be designed to check assets by other providers as part of troubleshooting.
This won't help, as many blueprints have been made using text editors (for example cloning assets), which sometimes resulted in duplicate IDs leading to crashes.... Repaints for example, you cannot use the Blueprint Editor as you'd need the source files... It's a matter of trust, but maybe a freeware coder will come up with such a tool. Always check after you've installed new freeware stuff, if it crashed you know where to look at.
SilverLining The stars are still not present, and I've found out why. In older versions, a "Silverline.override" file was present, adjusting the magnitude. This file is missing now, and changes were made directly in the config file, but the magnitude wasn't updated there. # Adds the given value to the simulated magnitude of each star. # (negative is brighter, positive is dimmer.) star-magnitude-adjustment = -3 Put this into SilverLining.cfg to bring back the stars. It is set to zero currently. Unfortunately, the config file is not used ingame, but needs recompilation of the SL shaders I'm assuming.
I think I brought this up in a similar thread to this on this forum, but would it be possible to allow AI locomotives to couple up to stock that has moved since the start of the scenario please? I'm not 100% sure how it works, but the game has to do something at the start of a scenario (such as recording vehicle locations) so it knows where the extremities of each rail vehicle is. This makes it possible for AI locos to couple up to stock that has not moved since the start of the scenario. However, this step of "baking" the consist locations is not repeated over the course of a scenario. This makes it impossible for AI locos to couple to stock that has moved since the start of the scenario, as the game thinks the road is empty (so the loco just goes straight to the end of the marker, which is what it normally does when performing any other instruction). A possible solution would be to find the function in the source code that "bakes" the consist locations and make it possible for this to be tied to a new scenario instruction or script function so the scenario writer can refresh the locations as and when needed. If it's possible to do, this would be much appreciated. Steam-era scenarios at terminus stations or large interchanges (anything involving a station pilot really) are at the moment very limited by what can happen. This change would vastly increase the operational interest.
Silly question about this topic but I have to wonder. Steve asks for improvement ideas - does this mean to also try and suggest new features which aren't in the game? Or just improvements over issues that we might find on the current versions of the game ( or public betas )? I'm not 100% sure if the team is looking to change the "logic of the game" or just simply make the game work more smoothly.
One request that will actually enhance the realism of the game very much. In the QD AI flyout. Next to the no stop box, have a box for “stop in the middle of the marker”. Which should do the following: Stop AI trains so that the middle of the AI train is in the middle of the marker. Why: It simply looks ridiculous when short passenger trains stop at the end of long platforms. NO trains do this in real life, except perhaps when they are not picking up passengers.
Not quite. I want an option make a passenger train ( of any lenght) to stop at platform markers in the following way; With an equal amount of marker in front and behind the AI train. I am talking QD scenarios here, because that is what i do, but could be in standard scenarios as well, and all will benefit from it.
Silverlining: When cloudy, the shadows the clouds casts are way too dark. An addition to silverlining weather would be a system of random intervals of rainshowers. Yet a thing that would make it more “real world”.
I suggest a toggleable option for the main menu that turns off its animation so the menu can be instantly accessed.
Suggestion; Allow the google overlay to be seen for untextured parts of the terrain not just in the editor, but in the route itself. Ofcourse as something you enable in the route editor.
Small suggestion - make it possible of using all numpad keys - so far only Divide, Add, Multiply, Substract, Decimal and Enter works. Numbers are not. EDIT: Also enable Shift+Ctrl+0 combo back... AFAIK it used to work, now it´s not working anymore. And the last thing that have crossed my mind - would it be hard to implement correct controller behavior controlled via Shift+SomeKey or Ctrl+SomeKey or Shift+Ctrl+SomeKey? Now when you just release Shift or Ctrl first than "SomeKey", the controller will execute the last sequence and won´t stop. Means the switch will still turn and button will stay pushed down, even if you have AutoRelease enabled. You must hit appropriate combo again to stop rotate / release it. Of course, if you release SomeKey first, everything behave as it should.
Is there a way for DTG to stop Steam forcing random file verifications upon us when buying DLC or downloading a TSC update? It´s happened to me twice this year and it´s really annoying to copy over a backup for hours and hours afterwards to rectify third party sound and routeupdates.
I was thinking of making such a tool. A tool that checks Assets for errors, and are all their "parts" (Textures, GEO's, etc) are present or missing (or corrupted), and report those errors, and paths etc, if found to be bad. There was sort of a function like this in TS tools, but that is old now. There needs to be a new and more specific tool for this.
Camera Motion Sway I'm suggesting a menu toggle - or even better, a percentage slider which multiplies the given parameters. Currently cab sway can only be toggled off by editing the loco's cab camera blueprint and setting all XYZ spring/damping values to 1. Background: The most widely used camera spring and damping values of (0.1, 0.12, 0.06, 0.018, 0.015, 0.01) are too sensitive in Z axis when driving trains with coupler slack. Before your train is stretched this can lead to some nasty forward/backward "bumping" which is amplified by the camera parameters (but ok in external view). An option to reduce the amount (by multiplying the values by a factor) would be desirable. I am currently using parameters used by virtualRailroads for the cab camera sway for most modern engines (higher damping), while I prefer the defaults for Steam engines giving a very natural sway which is weighed differently (It's easier to push a human to the side than to lift him up, which the default parameters reflect well.) Even better this should be fully configurable by a menu (with the above parameters linked to a "default" button, and six sliders (XYZ spring and damping). Theoretically these values should be independent of the loco, as they just reflect the inertial forces (=spring) reacting to the g-forces experienced, on an average human (=damping). While the default Z parameters (0.06 spring, 0.01 damping) give a nice sense of acceleration, having coupler slack interferes too strongly, so I basically have two sets of parameters I'm using - one for slow freight locos, and one for rigidly coupled fast trains.
Good luck, I can assist you there. There's a lot of stuff to check for, and I've fixed a lot of assets myself (but never documented anything... my patched files are more than 1GB now) For example, the Sherman Hill UP Turbine scenario 15 crashes because the weather extension blueprint declares a <BlendInTime> of zero for a weather pattern, which was okay before but now crashes the game... minimum of 1 is allowed but it's not specified anywhere in the DevDocs. Maybe an unwanted side effect of the code rework, but then that's the only weather blueprint I ever found using zero blend in time. Also, duplicate IDs in blueprints can be a cause of trouble. G-TraX did a lot of manual text editor copy paste work in their blueprints, which can result in unexpected crashes. First thing would be to set up a table of allowed parameter ranges for ALL blueprints - likely the biggest part of the project. Then, structural XML checks (missing/unclosed tags, I've seen it all). There's empty animal blueprints in Alaska... so check for zero bytes. This was also the reason for Boston-Albany crashes after release because an empty sound file got through... which works as a single file but crashes when accessed by zlib in an .ap file...
In quick scenario editing; the ability to lock a switch. Sometimes the dispatcher just get’s the pathing wrong for the player train (and ai trains) despite ecerything being done correct via extra destinations etc. So the ability to lock a troublesome switch will save a lot of grief and “derailment due to switch set against player train” game endings.
An improvement to the rolling stock selection categories when building a Quick Drive consist, originally posted here: https://forums.dovetailgames.com/threads/how-to-request-features-for-future-tsc-updates.77724/ but should belong in this thread.
Hello everyone, if I could make some wishes for the further development of the simulator: 1. There is still a lot of potential to make the simulation more and more realistic using scripted objects. For some purposes the complexity and number of scripted objects in a scene would make it necessary to stop script(loop)s working for objects/signals that are far away. Being able to use the call "GetIsNearCamera" would be a great solution - unfortunately this call does not work for scenery/signal scripts at the moment. Maybe it's possible to enlarge the field of use for this call to scripted scenery objects and signal scripts? 2. Furthermore I would like to propose the enhancement to find a way to calculate the distance between an AI engine and the player engine (or alternatively: the camera) within scripts. It is needed for some purposes that would allow interactions of computer driven engines coming closer to the player. From my perspective, it would be the best solution to make the well known (Listener)DistanceSquared controller (from audio proxies) available via lua script api as well. Another way could be to introduce the "getNearPosition" call in extended form that allows calls from AI engines for getting the position of the player engine as well (with all its specific frame conditions. I would view it more as a "plan B"). Best, Benjamin
Just a personal Thank You! I have just bought the Ringbahn Berlin and am overwhelmed by the quality and detail of that DLC. This is what TSC needs, dedicated developers who love what they are doing. You clearly all do at VirtualTracks/TTB, as all your products are of outstanding quality. €35 well spent! (I just don't like custom FOV values in cabcam blueprints , leave the FOV as to how the user sets it by setting MaxFOV to 1 My eyes usually don't change their vision field depending on a loco)
Better handling of InputMappers Sometimes, the InputMapper is lost when switching cabs to a different loco. A fine example is the "Rocket Runner Turn" scenario on HIS' CSX Hanover Subdivision (official scenario pack). You start off in a (HIS) Dash8, and then switch cabs to the DTG CSX AC6000CW. Here's where the InputMapper is lost and only core controls work. But you can't operate the train brake via keyboard, as it needs the input to be bound to the "VirtualBrake" via InputMapper and not the core "TrainBrakeControl". Using the AC6000CW separately, it works like a charm. This bug has been present in older versions of TSC too, it's not something the beta introduced. Though I am not ruling out that this is a content bug and caused by the Engine script of the initial loco being used. Maybe there's a way the core engine can stop that script correctly and hand over controls to the active loco?
Spikee1975 , I have already posted this in one of my posts, just check one page back. And I believe it has nothing to do with engine script. It looks like the game engine loads only first InputMapper correctly. I also believe that it´s not just that only core controls works - more like that only same controls works. They can also be a "non-core", but must be present in both engine blueprints.
Good find, here's both mappers of that scenario's locos compared. The initial one uses core TrainBrake - seems you're right. Second mapper is not being used at all after switching to that loco. Seems like that cab switching code is very old and comes from a time where InputMappers weren't used (You know these old locos using C for cablight as it is a hardcoded key used for cylinder cocks normally, using that ControlValue to toggle the light). That means there is an "update-inputmapper" code missing. Should not be very hard to implement imho. Btw, just noticed you're a dev! Thanks for your work mate
Spikee1975 no problem TrainSim-Steve, would it be hard to modify OnCustomSignalMessage() call to have one additional parameter called "direction"? So scripters would be able to detect which side of loco custom message came to?? It would greatly improve signal message detection in locos. Currently we are not able to detect that. Or, to be more precise, only in a hard way by using another call GetNextRestrictiveSignal(), compare distances and use only correct parameter. There are locos that use cab signalling system, but if such loco stands on track with signals attached to both ends and with links oppositely oriented, it will get both informations. Such modification would allow to decide which information to handle further.
Include the European and US assets in the base package Time and time again I stumble across error reports of missing assets (latest Brockenbahn), as many new players do not have the required dependencies (and do not know about them). The logic as to why it's bundled with some DLC and not with others that require it causes frustration for new players (possibly putting them off from the TSC franchise.) They are buying TSC and Brockenbahn and it does not work. Shouldn't have to be like that. (Wait - that was a catchy norwegian 80s One-Hit-Wonder, wasn't it ) Include these packs in the game by default.
Gotta agree with Spikee1975 Those assets that many newcomers don’t have surely must put some off the game, when they open a route and have missing textures.
