This doesn't seem to affect the /LUSERS count for IRC operators - services clients still are included in the value.

I've found that if I comment out the "OPERTYPE" lines for both the services and BotServ clients in this module, it seems to work - must be specifically related to InspIRCd, as this adds +o regardless of the modes you set initially to any pseudo clients. A workaround would probably be removal of this mode after the OPERTYPE is sent. Not a huge issue, as its only a cosmetic one.

Otherwise, this module is looking like a winner - excellent work. Will it remain a third-party module, or do you reckon it'll eventually be included in the official distribution?

We discussed this feasibility some time ago and it was decided at that time that keeping it as a third party module was wise because we don't actively add 'features' to our stable releases and something this new needs to be tried and tested by a much larger userbase before it would be considered for inclusion.

Fortunately given the ease of installation this shouldn't be a problem to provide separately.

Fixed a segfault that occured when using OS KICK on a services pseudoclient, added a check to make sure TS6 is active and it should complain less about inspircd s2s messages anope doesn't care about..

I did NOT fix the issue above reported by Sm0ke0ut as I have been unable to reproduce this or find anything wrong with it. If someone else has experienced the same issue or finds a way to reproduce, let me know.

That was actually a bug in anopes TS6 support... I fixed this in SVN so recommend all people running this module to update to latest SVN.. The next version of the protocol module will require it anyways!

Looks like I've found another bug. Seems to trigger when I delink an additional server.

To reproduce the error, you need to link an additional server to your network, then remove it by terminating its process. Services will SQUIT after the delink of the additional server. I've noticed that in some occasions, you need to SQUIT the additional server more than once (a second time should do the trick) to trigger this bug.

I'm using the latest SVN of Anope 1.8.* and version 0.8 of your module.

Services doesn't give any reason why it stops - it just stops dead in the water. Normally I would be able to give you logs, but even in debug mode there isn't anything other than the other server leaving the network.

The IRCd handles the user and channelmodes +R.. Anope simply marks a user a registered by setting +r and setting the metadata for the account name. After that everything is handled by InspIRCd. And this particular message - though I d have to look this up - might not even be send by InspIRCd, but is likely send as a numeric, which the users' client then translates into a message in the users set language.Anope isn't even informed of this kind of stuff..

This fixes a number of issues of which the most important are: - session tracking: when killing clients on servers other then the uplink the user was not deleted. - fixed KILL syntax - fixed issue where people would be able to take over other nicks while services are down. the protocol module now uses the metadata to auto-ID users instead of the +r usermode.

Upgrading is recommended, but keep in mind because some changes are quite big it s possible some new bugs might have slipped in...

Also, for now, you will need to modify the anope core before you can install the protocol module. In the archive is a users.patch which must be applied to svn (2452 or newer), or simply replace the src/users.c in anopes source with the one in the archive (this is for svn 2452). If the core changes are stable, I will commit these to SVN so you won't have to patch the core again in the future..

Might I suggest adding usermode +k to each of the pseudo clients. It'll protect them from being killed from the network (like UnrealIRCd's +S) - also seems to add a 'is a <network> Service' to WHOIS output.

With the release of InspIRCd 1.2.0 I think the time is right to release version 1.0 of my protocol module. I now consider the module to be stable and suitable for use on any production network.I dare even say this module is more flexible then the one that ships with Anope-1.9 though more exotic setups are much less tested and may still be prone to a few bugs. The module *should* detect the presence of InspIRCd modules such as m_chanprotect or the disabling of halfop, but this is still largely untested.

I looked into this, but I can't do this (without making the module a requirement) for the version I release for Anope without more changes to the core. The module can be easily edited to include the +k user mode though for those that wish to use it.

I do have a slightly improved version of the InspIRCd protocol module which dynamically detects m_servprotect and adds the +k usermode, however it requires you run a more modified version of Anope. If you want to try it, you can find my modified version of anope, incl the protocol module and core changes in my git repository's master: http://vips.hopto.org/git/?p=anope/.git;a=shortlog;h=refs/heads/masterNote though that it does include other patches, such as the -1 access level for unregged users, and more (ex nefarious support) may be added later on depending on my needs...If you just want the changes required to anope and the "regular" protocol module look here.

Since I've been building Anope releases (mid 1.7.x) I've always built them with VS 2005 and have no plans to change this as it would mean everyone having to update their VC++ runtimes if they hadn't already.

Several module authors though have compiled their modules with VS 2008 which has already forced the above but I see no reason to change the default build.