some notes 2 (mostly feature requests) [0.15+0.16]

[Sedulus]

LuaScript.txt

• client:send(data) is not documented] fixed

Core

• it'd be nice if the "Unknown command: " also stated the username (and optionally the IP) so I could check which client is sending crap obsoleted by clientUnknownCommand

OpCom

• +loadfromdisk [access] [dchpp]
  would load the respective xml files from disk, inverse of refresh, all other plugins may handle their own reloading (like LuaScript already does with +reload)
• it isn't really nice that OpCom steals "+help*", for instance it would be good if LuaScript also had a chance to reply that it knows the +reload command.
  ACTION_HANDLED still needs to be called after the last script is done, so maybe one could implement a HUB_HANDLED return code instead which would allow scripts to get the message anyway. the inverse could be PLUGIN_HANDLED (hmm.. what would this be good for?). I haven't given this enough thought yet though. will be fixed with ACTION_STOP when it works =)
• +showuserswithlevel <level> [<regex_or_wildcard_enabled_thing>]
  (but then again, I can read the access.xml just fine ;) ), but an +isregged command would be nice to have in OpCom or an extra boolean for +reg, like +reg <nick> <pass> <level> [overwrite], so regged users aren't accidentally overwritten
• +refresh could reload the OpCom.xml settings, but then again, once a hub is set up correctly these things usually don't need tweaking (unless you want exceptionally high uptimes of course)
• ip mask specification is reversed (10.11.12.13/8 is converted to 10.11.12.0-10.11.12.255 when it should be 10.0.0.0-10.255.255.255) fixed

dchpp.xml

• a small note:

  Code: Select all

                  <ServerIp type="string">surfnet.mine.nu</ServerIp><!-- don't use :<port> =) -->

• why is RegistrationServers not in settings? settings.RegistrationServers could be a nice array in Lua

LuaScript

• functionality to reload a single script set (so the memory of other scripts isn't cleared). it would look like:
  +reload [script_set1[ script_set2[ ...]]
  (without arguments it would reload all)
  this needs an identifier of script sets.. something like <Context name="foobar"> (can't include space))
• a way to implement a timer. either like PtokaX or nmdc does it, or with a sleep command, like:

  Code: Select all

    while some_global do -- some_global may be modified anytime
        someFunction( someArguments )
        -- hm.. this might need a wakeUp() function too.. ?
        sleep( some_amount_of_seconds )
    end

  a sleep() would be more versatile, methinks
• (yeah, you know, just added it for completeness)
  a way to enumerate users. perhaps a linked list would be memory efficient: client:getFirst and client:getNext()
  PtokaX will use an array of strings for this if I'm not mistaken. fixed by foreach
• SendPmToAll(), it's not really that needed, a hubMessage() works just fine, but some scripters and Mass-Message junkies can't seem to live without it. the following suggestion would elimate the need for this though: fixed by foreach
• client group objects, like getGroupByLevel( lowest_level[, highest_level] ), which would return an object with the following methods:
  send( data ), privateMessage( data ), hubMessage( data[, from] )
  for emulating SendToOps() there would exist a need to find out which level has operator status, but this is not really needed (OP status being almost obsoleted and all) fixed by foreach

hm.. most things here will require more than a little work. sorry about that :)

[edit: moved some stuff around]
[edit: changed things fixed in 0.16,0.17]
[edit: highlighted stuff that I find important]

[Sedulus]

LuaScript:

• a way to talk to OpCom from within the scripts.
  
  what would be a nice way is having the scripts call events in other plugins.
  like:
  
  create a fake client object, and then call the other plugin, like:
  
  local opcom = dchpp.getPlugin( "OpCom" )
  opcom.clientMessage( fakeclient, "+banip "..some_ip )
  
  in theory this sounds possible and is both clean and very extensible.
  
  if scripts were to be able to be called too, they would need some kind of registering method. like dchpp.registerPlugin( "my_own_script" )
  
  
  if this is hard/impossible/creates bloat, then it would imo be best if OpCom was extended with some features,
  or of course if you know some other neat way to do this

OpCom:

• +kickban <user> <time> [reason]
  to kick someone with a reason and ban them for the specified amount of time at the same time
  implemented in 017 with ban descriptions, people get to see why they were kicked in the you-are-banned message
  
• a description in both IP-allow lists and IP-ban lists.
  (like: <IpRange ..... Description="[tue]arse, progra~1+windows dir">)
  
  first of all, it would be nice if you could lookup why you kicked someone for the specified amount of time.
  
  second, ip allow lists can grow large quickly, and would need extra book keeping
  
  third, for ip allow lists, so you could specify forced network prefixes for nicknames (i.e. 10.0.0.0-10.255.255.255 -> [LAN]someuser, 11.12.13.0-11.12.13.255 = [SomeNet]someotheruser)
  added in 017, thanks arne :)

Core:

• the times() function still doesn't work. the hub reports 03:16 cpu usage, while it is 0:06+3:16+7:35. the fix didn't work =)
  times() has been removed (only for linux?) in 017
  
• I've had trouble with registered bot names not unregistering.
  
  since the PtokaX interface does not have a shutdown() event, the following occurs:
  at every +reload the bot name registers and we send a $Hello
  then: removeNick() doesn't work.. it seems like the hub keeps a stack which has to be emptied..
  so the nick disappears first after you've called removeNick() as many (?) times as you added it with addNick().

[edit: marked things fixed in 017]

[Sedulus]

LuaScript:

• in dchpp.clientPrivateMessage( client, to, data ), data contains "[Rug.nl]Sedulus $<[Rug.nl]Sedulus> my message" instead of "<[Rug.nl]Sedulus> my message" posted in "bugs 0.17"

[edit: mark]