Why Should An Ai Collision Stop The Game ?

Why should an AI collision stop the game ?

Can't DTG "simply" tweak the code so the game continues ?

 

it is a Railway Simulator - Train Crashes cause the trains to stop.

 

I realize that.

But why should an AI collision stop the game ?

 

When trains derail in the game they don't behave as a real train would - there are no bits of train scattered across the track.
If they did they game could continue but you might run in to the train that has derailed as in real life.

What if you drove as normal and an AI train going the opposite way and crashed in to your train
Would you still expect to be able to continue to drive?

 

Well . . . . I assume AI collisions are probably not intended but bugs / imperfections from the algorithm or builders.

The ones I have seen are many many miles away.

Why should I be kicked out of the game when there is an AI collision at the other side of town ?

Just as one can disable getting kicked from the game by passing a red signal it would be great if one could disable getting kicked out after some AI engineer messes up.

 

If the collision involves trains that don't interact with yours, then maybe they should be ignored, but if they were going to interact they can't be ignored.

 

As long as I am not in a collision myself there should be no reason to kick me out of the game.

Too bad that is not the case. Today I was kicked out of a Saluda Grade scenario after weeks of hard work. AI colission right after loading the saved game

 

The cause of an AI collision is that trains aren't where they should be, possibly off the timetable, switches are misaligned, and the dispatcher is not reliable anymore. It's more of a phenomenon than the cause.

My absolute favorite condition is "AI train has left the track". While I can understand a conditional silly with some train getting stuck or slow, I have absolutely no idea how the dispatcher can actually make AI leave the rails. Maybe misaligned switches after Go Via / spawn markers, but how.

 

I think "AI train has left the track" means it has not followed the expected route - but I might be wrong.

 

The cause of AI collisions are mostly the pretty ancient dispatcher code being unable to correctly handle AI trains. If there aren’t any AI trains spawning in the same signal block, they NEVER should collide. No matter the pathing actually, since an occupied block is inaccesible in real life.

So i agree, AI collisions should not stop the game, since they happen as a result of the game itself.

 

Disagree on that. An AI collision is an indicator of a flaw in the scenario or signal script. The dispatcher works well if it's using valid data.

For example, one of the first scenarios in my TS career I was wondering about was "Meat Market" on Somerset Dorset. There's an AI collision happening.

On inspecting the scenario, I found one consist to be placed above a signal link, moving it back a little solved the issue. The train was then waiting correctly for the block to be free and the crash did not appear.

It can also be misplaced signal links (There's one at Mossend Yard entry on WCMLNorth for example). Or bad signal scripts like RSSLO's.

The dispatcher itself is pretty solid. It is relying on signals exchanging messages correctly. And a train placed over a signal link will cause the block clear message to not work - in TSW this leads to stuck trains for example.

So in tech speak, a content and not core issue.

 

Whatever the reason is, core or content. They should have programmed it in such a way that a collision , not involving me, does not end the game.

 

Which is not possible, because the main dispatching happens at scenario creation level. All instructions and timings are stored in the scenario.bin - the dispatcher cannot react to unforeseen events, this is just not possible. And the dispatcher relies on the signals acting like it expects it when saving the scenario.

And a collision screws up the predispatched timetable. The game is just not made for that. And as said, there's a cause for it that can always be fixed. Collisions must not happen, and need human dispatcher intervention which the game cannot deliver, that's way out of scope for a simulator.

Ending the scenario after a collision is an indicator for the dev to debug the scenario - the game just cannot execute the instructions given to each service anymore. It is not an AI that can decide, "oh well, the player is probably not affected, so let's just move on". It needs a human to check on the situation (like in real life) - by editing the scenario again.

This is to make sure the game itself won't crash to desktop - remember TSC is not a single-developer product, but a platform where everyone can make its own signalling scripts and content.

Hope that little technical insight helps, but somehow I've a feeling you only want to hear "The game should act as I want!!!". In that case my explanations are futile.

 

The dispatcher simply shouldn’t crash trains into eachother. No matter what the quality of the signal scripts are.

 

But the dispatcher only sees what the signals are telling it. The dispatcher doesn't see what you are seeing. It sees tracks.bin, timetables and signal messages and links.

So if a train is placed over a signal link, it will receive the message of the next signal and just cannot see that a train might be in the same block. So it will send the train to the next signal as soon as the service start time is true. That's pretty logical, and as a programmer facing this, you have two options - stop the train (TSW logic, you can despawn it to resolve the issue) or let it run (TSC logic).

If the scenario is setup correctly, it won't happen anyway, so imho it would be a lot more helpful if the scenario where it happens was declared.

So imho, collisions should not happen - but they can due to scenario building errors which can be easily fixed. And as this is the worst thing to happen, I think it's fair the session ends.

 

> I think it's fair the session ends.

Take off your programming hat and put on you gameplayer cap....

It is nuts to kick me out of the game for something that happens 10 miles away at the other side of town that has nothing to do with my train.

 

I think I'll stay out of these discussions in the future.

No reason to explain why things are happening here. Instead of people being thankful for insights, I'm getting attacked and you're acting like a child. Quite toxic to be drawn into discussions with you.

Yeah, people should live in peace together. But reality is different. TSC is a game that relies on code and data. And if information is not there because of a human error that placed a loco onto a section that will prevent the initialisation, you're blaming a piece of code that just cannot act differently, because for a block clearance/occupation it would need to look back beyond the "big bang" which is the start of the scenario.

Pretty childish behaviour in here. Don't tell me to change my view on things - it's you having a problem not me.

If a flood is happening, you'd not go and erect protection and dams, but shout out to the heavens. "It should not rain that much!"

If your car runs out of fuel, you'll be crying "But it should drive anyway!".

I'm seriously considering to keep my knowledge to myself and private discussions. These forums are mostly unthankful. Wasted energy. I could have fixed and enjoyed a scenario instead of typing this.

 

Your knowledge is always appreciated. Now stop sulking

 

To look at it from a programming point of view - and I admit my knowledge here is extremely rudimentary - would there be a possibility for the program to check whether the player-driven train has left the track (a true/false check) or if it is an NPC train, and if it is the latter then not force end the session?

 

Yes; the issue is what happens after.
It would be possible to despawn the trains, or ignore the collision check.
It can be really weird, though. Simply, what if you create a round trip scenario with followers lined up (in the block or portal), but you never start? The trains behind will crash, overlap or disappear, making it really funny when you see them (overtakes, or on your way back).

Also, a lot of railroads have a "global unspecified emergency" signal which effectively shuts down the entire network (division).
One of the standard causes for it is a crash - train disappearing, unreachable, with or without reporting emergency application before.
(It was the command that the signalman attempted in that relatively recent Flirt crash in Germany. Except he issued it to the track worker channel, not trains.)

 

The only time I've experienced AI Collisions is a bug where sometimes loading in from a save at busy areas of a scenario messes something up (I don't know what exactly) and causes some sort of AI services to crash into eachother.

With all due respect as solely a gameplayer myself; programming hats are required. It's programming that runs the game and lets us play it in the first place. Without programming, no game. Spikee1975 has invaluable knowledge of this games programming and coding; and if he says it isn't really implementable I trust him on that.

I feel that you are looking at it from a "human" perspective if that makes sense? A program can't simply see a derailed train with it's own eyes and decide what to do next like a human can... All it's actions and executions are predetermined by specific code commands a human wrote. To implement this feature you speak of a huge new coding implementation that a game like TSC probably wouldn't be able to execute properly without an immense amount of issues would be required; especially for a very rare issue I have barely experienced over years of playing this game since 2013. If anything it's the scenario in question with these bugs occurring that should be fixed by the scenario creator as people have said it's on the content glitch side of things, not a core code implementation issue that has to be sorted out.

 

If two trains are placed in a signal block then they will collide as there is nothing to keep them apart.

 

Then Fix the scenario so it does not happen again.
Make a note of what collided where and have a look in the Scenario Editor.
It might be a case of moving one train a short distance - which you can do by selecting the entire consist.

Having done that you would be able to play the scenario again with a problem

 

Nope, I will not fixed the game myself :-P

I bet the core code catches many errors and many problems, from scenarios and other culprits, and handles them fine without sending the engineer home. The whizzkids just need to implement some code to properly handle this one as well.

 

I sympathise with your frustration but the problem is as described above by Spike et al - a scenario (or signalling) error caused by a human being who is almost certainly not the core game engineer (whose code is working just fine). The simple (but annoying/time-consuming) way is to fix the scenario (or raise it as a bug with the provider of the scenario). Asking DTG to change the core engine to "fix" this is a much bigger task than i think you realise. Let me try to explain what it would need to cover:

• an AI/AI collision occurs - do you delete one train or both? if one then how do you decide which?
• whichever one you delete may be important to the successful running of the scenario - how does the game engine know this?
• the collision may occur within sight of the player - is the sudden mystical disappearance of trains ok for you?
• an AI/player collision occurs - do you just delete the AI train and make the player train invulnerable?
• other stuff I haven't thought of ;-)

In all cases AFAIK the problem is caused by 2 AI trains ending up in the same block and on a collision course due to either incorrect placement or bad signal placement. As previously stated, neither of these things is the fault of the game engine and neither is within the realistic scope of a developer to add mitigation code without screwing with the way the game operates. There may be a special 'resume from save crash' bug though I haven't expereinced this myself. If that were the case then it would be something for DTG - but unlessuntil someone demonstrates that I suspect you are left with fixing the scenario (you could just randomly delete on the offending AI trains and see how it goes...but don't be surprised if sometime later you get another problem caused by the absence of the train you deleted).

 

I am not frustrated, but am surprised that so many gamers here think it is the correct way and nothing wrong with it.

​

Scenarios are full of issues and problems. But many many of those do not end the game.

Of course the one we are talking about here can be, and should be, handled differently by the core code.

life is full of priorities, also for DTG. If this is on their priority list, and if it is worth spending the resources to fix it . . . . . . . . no idea , but I sure hope so.

 

I'm not sure any of those things are necessary for what is being discussed here. I posted this earlier in the thread:

My thinking here (and as I said before, my programming knowledge is very limited) is that the scenario would continue to run, as far as possible at least, and the player would be free to continue there journey. Obviously, there is a possibility that the scenario becomes impossible to complete because the derailed train is blocking the player's path, or because subsequent trains are unable to progress, but you are no longer being arbitrarily booted from the session because of something that may or may not actually impact the tasks the player train has to complete.

 

More like - There are many ways to put it, but one should have zero expectation from DTG to fix anything.
Put that down as an axiom and move forward - fix, accept, boycott, or shame (spread the word).

They didn't manage to fix a most certainly trivial issue with extracting workshop content in 9+ years.
It generally proves that they're not competent, reinforced by the product manager backing out of upgrading the game.
Nicer way to put it is that DTG is a group of marketing and salesmen, who also inherited the curse of having to care for a code with many smarts, some mistakes, but certainly lots of legacy. It must be roughly 20 years old. As anywhere anytime, projects dictated by finance and sales fail, including TSW, because no MVP is long term viable. Only love projects made by caring professionals cut it. It's not their fault. They grew up studying these professions, and they believe in it.
They probably also did the math and figured that any fixes - small or big - aren't financially worth it, so they do communication stunts instead.

 

I’m pretty sure it would not take many lines of code to change ai collisions to not end the game.

What is the use of ending the game anyway? Such a strange “feature”.

 

This is what annoys me. Constructive technical discussions being derailed into the usual "DTG don't fix anything" rants.

Have you read the changelogs in all the beta threads?

Do you know the difference between a bug and intended error handling?

Next thing you're crying for will be "Why are divisions by zero not allowed? They should fix that!". Someone will explain and you'll accuse them of being an apologist.

TSC is the code, the scenario the content. An unresolvable issue happens. The game tells you what happened and quits, just like any debugger would.

I've said all on the matter. It is not a bug, it is intentional content error handling. So nothing to be fixed.

And "I think it would be easy adding a few lines of code" is an assumption that just might be totally false and would need a live dispatcher and spawning / despawning functions like in TSW - basically a new game - but of course, you're the specialists. Not Steve or his team of core coders.

Best answer was already given, in a way more effortless and elegant way then mine by Peter:

 

Come on. Even in meticously made QD scenarios, and dare i say i am an expert in these, i’ve had the dispatcher crash trains into eachother and end the game. This shouldn’t happen. The dispatcher ought to be able to solve how to get trains that don’t spawn near eachother from a to b to their destinations. And if it isn’t able, it shouldn’t end the game. End of story.

 

"They" kept our Railworks alive for almost 15 year. And I love them for it !

 

That is not correct. During a crash most trains in that general area continue. Let alone the ones at the other side of town. . . . at least in the countries of which I follow the news.

 

Ditto.

 

Quick drives are something of a special case, in that there is a degree of randomness in what is spawned where. It is very difficult to test every possible combination to ensure that there are no clashes. Route set up also comes in to play again here - the shortest section of line with incorrect directionality set up can easily play havoc with train routing, and is something that is very easily missed when setting up the route in the first place.

But I feel like we're getting somewhat away from the crux of the topic into what causes AI collisions/derailments rather than why that should cause the session to end.

 

AI crashes are badly written (or modified) code. Which scenarios are you having problems with. You should not need to edit the scenarios however bad code still gets published. If you need some help let me know. I can test to see if I get the same issue. Sometimes it is necessary to redownload the DLC to fix some of these issues.
Respectfully

 

Has nothing to do with code. I've explained above that it's misplaced consists.

 

A misplaced consist as far as I am concerned IS badly written code. In this case the author probably did not set everything up correctly. It may be that the pathways are not correct or do not synchronize with other trains and the scenario has not been fully tested. In layman's terms this is badly written code by the author. A typical user should not be expected to debug a scenario which was not correctly authored. One must not expect everyone using the forum to be TS Editor literate.
Respectfully

 

Placing a consist is not code, but data. That's a fundamental difference. Code processes data.

It's badly authored scenarios, agreed. But the topic is about if the game should exit or not in that case. It has to, imho.

In easy words, the discussion was about the game (code) handling bad scenario design (data).

And from my experience, having played about 6,000 scenarios, this only occured on less than ten scenarios. And these were fixed by the community.

 

Spikee I personally agree with you as I code for a living. I believe Woodland is not wanting to mess with the TS Editor. It looks like she is attempting to trawl through some US DLC scenarios. I am sure there are some disappointments out there and having spent money on DLC it is not very satisfying. I personally am happy to debug scenarios although it is not everyone’s cup of tea.
Respectfully

 

So do I, and sharing fixes with the community.

 

Maybe if WoodlandTracks was to ask about a particular scenario when a problem has occurred then somebody might know of a fix that has been uploaded?

 

Some folks do not realise why we were given 2 eyes, 2 ears, one mouth and a large brain. Look and read, hear and listen use the brain before the mouth (in emails substitute fingers for mouth but I'm sure most get the picture).

 

Not sure if you just called me stupid?

 

I don't think he was referring to you.

 

tl:dr if already mentioned, but the best process to allow the scenario to continue if two AI trains to collide is simply remove both trains involved from the map and reset the signalling state. I do agree it should not interfere with the player train. Bear in mind this is often happening miles away from the player and is essentially just a lot of 0’s and 1’s shuffling through the location coding.

 

Disagree. If you're already in the editor, why not keep the AI as intended by just moving the offending trains a little back so they sit nicely in front of their signal links. Problem solved. Your way is the TSW way

 

That is the preferred way but the OP is not interested in changing things in the Editor.

 

But Vern is.

Also, report them and I'll fix them for you . There's no other way, the game won't and can't change. But scenarios can.

 

I meant when the scenario is being driven, not in the editor. Similar to what happens in Run 8 if two trains side swipe each other. Yes it would require some core changes and a bit of coding, but they are still presumably working on TSC and not moved all the coders across to TSW.