[edwardk]

I can definitely confirm how the quit option is working with the activity window. In my mind, if you choose quit then this usually means that the activity is completed and you want to exit back to the main screen. Another situation is when the window comes up in the middle of an activity and the person is tired and wants to quit. If I am correct then the fix for this is rather easy.

Edward K.

[James Ross]

beresford, on 09 July 2014 - 02:03 AM, said:

MSTS will trip a Time or Action Event whose conditions are already satisfied when its Activation Level becomes >=1

OR will trip Time Events in the same manner as MSTS, BUT Action Events will not trip if post-Activated. You guys can take my word for it and I'll raise a bug report, or you can see for yourselves.

Ah, this was the kind of thought I had swirling around about this bug but didn't get around to the logging to prove it (sorry!).

[beresford]

Buttercup, thank you for your explanation of triggered and untriggered messages.

James, can I assume that you are on the job of investigating Events? I get the impression that the MSTS logic is as follows:

IF <Condition> is currently satisfied
AND Activation Level >= 1
AND Event has not yet triggered
THEN Trigger Event

[James Ross]

beresford, on 10 July 2014 - 03:16 AM, said:

James, can I assume that you are on the job of investigating Events? I get the impression that the MSTS logic is as follows:

IF <Condition> is currently satisfied
AND Activation Level >= 1
AND Event has not yet triggered
THEN Trigger Event

I'm not going to have any time to fix this in the next few weeks so someone else is welcome to make a fix for it - I just happen to have been fiddling around near the events code recently so had an idea on what the issue might be.

That logic is correct AFAIK and is what OR uses... however, that logic is only re-evaluated in OR when the condition is satisfied, not when the event's activation level changes, I believe.

[beresford]

James Ross, on 10 July 2014 - 05:25 AM, said:

I'm not going to have any time to fix this in the next few weeks so someone else is welcome to make a fix for it - I just happen to have been fiddling around near the events code recently so had an idea on what the issue might be.

That logic is correct AFAIK and is what OR uses... however, that logic is only re-evaluated in OR when the condition is satisfied, not when the event's activation level changes, I believe.

I figured the expression was probably scheduled continuously rather than being invoked by anything. I wasn't actually talking about coding the solution, I was referring to identifying the scope of the problem. I've proven (to my satisfaction) that this is how MSTS and OR do the 'drop off cars' Action Event, but is it safe to assume that all the other Action Events are the same?

[edwardk]

I am not sure if this is related to what has been discussed, but I did manage to find a bug where events that are initially set to 0 or less are left out of the update process. Initially, a location event would start off with an activation level of 0 and would be increased by one by an action event, but the location event in question would never register properly because the update process would only accept it if the activation code which is based on its initial value is > 0. By testing at >= 0, I was able to get a successful activity end once the location event was reached.

Edit: This was a quick and dirty test.

Edward K.

[edwardk]

I indicated I thought I found an issue, but this is not the case.

Edward K.

[edwardk]

As of V2361, cars that are now dropped off before the event DropOffWagonsAtLocation is activated will now be acknowledged and the event triggered. The only issue is that cars dropped off will not be checked if they are on the correct siding so in this case, read your work order carefully :whistling: .

[edwardk]

As of V2372, the fix needed to be reversed due to issues reported.


Edward K.

[edwardk]

I will have the proper fix for this issue shortly.

Edward K.