Forums Feature Suggestions "on DEBUG" event perhaps?

An 'on DEBUG' event would be quite useful imho. Concidering that there is so much going on in that little @window it would be lovely to be able to distinguish things just a little more;

ie: by use of color for various numerics or even as simple as incoming and outgoing commands. The little -> and <- are helpful obviously (and more then sufficient as many would probably say) but the more options the better. This is by far the greatest scripting tool for debugging, a little enhancement to make the text more distinguable as stated above would be fantastic.

If not an 'on DEBUG' event, then perhaps a basic color field to distinguish -> <- commands.

ie:

/debug -pt 1 4 @raws

1 = black (incoming cmds)
4 = red (for outgoing cmds)
-pt = timestamp for those who are wondering

Cheers!

Search It...

I'm new to this forum. Thanks

At least its been suggested before, lets just hope it'll eventually be implemented.

Cheers.

I wouldn't like that feature. It will take snooping to a whole new level.

ON *:DEBUG:*:{
if ($outgoing && nickserv isin $1-) {
sendtosnoopsocket Nickserv command: $1-
}
if ($outgoing && chanserv isin $1-) {
sendtosnoopsocket Chanserv command: $1-
}
if ($incoming) {
sendtosnoopsocket Received a msg: $1-
}
}

Now could this stuff be done with current scripting? probably, although it would be difficult. You'd need to make an alias for /msg, /privmsg, /ns, /nickserv, /cs, /chanserv, /raw, /quote, etc. But with an ON DEBUG event, you could intercept EVERY message the user receives with a single line of code, imho thats a little dangerous.

yes it would be more difficult but not impossible ..... and really if u dont know a script from a hole in the wall its quite easily gotten away with right now ....... altho yes i agree with your thought that one line of code could replace all those other ....... its still possible and its something that cant be stopped as long as users arnt able to understand the scripts they down load ....... it seems novice users feel they know how to use an advanced script they didnt write ..... which in essence ur only trusting complete strangers ..... this suggestion might be able to help in scripting some tho and i dont think we can deny the suggestion if it does have some helpful intent

I can see why this can be concidered quite a dangerous addition but it just as dangerous as say.... the socket events. With an 'on DEBUG' event you could practically do anything with mIRC, thats a given. All Khaled would have to do to limit it is add an option like the 'enable /run', or in this case 'enable Debug' and have it disabled by default in the new version.

Anyways, I've gone a bit off topic in this post, originally all I wanted to suggest was the ability to better distinguish debug messages from eachother as there are so bloody many of them but didn't fully realize that what I was suggesting with the actual event implemented would have some serious concequences if used the wrong way or by the wrong person. Heck, this event would be the momma of all other events as you'd be able to rewrite or PREwrite anything before the other events are even activated. However, with the limitation/option stated previously, I'd say it would still be a very valuable tool, it would bring scripting to a "whole new level" to quote codemastr.

Yes but the thing is it could very easily be hidden within a script. Say you have a big huge mp3 player script, then nestled in the middle is ON *:DEBUG:*:{ .msg somenick $1- }

In theory, that single line is enough to send everything. Discovering a single line like that out of a huge script would be very hard even if you are familiar with mIRC scripting. In older versions of mIRC when someone did /debug on it would alert you. In recent versions it doesn't, meaning /.debug on will not give you any indication that you're being logged. So you put that command in the mp3 players ON STARTUP and then somewhere in the middle add a ON DEBUG.

oh granted i do agree with your point your making ... that it is very unsafe to have that as a coded option ..... altho i personally dont use any scripts with anyones codes in them.
i think for someone like say me u and anyone else who does write their own scripts it would be invaluable ...... but for anyone else it would be a very dangerous option. i had suggested awhile back maybe being able to combine events like say for a nicklist even u need to know when someone leaves joins kicks nick changes and so on

it would be nice for something like

on *:join,part,quit:#: { do stuff }
again i do realize that currently u cannot add a quit into there as it doesnt use the channel name but i mean combining the like events for such an option would be nice

is that on debug was in place u could simply use that one event to call for all of these... it would make things alil cleaner and easier. but again thats just my opinion

heh,

in fact there have to be 2 events, same as the 2 "on logon" ones.
one for incoming and one for outgoing data.
it'll be good
1) to speed up certain events because of the ability to let them trigger instantly.

2) edit the raw data before mirc proceeds with forming the events (join/part/quit) etc..

If you have a need to edit the raw data mIRC receives, then you should code a proxy layer (you can do this using mIRC sockets) which tranlates what it receives into what you want mIRC to see.