| View previous topic :: View next topic |
| Author |
Message |
intel
Halfop
Joined: 26 Feb 2008
Posts: 57
|
 Posted: Sat Mar 01, 2008 9:21 pm Post subject: Global settings |
 |
|
| 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. |
|
| Back to top |
|
 |
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Sat Mar 01, 2008 10:44 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Sun Mar 02, 2008 12:16 am Post subject: |
|
|
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.
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Sun Mar 02, 2008 12:37 am Post subject: |
|
|
*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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Sun Mar 02, 2008 1:10 am Post subject: |
|
|
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.
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Sun Mar 02, 2008 1:22 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Sun Mar 02, 2008 2:24 am Post subject: |
|
|
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...
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Sun Mar 02, 2008 2:56 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Sun Mar 02, 2008 5:50 am Post subject: |
|
|
| strikelight wrote: | | 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.
| strikelight wrote: | | 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?
| strikelight wrote: | | 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...
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Sun Mar 02, 2008 8:49 pm Post subject: |
|
|
| nml375 wrote: |
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.
| nml375 wrote: |
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.
| nml375 wrote: |
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.
| nml375 wrote: |
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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Mon Mar 03, 2008 6:58 pm Post subject: |
|
|
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 ?)
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Mon Mar 03, 2008 7:52 pm Post subject: |
|
|
| nml375 wrote: | 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: |
# 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)
| nml375 wrote: |
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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Mon Mar 03, 2008 8:22 pm Post subject: |
|
|
Ahh, you are right 'bout it being available in earlier eggies, my bad...
| Quote: | | 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...
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
strikelight
Owner
Joined: 07 Oct 2002
Posts: 708
|
| Posted: Mon Mar 03, 2008 8:44 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
nml375
Revered One
Joined: 04 Aug 2006
Posts: 2857
|
| Posted: Tue Mar 04, 2008 12:49 pm Post subject: |
|
|
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?
_________________
NML_375, idling at #eggdrop@IrcNET |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
