View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003152 | unreal | ircd | public | 2006-12-19 23:09 | 2007-04-19 02:37 |
| Reporter | Bricker | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| OS | NA | OS Version | 0 | ||
| Product Version | 3.2.6 | ||||
| Summary | 0003152: sorted /stats o layout | ||||
| Description | You know, I am on a network that has a lot of olines, and when im trying to sort stuff out, or to see who has what and I do /stats o, its just one bug floppy mess. I was wondering if their would be a way for future releases to make a more clean output. maybe something along the lines of /stats o Network Admins O *@* * Test rDRhgwlcLkKbBnGAaNCzWHtZvqd Services Admins O *@* * Test1 rDRhgwlcLkKbBnGAaCzWHtZvqd Server Admins (which could also include Co-Admins) etc etc etc... something a little more clean then seeing a whole mess of O *@* * blah rdhHFHDSHah clients over and over with differnt flags, names etc. it just becomes a strain for big networks with a lot of ops trying to find exactly where someone is, etc. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Hmm, I like this idea, tbh there's always room for improvement, and always room to clean up. |
|
|
+1 :] looks good! |
|
|
I like this. Nice:D |
|
|
"/stats something" usually can be used by scripts, services, stats, other parsers, etc, and "user friendly formatting" can cause inconvenience for those. maybe it is better to do this is some other way? not through stats? |
|
|
but those who dont use scripts, it comes out messy. me honestly i've never seen anyone that has a script that makes the output of /stats * look good...or do anything with it really. And I've used a lot of scripts in my time. oh, and if it does mess up the scripts, people love to recode! :) -Edit- Changed "stats" to "scripts" in first line, 6th word from left :P |
|
|
Well the "headers" could just be RPL_TEXT and the rest is the normal numeric. But as it is, it's easy to have the stats O already sorted (but not pretty-sorted like suggested) - sort them in your config (sort "ascending" (locals first, then globals, admins, etc) and they come out "descending" since unreal reads config file backwards)! |
|
|
Or, in a way to make Unreal a little more appealing, it could be made to send it out more cleanly, or at least make it an option to set before compile, sort of like the prefixes. |
|
|
Problem is, if you start changing the numeric formats, you break everything that depends on them. I'm sure unreal's already gotten on many client coders hatelists just because of some of the stuff we've done to numerics (+z numeric, anyone?). If you look at a lot of the numerics, you'll notice for the most part that they're insanely easy to process by a program. The fields are clearly seperated into seperate parameters, so it's a simple, say, params[5] to get the flags. Numerics are generally machine-readable, such as the /who replies - only a few (RPL_TEXT, motd numerics) are for people. Others that are all text may simply have all their meaning contained entirely in the numeric (RPL_YOUREBANNEDCREEP, RPL_WELCOME, etc - simply receiving these tells you that you're ban user{}'d or allowed in). I believe the intent was that the client program would intercept the numeric, and format it in a more appropriate manner, rather than waste bandwidth and CPU time by having the ircd do it. I know I've made mirc do just that with *:lines. When you see fancy formatting from a numeric (such as is typical for the WHOIS numerics), it's usually the client formatting it, not unreal. Sorting is an entirely reasonable thing for the ircd to do, however. But once again, it can already be done by sorting your config entries (they're just dumped in reverse order) and thus avoid the ircd having to do it every time (and sorting isn't a cheap process). |
|
|
How difficult would it be to have the list sorted as it's taken in from the conf? If too, then is there anything we can do aside from your (aquanight) suggestion of ordering them in the conf? If not, can we close this? |
|
|
I agree with aquanights statement that the admin could just sort the oper {} in the conf, honestly. A third party module for this would be better |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-12-19 23:09 | Bricker | New Issue | |
| 2006-12-19 23:12 | aegis | Note Added: 0012858 | |
| 2006-12-19 23:27 | Bock | Note Added: 0012859 | |
| 2006-12-20 18:30 | vonitsanet | Note Added: 0012864 | |
| 2006-12-20 23:15 | avb | Note Added: 0012866 | |
| 2006-12-21 00:40 | Bricker | Note Added: 0012867 | |
| 2006-12-21 19:50 | Bricker | Note Edited: 0012867 | |
| 2006-12-24 13:15 | aquanight | Note Added: 0012894 | |
| 2006-12-25 17:35 | Bricker | Note Added: 0012903 | |
| 2006-12-25 20:10 | aquanight | Note Added: 0012905 | |
| 2006-12-25 20:12 | aquanight | Note Edited: 0012905 | |
| 2007-04-18 16:19 | WolfSage | Note Added: 0013531 | |
| 2007-04-19 02:36 |
|
Status | new => closed |
| 2007-04-19 02:36 |
|
Note Added: 0013576 | |
| 2007-04-19 02:36 |
|
Resolution | open => no change required |
| 2007-04-19 02:37 |
|
Relationship added | child of 0003284 |
