Instead of having to place consists all over the route, when scenario creating. Why can't we have the use of the QD markers for AI. Too place both active AI and static AI, as per the QD function. It would certainly make standard scenarios more interesting and less predictable. But also retain the full standard scenario functions.
While this would be a nice feature, I doubt it is possible with the game engine without a major rewrite. The path of every train must be precalculated even before scenario start, it is decided at the time the scenario is saved in the editor. The QD is doing nothing else, it takes your input, and puts together a Standard Scenario based on the spawn markers. When you play it it is already a standard scenario. You find it under Build->Scenario->Route->Standard->"Quick Drive Scenario". This gets overwritten everytime you start a new QD on the route. Adding random AI could interfere with the player instructions and timings. Hope this answers your question.
Not really buddy, it's only the games LOVE poor ai and signal logic that prevents this from being possible. DTG fail again.
I do agree with Mike on this. We need a better way of placing trains than the current longhand method. And the signalling AI needs to be capable of making on the fly decisions not just playing out a pre-determined plan. Run 8 now manages this with its "Otto", not perfect but it can dynamically route trains, make priority decisions and regulate traffic as necessary. It doesn't even need a specific path across the route as it can work this out as the run unfolds.
Would be nice - but won't come to TSC, don't expect the core game to change. Run8's Otto dispatcher took years of development and the game engine is completely different from TS' scenario based and single route design. All AI paths are fixed in the scenario.bin - no runtime changes. If you provoke changes by leaving your path or SPADs, there's likely a collision to occur or junctions set against you. Even in real life on-the-fly decisions are not trivial and can still only be made by human dispatchers. Run8 offers Otto or player control over the dispatching, nice thing if you're in a multiplayer session. This is not to sound disrespectful, but RSDL/RSC/DTG's main goal was to buy a working game from Kuju (which was at its time the best there was) and make money producing content for it and keeping it alive and updated (Microsoft/Kuju only released one single patch for MSTS!). In the beginning they added a lot of features (see here: https://sites.google.com/a/railsimd...e-manual/ts-new-features/train-simulator-2012 ), but I don't take that for granted any more, the game is classic and has come to a rest in development (as development started in 2004 it's now 18 years old actually), with bugfixing hopefully being the priority. I don't even want a new UI - got so used to it now.
Sadly this is one of the limitations which can ruin enjoyment, if a scenario always plays out the same way. I dived back into Snowrunner this evening and although each mission gives you an objective, it’s up to you how you complete it. Likewise ATS or ETS2, you can blast your load down the motorway or choose to take the more scenic route, especially if you have ProMods installed!
I would not say this. There is the workshop. Play other scenarios, create your own and do Freeroams - or Quickdrives. QDs were made exactly for this - a different experience each time you play it. Consider that in RL you are bound to the path the dispatcher assigns to you - otherwise a complex thing as railroading would not be possible in high traffic areas. It is simulating a scenario. So we won't have dynamic trains in a Standard scenario, that's for sure. But - this is what Zusi's power is - we could have random delays for AI trains. In Zusi you can adjust a "chaos factor" slider ingame which makes trains delay and you'll have to wait and encounter more red signals. It even can even reroute you. But it can also lead to a lockup - two trains facing each other needing the same block - that's it. Then you have to remove one train to keep playing. The TS dispatcher won't be updated - too critical because of backward compatibility which is more important than anything.
I am pretty convinced QDs are actually build on the framework of standard scenarios. Therefore it should actually be possible. The dispatcher code certainly handles them exactly the same way, as does the signal scripts.
QD template + your loco, start , dest and time -> fixed standard scenario. You can edit it like any other scenario after it has been created But TS cannot handle random routing events. If something goes wrong you get the message "Service xxx has left the path" and the session is stopped. Therefore all random elements like AI spawns are calculated before the output scenario is created. There is no runtime randomness other than the player's input. Which can be restricted even more using "HandleOffPath". But the OP's suggestion to have a standard scenario playing out differently everytime is not possible. Maybe there is a limited possibility to use the ScenarioScript - but this will not influence the dispatcher. It is not a "fail" - the engine was simply not designed for this - as random events are rare in real life railroading too. And I'd say coding a working dispatcher is as tough as coding a chess engine. Things are done by humans in RL, easy stuff like self-blocking signals are left to AI. What IS possible is to do very creative QuickDrive scenarios. One workaround would be the creation of a new scenario type. It would need to be regenerated at each start - but I simply do not think they will put in the effort of coding a new feature after 12 years into a game that now has "Classic" status. I just don't think so. Like to be proven wrong, but... no. So to sum it up: Runtime variations - NOT possible, new Scenario type: possible, but unlikely to happen
There is no randomness per se in QD. Only percentages that determine if a train spawns, which make the scenario seem random to the player. When the scenario starts that has been already been worked out, and all trains have fixed routes. The error message you quote happens for another reason. When the dispatcher is unable to route the AI train to it’s destination. This happens 95 % because a hand switch actually only can switch one or two times, so the AI train that needs it to switch more than that, gets stuck, and leaves the path. AI trains have their routes calculated in exact the same way in qd and standard. I think it is indeed very possible to have spawnpoints (both ai and consist) in a standatd scenario). But let’s ask DTG Jamie if it would be technically possible to have qd ai and consist spawnpoints in a standard scenario.
Basically we're saying the same thing. As much as I support the idea I do not expect it to happen - because it would require completely new code for the engine. As a standard scenario is fixed, it would need new precompilation every time you run it.
