Preffered bot types [Cmd Line/Gui]

[oldskooldrew]

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..

[Arta]

A GUI is certainly easier, but a command-line is nice for quick changes.

I'd say it's best to have both.

[LordNevar]

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.

[iago]

Commandline with detachable gui (the gui makes a tcp connection locally).

[K]

no interface with various plugins providing console / gui / web interfaces.

[hismajesty]

console (or no gui) for moderation bots.
For chat bots I prefer a standard gui.

[dxoigmn]

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.

[Falcon[anti-yL]]

Didnt Feanors Firebot go into Moderation mode by taking away chat screen etc and go to command driven?

The old one did.

[Skywing]

I support both in BC, though there are still a few rarely used things that can only be set through the command line.

[oldskooldrew]

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?

[Kp]

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?

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.  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.

[Grok]

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?

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.  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.

[Kp]

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.

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.

[tA-Kane]

Commandline with detachable gui (the gui makes a tcp connection locally).

A good firewall would likely block that.

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.

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

[Adron]

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.