Release Notes for EPIC5-2.1.1 (Released: 2019-02-24) *** News 02/24/2019 -- EPIC5-2.1.1 released here (Abulia) (Commit id: 1899) *** News 02/05/2018 -- CTCP UTC now implemented as script Given the below feature, CTCP PING support has been rewritten, and CTCP UTC is now scripted. *** News 02/13/2018 -- New flag for $ctcpctl(), "REPLACE_ARGS" There are actually two kinds of CTCPs that replace things * CTCP PING replaces its argument(s), but is otherwise handled "normally" NOTICE nick :\001PING \001 becomes NOTICE nick :\001PING seconds\001 * CTCP UTC replaces itself entirely: PRIVMSG nick :\001UTC 1518582810\001 becomes PRIVMSG nick :Tue Feb 13 22:33:30 2018 So it's not enough to say that "a CTCP handler can replace itself by returning a string", you need to be able to say whether this CTCP replaces its arguments only, or whether it replaces itself entirely. * $ctcpctl(SET REPLACE_ARGS 1) * $ctcpctl(SET REPLACE_ARGS 0) Select whether or not a CTCP handler that returns a string replaces its arguments (like CTCP PING) or replaces itself entirely (like CTCP UTC). The default is 0 (replace entirely) *** News 02/05/2018 -- Some CTCPs are now implemented as scripts YOU NEED TO START DOING /LOAD ctcp IN YOUR STARTUP SCRIPTS. One of the larger projects in EPIC5 was to move as many hard coded things into scripts as was feasible, so you, the user (or the script you're using) can have as complete control over them. We've moved a lot of functionality out into scripts. Traditionally those users who don't have startup scripts (~/.epicrc or ~/.ircrc) get /load global as their startup script. One of the things /load global does is /load builtins which brings in the scripted features. Now /load builtins will /load ctcp, which implements these core CTCP functions entirely in ircII, so you are welcome to modify or remove them, as _you_ choose. VERSION PING ECHO CLIENTINFO USERINFO ERRMSG FINGER TIME Maybe more will be migrated in the future. But this is a good start for now. This is also a great example of how to build your own first-class ctcp handlers! *** News 02/04/2018 -- User-defined CTCP handlers with $ctcpctl() You can now create your own first-class user-defined CTCP handlers. A CTCP handler is a block of code that takes four arguments: $0 - The person making the request $1 - The target of the request (you, or a channel you're on) $2 - The CTCP that was sent $3- - Arguments (if any) to the CTCP A CTCP request handler is a CTCP handler that handles incoming requests (over PRIVMSG). A CTCP request handler can either (1) generate a response or (2) substitute something. A response can be generated with: /CTCP $0 $2 Your Response Here A substitute string is /return'ed by your handler, and replaces the CTCP in the original message. A CTCP response handler is a CTCP handler that handles incoming responses (over NOTICE). A CTCP request handler can either (1) Output the response in a special way or (2) substitute something CTCP response handlers are unusual, because the ordinary handling of CTCP responses is the expected behavior. Syntax: * $ctcpctl(SET REQUEST {}) Register as a CTCP handler for requests. * $ctcpctl(SET RESPONSE {}) Register as a CTCP handler for responses. (Note -- handling responses is unusual. Normally you just let the client output responses in the ordinary way) * $ctcpctl(SET DESCRIPTION ) SET as the CLIENTINFO for . That is, when someone does /CTCP CLIENTINFO , will be returned as the description for this CTCP. * $ctcpctl(SET SPECIAL 1) * $ctcpctl(SET SPECIAL 0) Enable/Disable a CTCP as being "Special". A "Special" CTCP is a remote function call, and handles everything itself. There are only two "special" CTCPs -- ACTION (/me) and DCC. I'm not sure if anyone will create a "special" user-defined CTCP * $ctcpctl(SET RAW 1) * $ctcpctl(SET RAW 0) Enable/Disable a CTCP has requiring the "raw data". Ordinary CTCPs transport strings, and they have to be recoded according to /encode-ing rules. But some CTCPs transport binary data, and so the handler needs access to the raw binary data. Ordinarily, the raw/binary data is CTCP encoded, which mens you can pass it to $xform("-CTCP") to recover the raw bytes (although it might not be a C string, so you can't assign it to a variable.) There are corresponding GET operations for the above You can get all the registered CTCPs with * $ctcpctl(ALL) Very soon, quite a few CTCP types will be migrated out to a script that will be /load'ed from /load global, and you may have to add it to your own start scripts if you do not /load global. I need to write much better examples for all this. To look at this you'd scratch your head and wonder why you care. But being able to add new CTCPs instead of requiring them to be written in C in a new version of epic is expected to help a lot of people. *** News 01/16/2018 -- New status expando %{1}P ("status prefix") and variables The %{1}P value will expand to a "when window current" or "when window not current" value. The idea is to put this at the start of your /set status_format or /window status_format type variables. When a window is current, %{1}P will expand to either /window status_prefix_when_current or /set status_prefix_when_current When a window is not current, %{1}P will expand to either /window status_prefix_when_not_current or /set status_prefix_when_not_current You can use this all in your ~/.epicrc, like so: set status_format %{1}P%T [%R] %*%=%@%N%#%S%{1}H%H%B%Q%A%C%+%I%O%M%F%L %D %U %W set status_prefix_when_current ^C37,40 set status_prefix_when_not_current ^C37,44 which will make your status bar white-on-black when current, and white-on-blue when not current.