INT DIVIDE BY ZERO Error

[SteveP_trains]

Just wondering whether anyone has any further ideas as to what causes this error to occur occasionally when running a Scenario?

The feedback I have gathered about it so far is .............

1) I am able to workaround this sometimes by entering the scenario via the Build menu option and then clicking the Play button

2) A web solution suggests that this occurs because there are too many routes in the system so disabling ones that are not used frequently may help.

3) Also, doing a "Local File Verification" procedure from your STEAM account on TS may help if it finds a corrupt file and downloads it again for you. - this one worked for me for a while!

4) I’ve also found that disabling your internet connection while starting TS2020 seems to prevent the Divide By Zero error sometimes.

It's very frustrating to get the inconsistent error and so difficult to come up with any reliable solution.
Any thoughts would be welcome.

Regards

Steve

[AndiS]

1) I am able to workaround this sometimes by entering the scenario via the Build menu option and then clicking the Play button

If you see the same problem in the same place in the same scenario more than once then you should contact the scenario author. If that fails or is a disappointing experience, put the author on your private list of sources to avoid.

2) A web solution suggests that this occurs because there are too many routes in the system so disabling ones that are not used frequently may help.

I have seen quite a few posts by people who do that. It will depend on the size of your collection and your usage habits. Basically I can only recommend getting rid of stuff you don't need if it can be revoked. Some people say that your computer resources (memory of all sorts) can get exhausted but what is more all your verification routines will run extra long on useless files.

3) Also, doing a "Local File Verification" procedure from your STEAM account on TS may help if it finds a corrupt file and downloads it again for you. - this one worked for me for a while!

In this case, you need to observe when it stops working for you and for which files. It is quite logical that it does not fix new downloads before the first verification.

4) I’ve also found that disabling your internet connection while starting TS2020 seems to prevent the Divide By Zero error sometimes.

I can only recommend to play offline. Whenever you go online, repeat the verification that worked for you after you went offline again. I have no idea of the details of the inner workings of the Steam client and TSxxxx but obviously stuff gets updated in the background which is a good thing unless there is some bad content in the stream that you just fixed.

It's very frustrating to get the inconsistent error and so difficult to come up with any reliable solution.
Any thoughts would be welcome.

As sketched above, you need to narrow it down. DTG do a bit to help by improving these verification routines (I suppose) but such checks are always a bit behind the errors that crop up, at least in real life software.

[SteveP_trains]

Thanks Andy - I am the route/scenario author - so I can genuinely say the experience was pleasurable

Joking aside, the error is not consistent in any of the scenarios and not at any specific positions so I can't do much about fixing things. Some people have errors and others don't so there must be a config or environment issue that seems to trigger things.

I was just reaching out to see if anyone had any more feedback or ideas over and above what I had discovered.

Thanks anyway

Regards
Steve

[SteveP_trains]

Andy
Long time since I picked up this thread but I've had some more info as a result of running LogMate and amongst load of other messages found there was a lot of these.
I only got as far as these by opening the scenario via Build which usually gets through these Divide By Zero errors and wondered if this is a problem or just TS being picky!!

Seem to refer to one of your .OUT scripts so can't look myself at it. Any thoughts??

Steve

[AndiS]

I never saw such an error. And I have no clue how it can come along. These lines belong to code that writes the state of signal arms to the logfiles if you use the logging objects provided with the signals. There is not much in them that can go wrong and nothing that appears worthy of event trying.

I'd say your signals are pretty confused. You could have a faulty script file where the gArmTable has an issue. But much more likely, the whole startup of the route has an issue.

You mention you use Build to get into the route at all. So you still have this divide by zero error?

No idea about the complexity of your route, but generally such a mystery is only unravelled by dividing it into small pieces. Either by taking out a lot of stuff from a copy of the original route the error disappears. Or by putting together suspicious parts until the error reappears.

You are not the first one I see in such a situation but I never developed a reasonable suggestion when people are stuck with a complex route that developed an error long ago with not idea as to what would be those last modifications that might be to blame.

[SteveP_trains]

Thanks Andy. I think it’s a TS2022 issue as sometimes it will start the scenario with no problem, then it will error sometimes but going into the route via Build will almost always be ok and playing from there is no issue.
I just wondered if the errors meant something to you.
The signalling is not very complex on route and issue is so sporadic I can’t get too hung up about it.
Thanks

Steve