Forums General Discussion Help to change a CTCP version reply

Hi, I have a script which have a CTCP reply, but it's not like any other CTCP reply that I can easily change, but it have an option to disable the load of the CTCP version DLL files on startup. How can I still change it, and which part of the script do you need to know this?

If you're referring to the default version reply from mIRC, then you can not remove or change this.

To my knowledge the default version reply is no longer in a DLL but is hard-coded in the executable.

If I'm misunderstanding you, and you're talking about changing the reply for a script (which I'm thinking is more likely each time I read your post), then you would have to look for a line that reads something like

Additionally, if this is a scripting matter, then it should've been posted in the Scripts and Pop-Ups forum

THERE ISN'T ANY CTCP VERSION IN THE REMOTE.

Your question, in its current form, is unanswerable.

As a result, any answer is guess work.

Don't yell at people for guessing wrong. Start by asking a proper question instead.

Using a dll to change the version reply is generally frowned upon here.

Years of work has gone into mIRC, it's only fair to give the author credit and leave the version reply alone.

I'm just wondering..
There are actually ways to change - or even remove - the default mirc version reply using simple scripts.
Anyway, I am not going to edit this in any case - My question is, may I append my own text after mIRCs message?
I mean, I prefer having 1 version-reply including all information instead of 2-3 for various scripts I am using.
Anything that speaks against mIRC v6.33 Khaled Mardam-Bey (some script here)?

I don't think anyone would have a problem with that. Maybe make it clear that the script is written by you though so people don't go to Khaled if they have problems with your script.

I'd personally see no problem with that assuming you stick to your word. The reason K hasn't bothered allowing this is because given an inch, most people want a mile. It would be smart to introduce some kind of version name registration system where any script can register itself and mIRC will automatically report it in a reply... something like

/regscript mycoolscript/1.1.2
/unregscript mycoolscript/1.1.2

K could limit how long the text could be, disallow spaces, etc., to discourage somebody filling the line with only their information

and mIRC will report: mIRC v6.33 Khaled Mardam-Bey mycoolscript/1.1.2 someotherscript/3.4.2, much like an apache Server HTTP header reply.

The only problem would be the user may end up being responsible for unregistering the script from the list as I doubt authors would take advantage of infecting the list for advertising purposes and then not cleaning up if the script is uninstalled (not that they can even know if their script has been uninstalled).

The benefit, however, would be that it would allow the appending of information without the possibility of hijacking the reply, which I think is the real reason the version reply is off limits.

I personally have my version reply set to something LIKE (not exactly)

mIRC v6.33 on WinVista (by Khaled Mardem-Bey) w/ <scriptnames loaded - Called by an alias)

or...

<scriptnames loaded - Called by an alias) on mIRC v6.33 / WinVista (by Khaled Mardem-Bey)

Oh, and that solves your /regscript problem. Let each script call an alias...


eg
mirc1.mrc has "alias -l mIRC.AddonName return Something1"
mirc2.mirc has "alias -l mIRC.AddonName return Something2"

I suppose the limitation here would be that mIRC would only see one addon per script, but this would solve the loading/unloading.

Also... because they are local aliases, mIRC could have a global mIRC.AddonName alias that returns all of them, space/comma seperated.

I don't think aliases are quite the cleanest builtin solution.. mIRC can do better if its given control of the situation. A local alias wouldn't actually work anyway unless mIRC cheated and accessed it as a global for the reply. In general, it's just confusing because mIRC rarely relies on alias overriding to define functionality from the script engine. What I mean by that is that you're never expected to fill in a specific alias name to make mIRC do something, it would be hard to document and, it just doesn't fit.

It did make me think of something useful though..

I usually hate abusing mIRC's more obscure syntaxes but I think this is one of the few situations that truly justifies a:



Directive parsed by mIRC. That would be the only one to truly be file dependent and leave when the script was unloaded. If a script owned many files it would just define #script/#version in one of them. Same as an alias but defined by a relatively familiar construct and less error prone in actually getting it right. Also, #script/#version would also be the only syntax that would work if your "script" was an alias or popups file (alias could not).