Addition of BLETTERS

[GoogleCodeExporter]

BLETTERS are broadcast letters set on the bucket or bucket parent. For specific 
hooks, you can trigger off customized broadcasts.

Original issue reported on code.google.com by Fleety...@gmail.com on 15 Dec 2009 at 3:08

[GoogleCodeExporter]

I have this coded if it is of interest for the next version (though I don't 
know if everyone will find it useful):

Needs new help file for BLETTER.

Add into JDO/TRIG_ADD:
   @trigger %va/TRIG_BROADCAST=[parent(%0)],[u(parent(%0)/BLETTER_%3,%0,edit(%1,|,@@PIPE@@),%2,%3)];

JDO/TRIG_BROADCAST changed to: 
   @switch %1=,{@@},{@pemit/list [setq(0,%0)][filter(%va/FIL_BROADCAST,setunion(lwho(),))]=[ansi(hc,JOBS:)] %1}

Original comment by Fleety...@gmail.com on 15 Dec 2009 at 3:14

[GoogleCodeExporter]

I think I might like something like this but not sure I understand your 
implementation.

As it stands, many different commands call trig_broadcast with different text.  
This
change appears to only affect a small number of them. Is it worth the overhead 
for
something that could be done by simply changing the appropriate command 
(+job/add,
for example)?

Original comment by widdis@gmail.com on 15 Dec 2009 at 3:52

[GoogleCodeExporter]

A related comment. Many of the different calls to TRIG_BROADCAST have the job 
code in
inconsistent format.  Some have Job %0, some job # %0, some [name(%q0)].  I 
would
like them all in a standard format, possibly passed to a separate function to 
be able
to specially-format the job # (or full job name) so it stands out in the 
broadcast. 
(Imagine something like ansi(h,job 1) or the like....).  

Combine this with your idea and you could highlight the various bucket names
differently.  Code in cool blue, REQ in yellow, etc.

I actually have edited my own trig_broadcast to edit all job<non-digit><digits> 
to a
consistent format that is pueblo-link-clickable to look at the +job:  
&trig_broadcast
JD=@pemit/list
[setq(0,%0)][filter(%va/FIL_BROADCAST,setunion(lwho(),))]=[ansi(hc,JOBS:)]
[regeditalli(%1,Job\[\\D\]+\(\\d+\),pueblify(Job $1,+job $1))]

Original comment by widdis@gmail.com on 15 Dec 2009 at 4:04

[GoogleCodeExporter]

The above code is for customized messages in addition to those posted by 
commands - so you get two messages instead of one.

Alternatively, we could remove all broadcast instances off the commands and put 
the default BLETTERs on the bucket parent - and then you can override on the 
bucket level.

Another alternative: Make the behavior change to 'if a BLETTER is found, 
broadcast that, if not, broadcast the default text'.

I suppose the reasoning for all of this would be that a game might want custom 
messages that it doesn't want overridden on an update. It also sort of rounds 
out the *LETTER functionality of the system - all the other major 
interface/interaction TRIG_*s have an associated *LETTER with them, except 
TRIG_BROADCAST.

Original comment by Fleety...@gmail.com on 15 Dec 2009 at 4:19

[GoogleCodeExporter]

I hate this thing, and it hates me, too.

Original comment by Fleety...@gmail.com on 15 Dec 2009 at 4:19

[GoogleCodeExporter]

I strongly favor one line of text rather than 2.  The "If a BLETTER is found 
use,
otherwise default" sounds very good.  I believe you could just stick a bunch of
default BLETTERs on the JPO and the buckets would inherit them unless 
overwritten.

And agreed re: overwriting messages. I came up with the hack in comment 3 after
tiring of rewriting my individual hacks for all the commands after every (test) 
update!

Original comment by widdis@gmail.com on 15 Dec 2009 at 4:24

[GoogleCodeExporter]

Bletters are installed with more acceptable behaviors.

There's still a few things that need cleaning up (for instance, +job/esc will 
say
'JOBS: Job 91 has been escalated to 3 by Bob.' instead of 'RED'), and has yet 
to be
seriously tested, so I'm leaving this job open for the time being.

Original comment by Fleety...@gmail.com on 7 Jan 2010 at 7:02

• Changed state: Started

[GoogleCodeExporter]

I've tested the hell out of it, and all the responses are good since r217.

Original comment by Fleety...@gmail.com on 16 Jan 2010 at 9:55

• Changed state: Fixed