Forums Feature Suggestions To be able to override internal $identifiers.

Would like to see a -i switch added to the ALIAS prefix to allow an alias to have priority over a built in identifier.

Currently any alias such as "alias debug { etc etc etc | return something }" can not return its own $debug value, it well always return the true debug window, since (as said in the help) "Built-in identifiers of the same name have priority."

I would like a switch to be able to override them. (dont want it to be the default action as that likely well cause other scripts to fail)

$Debug is one i have a need for, I want to maintain my debug window with my alias being run on each line, while also allowing someone elses script to appear to be able to do a /debug command, which my script can handle as a sub component of its own, obviuosly I would prefer to be able to, if something asked for the $debug identifier be able to return the window that the other persons script set as the debug window. So you can setup a fully transparent handling layer. (PS I have managed to get around this one actually).

Another example might be with the potential problem with long and short filenames on the /DLL command being talked about in the bugs forum, such an alias as follows could exist that would adjust the filename internally to a longfilename and call/load the dll as needed.

(Please note : roughly scripted so im ignoring spaces in filenames, error checking etc, its just an example to the idea)


Im unsure on the reason In built identifiers take priority, I can see the ability to override internal identifiers open to be used to abuse unsuspecting people, but in the same moment i see it as a great debugging aid also, such as being able to debug a ON *:TEXT:*:* { event } by setting the identifiers as needed and calling it as an alias (here i used /testme)

^ by simply remarking out the unwanted settings of chan and nick you can test the event as if its on a live channel(s) being set off by what ever nick is needed etc.

There's already an option to return the scripted identifier:

Its still not $dll or $debug as I said, an option to allow the internal identifier to be overriden, so you can seemlessly install a code layer between the internal command and someone script, I cant expect everyone to script $.dll instead of $dll.

Some may say well if you want to do that then go through there scripts and make the changes, and I say if thats the case, then why let you override internal commands either, if u have to alter the other script, then /dll and /debug can be altered to /my_dll and /my_debug as well.

Overriding those aliases will cause compatibilty to lack with other scripts. i dont see whats wrong with $.me or $.dll or $myme $mydll anyway. definatly a no on this one if it was up to me.

Considering there's already a way to use scripted commands and identifiers or mIRC's built in commands and identifiers, I don't see what the problem is, your feature suggestion is already in mIRC.
Identifiers just require 1 extra character after the $.

Well it now? And you would know that why?

All a script needs to do is read the passed parameters and if relevent to the script deal with them, if not pass the identicle parameters to the true $identifier and return that to the calling script. This being not different from what you can currently do with customized commands.


What i suggested was a way to override any default identifier without effecting current scripts (ie: the -i switch), since the default COMMAND can already be overriden I ask simply why not the default RESPONCE, especially if that $identifier happens to have a command that been replaced already!


To you and Tidy Trax about why not use $mydll or $.dll, well I dont really feel like answering that but try this post out for why Link

if you override wat $chan returns it will affect other scripts and the if not it is gonna be ignored by many., it should only work in conjunction with the -l switch IF added. Furthermore i like to add that snobby comments are greatly depreciated.

The whole idea is to override in such ways as to not cause problems to other scripts (this of course is up to the quality of the script invoked), thats what seamless layers are, currently mirc doesnt have the ablility to introduce them by simple scripting alone. The idea it should only work only in conjunction with the -l switch is understandable in your eyes but if that were the case then why have the -i switch, if it only works on your own code then you can just call your own alias names so its not needed. Below I have given a not overly tested example of what one might want to do. A fictional MUD exists using a network and channel as its interaction point with the server and clients, when a any other irc user is in the channel they would get the topic as normal from $chan(incars).topic a player currently in the MUD would however recieve a Personalised topic with there time in there player name, a message, and the original topic up to the first ~ being that the orginal topic maybe " blah blah mud notices blah blah ~ Come join us in the MUD download the script at http:\\..... " and a player does not need to see the join ad.


^ I havent done much checking exact correctness on the passing to the original identifier, i would do some more if it was a real script.

Oh and i dont want to get into a slanging match about snobby comments but i was replying to "will cause compatibilty" when in IMO that should have been "could cause compatibilty"

No, it will cause compatibility issues because not everyone thinks of everyone else when scripting, like setting global vars when not needed.

Well that IS a "could cause" then not a "will cause".

example: Having a loaded fire arm "could cause" an injury, just becuase not everyone handles it with care, does not mean it "will cause" an injury.