Opers + mIRC

[slakker]

Do any/how many EFnet opers use mIRC? If so, what type of features would be useful in a script? I'm currently developing an oper module for the new ircN and would love any input on what would be handy. What I have for ideas and some functionality presently are:

1.) Separate oper windows (e.g. for operwall, different server notices, etc.)

2.) Nicklist menus for kill, kline, gline

3.) Menus for and themeing of stats requests

4.) Filter kill and who kill

5.) Auto oper (network specific) and auto set modes on oper

Any other ideas or input would be appreciated.

[Osc]

I use mirc.

As far as oper specific features go, you will get further making each thing a separate script, rather than an all-in-one thing.

Why is that?

Because, as any oper should know, prefab scripts suck: they do the unexpected at the worst possible time and completely ignore what the help file tells you will happen if you try to do something.

So, if you want anyone to use what you have or plan to produce, don't do an all-in-one and don't integrate it with ircn.

What else can you do that will increase the chance that someone else will use what you produce? Do not even think about making it 'pretty' or 'leet' with colors or borders: you can't tell what I may have as a background and anything else you *add* to the information you parse only distracts from that information. Just stick to parsing the info and displaying that info, nothing else.

Now, your list, from my perspective:

1. done, by halting everything else =]
2. no one mass kills or mass klines anymore. creation of gline lists are already 90% automated.
3. already covered above. =] this would be the place to do your work, imho, the most useful.
4. covered by #2
5. personal choice here: I prefer one instance per server, less chance I'll do on server A what I meant to do on server B.

HTH

[slakker]

I use mirc.

As far as oper specific features go, you will get further making each thing a separate script, rather than an all-in-one thing.

Why is that?

Because, as any oper should know, prefab scripts suck: they do the unexpected at the worst possible time and completely ignore what the help file tells you will happen if you try to do something.

So, if you want anyone to use what you have or plan to produce, don't do an all-in-one and don't integrate it with ircn.

Noted...though since I work on ircN I'll probably do both (ircN module and standalone script).

What else can you do that will increase the chance that someone else will use what you produce? Do not even think about making it 'pretty' or 'leet' with colors or borders: you can't tell what I may have as a background and anything else you *add* to the information you parse only distracts from that information. Just stick to parsing the info and displaying that info, nothing else.

Does that mean you'd rather see, for example, a stats p request that displays:

[O][GKxOCRUhdanLspB] slakker (slakker@blah.blah) Idle: 198423

or:

Oper: slakker (slakker@blah.blah) Privs: GKxOCRUhdanLspB Idle: 2days 7hrs 7mins 3secs

I wasn't clear on your opinion as far as formatting parsed info, other than the comment about colors and such.

Now, your list, from my perspective:

1. done, by halting everything else =]
2. no one mass kills or mass klines anymore. creation of gline lists are already 90% automated.
3. already covered above. =] this would be the place to do your work, imho, the most useful.
4. covered by #2
5. personal choice here: I prefer one instance per server, less chance I'll do on server A what I meant to do on server B.

HTH

Thanks.

[Osc]

slakker> Does that mean you'd rather see, for example,
slakker> a stats p request that displays:
slakker>
slakker> [O][GKxOCRUhdanLspB] slakker (slakker@blah.blah) Idle: 198423
slakker>
slakker> or:
slakker>
slakker> Oper: slakker (slakker@blah.blah) Privs: GKxOCRUhdanLspB Idle: 2days 7hrs 7mins 3secs

Well, the privs don't really matter, and we know they are opers (else they wouldn't be in stats p). What really matters, imho, is the nick and idle time. What would be neat would be to list with the lowest idle time at the bottom of the list. So...

slakker (slakker@blah.blah) 2days 7hrs 7mins 3secs
slakker1 (slakker@blah.blah) 7hrs 7mins 3secs
slakker2 (slakker@blah.blah) 7mins 3secs

[munky]

that's easy. on each 249, populate a list, on 219, sort it (please don't use bubblesort), then print it and clear it (so next stats p is working from an empty list)
many scripts sort stats p by idle time, usually shortest first, not last

to combat a race condition, you could use a hash table, assuming mirc supports them. this is so that a /stats p irc.server1.com doesn't output with /stats p irc.server2.com (would hybrid/ratbox/csircd put out multiple stats responses at once?)
details on how the ircd would handle outputing multiple stats requests would probably have to be requested in the ircd forum, or ask an ircd coder

[slakker]

Thanks for the input on sorting by idle time. mIRC does support hash tables and that is currently how the requests are handled in regards to keeping them network-specific. The reason it actually displays 'Oper:' is because it differentiates between Oper and Admin.

[HM2K]

I personally don't think any EFnet opers would use any scripts created by a 3rd party, especially in mIRC, besides ircN sucks anyway.

I would recommend trying a network that uses UnrealIRC rarther than ratbox/hybrid, they are more likly to be your target audience.

[wundr]

besides ircN sucks anyway.

Why? I've been using ircN 7 for years, and rather like it (although I admit I haven't tried the ircN 8 betas yet). Why does it "suck"? If you are telling a member of the ircN development team that their project "sucks", it may be useful to tell them why you think so.

I would recommend trying a network that uses UnrealIRC rarther than ratbox/hybrid, they are more likly to be your target audience.

I'm curious why you say a network that uses UnrealIRC would be more interested?

BTW, plenty of EFNet opers use 3rd party scripts on various clients...

[slakker]

I'm curious why you say a network that uses UnrealIRC would be more interested?

Me too

Besides that, ircN has always been developed with EFnet in mind. In addition, I have talked to a few opers who either do or have used ircN and were receptive to the idea of an oper module for it (regardless of whether or not they themselves would actually use it). Even if nobody on EFnet uses it, there still may be opers on smaller networks that run hybrid/ratbox that may find it useful.

[lucy]

i probalby wouldn't try a 3rd party oper script by some random person i didn't know.... unless other opers checked it out first... or it was real obvious from looking in it, that it was nothing 'bad' in it.

[Osc]

Which is exactally why I woudn't use ircn or, for that matter, anything by a 3rd party that I can't glance at and *know* it's not gonna fubar the network.

This is why I suggested that whatever you do, have that thing do one thing only per script/file.

I just looked at ircn. It is 61 files in 16 different directories, and 817 k.
All my scripts (9) are only 35 k. ircn is 23 times as much.

[slakker]

I just looked at ircn. It is 61 files in 16 different directories, and 817 k.
All my scripts (9) are only 35 k. ircn is 23 times as much.

When ircN gets out of the beta stages this will be trimmed down quite a bit as it won't include all of the module files. That said, I didn't exactly intend on driving the conversation in this direction. I'm only looking for ideas to put in a script that I'll be developing regardless of how many people use it. Besides, I wouldn't exactly expect anyone on a large network to use a beta (though I know one who did with no problems).

[Mouse]

I did made my oper scripts based on other oper scripts.
I just use my modded mirc and my scripts to oper up on some networks
Been opers on other networks for years

[SMeK]

I'm currently using NoNameScript (mIRC script) to oper on unreal and hybrid networks

I used to have a script that filters all glineskills etc into windows, but it got rather large annoying having so many windows open (i use a channel hider to hide idle channels)

And as for the popups for oper commands, thats something that can be easily added. I for example added Chanserv commands and some oper commands to my script. But try it anyway, if an oper is concerned about 3rd party scripts they can always read through them to see what they do

[munky]

i think the primary concern is hard to see vulnerabilities, such as the old $calc() bug. a deft programmer can put a backdoor into a script that would be hard for most other programmers to catch. and don't forget, most opers aren't programmers.
when you're dealing with 100k users, it may be easier to put your faith into a fellow local oper than in J4ck_t3h_skr1pt0r from JoeMamaNet.