Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[w00]

Hi guys, cannot find an answer yet.
Any1 can point me the flag or correct settings/script to see the topic * Set by <nickname>..
instead of shoiwing * Set by ChanServ. as anope is still keeping the nickname who set last
topic on rejoining empty channel. very easy and obvious, but where is the setting or how to
make it.. thanks!

w00

[CrazyCat]

I think this is an ircd server feature, not services. It's really ChanServ who set the topic (because the channel was empty or someone tried to change the topic), and it's the ircd who displays this message.

[w00]

well, what i see, anope act as a connected server to my unreal,
so all the "chanserv" doing is synching with real server, so if
chanserv internally make "* Set by <nickname> on Wed Apr 16 13:37"
it will be seen by everybody at the server on join.. ircd? but

if Chanserv (as user) setting this topic at the right moment as
user join then the date of setting topic will be current too, not
the old one when real user was set it..

any ideas? =)

w00

[w00]

CrazyCat:
hm.... i use Unreal3.2.10.2, other ircd probably can show it correctly as i want? can you confirm it?

[CrazyCat]

CrazyCat:
hm.... i use Unreal3.2.10.2, other ircd probably can show it correctly as i want? can you confirm it?

No, because the information sent is good.
If you're the first to join a registered channel (with defined topic or with keeptopic enabled), it's really ChanServ who sets the topic.
And if you the channel is setted with the topiclock option and someone tries to change the topic, it's really ChanServ who re-change the topic to the original one.

The ircd only knows what it see : ChanServ changed the topic.

[Andromeda]

I'm afraid CrazyCat is right, that boils down to the IRCd not Anope.

I don't think there is any way possible to show the topic set by user even on a developer level without modifying the IRCd to allow "fake nicks" for U:Lined servers which in theory could use any nick to set a topic or send a message.... I also wouldn't recommend this, there are safeguards in place to prevent user abuse.

Unlocking this would allow use of commands such as /os svssay <some fake nick> <chan/user> <message>... which could be pretty neat, but would no doubt be abused on many networks.

There's also no telling what other side effects this could cause... but none the less, there is nothing Anope could do, it's the IRCd.

[w00]

thanks for reply..

okay, but how ChanServ can set topic in the "past" date if its
setting it right after join empty channel, then easy can be
used a nick of the user who set topic as it stored in:

info #channel all

[13:37] -ChanServ (services@some.thing)- Last topic: some_topic
[13:37] -ChanServ (services@some.thing)- Topic set by: w00

should be a routines to pass this info too..
or make chanserv rename itself for a moment of setting topic for a nickname
from 'topic set by:'


PS. locked topic mode not interesting.

lets modify ircd then... please save my time and tell me where to dig next..

i not remember what happening during splits and how info synched in this
situation (topic set by ircd.stealth.net.. ? topic date?), or each server will
have their own setting until somebody will set new topic.. or maybe splits
not a case nowadays, as i am talking about 90-x..

tnx

[Andromeda]

I'm not entirely sure what you're trying to say here, but I think I get the gist of it all...

Simply put, you could modify the IRCd, but no, I can't tell you where to dig for how... every IRCd is different, that's why Anope has protocol select in the configuration files so it will send/receive the correct messages... sadly to say, you're on your own with that one.

Honestly I don't see the problem with just letting ChanServ set the topic...
But what you're wanting is for a user to set a topic when that user isn't setting the topic.... it can't be done safely. Basically it would be like me posting this reply on this forum but wanting my name to display as "Administrator"...

IRC protocol is very specific.... for example, with Unreal, the raw protocol for topic would be:

Code: [Select]

:source TOPIC #channel nick timestamp :text
Where source would be the person/service setting the topic. You can't just use *any* source you want, it has to exist within services to do.

Sorry, what you want is realistically not possible.

[katsklaw]

Actually, source would be the server sending the data, in this case source = ServerName. Ircds generally have security measures built in to prevent bogus data from being injected. In this case if nick is not from source, it's likely dropped as erronious data.

That said, its possible to write a module to append the setting nick to the end of the topic by TAIL'ing the topic command.

Hope that helps.

[Andromeda]

Actually, source would be the server sending the data, in this case source = ServerName. Ircds generally have security measures built in to prevent bogus data from being injected. In this case if nick is not from source, it's likely dropped as erronious data.

That said, its possible to write a module to append the setting nick to the end of the topic by TAIL'ing the topic command.

Hope that helps.

"source" is the location it came from, it doesn't need to be a server. If you use /topic #test boo, YOU will be the source.

For example:
Self: /topic #Test boo = :Andromeda TOPIC #Test Andromeda 1397845002 :boo
Services: /cs topic set #Test boo = :services.mynetwork.tld TOPIC #Test Andromeda 1397845002 :boo

(Note this syntax is IRCd dependant; and I *did* just verify this to be 100% sure it didn't set source to the server the user was on)

[katsklaw]

"source" is the location it came from, it doesn't need to be a server. If you use /topic #test boo, YOU will be the source.

For example:
Self: /topic #Test boo = :Andromeda TOPIC #Test Andromeda 1397845002 :boo
Services: /cs topic set #Test boo = :services.mynetwork.tld TOPIC #Test Andromeda 1397845002 :boo

(Note this syntax is IRCd dependant; and I *did* just verify this to be 100% sure it didn't set source to the server the user was on)

Keeping in context of the conversation, your latter example would apply, thus making Anope the source. Which is why I said "in this case"