What is the consensus on what bot programmers prefer on how to do settings changes? What is it for users? Is a mix of both preffered?
- Conducting a study to find the best way to continue on with my bots user settings/configuration changes.
-Edit: By command line i mean by doing (i.e. "/setpass blah") instead of using a form and a text box etc..
A GUI is certainly easier, but a command-line is nice for quick changes.
I'd say it's best to have both.
I would have to agree, but I wouldn't recommend it for actual commands in the bot, could cause problems with access controls. GUI is definately a nice way to go for the bot newbie, and inbot cmds is handy for advanced bot users, and for people to learn in the future if they don't already know.
Commandline with detachable gui (the gui makes a tcp connection locally).
no interface with various plugins providing console / gui / web interfaces.
console (or no gui) for moderation bots.
For chat bots I prefer a standard gui.
Funny how this thread has gravitated from whether to use a gui or command line for configuration settings to and overall view of how a bot should be.
I would recommend implementation of both. GUIs are nice if done correctly and command-line is useful when it comes to scripts and quick changes in the configuration.
Quote from: (V)eh on September 07, 2004, 05:17 PM
Didnt Feanors Firebot go into Moderation mode by taking away chat screen etc and go to command driven?
The old one did.
I support both in BC, though there are still a few rarely used things that can only be set through the command line.
What about all command line? or no GUI AT ALL, meaning using a console in vb? Would using a console bring resource usage down, and maybe better for moderation/stability?
Quote from: oldskooldrew on September 08, 2004, 07:22 PMWhat about all command line? or no GUI AT ALL, meaning using a console in vb? Would using a console bring resource usage down, and maybe better for moderation/stability?
If you're at all concerned about performance, you really shouldn't be using VB. It's intended for rapid creation, not rapid execution. Now that the obligatory VB bashing is out of the way:
* Using a console in VB is just silly; if you don't want a graphical interface, why use a language that puts lots of effort into letting you easily have a graphical interface?
* Using a console could require fewer resources than a GUI, depending on how the console is configured (amount of scrollback) vs. complexity of your GUI. I'd guess in most cases you'd use fewer resources.
* Better for moderation/stability: that's just silly. Your GUI is the last thing you should be worrying about stability on. :P As for moderation, there's really no point having a fancy interface on a client that's meant to run unattended, so running it as a console (or, even better, as a console-free service) would be more logical in such a case.
Quote from: Kp on September 08, 2004, 10:27 PM
Quote from: oldskooldrew on September 08, 2004, 07:22 PMWhat about all command line? or no GUI AT ALL, meaning using a console in vb? Would using a console bring resource usage down, and maybe better for moderation/stability?
If you're at all concerned about performance, you really shouldn't be using VB. It's intended for rapid creation, not rapid execution. Now that the obligatory VB bashing is out of the way:
* Using a console in VB is just silly; if you don't want a graphical interface, why use a language that puts lots of effort into letting you easily have a graphical interface?
* Using a console could require fewer resources than a GUI, depending on how the console is configured (amount of scrollback) vs. complexity of your GUI. I'd guess in most cases you'd use fewer resources.
* Better for moderation/stability: that's just silly. Your GUI is the last thing you should be worrying about stability on. :P As for moderation, there's really no point having a fancy interface on a client that's meant to run unattended, so running it as a console (or, even better, as a console-free service) would be more logical in such a case.
Rapid GUI is not the only thing VB gives you rapidly. Database development, well, nearly anything you would do with COM libraries, VB makes it easy to build rapidly. That said, doing everything rapidly then fighting your way through a console display is rather weird when it is so simple to do with a listbox or multiline textbox, or just a plain form using print.
Quote from: Grok on September 09, 2004, 06:14 AMRapid GUI is not the only thing VB gives you rapidly. Database development, well, nearly anything you would do with COM libraries, VB makes it easy to build rapidly. That said, doing everything rapidly then fighting your way through a console display is rather weird when it is so simple to do with a listbox or multiline textbox, or just a plain form using print.
I
did credit it with rapid creation in general! :) Remarking on rapid GUI development is just an instantiation of the more general remark about it being designed for rapid creation, not rapid execution.
Quote from: iago on September 07, 2004, 07:33 AM
Commandline with detachable gui (the gui makes a tcp connection locally).
A good firewall would likely block that.
Quote from: Grok on September 09, 2004, 06:14 AMdoing everything rapidly then fighting your way through a console display is rather weird when it is so simple to do with a listbox or multiline textbox, or just a plain form using print.
For anything thinking it would be funky using a listbox, it is kind of. But it's fairly practical. My KaneBotAdmin tool uses a listbox to show various events. It's a matter of something so simple as ListBox.AddRow EventText (if empty) or ListBox.InsertRow 0, EventText (if not empty). That way, the event is always at the top of the listbox (since there's no way to do automatic scrolling in REALbasic..., which I wouldn't want anyways). When the events go massive, do a simple check for some amount (I set it to 100, since I hardly even look at the events anyways, lol), and then remove the oldest event from the listbox with ListBox.Remove ListBox.ListCount-1
Quote from: tA-Kane on September 09, 2004, 10:20 AM
Quote from: iago on September 07, 2004, 07:33 AM
Commandline with detachable gui (the gui makes a tcp connection locally).
A good firewall would likely block that.
Ah, but that wouldn't be a
good firewall... A good firewall won't block the connections you want.
Quote from: Adron on September 09, 2004, 10:28 AM
Quote from: tA-Kane on September 09, 2004, 10:20 AM
Quote from: iago on September 07, 2004, 07:33 AM
Commandline with detachable gui (the gui makes a tcp connection locally).
A good firewall would likely block that.
Ah, but that wouldn't be a good firewall... A good firewall won't block the connections you want.
Right now, it only accepts connections from localhost. Do firewalls actually block loopback? I've never really used a software firewall, so :/
Quote from: iago on September 09, 2004, 11:59 AM
Quote from: Adron on September 09, 2004, 10:28 AM
Quote from: tA-Kane on September 09, 2004, 10:20 AM
Quote from: iago on September 07, 2004, 07:33 AM
Commandline with detachable gui (the gui makes a tcp connection locally).
A good firewall would likely block that.
Ah, but that wouldn't be a good firewall... A good firewall won't block the connections you want.
Right now, it only accepts connections from localhost. Do firewalls actually block loopback? I've never really used a software firewall, so :/
I was working with Red Hat linux about a year and a half ago, and indeed it did have a firewall that blocked loopback. Took me a long time to figure out that's what was going on, too, and even longer to figure out how to disable the firewall.
I think the specifics was that it only blocked loopback on non-standard ports (eg, it would allow a connection to localhost on ftp, telnet, web, etc, but not the port I was using which was 2169).
Quote from: tA-Kane on September 09, 2004, 02:36 PMQuote from: iago on September 09, 2004, 11:59 AMQuote from: Adron on September 09, 2004, 10:28 AMAh, but that wouldn't be a good firewall... A good firewall won't block the connections you want.
Right now, it only accepts connections from localhost. Do firewalls actually block loopback? I've never really used a software firewall, so :/
I was working with Red Hat linux about a year and a half ago, and indeed it did have a firewall that blocked loopback. Took me a long time to figure out that's what was going on, too, and even longer to figure out how to disable the firewall.
I think the specifics was that it only blocked loopback on non-standard ports (eg, it would allow a connection to localhost on ftp, telnet, web, etc, but not the port I was using which was 2169).
You didn't have it configured right, then. :) Most Linux kernels have a hack that any traffic sent to any of the addresses that it owns from the local system is considered to come from lo, even if the IP address belonged on, say, eth0. Rather than disabling the firewall, you should've added a rule with target ACCEPT for interface lo. Be sure to set it to interface lo, else you'll be opening up the system to the network.