Forums Active Threads Past Year

Thanks for your bug report. I use mIRC via Remote Desktop all the time and have not come across this so far. There are so many reports of Remote Desktop freezing issues on Google that it is hard to know what the cause is. Microsoft has fixed issues with Remote Desktop freezes in Windows 10/11, so it could be related to that. I would really need a reliable method to reproduce this in order to track it down.

Thanks for your bug report. I have added support for this in the next beta.

I wish sir, not I want. I'm here to try to learn. And I thanks You again for support, sir
When a user join or already joined in my channel:

1 - it may use registered nick (on /whois we can see---> <nickinuse> is identified for this nick).
2 - it isn't using a registered nick (on /whois we don't have ---> <nickinuse> is identified for this nick).
3 - when a user is joined with a registered nick, it may change in a unregistered one.

So I wish (always if possible) , a nick checker, i.e.:

1 - ON JOIN everyone (op included) #channel: if is registered with /ns , then nothing happen
2 - ON JOIN everyone (op included) #channel: if nick is not registered with /ns , it receive a warn after 10 seconds, then a kick after 60 seconds;
3 - ON newnick (nick change) , everyone (op included) #channel: if new nick is not registered with /ns, it receive a warn after 10 seconds, then a kick after 60 seconds;

If it join or change with a registered nick but not identified, is solved with Your wonderful creation, because it'll be changed in a guest nick (MindUser*****) by the server, and Your script is ready to act and wonderful working (I never stop to thank You , sir)

I hope I been more clear sir.

Okay, so this is related to $bvar() when N,M is used. Looking at the code, there is an strlen() in the loop which would likely cause an issue for long strings. This has been changed for the next beta.

In case you're just having trouble using just the 1 network, here is the instructions for trying to connect to Libera.chat

https://libera.chat/guides/connect

The Tor instructions are further down on the page, and hopefully they give you enough clues to figure out what your problem is, and then you can post to the forum once you figure out how to do it right

They only have 1 server that lets Tor connect, and because of abuse they require you use a mirc-options/connect/options/SSL client certificate, which means you need to first connect there to register a nickserv account, and then be connected in order to attach the certificate's fingerprint to your nickserv account, which are 2 things you can't do from a Tor connection, which means you're leaving a record of the true IP address which 1st connected using that certificate, though I guess maybe you could do that from a friend's house or from a fastfood wifi hotspot.

Well, I guess you don't have to actually be connected using the client certificate in order to add its fingerprint to your nickserv account, as long as you're logged into nickserv, so you could login at someone's house and copypaste the certificate fingerprint hash there, without actually bringing the certificate there.

I reported that to Libera as a security hole, but they don't consider it a problem, though they seem to be the only network I've yet encountered which does not require you to use a certificate to connect to them while adding that fingerprint to nickserv.

If you're concerned about having some networks that you connect via TOR while other networks you don't use Tor, mIRC now allows you to have a per-network client certificate so you're not needing to use the same fingerprint from a Tor and non-Tor connection. Though you would probably want to have mIRC installed into 2 different folders, 1 for Tor and 1 for not-Tor, and not login to the same nickserv account from both.

mIRC only supports 1.1.1 versions of OpenSSL.

Quote from the change log:


You will need to wait for Khaled to add support for 3.x.

Side note: Your filenames include "x64" which implies 64bit file. mIRC is 32bit and trying to load a 64bit DLL into a 32bit EXE will not work anyway.

Is ok /notice,no boring in chan. Thanks again sir

The /help Key Combinations
page can be fleshed out with missing hotkeys. I looked to see if the ctrl+shift+del window mentioned by eahms was there, and found it wasn't the only thing missing

alt+A / alt+J / alt+D for favorites and/or aliases
alt+B addressbook
alt+C chat
alt+E server-connect window
alt+I online timer
alt+K colors
alt+L channel list
alt+N Notify list
alt+O options menu
alt+P popups
alt+R script editor
alt+S dcc send
alt+U toggle Urls

Some navigation keys are missing or incomplete.
For Ctrl+Home and Ctrl+End the description reads as if it applies only to the editbox, but is in a section outside of "Editbox keys". And then a lot of editbox and script editor navigation keys are missing, such as Ctrl+Backspace, Shift+Home/End, shift+leftclick, Ctrl+Left/Right Arrows, etc

I'm used to seeing these described as arrow, so took me a little bit to figure out what 'cursor' meant here, since that usually means the position where the cursor is blinking. Likewise figuring out that 'copy' in several places means 'holding the left mouse button down'

For the items explained in other pages, can simply have a hyperlink instead of repeating the description

(1) Can [recent] be given the same behavior as [channels] by allowing it to be edited by Notepad or writeini/readini?

(2) And can the behavior of [recent] be modified so that joins due to Favorites autojoins or "keep channels open" or "rejoin when kicked" be exempt from affecting the [recent] list?

Either that, or change the max number of channels in the Favorites List per-network to be increased above the current 20, based on how many channels at that networks are being autojoined.

--

The Favorites list in mirc.ini [chanfolder] and channels.ini [channels] has always been able to be edited with Notepad or /writeini or /remini, and the changes are immediately seen and honored by the Alt+J manager, and the edits stay there when the manager writes its own changes to disk.

But doing the same kind of edits of the new [recent] or the old [chanfolder] doesn't show in the tools/favorites/history listings, and the edits are all gone from disk the next time a channel-join gets added to [recent] or exiting mIRC.

By being able to edit the [recent] list the same way the old [chanfolder] and new [channels] can be edited, a script can make the [recent] list more useful. Such as letting someone script something to remove the active channel from [recent] after you /part it, or adding a join-recent popup in the channel window menu itself instead of using the top menubar/tools.

Also, it would enable scripting the selective deleting of test channels or typoes from history that now push something else off the [recent] list before it deserved. Or, being able to prune the freenode channels off the [recent] list, or zap channels from other networks that you don't plan to ever visit again.

This #2 change would also make the suggested join -h more effective, and is described in more detail in that post.

While the top menubar currently has a "clear history" choice, that wipes the entire list, so the only other way to remove selected channels from [recent] is to edit the list while mIRC is not running.

/join -h switch
/part -h switch

The usefulness of these switches partly depends on other behavior changes suggested for the [recent] list and [channels] favorites list as suggested separately and also described below.

--

/join -h #channel would allow Joining a channel without adding the channel to the [recent] history or moving it to the top of the [recent] list if it's already there.

/part -h #channel would Part the channel and then remove it from the [recent] history list. If the suggestion of being able to edit the [recent] list is granted, then /part -h could also be scripted as a channel-menu popup, and a limited amount of the /join -h behavior could be scripted, except for a race condition between autojoin adding things to the list that /join -h was trying to prevent. An optional behavior for /part -h could be to remove a #channelname from [recent] history even if you're not in it.

These would also work more effectively if the other suggestion post goes into effect - that adding/updating the [recent] list not be done when the join is caused by autojoining from Favorites list, or from "rejoin on connect", or "rejoin when kicked", in order to expand the usefulness of the [recent] list without expanding it.

--

From observation, it looks like the [recent] list works by adding/moving each channel join to the top of the list each time the channel is joined, and it limits each network to having max 20 spots on the list. If there's a combined max total for the entire list, I've not encountered it yet.

So the only time something gets dropped from history is when there's already 20 spots taken by that same network when you join a channel not already in history, which makes the lowest channel for that network get dropped, not necessarily something near the last item in the entire list.

This also means that if you join some network and you then join a channel there, but then never visit that network again, it doesn't look like there's a way for a network having gained N channels on the [recent] list to ever have that count decreased without zapping the entire list from /tools/favorites/history/clear

--

Joins added to the [recent] list or bumped to the top of the list include those generated by being autojoined from the favorites list, plus those generated by tools/options/irc/ "rejoin on connect" in combination with "keep channels open on disconnect", and those generated by "rejoin when kicked".

It is useful to add to the [recent] list for joins due to checking the box for "autojoin when invited", but I'm not so sure if there's a need to add/bump-up channels in the [recent] list if the join is caused by the above 3 situations.

Most of the usefulness of the channel history would be for channels you manually joined or from "auto join on invite".

If the user wanted to find channel history for the channels in their autojoin list, they could be found in the favorites manager from where they autojoined them. If the channel is listed in Favorites without having 'autojoin' checked, then yes it's fine to add it to the [recent] list.

If the join is happening due to the window being kept open during disconnect/reconnect it shouldn't need to be updated/bumped-up since it's not really a manual join.

--

A example situation where the current behavior fails:

Assume someone always autojoins 21 channels on a network. This fills up that network's quota of 20 on the [recent] list, and the first of the autojoin channels get pushed out, and no manual joins ever survive the next reconnect to that network.

If they autojoin 15 channels, the top 15 spot get churned each time they reconnect, and there's only 5 spots left for everything else.

If they're in 20 channels and have both boxes checked 'rejoin on connect' and 'keep channels open' in Options/IRC - if they then manually join a 21st channel which adds it to the top of their [recent] list and then /part it, the next time they reconnect to the network, that 21st channel gets pushed off the [recent] list by the 20 channels they're already inside that get rejoined on connect simply because the #window was open - even if the Favorites list doesn't have the autojoin box enabled.

It seems more useful for the [recent] list to not be updated due to something that rejoins a #window that's already open.

If the favorites-autojoins and rejoin-on-connect/kick stopped being added to history, that avoid the autojoins filling up that network's quota of 20, which makes the [recent] list more useful without enlarging the network quota based on how many autojoins it has.

--

If the Favorites List and "keep channels open" continued the existing behavior of adding/updating the [recent] list, "join -h" would allow several workarounds which could produce the same effect.

One workaround would be for someone to script their own autojoin script that uses join -h to keep the autojoins from filling up the [recent] list.

The other workaround would be to continue using the favorites list, but uncheck the manager's main window box "enable join on connect". They could then have their autojoin script parse the favorites list near ON CONNECT looking for channels at the current network who have the 'join on connect' box, and the script could then use /join -h against them all.

If the "rejoin on connect" option continued to bump channels to the top of the list when they rejoined a kept-open channel window, both workarounds would also need to uncheck the 'rejoin on connect' box while continuing to have "keep channels open" checked, and then during ON CONNECT have their script look for open #windows needing to be rejoined with /join -h

Yes grasshopper, hashtables are great. You can control when/if they're written to disk, so can avoid the need to clear the /set -e %variable from vars.ini should windows crash without getting a chance for ON EXIT to sanitize it. Plus the the /hadd -u999999999 item equivalent to /set -e %variable won't be written to disk unless you specifically use /hsave -u
I've seen cases where it can benchmark faster to use a hashtable instead of a local /var because you don't need to use the [ square braces ] to create compound itemnames in a hashtable that are built from combining $network,$chan,$nick etc

You can't quickly hunt down global variables based on their contents, but is easy to do with hashtables.

The big case where you can't use hashtables is when there is so much data that it can't fit in memory, such as in a !seen database that's been built up over years or is in busy channels

Thanks for confirming. So this is the same issue we've seen in the past where, for some users, Windows is force-closing mIRC before it has a chance to finish updating mirc.ini.

Yes, I was testing in Windows 10 in this case. But the notifcation settings are more or less the same in Windows 11.

My copy of Windows 11 found another update and it is now the same as your version. I am seeing the same issue as you in this version of Windows 11.

After spending the last few hours testing it out, it looks like the latest Windows 11 update has broken all of the standard methods that are widely used to get information about the tray area. mIRC actually has four different implementations for this - each using different APIs. It was using the simplest method, which previously worked on all versions of Windows. None of the four implementations work on the latest Windows 11 - even the most basic API calls fail.

It's difficult to say exactly why these methods are no longer working - it could be that Windows 11 is using a stricter security model that prevents Win32 applications from accessing this information.

In any case, I also noticed that Windows 11 allows you to hide the hidden tray area. This means that if mIRC is minimized to tray, and Windows places it in the hidden tray area, and the hidden tray area is hidden - you will simply not be able to access mIRC. And since there no longer seems to be a way for an application to determine whether its tray icon is hidden or not under Windows 11, this undermines the use of the tray area for applications that have a "minimize to tray" feature.

I am going to remove support for the "tip" warning that mIRC is minimized to the tray, since there does not seem to be a way to make this work correctly any more in Windows 11. This change will be in the next beta.

Update: It looks like this issue is due to Microsoft changing core parts of the Windows interface to XAML controls. The tray information should still be accessible, using WinUI and XAML via Win32 applications but C++ examples are sparse. All applications that previously needed to read the contents of the tray are now broken and need to be updated for the latest version of Windows 11 but still need to use the older methods for previous versions of Windows.

The Clear History feature on ctrl + shift + del like a browser is an awesome feature, I use it every time I close mIRC because I always go back to my default, archived and backed up settings, in fact, would it be possible to have an "autoclear on exit" check box (unchecked by default)?

Thanks.

Not seeing any PM's here

In addition to https://forums.mirc.com/ubbthreads.php/topics/271330/re-ial-me#Post271330 where having $ial($me) be persistent would allow setting ialmarks against yourself earlier and in more situations....

Ideas below are based on things I was encountering in trying to use ialmark for
https://forums.mirc.com/ubbthreads.php/topics/271388/re-nick-checker#Post271388

• 1. The messages displayed by /ialmark are confusing to someone who's trying to understand how to use the command
  
  //ialmark $me foobar
  * Marked maroon 'default' 'foobar'
  
  suggested change:
  * Marked maroon 'default' as 'foobar'
  
  The message is often deceiving about what the command just did. The 2nd command of both pairs below shows a message as if it's *doing* something when it's not - it's simply displaying whether the label has a .mark attached to it or not, even though it shows the identical message.
  
  //ialmark -r $me
  * Unmarked maroon 'default'
  //ialmark $me
  * Unmarked maroon 'default'
  
  //ialmark $me foobar
  * Marked maroon 'default' 'foobar'
  //ialmark $me
  * Marked maroon 'default' 'foobar'
  
  Suggestion: These should not show the same message as if these are 2 ways of accomplishing the identical task. When first using ialmark, I'd see a message saying that the command was removing the named label, and then later I'd repeat the same command, and couldn't understand why the named label was not being removed there too. The messages would be more helpful if they were something like
  
  //ialmark -r $me
  * Removed maroon 'default'
  //ialmark $me
  * maroon 'default' is Unmarked
  
  //ialmark $me foobar
  * maroon 'default' Marked as 'foobar'
  //ialmark $me
  * maroon 'default' is 'foobar'
  .
• 2. Syntax to remove the 'name' if the 'mark' parameter is blank. I was keeping a space-tokenized string attached to $me, and I was finding that
  
  .ialmark -n $me list %list
  
  ... behaved differently depending on whether the %list was blank or not. If %list was non-blank, it replaced the existing content of the named label, as expected. But if it was blank, it switches to the syntax for simply displaying the existing content of the named label - except because of using the silencing dot, it doesn't even do that.
  
  Suggestion: It looks like ialmark and $ialmark are not designed to have blank strings as the mark, as can be in hashtables, so it would be useful to have something like -nz behave as a conditional -rn if the there is no string being set due to a blank %var or $identifier return value. but otherwise would update/add the named label if there was a string to be set.
  
  //ialmark -nz $me list %list
  if (%list is non-blank) then is /ialmark -n $me list string-inside-variable
  if (%list is blank) then is /ialmark -rn $me list
  .
• 3. Similar to how -wn allows deleting named labels that match a wildcard pattern, allow a -W that matches a wildcard pattern for the nick. If I want to remove the 'registered' named label from all nicks, it would be faster and more straightforward to be able to do "ialmark -Wnr * registered" instead of looping through the 2600 nicks in my $ial, and could remove all marks from all nicks like "ialmark -Wnrw * *". This should be backwards compatible since * and ? are not valid in nicks.
  .
• 4. Since $ialmark syntax currently has parm1 being a nick, it could be backwards compatible to allow parm1 to be numeric N to find nicks having a specific named label attached to them.
  
  $ialmark(0,registered) = number of nicks having that named label
  $ialmark(1,registered) = 1st nick having that named label
  $ialmark(1,default).mark = for the 1st nick having a string attached to the default label, returns that .mark
  
  Unless there's some kind of behavior that should happen for $ialmark(1,1) (0,0) etc, they could return $null? Or is this getting too far into some kind of $ifind ...

Can you clarify if you're trying to get help with how to use mIRC or use Mibbit? I've not used Mibbit, so I don't know if they have a place explaining how to use it.
At the top of this website the link "Help" (not the lower help that explains how to use the forum) has quite a few links that include basic and more advanced topics. Including
https://www.mirc.com/ircintro.html
and
https://www.mirc.com/install.html
That top link is even intalled as a .chm file in the MIRC folder

If you want it to work with your own input, you can use the ON INPUT event handler to look for you typing 'ciao', as you can find in the F1 help or at

https://en.wikichip.org/wiki/mirc

Or is much simpler for you to create a custom alias named 'ciao', and then you can invoke it by typing /ciao in channel. Something like:


Or for this case, instead of looking at everything you type to see if it is '!countdown', you can create an alias like this that reacts to /countdown 5, and is my attempt to modify the existing script as little as possible


Reminder that the above doesn't work in the 6.35 you were first using because of how timers are handled there, as I described in the earlier post. Also, the above alias uses the newer $unsafe identifier that defends against strings created by not-you, which in this case is a channel name containing ,$word or ,%word which is extremely unlikely but can be a big problem if it does happen.

Assuming it's not needed, you can either remove the $unsafe( ) wrapper or you can add an alias that is ignored by newer mIRC that already has this built-in, but in 6.35 it would give most of the functionality of the $unsafe identifier:


But is a good habit to be in where you use $unsafe for strings that you did not create, as described in the above wikichip link for 'msl injection'

Update:

In addition to $read and /filter benefiting from case-sensitive searches, so could other text scanning functions like $fline and $hfind, which currently allow this only with regex patterns which many users are not familiar with and which comes with its own bag of special symbols.

--

For $hfind a 'c' switch could modify the 'nWw' to be case-sensitive matches.

--

For $fline which has a bitmask parameter for the switches, this could be additional bitmasks.

T parameter now:
1 = listbox
2 = regex
New:
4 = non-regex search is literal text
8 = non-regex search is case-sensitive
16 = non-regex search is substring match

Bitmask 4 would allow searching for 'hello?' without also finding 'hello ' and 'hello!' and 'hello.' and 'phellogen'

Bitmask 8 would allow searching for case-sensitive spelling of a word or wildcard without also finding case-insensitive matches

In effect, the missing functionality of operators like

if ($1 == hello?)
if ($1 === hello?)
if (%string iswmcs $1)
if (%string isincs $1)

If $fline used T=2 regex bitmask, either the T=4 bitmask should be ignored or a syntax error. T=8 could either be ignored or could disable the /i flag. Is probably simpler to have T=2 make it ignore T=4/8.

Update:

Though $hget could benefit from $hget(string).name to force it to always "Returns name of a hash table if it exists", the other $hget syntax doesn't handle numeric tablenames gracefully. While /hdel and /hadd correctly add and remove items from numeric tables, and /hfree 2 deletes the table named 2, the other hashtable identifiers do not handle numeric tablenames correctly.

Now:

$hget(2,1).item = 1st item of whatever is the 2nd tablename
$hget(2,string) = value of itemname=string in whatever is the 2nd tablename

$hget(0,1).item = ignores the 2nd parm and the .item property and always returns the number of tables
$hget(0,string) = ditto

//echo -a $hfind(2,*,0,w,echo -a $1) = lists all the items in whatever is the 2nd tablename

--

These identifiers could be handled by giving $hget an extra parm for switches that would force the 1st parm to be seen as a tablename, and giving the existing $hfind switch list an extra parm.

Assuming the new switch an arbitrary 'X'

For numeric tablename '2', it would still need .name to check for the table's existence, because $hget(2,X) would crash with current syntax which gets the value of itemname=X from the 2nd table in the list.

However $hget(2,itemname,X) could get the value of itemname from tablename=2, and $hget(0,itemname,X) would then look at the numeric tablename too. Or, instead of $hget(2).name to see if tablename=2 exists, it could avoid a new properity $hget(2).name when parm2 exists as null, $hget(2,,X) instead of adding $hget(2).name

The only problem I can see for $hget is that since existing syntax currently uses the 3rd parm only to hold the name of a &binvar, it would need to assume that parm3 beginning with & does not hold any switches so there would be no support for loading a &binvar from a numeric table - or else the switches would need to be in parm4.

--

For $hfind, $hfind(2,*,0,wX,echo -a $1) would force the 1st parm to be seen as a tablename.

Since $hfind already has the 'n' switch which behaves the same regardless whether using 'n' or 'N', maybe the new switch would be something like 't' that could be used with the same meaning for both identifiers?

Update:

From discussions in channel, I see now that I misread this thread, which explains my confusion over why it was named $timer().name, as I thought $envvar().name was added because of $timer().name rather than the other way around. Since .name for $envvar() has existed from the beginning, maybe the solution is instead a new+optional parameter that forces the 1st parm to be seen as a name rather than detecting if it's numeric, so $envvar(%string,n) would work as expected with .name and .value regardless whether the varname held in %string was text or 0 or positive-numeric.

This issue seems related to the other thread...

https://forums.mirc.com/ubbthreads....r-using-local-cert-by-default#Post270782


--

In this case, the GROUP parameter is remembered only if you DO use the server command to create a new window. To re-create:

1. Open new instance of mIRC, and it remembers the settings for the last server connection that was either created or closed. If mIRC closes in an orderly fashion, that will be the connection you use as $scon(1) since it defaults to closing them right-to-left, making the 1st connection be the one whose info is last written to mirc.ini. However this time I noticed a change in behavior because my computer had crashed, which resulted in mirc.ini not containing the info from $scon(1)

In this example, the only status window sees:

//echo -a network: $network servertarget $servertarget port: $port group: $server($servertarget).group target: $server($servertarget,1)

result:
network: Libera.Chat servertarget calcium.libera.chat port: +6697 group: Libera.Chat target:

(My serverlist has targets both for calcium and the round robin servers)

2. Now try to connect to a different network, using its serverlist groupname. In this example, I'm using SwiftIRC:

/server -g SwiftIRC

result: * Connecting to calcium.libera.chat (+6697)

3. Now try to do the same thing except doing it in a brand new status window

/server -n
/server -g SwiftIRC

result: same, except is now trying to connect to Libera's roundrobin instead of calcium, I'm guessing it cloned the $network from 1st window, but not $servertarget too

4. Now use -m to do the same thing:

/server -gm SwiftIRC

correct result: * Connecting to irc.swiftirc.net (+6697)

If I try to use this new connection like /server -g UnderNet
it again ignores the Group and tries to connect to the current network, SwiftIRC, instead.

The current workaround to the -g GROUP parm being ignored is something like:

doesn't work: /server -g GroupName

workaround for correct result: //server $server(1,GroupName)
... which returns the 1st $servertarget in the serverlist associated with that Groupname

maroon, that is SUPER helpful. Thank you so very much! Appreciate it a lot!

$ini(file.ini,N).name
$ini(file.ini,section,N).name
$ini(file.ini,section,item).value

There currently is no support for locating whether a numeric [section] or numeric item= exists without a bruteforce loop searching for it. While you can try to use $readini(file,section,123) to see if item= named '123' exists, that only works if it has a non-blank value, and does not work with /writeini -z delme.ini section 123

This would make a way for $ini to be compatible with /writeini and $readini who currently handle numeric [section] and item= parameters as if they are literal text strings.

//var %section 3 , %file delme.ini | .remove %file | writeini %file section1 item value1 | writeini %file %section item value2 | echo -a : $qt($ini(%file,%section)) vs $qt($ini(%file,2)) $ini(%file,section1) vs $readini(%file,3,item)

result: : "" vs "3" 1 vs value2

--

Closely related to this, it would be much more streamlined for scripts to be able to use $ini to obtain the item values the same way it gets the item names, without needing an additional disk read to $readini. To avoid ambiguity, unless there are going to be additional propertynames, .value should treat numeric section and item parameters the same Nth-in-list way it currently does when not using any .property.

//var -s %t $ini(mirc.ini,logging) , %i 1 | while (%i <= %t) {
now: echo -a %i: $readini($mircini,nt,logging,$ini($mircini,logging,%i))
new: echo -a %i: $ini($mircini,logging,%i).value
inc %i }

I don't see the need to give $ini the behavior of evaluating %word and $word or handling piped commands in the =value since can use [ ] if needed.

--

The intent of $ini(file.ini,N).name would be to return the Nth position of the numeric item name, the same way that $ini(file.ini,text) does, and that $timer(123).name does.

A design decision would need to be made how to handle $ini(file.ini,12,34).name and $ini(file.ini,12,34).value where it's possible for 2 parameters to be numeric.

Unless there is also a .namevalue property, I believe it would be simplest to have $ini(file.ini,12,34).value behave the same way $ini currently handles numeric inputs without the .value property and treat all numeric inputs as the Nth position, except for returning the value of the 34th item in the 12th section.

For $ini(file.ini,12,34).name it should always return the position for the 34= item if it exists. But a design decision would be needed whether the 12 should always be the Nth section or the name of a section.

The latest beta can be downloaded here and includes the following changes:

update

I see now that versions.txt says you can make an autocolor rule by using * as the color number, but doesn't actually work:
/cnick foobar *
* /cnick: insufficient parameters