Two items:
Item 1
SighelmofWyrmgard wrote: .... assuming you're hidden ... playing an instrument will not unhide you and will only be heard by the player. [To be clear, I meant, "only by the player of the character who is playing the musical instrument"]
Only moments ago, I tested this in-game to confirm that it is correct: you can be standing right beside another character who is playing a musical instrument and the instrument will only be heard by the instrument-player, if the instrument-player is hidden.
Now, if one happens to be dual-boxing, "focus-loss" will occur on the inactive client and in-game sounds generated on the inactive client will not be heard (although the in-game music can still be heard regardless of focus-loss): anyone "juggling clients" would have to check back with the detecting character, periodically, to check to see if the detector has detected anything.
However, as to the question in the OP, if the real-person-game-player wanted to camp somewhere and wait for something to be detected, but be AFK (leaving the client "up", so that focus-loss does not occur), then the type of macro I described above would work just fine.
Item 2
Kabup, please take no offense but,
Your macro is upside-down, and will likely get anyone relying on it for a PKer-warning killed.
It is upside-down in the respect that it is of the format, "detect and, if no detection, wait 10 seconds but, else, repeat 10x: sound alarm and then wait 1 second"; it would be a lot better if it were, "if detection yes sound alarm and wait 1 second but, else, detect and wait 1 second".
I see two big flaws with the first format:
1, with no pause between the detection and the sysmessage check, only a little latency will cause the macro to miss the on-time Sysmessage and, instead, remember the previous Sysmessage (which, logically, would have been "no evidence"): this almost guarantees that the macro will execute 1 more "detection" loop before sounding the alarm; the alarm will not be on-time, but 10 seconds late ... You might also get a false alarm on the first run: algorithmically, it's not sound.
2, and this is related to 1, Razor remembers Sysmessages, so you want the macro anchored to the unique "detect-yes" Sysmessage, and not the "detect-no" that the upside-down macro uses and will be constantly spamming: remembered Sysmessages could prevent your macro from sounding the alarm for a couple of minutes, or more!
So, I would amend your macro thusly,
If Sysmessage
"track" ;"which" might be just as good EDIT: I bollocks'd this, use,
If Sysmessage = "Select" ; or "like"
[Sound Alarm Action]
Pause 1.0 second
Else
UseSkill Tracking
[Gump-selection blahblahblah]; EDIT: you will want to edit the "Wait for gump" time-out to only 1 second, also
Pause 1.0 second
End If
[Loop!]
With no latency, you'll get a one-second delay until the alert is sounded; with some latency, it will be only latencytime+1second before the alarm sounds.
"Hey Saxmund, don't you mean 10 seconds, instead of 1 second, after UseSkill Tracking?"
No, I don't: the macro is not listening for anything in the "You must wait ..." skill-delay Sysmessage and will ignore all of that spam; additionally, regardless of latency and/or variations in latency, the Tracking skill always will be used as soon as it possibly can, for each continued iteration, to within 1 second.
With 10-second delay, even a tiny "blip" of server-side/connection lag could cause a 19+ second gap in the effective detection loop, by completely failing to execute for an entire 10-second iteration; lots of "blips", and the macro will be constantly bouncing out-of-sync/back-in-sync.
So, to all who wish to try such things, do well and heed what I have said.
SS
P.S. I might rather employ item-usage-against-target-type, instead of Tracking, for this sort of thing, as Tracking might "stack" a few gumps and screw-up the macro (if you were to say, go AFK for a couple of minutes, or something). However, Tracking has a range advantage ... Tracking will be fine if you're checking-up on the detector regularly.
SS
