dominikh changed the topic of #cinch to: The IRC Framework | Latest version: Cinch 2.3.1
Iota-Spencer is now known as ZeeNoodley
Rickmasta has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Rickmasta has joined #cinch
Rickmasta has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tinnvec has quit [Ping timeout: 246 seconds]
tinnvec has joined #cinch
postmodern has quit [Quit: Leaving]
Rickmasta has joined #cinch
Rickmasta has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Rickmasta has joined #cinch
Rickmasta has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Zarthus has quit [Quit: I can't go to hell. I'm all out of vacation days.]
Zarthus has joined #cinch
apeiros has quit [Ping timeout: 264 seconds]
apeiros has joined #cinch
ZeeNoodley has joined #cinch
ZeeNoodley has quit [Changing host]
<tinnvec>
So, the main channel my bot is in uses chat replay on join
<tinnvec>
is there already a delay setting? or a way I can ignore commands for X seconds?
<tinnvec>
that is, if something exists already
<tinnvec>
since I got my VPS switched over to systemd and wrote a service, teh bot now reboots perfectly
<tinnvec>
however, since I have a !kill command, the bot reads this as a new command on re-connect if it is within the replay window
<leftylink>
heh... I've seen various things. I'm not sure of a good solution yet. timestamp? no, irc doesn't do timestamps
<leftylink>
er, wtf do I mean by "seen various things"
<leftylink>
s/various things/various bots get bitten by replays/
<leftylink>
there
<leftylink>
for my bot it just happens to work because restart commands need auto, and the whois gets delayed long enough on bot startup (since bot is too busy gettign channel info to actually send the whois, and the whois times out after 30 seconds)
<leftylink>
s/need auto/need auth/
<leftylink>
lololololololololol?
<tinnvec>
ah lol
postmodern has joined #cinch
<tinnvec>
yeah I was thinking something like mark bot start time, send all messages nowhere for 5-10 seconds then continue on
<tinnvec>
oh duh, I should have looked deeper at config options
<tinnvec>
delay_joins is the answer lol
<tinnvec>
at least the simple one
<leftylink>
certain? I thought that was "delay joins until something happens" not "Delay processing of messages" as the current problem asks for
<tinnvec>
delays joining channel for X seconds or until event
<leftylink>
that doesn't seem like it would solve the replay problem. the replay messages will still happen - whenever the bot joins the channel
<tinnvec>
so, while it's not the most optimum answer, it would work
<tinnvec>
yeah, the replay would still happen but since it's only 60 sec of replay in that channel, it can be a temp solution
<leftylink>
I... I see...
<tinnvec>
I could take control of the :channel event
<tinnvec>
and then give it back after a sec
<tinnvec>
because yeah, just having it wait to join is pretty much the LEAST desireable way to go about it
<dominikh>
which IRCd is the networking using? most that have chat replay also have a bot flag and an option not to replay to bots
<dominikh>
alternatively you can place ZNC between the bot and the IRC network, so that when the bot restarts, the connection to the IRC server is maintained; and you can disable replay in ZNC
<dominikh>
tinnvec: ^
<tinnvec>
oh very interesting, I'm not sure, let me check
<tinnvec>
it's inspircd
<dominikh>
they should have the bot flag
<leftylink>
and you have made me realize that I completely forgot to set that mode on my bots
<leftylink>
this is the result of copypasta freenode bot.rb to other networks and freenode not having the bot flag
<leftylink>
so, oops.
<leftylink>
and this is especially embarrassing because I have raged at copy and paste coding at least three times to my coworkers this week
<dominikh>
not all kinds of copyying code are bad, though
<tinnvec>
hrm, looks like you were asked about this back in april haha
<dominikh>
yes.
<tinnvec>
and the resulting issue on inspircd looks unresolved
<dominikh>
oh, right. they didn't have the bot mode, did they
<dominikh>
2014-04-23.log:2014-04-23 01:08:33Paradoxwell, the patch i'm working on for INSP is to make it not send replays to +B users
<tinnvec>
they do, but unclear as to weather or not replay is affected by it
<dominikh>
well, set the mode and see if it helps or not
<tinnvec>
haha yeah
<dominikh>
if it doesn't, use some heuristic to drop the messages.
<dominikh>
or abandon inspircd
<tinnvec>
haha not my choice on the latter
<dominikh>
then you need to become more influential
<tinnvec>
oh, of note, you have to apply the +B each time you connect
<dominikh>
that seems obvious
<tinnvec>
well I suppose, but I'm not a huge irc nerd (at least not as huge as I thought)
<tinnvec>
I assumed it worked like auto-voice/op/etc
<leftylink>
but auto voice... directs some bot to set the mode whenever the user enters the channel. analogously, if you want a user mode to be set, you have to set it every time when you connect
<tinnvec>
well that makes FAR too much sense, leftylink
<dominikh>
actually now I have to wonder why it isn't listed in KnownOptions
<dominikh>
does setting :modes actually work?
<tinnvec>
just about to try, I don't need the +, I assume?
<leftylink>
it has historically worked for me. let's see if this is still a true statement
<leftylink>
or if I'm just crazy.
<tinnvec>
not mutually-exclusive statements
<leftylink>
work
<leftylink>
yeah it's fine
<tinnvec>
config.modes = ["B"] ?
<leftylink>
yup
<tinnvec>
hrm, something must not be right in our setup then
<dominikh>
why the hell does setting modes even work :D
<tinnvec>
lol
<tinnvec>
# @since 2.0.0
<tinnvec>
def modes=(modes)
<tinnvec>
(@modes - modes).each do |mode|
<tinnvec>
unset_mode(mode)
<tinnvec>
end
<tinnvec>
(modes - @modes).each do |mode|
<tinnvec>
set_mode(mode)
<tinnvec>
end
<tinnvec>
end
<tinnvec>
is why it works
<dominikh>
a) please do not paste more than 3 lines on IRC
<tinnvec>
or were you asking a different question?
<tinnvec>
oh sorry
<dominikh>
b) Bot#modes has nothing to do withBot#Configuration
postmodern has quit [Quit: Leaving]
<dominikh>
so, setting the option only seems to work because of a bug in the logic checking for unknown options
<dominikh>
c.modes = ... will work. c[:modes] = ... will not, whereas c[:server] = ... would work
<dominikh>
I wonder if that used to work in older Ruby versions… let's see
<leftylink>
ohmy
<dominikh>
no, it's a bug in my code. and a stupid implementation of ruby's OpenStruct. you would think that OpenStruct#method_missing would be defined in terms of OpenStruct#[], but no. method_missing just accesses the data directly
<dominikh>
I implemented the check in #[] and #[]=, but those don't run most of the time