Anope IRC Services
Anope Development => Modules => Topic started by: nucleus on December 08, 2006, 01:48:47 PM
-
ns_ajoin.c:1: error: syntax error before "module"
make[1]: *** [ns_ajoin.o] Error 1
make[1]: Leaving directory `/home/about/anope/src/modules'
make: *** [modules] Error 2
Can someone please tell me whats the problem here ?
How can i fix it
thx
-
is that module from the Anope Modules Site (http://modules.anope.org) ?
-
Originalno postavio/la n00bie
is that module from the Anope Modules Site (http://modules.anope.org) ?
Yes
-
open the file/module ns_ajoin.c which youv'e downloaded and you will see that it is written like this...
This module has been removed due to bugs in the original version. If you wish to maintain an updated version of this module please contact heinz (http://modules.anope.org/profile.php?id=7).
-
Originalno postavio/la n00bie
open the file/module ns_ajoin.c which youv'e downloaded and you will see that it is written like this...
This module has been removed due to bugs in the original version. If you wish to maintain an updated version of this module please contact heinz (http://modules.anope.org/profile.php?id=7).
I see i contacted heinz
thx
-
The original version has major issues, so there's no point in having it. The current file says "If you want to take over development" to contact me.
-
The Module ns_ajoin works not whit 1.7.18 Please Update this Module
-
a new ns_ajoin is being work on... :)
note though that i m writing a completely new version, not an update or so that would still use most old code. therefor my version will be incompatible with the older version. i prefer using no mysql so will store everything in .db's
-
I eagerly look forward to and anticipate your new ns_ajoin Viper ;-)
-
thx viper
-
When is this Module released?
-
when it s finished, or at least finished enough to do the basics it s supposed to do.
i haven't been able to work on it for 2 weeks though. The box hosting my testnet died... motherboard died, so i can't even test it at the moment... can't expect me to publish code that hasn't been tested at all... it might not even compile atm...
i got a new mobo and cpu for it now, but suse doesn't want to mount the partitions, so i ll prolly have to reinstall everything.. gonna take some time.
[Edited on 15-1-2007 by Viper]
-
for those interested, i did find some time to work on it and almost have it to the point where it s working and ready to be considered beta....
for those interested: http://vips.hopto.org/~viper/ns_ajoin.c (DONT USE THIS ON A LIVE NET!!!)
it will crash services upon unloading and contains a lot of debug alog()'s in the db saving routines!
for some weird reason the database saving routines work properly for an /os update, yet crash services and fail to save when unloading the module... for some reason the pointer to the next struct gets messed up... haven't been able to figure that one out yet... may take some time (still got exams 2)
just thought i d let ya know cuz i ve been silent for a month :)
-
You haven't been silent for a month... I just talked to you about it like 2 weeks ago ;-)
-
Any news Viper?:)
-
Originally posted by Armadillo
Any news Viper?:)
Viper will post an update when he has something worth reporting, please stop hounding him for an update, it's annoying and doesn't make him code any faster.
-
That was a nice meant question, so why the hell do you react in that aggressiv way? I only wanted to knew if there is any change or not...
-
Originally posted by Armadillo
That was a nice meant question, so why the hell do you react in that aggressiv way? I only wanted to knew if there is any change or not...
My reply was just as nice as yours.
Also, regardless of how nice you ask, repeated inquiries regardless of their source or intention still get annoying. I really meant what I said, when viper has something to talk about .. he will ;)
-
last time i looked at it, i still couldn't get past the issue where it made services crash during unloading... the same piece of code to save the db worked fine during normal operation though.
But since i m on erasmus in helsinki atm, it s needless to say that i have other things to do atm. This module s back on the shelf till i have either a lot more time (prolly not before i go back home in 2 months), or i get some bright idea as to what s causing it (even more unlikely..)
So yea... i just have nothing to talk about :)
-
well... i finally have news... a working development version of ns_ajoin. :)
I consider this to be a beta and no longer a highly unstable alpha like the previous draft i posted here a few months ago...
But just to remind you... this is not supposed to be used on a live network unless you don't care that much about stability...
Though it shouldn't be run on a live net, i would need a few people to test it and report their findings as well as any bugs they can find back...
Source: http://vips.hopto.org/~viper/ns_ajoin.c
This version should have everything in it that should be in it and that was available in previous ajoin modules. It uses .db files instead of a mysql database so no need to start messing with sql.
Note that it requires Anope-1.7.19 (or higher) or an SVN version higher then revision 1231.
[Edited on 26-7-2007 by Viper]
-
Viper you could always make the module check for the version in AnopeInit and MOD_STOP if it fails. Code follows: (Lets say you need svn r1256)
if (!moduleMinVersion(1,7,19,1256)) {
alog("Your version of Anope isn't supported.");
return MOD_STOP;
}
Thank you for the update! :)
-
ahhhh i asked something like this on irc but there wasn't anyone around who knew how it could be done...
thx a lot
-
Newer version (V4.1.7) available. Contains fixes for 2 crashbugs. (thx to n00bie for reporting them).
Source: http://vips.hopto.org/~viper/ns_ajoin.c
Changelog:
* Fixed crashes in ajoin add/del
* Added Anope version check
* Default ajoin flags moved to a const
* No longer storing empty entries with default configuration to the DB
-
The AJOIN event seems to join channels BEFORE the client's vHost is set. My suggestion would be to tie the internal event to the IDENTIFY command, instead of the internal EVENT_NICK_IDENTIFY one.
-
hmmm i see... hadn't noticed that yet
i d prefer to avoid to "tie" to the identify command since i d have to perform all the same checks that will still be performed by the identify command, thus doing double work. I wonder whether this couldn't be considered a "bug" in anope.. i would expect the identify command to have finished its work when it sends the event, yet the event is send a while before the end of the function...
-
ok I could be wrong and any coder can correct me :). but 3rd party modules are triggered on events before the core is, this is to allow 3rd party module intervention otherwise you would have the core denying access or other reactions prior to the module that has been written to change the behaviour of the command/feature in question.
Alternately, a callback could be used to add a dely to ajoin although the callback wouldn't be able to copmensate for latency.
-
well as i see it, the event should be send after the identify is completed. The core in this specific case sends the event before applying the vhost. And since the vhost is assigned by the same code that deals with the identify, it s not possible for a module to change this behaviour by for example returning MOD_STOP in the event.
...
}
}
send_event(EVENT_NICK_IDENTIFY, 1, u->nick);
alog("%s: %s!%s@%s identified for nick %s", s_NickServ, u->nick,
u->username, u->host, u->nick);
notice_lang(s_NickServ, u, NICK_IDENTIFY_SUCCEEDED);
if (ircd->vhost) {
do_on_id(u);
}
if (NSModeOnID) {
do_setmodes(u);
}
...
Just seems a bit weird to send the event in the middle of the function...
Then again if it was send at the end, modules like cs_accessfounder wouldn't be able to have the correct modes set automatically in one line.. so i guess it just depends on what you want to do with the event.
nvm me :)
doesn't matter that much anymore either, already hooked it to the identify command instead of the interal event :)
-
EVENT_NICK_IDENTIFY is likely sent at EVENT_START as with other events. Which can be useful in some instances where your module is attempting to block a users actions such as joining a forbidden channel.
-
Released v4.1.8 which fixes the earlier mentioned issue. The module now also performs the ajoining upon UPDATE.
The module has now been published on the modules site (http://modules.anope.org/viewmod.php?id=96) since I think it should be stable enough for use on production networks.
Which can be useful in some instances where your module is attempting to block a users actions such as joining a forbidden channel.
Yea, like I said, like it s send, it s useful in some cases, just didn't turn out to be in mine :)
-
Great stuff! Module works like a charm. Well done! :P
-
Services tends to segfault whenever a non-registered nickname attempts to use any of the AJOIN commands though.
I'm using Anope 1.7.19 with UnrealIRCd 3.2.6 on a Debian Linux system.
[Edited on 14-8-2007 by CuttingEdge]
-
Originally posted by CuttingEdge
Services tends to segfault whenever a non-registered nickname attempts to use any of the AJOIN commands though.
I'm using Anope 1.7.19 with UnrealIRCd 3.2.6 on a Debian Linux system.
[Edited on 14-8-2007 by CuttingEdge]
[18.39.16] * Your nick is now blahblah
-
[18.39.19] -NickServ- Syntax: AJOIN { ADD | DEL | LIST | CLEAR } [channel] [key]
-
[18.39.22] [Misc] *** LocOps -- Server services.ircmojo.net[1.2.3.4] closed the connection
Confirned on Unreal-3.2.7, Anope-1.7.19 over FreeBSD.
[Edited on 14-8-2007 by katsklaw]
-
Darn my mistake...
I will publish an newer version of the module tomorrow.
For now you can use the devel version here: http://vips.hopto.org/~viper/ns_ajoin.c
It fixes the issue but I also want to add windows support in this release so gonna do that tomorrow before I publish it...
[Edited on 15-8-2007 by Viper]
-
Thanks for the quick response. I'll test it on my network this evening.
-
Published an updated version on the modules site (http://modules.anope.org/viewmod.php?id=96).
If you downloaded the devel version earlier, i reommend downloading te final 4.1.9 since the fix for windows also prevents an issue that could occur in the previous devel when the services are running in debug mode...
Changelog:
- Added win32 support
- Fixed segfault when AJOIN is used by an unregistered user
edit: i just received report of yet another segfault occuring when nicks are dropped and the db is saved. I added checks to prevent this, but apparently something s still going wrong. Will publish yet another new version tomorrow when i ve found the cause of this..
edit2: apparently there is some problem when the DB saving routines stumbles upon a dropped nick. I recommend to not use this module unless i can solve the problem. This might take a while.. i found the problem, but have no fix.. (http://forum.anope.org/images/smilies-new/frusty.gif)
[Edited on 16-8-2007 by Viper]
-
ok this will take a while...
I have to rewrite the way the module stores its ajoin list internally because of limitations in C and anope itself...
Till i find another way to implement it, i recommend everyone stops using the modue..
-
i need some people to test the new release...
a devel version of the new release that should resolve all crash bugs can be downloaded from here (http://vips.hopto.org/~viper/ns_ajoin.c).
Could some people try this out on their (test)nets, preferably with over 10 people who have an ajoin list and let this run for at least 24hrs. The fix does use more slighly cpu cycles and memory; i ll look for ways to reduce this later, but atm getting a new stable out should have priority.
edit: this is not yet meant for use on large production networks. I programmed it so certain circumstances that would normally only arrive with over a 1000 ajoin lists would occur with less then 10, making it very unsuitable for large nets, but shouldn't affect small testnets or nets with few users.
[Edited on 20-8-2007 by Viper]
-
Released... since no1 reported anything about crashes i m hoping it s finally entirely stable..
http://modules.anope.org/viewmod.php?id=96
-
Looks like this module does not work with the latest SVN of Anope. It complains about too few arguements in the 'anope_cmd_svsjoin' function within 'do_identify'.
Might have something to do with this: "Added support for channel keys to UnrealIRCd 3.2 SVSJOIN command"
I hope this helps.
[Edited on 5-9-2007 by CuttingEdge]
-
Think Viper knows about this and is just waiting for 1.7.20 to be release - he was the one that reported the issue! :)
-
Good stuff. Thanks for the reply! :)
-
yeah.. i have a new version of ns_ajoin just waiting for 1.7.20 :)
Can't publish it yet because most regular users wouldn't know how to get SVN and it would no longer compile on 1.7.19 so just wait a bit :)
-
I would know but I wont use svn on my ircd :D
-
/Me always uses SVN
partially cuz it s easier to update **lazy** :)
-
Actually, a small hack to the code is enough... Though it might be a bit scary, as I haven't read through the code properly...
Feeding the SVSJOIN with a NULL pointer for the password-string works for channels that doesn't need it...
Change:
anope_cmd_svsjoin(s_NickServ, u->nick, ac->channel);
to:
anope_cmd_svsjoin(s_NickServ, u->nick, ac->channel, NULL);
Just a quick 'hackup', possibly we lose out on a byte as we don't feed the routine properly, but - hm, it works for me...
-
true that will solve your not compiling problem, but it doesn't solve the issue of the module not properly joining users to +k channels... the renewed anope_cmd_svsjoin() takes a password (third arg) as well, but only works on unreal... had to work around that on the other ircd
/Me still waiting to release .14 :)
It fixes following issues atm...
* 4.1.14 Fixed ajoin failing under several conditions on a channel with +k..
* Added ban testing and unbanning if possible...
* Because UnrealIRCd is the only IRCd supporting SVSJOIN'ing to +k chans
* we now invite before joining on all IRCd's except unreal.
* We no longer unban the user if he is excepted...
* Added hooks for NS ID.
-
Also noticed that it doesn't always enforce users to join the channels set.
This might be something related to Inspircd however, so I'll tie my shoes and wait for the next release as well...
* unloaded module and waiting for next anope-release *
-
Originally posted by click
Also noticed that it doesn't always enforce users to join the channels set.
This might be something related to Inspircd however, so I'll tie my shoes and wait for the next release as well...
I thought i fixed the not joining issue in 4.1.13....
i never got around to setting up an inspircd testnet though.
So even though the module s supposed to work on all ircds with svsjoin, i only tested it on ultimate and unreal...
so a bit more details on the not joining all channels would be appreciated :)
Ps: and yeah, if it were me, i wouldn't use the version currently on the modules site either :)
-
Hi Viper. Come on and release .14 ;P
I can't compile .13 on anopes .20 :D
Cu in .08 ^^ hehe
-
.13 wasn't really meant for use on a live net anyways.. was a bit buggy imho
if i m not mistaken .14 was finished months ago and was simply waiting for .20 to be released... it neede the changes made to svsjoin :)
-
You request, We serve :)
Check the modules site for version 4.1.14.
Note that as of this version i consider it to be stable enough for use on a live network.
Lets hope it meets up to my expectations :7
Edit: Ok, nvm 4.1.14... had a stupid error in it cause it to crash anope in certain cases..
Up to 4.1.15
[Edited on 3-1-2008 by Viper]
-
hello,
I use this module in my anope, it function without no problem, but when I restart the services, all the channes are erased. The channels are not being save in the DB.
help-me!
-
Are you using the latest version (4.1.15)?
Are you running it on *nix and did you make sure anope has write permissions.
Is there any kind or error in the logfiles regarding this?
And does ALL nickserv ajoin data dissapear including /ns set ajoin option or just some of it...
-
Anyone using this please update ASAP to avoid services crashing over a nasty little bug...
Check modules site for release info etc...