Page 1 of 1
Unexpected aspect 18/05/2015 at 02:27 #72391 | |
Muzer
718 posts |
In the April 2012 timetable, 2E15-4 was delayed at Denmark Hill at signal 433, so when he phoned I told him I'd replace the signal to danger, and cancelled the route set from 439, causing 433 to be replaced to caution. When the train finished being delayed, I received the bugfeature of a brief ringing tone as usual, then in the Messages window I saw: "2E15-4: unexpected aspect 2 at S433 after seeing 6". This does not seem to have had any adverse affect on the game — I have not "scored" an ACOA nor has the driver stopped to phone control, so I'm guessing this was likely an internal debug message which isn't supposed to turn up/represents a "shouldn't happen" case. Hence my reporting it here. Save and screenshot attached. EDIT: Also attached is a snapshot from before the message, in case this helps. Post has attachments. Log in to view them. Last edited: 18/05/2015 at 02:31 by Muzer Log in to reply |
Unexpected aspect 18/05/2015 at 09:50 #72397 | |
GoochyB
222 posts |
I had a similar message in Saltley, unfortunately I don't have any further specifics other than that was also aspect 2 after seeing aspect 6. I'm afraid that doesn't really help other than point to it being core code and not sim specific.
Log in to reply |
Unexpected aspect 18/05/2015 at 10:53 #72399 | |
postal
5216 posts |
" said:I had a similar message in Saltley, unfortunately I don't have any further specifics other than that was also aspect 2 after seeing aspect 6. I'm afraid that doesn't really help other than point to it being core code and not sim specific.I can't comment about the individual circumstances identified here, but I raised something similar on the issue tracker a while ago (#8134 for those with access). From the comments there, I think that the unexpected aspect 2 after 6 is a report from the underlying code that the driver saw a Y when he should at worst have seen YY. Clive has an item on his long list that the code should be reworked so the driver reports events of this nature as well as ACoAs. “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 |
Unexpected aspect 18/05/2015 at 11:35 #72401 | |
Danny252
1461 posts |
" said:Clive has an item on his long list that the code should be reworked so the driver reports events of this nature as well as ACoAs.Does that not already happen? If you drop a signal back from YY to Y, or G to YY, or whatever, in front of a train, you'll still get a nasty phone call. Log in to reply |
Unexpected aspect 18/05/2015 at 12:05 #72403 | |
postal
5216 posts |
" said:" said:From the bug report about the particular circumstances I reported:Clive has an item on his long list that the code should be reworked so the driver reports events of this nature as well as ACoAs.Does that not already happen? If you drop a signal back from YY to Y, or G to YY, or whatever, in front of a train, you'll still get a nasty phone call. "This isn't ACoA, because the driver didn't see a change of aspect. It's an irregular aspect sequence, which is a different matter. Yes, we should have core code to detect this and have the driver report it. It's not the same as the ACoA code. Much of it is already in place, but it may need some reworking (the present "unexpected aspect" logic is very conservative and was designed for sim testing, not for actual play)." I don't understand all of the logic behind that but there is clearly a difference in the way that the code handles unexpected aspects depending on circumstances. Perhaps it is something to do with assumed sighting distances and whether it is assumed that the driver actually sees the aspect change. “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 |
Unexpected aspect 18/05/2015 at 12:45 #72407 | |
clive
2766 posts |
This message is, as postal reports, a sim debugging message. As each train passes a signal, a simple piece of code compares the aspect of that signal with the aspect of the previous one. If it's an illegal combination (e.g. YY followed by R) you get this message. This code is triggered purely when the train passes the signal. The numbers are the internal representations of aspects: 1 is shunt, 2 is Y, 3 is flashing Y, 4 is YY, 5 is flashing YY, and 6 is green. So that message means that S433 was yellow while the previous signal was green. The cases detected are:
[/li] [/ul] Note that if the previous signal doesn't have a yellow aspect the test is not made. The ACoA code, on the other hand, is triggered when the signal in advance of a train changes to a more restrictive aspect and either the train is within the signal's sighting distance or the new aspect is part of an invalid sequence according to the same rules as above. You can distinguish these two cases by the text of the alert: "received" versus "will receive". The ACoA code is suppressed in certain circumstances (e.g. another train in the way, lamp not lit, a second unseen down-change). The point of the bug report is that a driver won't phone about an invalid aspect sequence if it was set up before he saw it. Really he should be phoning and asking. Log in to reply The following user said thank you: postal |
Unexpected aspect 18/05/2015 at 14:10 #72413 | |
Muzer
718 posts |
This is what I'm saying though — surely the game should not report it as being an invalid aspect sequence since I responded to the delay phone call with "signal will be replaced"?
Log in to reply |
Unexpected aspect 18/05/2015 at 23:07 #72443 | |
Airvan00
129 posts |
Yes, but there is a time limit to replace the signal. IIRC 1 minute.
Log in to reply |
Unexpected aspect 19/05/2015 at 00:57 #72444 | |
Muzer
718 posts |
Indeed, but I replaced the signal immediately.
Log in to reply |
Unexpected aspect 19/05/2015 at 08:23 #72451 | |
postal
5216 posts |
" said:Indeed, but I replaced the signal immediately.At a guess there are two bits of code doing different things and the parameters are suffering from a mis-match. The ACoA bit of code would seem to be working correctly because the signal was replaced in front of the driver but no ACoA phone call was received. The other bit of code around unexpected aspects is not tied into the same loop as the ACoA code so did not take account of the phone call and replacement. This bit of code recorded that a train passed a G and was expecting at worst a YY. If the train then departed while the signal was showing Y, that bit of code complained as it was expecting a YY or G and it saw a Y. Nothing intrinsically wrong with either bit of code but as Clive has already said, there needs to be a bit of work to make the two bits of code work correctly in parallel. “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 |
Unexpected aspect 19/05/2015 at 14:54 #72470 | |
clive
2766 posts |
" said:Correct. The unexpected aspect code just looks at the aspect as you pass the signal, though I think it's coded to ignore it when a train is told to pass a signal at danger. Log in to reply |