Page 1 of 1
| Persistent fatal errors with Motherwell 27/12/2014 at 21:38 #67130 | |
WDAGRANT
18 posts |
Example Internal Error 1M91/1M11-1 in Calculate Priority at 00430D27 Program continues briefly then screen greys over and I am returned to Windows I am using windows 7 both trains are at Carstairs. 1M11-1 has already been given the road south, 1M91 is approaching signalled right up to the junction. This is only one example. It had happened several times in the last few days. I bought Paisley almost as soon as it was out but on returning to Motherwell. The first was a restart of an old session at which I was warned of a new version. This error was with a restart from the beginning. I have a saved file if it would be helpful David Grant Log in to reply |
| Persistent fatal errors with Motherwell 27/12/2014 at 22:26 #67132 | |
|
clive
2789 posts |
Thanks, but this is a known problem.
Log in to reply |
| Persistent fatal errors with Motherwell 14/01/2015 at 10:22 #67799 | |
|
WDAGRANT
18 posts |
Any progress on this known bug? Another simulation lost today. Also persistent false telephone calls from drivers disputing 'route set on to goods line' despite being a timetabled route set by the ARS David Grant Log in to reply |
| Persistent fatal errors with Motherwell 14/01/2015 at 11:18 #67801 | |
Peter Bennet
5402 posts |
On the second point I need more specific information such as where and which trains. Peter I identify as half man half biscuit - crumbs! Log in to reply |
| Persistent fatal errors with Motherwell 14/01/2015 at 11:38 #67803 | |
postal
5265 posts |
" said:Also persistent false telephone calls from drivers disputing 'route set on to goods line' despite being a timetabled route set by the ARSEdited as first attempt was probably wildly inaccurate! Possibly a result of the new COS (Class of Service) rules set into the latest core code which may require a slight adjustment to the TT. I don't think the Wiki has yet caught up with the change so I can't point you to an online explanation. Further edit: Clive posted an explanation of the changes on the Forum as the first posting in this link. “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Last edited: 14/01/2015 at 11:58 by postal Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 15:34 #67874 | |
|
WDAGRANT
18 posts |
The attached file will promptly generate the internal error in Motherwell which later proves fatal All incidents seem to concern one up train at Carstairs - but this may be chance On this occasion 1M83 is at Carstairs and 2S26-2 is ay Wishaw I really would be grateful if this can be sorted. Of all the pay ware simulations I have bought this presents most appeal for me as a single person operator - enough, but not too many conflicting movements. I would recommend it to all who use the simulations as single players. An example of the spurious phone over mis routing in 0L89 as it approaches M251 to enter Coatbridge DGL (as timetabled) - but this is just an irritation If it is revised core code that is causing the issue (and I don't recall the problem at first purchase) then please can we have the old core code back. Fatal errors are a disaster David Grant Post has attachments. Log in to view them. Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 16:59 #67879 | |
|
TimTamToe
664 posts |
With the internal error issue, as a work around whichever two trains are mentioned if you make them non ARS then you'll be able to continue without the sim closing unexpectedly. (right click train headcode and select make non ARS) Gareth Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 17:06 #67880 | |
|
postal
5265 posts |
David I don't know whether it is significant but the TT you are running shows as v4.1.0, The TT supplied with the latest version of the sim in the downloads section is v4.2.3. It may be that the TT and sim version are not compatible which is causing the errors. I've attached copies of v4.2.3 with this posting so you can download them and see if the problem persists. It raises the question about what processes are in place in if there is an update to the sim which is implemented through the Update Manager off the back of the Loader to ensure that the user also gets compatible timetables if the sim update causes problems with the previously released TTs. Post has attachments. Log in to view them. “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 17:28 #67883 | |
|
Peter Bennet
5402 posts |
The problem with OL85 (and others) is that for some reason the Pendolino speedclass box has become ticked (Train characteristics), I can't work out why. The default timetable that I have does not have the ticks but it's considerably different from yours in other respects. I'm not that familiar with the history of the timetable but for whatever reason it's seems an old iteration, though I'm not aware of this issue arising before in any event. Peter I identify as half man half biscuit - crumbs! Last edited: 15/01/2015 at 17:28 by Peter Bennet Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 17:32 #67884 | |
|
Peter Bennet
5402 posts |
" said:With the internal error issue, as a work around whichever two trains are mentioned if you make them non ARS then you'll be able to continue without the sim closing unexpectedly. (right click train headcode and select make non ARS)I found that I could re-enable ARS soon after with no difficulty. As an aside I can't provide any information on the timetable for loader updates as it's not my area of expertise. Peter I identify as half man half biscuit - crumbs! Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 17:45 #67887 | |
|
postal
5265 posts |
Been digging back into the archive and the corruption of the speed classes happened at some stage before v4.1. I have vague recollections of spotting this and manually editing all of the light engines to remove the check-mark against EPS-E but that must have happened post-v.4.1. Certainly the check-marks are not there in the latest release. Presumably it was not an issue with previous core code and has only now come to prominence with the recent changes. However, it is not a core code problem, it is a TT problem. “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 19:21 #67891 | |
|
WDAGRANT
18 posts |
Thank you for the suggestions. I have downloaded v4.2.3 and will try it. So far at 06:00 from an 04:45 start it's without error The previous timetable was that provided with the original program and I have not messed with it. The error was not present in several runs when I first started using the program. There would seem to be some merit in not allowing global core code upgrades. If its not broke.... Oh for the old standalone versions. Thanks again David Grant Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 19:41 #67893 | |
headshot119
4869 posts |
" said:Thank you for the suggestions. I have downloaded v4.2.3 and will try it. So far at 06:00 from an 04:45 start it's without errorWell it's really a choice between having an easily upgraded product via the loader, or sitting with a stagnant version. I know both as a developer and a user which I prefer! "Passengers for New Lane, should be seated in the rear coach of the train " - Opinions are my own and not those of my employer Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 20:50 #67894 | |
|
Peter Bennet
5402 posts |
What you can do is rename your loader version with a version suffix - e.g. I have a "SimSigLoader 4.2.315.exe", so you can always back-track if you find you don't get on with a newer one. Later builds of Sim may not function if they have new features but they will be highlighted red when you try and launch and you can use a different one. Peter I identify as half man half biscuit - crumbs! Log in to reply |
| Persistent fatal errors with Motherwell 15/01/2015 at 21:51 #67896 | |
|
postal
5265 posts |
" said:Thank you for the suggestions. I have downloaded v4.2.3 and will try it. So far at 06:00 from an 04:45 start it's without errorCertainly the "routed onto goods line" errors are a TT error. It is because of the updated core code that the errors have now come to light. Had the current core code been in use when the TT was written, the errors would have been flagged up early in the TT testing before release. In that respect, the TT was broke. “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Log in to reply |
| Persistent fatal errors with Motherwell 16/01/2015 at 04:34 #67910 | |
|
Airvan00
129 posts |
Re the persistent fatal errors that are occurring in a number of Sims. Yes it can be frustrating but Sim Sig is quite a complex program and many things can upset the apple cart. To explain my theory and offer a solution I need to mention a bit of history (apologies in advance, if it is long winded, but I need to explain it to give a bit of background) 10 or 20 years ago I would run the Didcot Sim. Down freight trains are programmed to cross from the Down Local to the Down Main at Milton junction. I got into the habit of crossing them instead at Morton cutting Junction, if it was more expeditious. I would manually select the signals and I would get the Message that 6xxx was routed of planned route, but after Milton junction the ARS would kick back in. No problem When Swindon A &B became available I would also handle freight trains in the same manner. However I noticed that for up trains often the ARS would not set the route in the vicinity of Milton Junction. Reason, “giving priority to 6xxx”. However that freight was still in the Sim but now well west of Swindon. I never understood this until now. Fast forward to the present day The fatal error messages, that I have experienced, have always included one train that I have taken off route. I posted a “work around” that Tim Tam Toe has helpfully reproduced above, some months ago in connection with another Sim. (Pause the Sim immediately on receiving the error and make both trains on the error message NON ARS before resuming) To avoid the fatal error completely, prior to rerouting a train, make it NON ARS, and only resume ARS when it is back on planned track. (Probably a good work practice to establish) With the small geographic sims like Didcot there was never a problem as rerouted trains would exit quickly. Along came Swindon A&B and trains were in the sim for a much longer period but XP probably was more forgiving. Now something like Win 7 is less forgiving and will white out and freeze. Note, the “Gods” of SimSig will never see this problem, as they like to run the Sim without ARS. A lot of people have reported that the error occurs when resuming after a saved game. I can only think that somehow some table is not saved correctly. I haven’t been able to test this as I always resume from a saved game. (I don’t have the time to run SimSig without saving) Of course all the above theory may be rubbish, but it works for me. I have just spent the whole morning on Victoria East and I took every freight train via the Chatham main instead of the Atlantic. Making them NON ARS before rerouting them, and no fatal errors whatsoever. Log in to reply |
| Persistent fatal errors with Motherwell 16/01/2015 at 07:02 #67914 | |
|
WDAGRANT
18 posts |
Anther exception error with Motherwell today 4M27 and 7M49 reported Can anyone identify the protocol that either timetable has violated? There is clearly a coding issue; the code should report the protocol violation - 'invalid timetable of train ????' would be helpful The code needs to catch the error / exception? Going non-ars with both trains immediately after the exception did let the program run on until I saved some 15 mins later Thanks again to all who are contributing to this thread I started Are any of the responders core code editors? David Grant Log in to reply |
| Persistent fatal errors with Motherwell 16/01/2015 at 07:51 #67918 | |
|
clive
2789 posts |
" said:Anther exception error with Motherwell today 4M27 and 7M49 reportedIt isn't a protocol error, it's a bug in the core code which isn't correctly handling some situation. (Programmers will recognize the phrase "unexpected NULL pointer".) There's nothing to report; the timetables haven't violated anything. Quote: The only people who work on the core code are Geoff and myself. This is Geoff's code, it's particularly complex (see other threads; ARS is a lot more sophisticated than you might think), and I don't know anything about it. So it needs Geoff to fix it. (Mantis number is 12100; it's not marked as fixed yet.) Last edited: 16/01/2015 at 07:52 by clive Log in to reply |