Global settings

[intel]

If I have the global setting for set global flood channel to say 10:60 but then for say Channel #XYZ I have it set for flood-chan 0:0 shouldnt that be the one that works? In order not get have the bot kick I need to set the global to 20:60.

[strikelight]

How are you making the changes? You need to use the .chanset command in the partyline for any channel settings after you've already added the channel. Changes to the .conf regarding the channel will be ignored.

[nml375]

To clarify, the global settings for channel-flood, aswell as other channel settings, are only used as a template when a new channel is added.

When editing settings, there are a few things to keep in mind. Eggdrop uses a "channels-file" by default, that will store all channel-settings for all added channels. This file is basically an automatically generated script with a series of channel add and channel set commands, and is executed once the main config-file has been fully executed. This has a drawback, that once you add a channel, you cannot alter any settings for it by editing your config-file. Instead you should use the .chanset dcc-command to update any settings.

If you, for some reason, cannot use .chanset - you'll have to edit the channels-file, or remove it to revert all channels to what's in your config-file. In fact, it is recommended that you completely disable the channels-file, along with the .chanset command if you must use your config-file to manage channel settings.

[strikelight]

*blinks*
In what scenario would one not be able to use the .chanset partyline command, if they are able to edit the conf file?

Point being, if they are some how unable to use the partyline .chanset command, they have more important problems they need to address first.

[nml375]

I said it was recommended, not required to disable the .chanset command. The reason for this, obviously, being that changes done with this command would not be permanent, and lost upon next .rehash/.restart or similar.

As for not being able to use the .chanset, reasons might not be restricted to being unable to access the dcc partyline. I have encountered cases where this was desired out of purely philosophic reasons where the botowner or one reason or other wants to use the config file for channel settings, making sure any and all settings found in the config file matches those present in the bot.

[strikelight]

As I stated, if they are unable to access their partyline, they have other issues they need to worry about first. Accessing the partyline is always something that can be fixed. With that said, it is NEVER recommended to disable usage of a channel file and/or the chanset command, just as you would never disable usage of the userfile and user manipulation commands in opting of adding users via the conf. Those that have 'philosophical' reasons for not wanting a channel-file, are those who simply do not understand, or at the very least are confused by how channel settings work with regard to the channel file.

So to reiterate, it is NEVER EVER recommended to disable usage of a channel file and associated partyline commands.

[nml375]

I would then counter with that it' is not recommended against disabling the use of the channel's file either. Wether to use it or not is a personal preference, quite obviously you're quite inclined on using it. Others might not be. Key issue is to make sure you don't "mix" the use of both concepts.
Unfortunately, the config file is quite ambiguous on this matter, as it suggests static channels with preconfigured settings to be entered while a channel's file is in use.

This discussion however, is getting way offtopic. The question was how to change various channel settings - and I believe my initial post covered most common issues, and misconceptions regard channel settings and the channel's file. Lets keep this ontopic...

[strikelight]

I find it important as users should not have the misconception that the disabling of saving channel settings to file is recommended (which isn't possible to disable, aside from code modification, or not loading the channel module, which even static channels would then be impossible to create). As for the config file being ambiguous about static channels, and preconfigured settings, it states that these channels are to be _added_ with those settings, it does not suggest that the config file be used for on-the-fly modifications of channel data.

Just making things clear for users that the channel file commands and manipulation were designed and modified over the years to be the _recommended_ method for modifying channel data.

[nml375]

I find it important as users should not have the misconception that the disabling of saving channel settings to file is recommended (which isn't possible to disable, aside from code modification, or not loading the channel module, which even static channels would then be impossible to create).

Disabling the use of a channels file is simple... just don't set chanfile within your config file. No need to edit source, not loading the channels module or such.. It has been such ever since the concept of channels file was introduced as a feature back in 1.3.0.

As for the config file being ambiguous about static channels, and preconfigured settings, it states that these channels are to be _added_ with those settings, it does not suggest that the config file be used for on-the-fly modifications of channel data.

In the same manner, anyone with a history of hand-edited config files (think apache, proftpd, dhcpd, dhclient, etc) would find it intuitive that if you change something in your config file, these settings would take effect upon next restart/rehash. Channels added through the config file are called "static" suggesting that anything you put in the config file remains, yet they are just as dynamic as "dynamic" ones. I've spend quite a few years explaining this behaviour to frustrated botowners, if it's so obvious from the scattered documentation - why are people still having these issues?

Just making things clear for users that the channel file commands and manipulation were designed and modified over the years to be the _recommended_ method for modifying channel data.

The recommended approach is either to only use static channels and ditch the channels file, or use channels file and ditch static channels. Mixing them will only cause headache in the end. Even so, there was a long time where you actually had to add atleast one static channel to your eggdrop for it to start properly, regardless of wether you were using a channels file or not...

[strikelight]

Disabling the use of a channels file is simple... just don't set chanfile within your config file. No need to edit source, not loading the channels module or such.. It has been such ever since the concept of channels file was introduced as a feature back in 1.3.0.

Actually, channel file existance precedes even 1.3.0... Even 1.1.5 has channel files. By your definition of the config file implying usage of eggdrop, not defining chanfile would be a no-no.

In the same manner, anyone with a history of hand-edited config files (think apache, proftpd, dhcpd, dhclient, etc) would find it intuitive that if you change something in your config file, these settings would take effect upon next restart/rehash.

Difference being is that there is no mechanism to alter settings on-the-fly with the aformentioned programs, being as they are daemons, whereas eggdrop may have daemon-like properties, it obviously is not.

Channels added through the config file are called "static" suggesting that anything you put in the config file remains, yet they are just as dynamic as "dynamic" ones. I've spend quite a few years explaining this behaviour to frustrated botowners, if it's so obvious from the scattered documentation - why are people still having these issues?

Channels added through the file are called "static", their settings however are _not_ called "static settings". I can not disagree that documentation may be lacking, but I can guarantee you of the intent of the channel file model.

The recommended approach is either to only use static channels and ditch the channels file, or use channels file and ditch static channels. Mixing them will only cause headache in the end. Even so, there was a long time where you actually had to add atleast one static channel to your eggdrop for it to start properly, regardless of wether you were using a channels file or not...

That is YOUR recommended approach, not the eggdrop development team's recommendation, be clear on that. The practicality of having a channel added in the configuration file, and being able to only alter its settings through the configuration file was tedious and cumbersome, hence the evolution of static channels having their channel settings branch out of being static settings, and making their way into the channel file.

[nml375]

It may be quite some time since I was involved in active development of eggdrop, but I'm quite sure the channels file was'nt introduced until 1.3... Feel free to point out where channels files are implemented within the 1.1.5-source (or 1.2.x for that matter)...

In any case, this discussion seems to get locked at the same issue that's been a plague for eggdev since ages; the constant arguing about including and enforcing various features usable to some, completely meaningless to others. Somewhere the main idea of making eggdrop as flexible as the user needs it gets lost, while we get stuck at "the coder's eggdrop" (remember eggdrop2 ?)

[strikelight]

It may be quite some time since I was involved in active development of eggdrop, but I'm quite sure the channels file was'nt introduced until 1.3... Feel free to point out where channels files are implemented within the 1.1.5-source (or 1.2.x for that matter)...

Despite my better judgement for pasting this from the eggdrop 1.1.5 config file, as I know you might see its comments as proving your point about there ever being a scenario where you shouldn't use a channel file..I do so as I believe it actually helps prove my point on the evolution of eggdrop, as static channels can now be modified on-the-fly:

Code: Select all

# if you want to dynamically change channel settings, and have them saved
# for next time the bot restarts, define this filename ( the filename
# you set here *MUST* exist else the bot won't load. Just create an empty
# file for this to work)
#set channel-file "LamestBot.chan"

^-- Taken from eggdrop1.1.5's configuration file. (My main botnet still runs 1.1.5, my test botnet runs 1.6.x)

In any case, this discussion seems to get locked at the same issue that's been a plague for eggdev since ages; the constant arguing about including and enforcing various features usable to some, completely meaningless to others. Somewhere the main idea of making eggdrop as flexible as the user needs it gets lost, while we get stuck at "the coder's eggdrop" (remember eggdrop2 ?)

But that's just it... if we were to take your suggestion, and remove dynamic settings from static channels, we lose flexibility. Prior to static channels having their settings alterable on-the-fly, users would complain of not having an easy method of changing those settings on-the-fly. Hence, the modification of the behaviour of static channels.

[nml375]

Ahh, you are right 'bout it being available in earlier eggies, my bad...

But that's just it... if we were to take your suggestion, and remove dynamic settings from static channels, we lose flexibility. Prior to static channels having their settings alterable on-the-fly, users would complain of not having an easy method of changing those settings on-the-fly. Hence, the modification of the behaviour of static channels.

The point rather being, allow those who indeed use dynamic channels the option of using a channels file - don't argue that everyone should use it just because it's there...

[strikelight]

Not arguing that it should be used just because it is there (although it IS there for a reason).. The reasoning is that it is practical, efficient, non-cumbersome, and more or less, straight forward.

[nml375]

Neither am I arguing that none should use it. I don't argue with recommending people to use this feature, neither do I tell not to use it just because they have the option (in fact, I'd probably say it's a "don't disable unless you know what you are doing" kind of option) - your initial posts however gave me the impression you're saying it's wrong to not use it (hence not really making it a optional feature but a mandatory part).

As for the problem with "static" channels in your config-file, there are numerous "solutions" - each with it's own caveats, and I faintly recall it being discussed alot along with the arguing pro/con xml-configs..
One thought that came to mind as I'm typing now however, that should'nt break too much, would be revision numbering similar to named. Wether it's worth the work to implement it is a different story.

Nevertheless, intel; any luck getting your settings in order sofar?