|
Moo Apprentice
Joined: 10 Apr 2009 Posts: 145
|
Posted: Sun Aug 01, 2010 10:27 pm
#print / #gag |
Is there a way to make messages I display myself, with #print or something else, immune to being gagged?
I would say that it should be up to my script to not display the messages, if I didn't want them displayed, rather than let them be gagged..
The problem comes when I do #gag 10 or similar, to try to hide the next 10 or howevermany lines from the mud.
Sometimes messages displayed by my script (which I obviously do want displayed) get hidden, and lines I wanted to hide get through instead.
Is there any way to avoid this? |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Sun Aug 01, 2010 10:54 pm |
#PRINT should not fire the #GAG. If it is, you need to write a bug report on it.
By nature, #PRINT was created so that you COULD display messages to yourself that would normally fire a trigger.
Charneus |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Mon Aug 02, 2010 2:01 am |
Quote: |
Is there a way to make messages I display myself, with #print or something else, immune to being gagged?
|
Yes, if you use #GAG, #GAG 0, or #GAGSPACE. #PRINT does not send its output through the trigger parser and so any trigger that would gag a line using these commands will never be able to target the #PRINT-generated line. However, the other gagging commands do not care how a prior/upcoming line was generated.
Zugg may decide to put this on the wishlist, but otherwise there's just no way around it other than to avoid using block gagging or to use such in a manner that does not interfere with the messages you want to keep (given multiple sources of triggering, this is not as easy as it sounds). |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Moo Apprentice
Joined: 10 Apr 2009 Posts: 145
|
Posted: Mon Aug 02, 2010 10:23 am |
charneus wrote: |
By nature, #PRINT was created so that you COULD display messages to yourself that would normally fire a trigger. |
Yup, it's not my #printed lines making triggers fire that is the problem, but my #printed lines being eaten by block gags.
MattLofton wrote: |
Zugg may decide to put this on the wishlist, but otherwise there's just no way around it other than to avoid using block gagging or to use such in a manner that does not interfere with the messages you want to keep (given multiple sources of triggering, this is not as easy as it sounds). |
I'd like this added to the wishlist, please. I think #printed lines are obviously "wanted" lines and should never be gagged. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Aug 02, 2010 4:08 pm |
Unfortunately, once a line has been added to the screen, there is no way for CMUD to remember where it came from. So when doing a "block gag", every line on the screen is treated the same way. CMUD can't tell that a line was added via #PRINT or whether it came from the MUD. Sorry.
|
|
|
|
Moo Apprentice
Joined: 10 Apr 2009 Posts: 145
|
Posted: Mon Aug 02, 2010 10:29 pm |
So.. It displays everything, then if it needs to be gagged, it removes it again?
Isn't this rather slow in performance terms?
Why not check if it needs to be gagged before displaying it at all?
Or... If this can't be changed.. What about what I suggested. Some kind of special code or character that the gag code looks for which tells it to ignore that line. This could be used even if the line was already on the screen, and wouldn't need to be restricted to #print. |
|
|
|
Arminas Wizard
Joined: 11 Jul 2002 Posts: 1265 Location: USA
|
Posted: Tue Aug 03, 2010 1:29 am |
You mean like maybe how #ungag works for show?
Here's a work around that you can use for print.
Code: |
<?xml version="1.0" encoding="ISO-8859-1" ?>
<cmud>
<alias name="Test" copy="yes">
<value>#show {1 this is a test.}
#show {2 this is a test.}
#show {3 this is a test.}
#call @gagblockF("1")
#show {4 this is a test.}
#show {5 this is a test.}
#show {6 this is a test.}
#call @printF("This was a test.")
#show {7 this is a test.}
#show {8 this is a test.}
#show {9 this is a test.}
#call @gagblockF("0")
#show {10 this is a test.}
#show {11 this is a test.}
#show {12 this is a test.}</value>
</alias>
<var name="gagBlockS" type="Literal" usedef="true" copy="yes">
<value>0</value>
<default>0</default>
</var>
<func name="gagblockF" copy="yes">
<value>#switch ($state=="1") {
gagBlockS="1"
#gagblock
} ($state=="0") {
gagBlockS="0"
#gagoff
} ($state==%null) {
#return @gagBlockS}</value>
<arglist>$state</arglist>
</func>
<func name="printF" type="String" copy="yes">
<value>#if (@gagBlockS=="0") {#print {$text}} {
#gagoff
#print {$text}
#gagblock
}</value>
<arglist>$text</arglist>
</func>
</cmud>
|
Basically instead of just using #print #gagblock and #gagoff you would use the functions @printF and @gagBlockF.
For an example on how to use it just look at the test alias. |
|
_________________ Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
Moo Apprentice
Joined: 10 Apr 2009 Posts: 145
|
Posted: Tue Aug 03, 2010 1:40 am |
Another workaround might be to use a multistate trigger to gag each individual line in my block. But really I think this is simple enough that it shouldn't need a workaround.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Aug 03, 2010 4:42 pm |
Quote: |
So.. It displays everything, then if it needs to be gagged, it removes it again?
Isn't this rather slow in performance terms? |
*ALL* triggers are processed *after* the text is already sent to the screen. This allows triggers to fire on the actual text being displayed instead of worrying about network packet breaks, control characters, or other tricks the MUD might try to use to mess up your triggers. This is how CMUD (and zMUD) have always worked and will not be changed.
It does not effect performance in CMUD. CMUD optimized this so that #GAG triggers are checked before the screen is actually refreshed.
The #PRINT command gets around this by temporarily turning off triggers while it is printing the text to the screen and then turning them back on again. |
|
|
|
Moo Apprentice
Joined: 10 Apr 2009 Posts: 145
|
Posted: Tue Aug 03, 2010 9:22 pm |
Ok then.. So how about it turns off the (block) gagging while printing the text, too?
|
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Wed Aug 04, 2010 12:27 am |
Because the block gagging has no idea that a line was issued via #PRINT.
1)this is a line from the mud that a trigger matches, it is a 2-state trigger that is now waiting for line #4
2)this is a printed line.
3)this is a line from the mud that you don't do anything with
4)this is a line from the mud that a trigger matches (state 2 from the trigger that matched line #1), it gags the last 4 lines because you don't want to see them. |
|
_________________ EDIT: I didn't like my old signature |
|
|
|
|
|