set::history::channel::playback-on-join::lines and
set::history::channel::playback-on-join::time were ignored,
the limit in the +H channel mode was used instead.
Reported by k4be in https://bugs.unrealircd.org/view.php?id=5707
This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
and HOOKTYPE_REMOTE_CHANMODE are called from the SJOIN code.
We now set the samode argument to -1 if it is an SJOIN server sync,
so chanmodes/permanent won't destroy the channel while processing
the SJOIN. The SJOIN code already takes care of destroying at the end.
so they can fetch more history than the standard on-join history.
In the future we are also likely to implement IRCv3 CHATHISTORY
once that becomes an official specification. However, until it is
specified and until most major clients support it, several years
are likely to pass. It would be a shame to withhold channel
history to many end-users in the meantime when it takes so little
effort from us to provide an easy command.
See also
https://www.unrealircd.org/docs/Channel_history
And in particular the new section:
https://www.unrealircd.org/docs/Channel_history#Playback_frontends
which explains the relationship between on-join playback,
HISTORY and CHATHISTORY.
Release notes:
+* [Channel history](https://www.unrealircd.org/docs/Channel_history) used
+incorrect time internally, resulting in messages expiring too soon.
+The syntax is now really ```/MODE #chan +H lines:time-in-minutes```.
+To make clear that the time is in minutes, an 'm' will be added
+automatically by the server (eg ```+H 15:1440m```).
Bug reported by k4be.
all known flags as well. So you can now add stats via modules.
Only the stats help is currently missing if you do so.
=> Moved dccdeny stats to dccdeny
deal with servers with different set::allowed-channelchars settings:
* We reject the link if set::allowed-channelchars settings differ between
UnrealIRCd 5 servers.
* For the case where you have a mixed network consisting of UnrealIRCd 4.x
and UnrealIRCd 5.x servers we try not to desync, BUT will not allow
anyone to join the invalid channels locally. For IRCOps a message is
printed with additional information on such a failed JOIN attempt.
See https://www.unrealircd.org/docs/Set_block#set::allowed-channelchars
for the different settings, which are best and U4<->U5 advice.
1) HOOKTYPE_CAN_SEND is now called HOOKTYPE_CAN_SEND_TO_CHANNEL
The arguments and return values are unchanged
2) similarly can_send() is now called can_send_to_channel()
3) If you want to block or alter a message you must now
use HOOKTYPE_CAN_SEND_TO_CHANNEL and return HOOK_DENY from
there with an appropriate *errmsg filled (see nocolor and
many other modules for an example)
4) You CANNOT use HOOKTYPE_PRE_USERMSG anymore to block a message.
I actually wanted to rip this hooktype out entirely, but
delayjoin needs it. HOOKTYPE_PRE_USERMSG is only useful for
notification that a message is going to be sent BEFORE it is
actually sent (which is exactly what delayjoin needs, so it
can send a JOIN if the user is currently invisible).
5) This is all to make things more clean:
* HOOKTYPE_PRE_USERMSG is only for delayjoin
* HOOKTYPE_CAN_SEND_TO_CHANNEL is used for exactly what the
name implies. You can also change the message text there,
such as for +G, +S, etc.
This so I - and others - don't constantly have to wonder whether the client
is called sptr, cptr or acptr in a simple routine.
Insane --> 212 files changed, 6814 insertions(+), 6945 deletions(-)
Couldn't just mass-replace of course since there are places where there
are multiple clients involved. So had to check each function.
Also renamed some 'acptr' to 'target' and such.
I will write a page with new style rules later.. but in short if there is
only 1 client involved it will now be called 'client'.
'sptr' is sufficient and in most cases the only one you should care about.
Should you need it, you can access sptr->direction in cases where you
need the old information (usually only for some sendto_* functions
and some protoctl checks), so 'cptr' was redundant too.
[!] This change likely introduces some bugs. This was many hours of work.
I only cut some corners in 4 functions, which will be fixed at a later
stage..... yes, more major changes to come.
On the plus side, I likely fixed some bugs in the process. Situations
where cptr vs sptr usage was incorrect. Eg using cptr->name (near server)
when sptr->name should be used (the actual source server), etc....
which specifies the time in milliseconds rather than seconds. This
allows for additional precision, or at least multiple calls per second.
The minimum allowed every_msec value is 100 at this time.
The prototype is now: EventAdd(Module *module, char *name,
vFP event, void *data, long every_msec, int count);
which would be too much coding effort for such an unusual event.
(Reloading is fine though, for eg upgrading-on-the-fly)
Issue reported by westor in https://bugs.unrealircd.org/view.php?id=5416
MOD_UNLOAD. And MOD_HEADER(xyz) is now MOD_HEADER even without ()
since this isn't a function, really.
To make things understandable I added the following to the
developer section of the release notes:
* The module header is now as follows:
ModuleHeader MOD_HEADER
= {
"nameofmodule",
"5.0",
"Some description",
"Name of Author",
"unrealircd-5",
};
There's a new author field, the version must start with a digit,
and also the name of the module must match the loadmodule name.
So for example third/funmod must also be named third/funmod.
* The MOD_TEST, MOD_INIT, MOD_LOAD and MOD_UNLOAD functions no longer
take a name argument. So: MOD_INIT(mymod) is now MOD_INIT()
the chanmodes/delayjoin module must be named chanmodes/delayjoin
in the module header.
This because currently we have two module names for each module,
one is the name from the MOD_HEADER and the other is the
relative path, such as used by loadmodule and is_module_loaded().
This commit also (not entirely, but practically) breaks loading
of modules outside the regular modules path. I don't think that's
a problem, although it could use a bit more documentation.
This so we have a few simple concepts:
Client: this can be a user, server, or something unknown yet
Then the type of clients:
User: this is a user, someone with a nick name.
Server: this is a server
Etc.
aChannel to Channel, and some more. Third party module coders will
love this. But.. it makes things more logical and the doxygen output
will look more clean and logical as well.
(More changes will follow)
Use a more simple hashing algorithm and one that uses 64 bits,
don't allocate any memory dynamically, just use an int64_t.
Also, only do the hashing if 'r' is actually enabled in +f
on the channel, as otherwise it's pointless.
Bram Matthys