Feature Proposal: @NotifyState

[Alan Glover]

Consider a script which wants to be sensitive to other restrictions before attempting an action. For example, it might want to do a forced TP but wants to know whether the TP is going to be blocked by @tploc.

It might seem that @notify:tploc is exactly what's needed here but there are several problems which make it unsuitable for this.

a) Since @notify reports all activity, it's not true that seeing a @tploc=y come through notify means that TP is now allowed, because there could still be a @tploc=n in effect from a different source

b) Counting the @tploc=y and @tploc=n and considering that TP is allowed when the counts are equal cannot be relied on because objects may well apply their restrictions more than once (and also @clear might be used instead of @tploc=y)

c) @clear needs to be considered too - it MIGHT cause TP to be allowed or it might not; it depends whether the @clear coming into the notify is on behalf of the object with the last remaining @tploc=n in effect. If another object still has @tploc=n in effect then seeing @clear notify DOES NOT mean that the @tploc is now cleared

As it stands, it's not possible to track the status of a restriction solely using @notify. The only reliable meaning it has is a prompt to the script that it should query state using @getstatusall to detect what restrictions of interest are still in effect.

The proposal following is designed to eliminate this problem and also to reduce the need for the alternative way of tracking restrictions (using @getstatusall on a polling basis).

Proposed syntax @NotifyState[:<part_of_rule>[;<custom_separator>]]=<channel>

How it works:-

Changes are only communicated when a restriction is actually added or removed, NOT every time a rlv command is issued but only when there is a change on the central list of restrictions in effect (the same list @getstatusall uses)

@clear is NOT notified as @clear, but applicable @rule=y notifications are generated when an @clear causes one or more restrictions to end.

The benefit of this is that once initialised with the current state from a @getstatusall call, a script can then be passively informed on all changes of interest without needing to poll or do subsequent @getstatusall changes to clarify @notify results

[Marine Kelley]

I like the idea, indeed @notify notifies of changes, but often what a script needs is the current state. I think this is something worth implementing, it would simplify the job of a scripter a lot.

[Alan Glover]

Thanks for the positive response here. Thinking about it a little more, I would also like to propose an extension which will simplify the start of state monitoring. At the moment, the script would need to do a @getstatusall call initially to set up the starting state before relying on @notifystate for ongoing updates.

This could be avoided if @notifystate were to make an immediate reply just after it has been called by the script reporting on the current state as if it were new (since it is new to the script at this point).

Thus if tploc and tplm were restricted at the time @notifystate:tp;# were issued the script would get an immediate reply of #tploc=n#tplm=n

With this extension, there would be no need for any additional code to establish the starting state.