mIRC Homepage


Posted By: Dromedary

$requnlock - 24/08/06 05:36 AM

for obvious reasons, you can't just make unlocking locked things scriptable. what i do think is possible, however, is an identifier that will do a request unlock for certain things (mainly, dll, run, and decode). what this would do is put a pre-formatted message on the screen requesting to unlock the feature. thus meaning, the scripter could not have any influence what-so-ever of what this request said, they could just simply request the unlock. in this message box, put a pretty scary warning saying that these things are dangerous and maybe even give a link to the help file explaining in more detail.

my point is though, i think it would be grand to have the ability to request to unlock an identifier.. but of course, not allowing too much control to the scripter so that they could deceive the user into clicking yes.
Posted By: DaveC

Re: $requnlock - 24/08/06 06:43 AM

I would rather have an UNLOCK command that required a passkey to be entered, one store in the registry like the mirc password hash,the effect of the unlock command would last only for the length of the script it was run in, preferably even only the specific script its running in (aka wont be unlocked in any called alieas or identifiers). This would allow a script requiring one of the lockable commands to unlock it with a supplied password, which it can insert itself from its own stored info somewehere or in the event its an older script simply adding /UNLOCK <PASSKEY> on the line before it well correct the script.
Posted By: Om3n

Re: $requnlock - 24/08/06 07:10 AM

Agree with DaveC, I think an /unlock password would be much better than a prompt.

A prompt immediately brings up all the same issues that $input would directly in an event, like pausing everything waiting for user interaction. (since if it didn't pause, the script would run and not do what you want to anyway, making the prompt useless.)
Posted By: Dromedary

Re: $requnlock - 25/08/06 05:24 AM

well, my point is, when you have a script that requires unlocking say $dll you can do an on load thing that does the request for unlocking. once it's unlocked with this, it should either remain unlocked, or maybe have check box stating 'unlock for this session only' so that it returns to its locked state when the user quits mirc, or possibly make it scriptable to relock something after it's been unlocked.

the password wouldn't be so bad, but a lot of people would just rather not deal with setting up a password and may make mirc less attractive when it comes to irc newbs needing to connect to an irc server.
Posted By: DaveC

Re: $requnlock - 25/08/06 05:38 AM

Being repeatitively asked if its ok to unlock something would really piss me off personally.
Posted By: Om3n

Re: $requnlock - 25/08/06 08:11 AM

I'm apposed to any kind of internal popup, even during on load and on start events. Try adding a script that pops up an input box all the time before running certain procedures, you will soon experience why its not a great idea. A command is better imo, but i can see why some would find this undesirable also (or just a pain to have to code in). Maybe some way to allow 'safe' scripts to run certain locked commands? shrug.

For now you could just script in an on load warming for the script using the $lock identifier. $lock(dll)
Posted By: Talon

Re: $requnlock - 28/08/06 06:32 AM

decode is just base64 decoding, which is easily scriptable.. if you need a decode, make your own.. as for dll and run, It would be much more simple for an on load event to echo an error and unload itself checking $lock saying in the echo, this script utilizes dll and/or run, which is disabled in your mirc, If you wish to use this script, please unlock these features in your mirc settings.
Posted By: Dromedary

Re: $requnlock - 01/09/06 06:29 PM

i don't see how any of the complaints made could not be accomidated by either a) only allowing it inside of an on load script, or b) only allowing it to be requested once every X amount of time (perhaps, once per session [meaning once every time mirc runs, and no more until mirc has been exited]) with addition to having an option in the locking section of mirc to not pop up any box asking about unlocking variables. if you look at it like "well, this is going to be nag and i hate nag", then what's the difference between that and having a script nag you with a popup that's not authored by mirc itself? if a person is going to nag you with a popup, they are going to nag you with a popup. it doesn't matter if they use mirc's internal commands or if they chose to make their own popup to nag you with.
© 2021 mIRC Discussion Forums