Forums Feature Suggestions Hex in identifiers and commands

I've been an mIRC scripter for a couple years now and have done many great things with mIRC. My latest big projects have include an IRC server and web server. As my projects grow more complicated, it seems harder and harder to get by with the limited ASCII-based identifiers. For example, I was thinking about creating a SOCKS proxy server with buil-in live socket stream monitoring and editing features, and a complete remote administration tool. The more I plan out the internal workings of these projects in my head, the more I realize how limited I would be with the ASCII-based identifiers provided by mIRC's scripting language. Here are some examples of thoughts I had as to hex-based usage in existing and new identifiers:


Anyways, being able to read and write hex in such ways shouldn't be very hard to implement into mIRC's scripting language, and it would be a huge convenience for scripters such as myself. If this is an old subject, or something similar already exists, please let me know.

Ok well first off let me start out by saying, the projects you are talking about are not what mIRC was designed for. If you want to write a proxy server, use C, C++, Java, or any other computer language. Creating a webserver or irc server in mIRC is (imho) laughable. If you don't understand what I mean, I made a simple script in mIRC that looped through a string comparing it character by character. I made something to do the exact same thing in C. The C program executed over 500 times faster than the mIRC script. mIRC scripting is fine for making an "on join" script, but it is laughable to think it is suitable to create a server...

In any case... how exactly does that hex syntax make anything easier?

why is:
if ($mid(<text>,15,2) == \x0D\x0A) { ... }

so much easier than:
if ($mid(<text>,15,2) == $+($cr,$lf)) { ... }

I really see absolutely no gain in implementing what you stated. All it can possibly do is slow down mIRC because it now has to recognize and parse \x characters.

You don't need the socket scripting functionality to make an onjoin script, yet that functionality is there. The fact that socket scripting functionality exists only proves that the scripting "language" of mIRC was meant to be a bit more than simplistic at its best. It doesn't matter what mIRC was made for, what matters is that there are features that can be utilized and stretched to do amazing things. And doing the stretching is a fun process.

If you thought that my post was an attempt to be able to identify carriage returns and line feeds, you missed the entire point. I only used carriage returns and line feeds as something easily identifiable to get a point across.

I did not post for input on alternative methods of doing what I mentioned. This post related to mIRC, and mIRC only.

Just because you don't use mIRC for more complex things than simple scripts doesn't mean there isn't a use for its complex features. I seriously think that this feature would add lots of possible capabilities to the mIRC scripting language.

Creating new identifiers/commands specifically for hex (such as the binary identifier and command set as opposed to the ASCII identifier and command set) would relieve the current identifiers and commands from being slowed down, although I'm not sure that would be a real problem depending on its implementation.

Can't you use $base() and $asc() to change the ascii in to hex?

In your example, compare having to use $base on every byte of a long string in a while loop, to feeding the string directly into a $hex identifier, as-is. Would be a major difference, and ASCII values cannot be used in all cases.

It wouldn't really be that slow. Basically what you're asking is for mIRC to have functions which have absolutely zero to do with IRC or scripting, which have very specific uses. If you choose to make mIRC do something completely different to it's intended area then that's your decision, but you can't honestly expect mIRC to then have features added because you can't easily do what you want.

That's where you're completely wrong. It has just as much relevance to IRC as the already existant socket-scripting does. It has everything to do with scripting, and the abilitiy of the commandset to understand the hex system. Such capabilities are not just specific to my needs or interests, but have an unlimitted span of usage possibilities. Your post makes absolutely no sense.

Would you care to give an example of a semi-IRC related usage for this then?

First thing that came to mind when I read your post was databases. There are many reasons to maintain databases, such as OP databases, seen databases, trivia question databases, etc. Suppose you want to implement a database that is not a low-level flat database, but is a database based on another protocol and is made for another software package. Most external database protocols, for example MySQL, rely on being able to send and receive hex data, not just ASCII data. Granted that MySQL is an advanced database system for IRC usage, it's just an example that popped into my head. This would allow the maintenance of such databases to be easier, more efficient, and based on protocol, plus any comfort levels of a user maintaining the datase with their own software package that they are accustomed to using.

As you say, it's a big leap from IRC to MySQL. In my opinion the use of such things is so rare and unnecessary that if someone decided they wanted to communicate with MySQL it wouldn't be unreasonable for them to either do a fair bit of scripting of connect via DLL. I believe there is a MySQL DLL for mIRC, so someone apparently agrees with me.

If people want to use MySQL they can use a MySQL DLL, it really isn't worth Khaled adding such an option though, as the vast majority of mIRC users would never touch it.

Bah, MySQL was just an EXAMPLE. I don't use it myself. I'm surprised you all don't see the potential uses/usefulness.