Can be properly tested using this code:
Possible bug with denyCurrentSend
Possible bug with denyCurrentSend
Within the last week, I decided to make use of denyCurrentSend and after a number of test, I stumbled upon a possible bug with it. If you try to send something after using denyCurrentSend, it ends up not blocking what you're trying to block and instead proceeds to send it.
Can be properly tested using this code:
Can be properly tested using this code:
Re: Possible bug with denyCurrentSend
In the case where you are sending a replacement command, like you are there, you can make it work by sending the new command and then calling denyCurrentSend. Not sure if it has issues with just denial without replacement though.
Re: Possible bug with denyCurrentSend
I think you're misusing this feature to create a custom alias system on top of Mudlets. I'd recommend just making an alias or making use of tempAliases().
The idea behind the function is to just block a send() and that's it. If you need input triggers that do replacements, that is exactly what aliases are for.
The idea behind the function is to just block a send() and that's it. If you need input triggers that do replacements, that is exactly what aliases are for.
Re: Possible bug with denyCurrentSend
None of those would work for me needs, the issue is that as I've no way of knowing if I need to send the new command until after I've already sent the command I want to block, and this way, I save time and don't have to wait for another chance to send the necessary command, and usually by that time it means I've missed my chance. What I did to work around it was just raise an event and used another function to do the sending.Vadi wrote:I think you're misusing this feature to create a custom alias system on top of Mudlets. I'd recommend just making an alias or making use of tempAliases().
The idea behind the function is to just block a send() and that's it. If you need input triggers that do replacements, that is exactly what aliases are for.
Re: Possible bug with denyCurrentSend
Aliases can be pretty detailed and powerful. Certainly enough to handle what you seem to be trying to do, which is switch out one specific command for one of two other specific commands when certain conditions are met. I don't exactly know the syntax for the original commands that are being sent (since you don't show the command as it would be sent), but I would guess that this would work to do what you have in your example:
Pattern: ^psi (?:mindblast|psychicvampirism)(.*)
Code:
Pattern: ^psi (?:mindblast|psychicvampirism)(.*)
Code:
That assumes that you are setting "mindbursting" somewhere else (which matches with what you have in your example), and then sends the new command if mindbursting is true, or the old one if it isn't.