An experienced user that knows what they're doing knows that, they would also know not to corrupt the script in such a way it wouldn't work.
The idea behind this is very basic-- people that have absolutely no idea what they're doing wouldn't be able to render a script unfunctional if they accidentally over-write an existing variable.
It's not taking in consideration people that know scripting indeep at all. The "defender" term is against people that damage the script unintentionally, not highjack it to fit their needs.
There might be no way to make mIRC's configuration uneditable to avoid bypasses and change of the interface, unless you encrypt it, I believe.
First of all Id like to say I appreciate what you are doing. It's a cool idea. What I see from what Riamus is saying is, from a scripters point of view.
I will use blatant examples here, please disregard how stupid it would be to actually write this.
I write:
on *:join:#:{
set %nick $nick | set %time time
msg $chan %nick joined $chan at %time
}
on *:text:*.lastnick:#:{
msg $chan %nick joined $chan at %time
}
Ok so I'm not you, I'm just a guy who likes your script and wants to add something to it. Now I have written normal basic code that sets a variable. What happens when that variable is used by you already. I am asking mirc to use %nick but your alias rewrote it to be %nick(2) so I get an error message and it doesn't work. I have to call a variable by its exact name or use $var to find it otherwise it doesnt work. So if I set a variable as %nick and your alias changes the name of it, my code is broken.
Well the script does warn you what the variable got renamed to, doesn't it? If you can write a small remote like that and know what a "remote" is, you would surely know how to make a simple edit such as to add "(2)" to the end of your variables, right?
I pose you this question: To break users' code if they rewrite existing important variables, or to allow users to break your script's functioning?
It is common sense that any successful script would use variables with chariteristic prefixes and sufixes, suchs as %sillyscript.variable, but what if by chance someone does try to over write this anyway, assuming they don't know what they're doing?
This is the purpose of this script.
It would be much easier to just prefix your own variables and
don't worry about protecting the variables of other scripts.
%bs.variable for example (bs = beau's script) or choose whatever
prefix you like that is unique to your script so that the chances
of one of your variables being overwritten by the user or by
another script are minimal. With this solution, nothing is broken
but your variables are still protected.
~ Edit ~
If I were to start seeing scripts using this method of protection,
I would start prefixing all my commands with ! to bypass aliases,
which would render your variable protection useless.
Yes, but do you comprehend that the script isn't supposed to trap the user?
If the user knows how to bypass variables in such a way it won't interupt the functioning of the overal set of scripts, that's fine.
But some users don't know, and some even accidentally over write variables essential for a prescripted mIRC's scripts, in some rare but possible cases, they even over write things difficult to be over writen such as very specific variables such as "%whatever.tmp".
That's the intent of the script, to nullify any possibility of variable conflict, the fact the user is experienced enough to avoid it doesn't come into this matter.
"%bs.variable for example (bs = beau's script) or choose whatever
prefix you like that is unique to your script so that the chances
of one of your variables being overwritten by the user or by
another script are
minimal."
When you said "minimal" you can't say "impossible" can you?
(Currently working on the /var issue, the /halt is already removed.)
