Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
I've been inspired by coinage to make a bot that helps with world building. For this bot, I decided to try something that, from what I've seen, none here seems to have tried before: Create a console bot with huge functionality and a decent interface.
The reason for this choice is that I use Linux, and it'd be ridiculous to make a bot with a GUI I wouldn't even be able to test. And I've had trouble with Gtk#'s compatibility on Windows before. Meanwhile, as long as no native calls are invoked, console bots should run everywhere. I could create a web app instead of a stand-alone app, but I feel really uncomfortable with them.
Source: https://paste.ubuntu.com/p/xxWjr96XJZ/
I managed to create a personally comfortable interface consisting of 3 lines of header, for the title, and 3 lines of footer, to tell the user what to do. I really like how it's looking. I plan on finishing this bot regardless of feedback, as it'll be useful for me at the moment of building worlds.
I want to know what you think about the idea of creating a "console" bot overall, rather than the bot itself.
My opinion: "I believe that console apps can be tuned as much as graphical apps, and the same functionality of these can be achieved through pure keyboard input. This allows the bots to be used on command-line-interface computers and servers, on computers without mouse (although who would use a computer without a mouse?), and depending on the user, can become easier to use."
Offline
Ive made a fair few before, and they are fairly easy to make and use as long as you dont want a log of chat or something, as you would then have both input and output happening at the same time, which gets quite difficult to deal with
Offline
A command-line menu navigated with the arrow keys will never be as convenient as clicking a button on a GUI.
CLI might only be more powerful after a huge amount of user-specific tuning - for instance by mapping every action to a key - and ain't nobody got time to either build or correctly configure something like that. Maybe they do, but it's not worth the effort to get it to a point where it outperforms a GUI.
The only time I might consider console over WinForms is in a bot that either does very little or requires very little interaction. This might be in something like a passive moving-platform BAL, a keyhook bot for power-editing a world, or a simpleID lookup table. Even then, a bot with a very simple or blank GUI could achieve the same things, and there's no point in taking into consideration the lighter weight of a console app on a modern PC.
Nah, I reckon the people who still make console bots do so because they like feeling cool, or started with CLI programs and are used to them. There's really not much point; the only reason CLI is even an option is because Visual Studio lets you do it. If I installed a program in this day and age that had a CLI and wasn't something like Git, I'd uninstall and go find something made by a sane person with usability in mind. What is this, 1980?
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
To LukeM: I've been able to work with both input and output on an experimental chat client. It's not that difficult to me.
To Tomahawk: Commodity with console bots, and non-breaking factors such as appearance, are fully practical and subjective. If they're comforting to the developer, it's what matters. In fact, console apps don't necessarily have to be pure keyboard input. It's possible to detect clicks on a console with platform-specific libraries. With small platforms checks and proper use of those, it's possible to create a console app that can be used like a form, without the need of graphical tool kits. It might be too much effort for the developers, but it's practical, not a restriction. Program usability, however, is technical, and it's the reason I picked console.
I've never had anything wrong with graphical apps. I'd pick them with console apps as a fallback, a last resort for users who for unknown reasons, can't run the graphical versions. The reason I picked full console for my project is the lack of a cross-platform graphical tool kit, which really limited my choices. I focus on making a bot that can be run by the most possible people, not a comforting bot for a small amount of people. I could pick Gtk#, but it'd mean only I would be able to use my bot. And I'm not going to move to Windows for the benefit of the majority. I'd rather make a bot that both Linux and Windows communities can use.
Offline
To LukeM: I've been able to work with both input and output on an experimental chat client. It's not that difficult to me.
So it doesnt mess up if you start typing something in the console, then it recieves a message before youve finished? If so (and its not messy) I'd like to know how, because Ive only been able to do it with annoying, unreliable and messy handling of the input one character at a time, and keeping it in a string which is removed then reprinted whenever theres a new output
Nah, I reckon the people who still make console bots do so because they like feeling cool, or started with CLI programs and are used to them. There's really not much point; the only reason CLI is even an option is because Visual Studio lets you do it. If I installed a program in this day and age that had a CLI and wasn't something like Git, I'd uninstall and go find something made by a sane person with usability in mind. What is this, 1980?
For me its just faster to make, as if all that I would have on the form is three inputs, a button, and a log, I might as well use a console app instead where this is built in
Offline
My chat client had an input line in the bottom, and it'd print the message from the top to a line before the input box. It was similar to the IRC Client: HexChat, but on console, and for EE.
The cursor would only move to the top when a message was received, and back to the bottom for typing, placed depending on the user message's length. It was tedious when I first tried, but once I got it, it was easy peasy.
I even made it so the message would crop when it reached the end of console. Was the real struggling part, but was fun.
Offline
I'm not entirely sure I understand the topic. Is it an announcement of a console based bot? Are you only making your opinion public related to console bots? Are you asking our opinions?
I'll assume all of the above.
Historically people moved from console based applications to graphical ones because they wanted to attract more users, to feel natural, to reduce interface complexity.
I'm sure you know people who haven't seen a terminal in their life. There's a minority of people who are comfortable using a terminal.
So the fact you're saying that "I focus on making a bot that can be run by the most possible people, not a comforting bot for a small amount of people." comes somehow as a contradiction to me.
I do not deny the fact that there are some cluttered GUI applications which feel suffocating. But generally speaking your choices are displayed more clearly in apps which use a GUI .
I could create a web app instead of a stand-alone app, but I feel really uncomfortable with them.
This seems like an idea worthy of being exploited.
A web app can also be an ostrich-camely native app with the help of electron.
A HTML5 bot would allow it to be run on phones, and tablets as well. Which might be a good idea considering you want to create a world building assistant. I can already picture how cool it would be to have the EE world on the computer, and a tablet as a dashboard / minimap draw pad.
However this fantasy isn't based on any concrete fact on how this bot would help world development in any substantial way.
Everybody edits, but some edit more than others
Offline
My handful of cents...
it'd be ridiculous to make a bot with a GUI I wouldn't even be able to test
By this, do you mean you can't test if the GUI would work on a Windows/Mac?
Well you can test it (on Windows at least). Just run a virtual machine running Windows, toss your bot on it and you're set! (obviously takes a bit of work... But it's far from hard or uncommon to do).
Sadly for Mac you might be out of luck.
Aside from that, a CLI can have issues just as easily as a GUI. For example a CLI application is much harder to scale with screen size. On a big screen and/or with a small font size you'll probably just end up with tons of unused space (if run on the full window).
as long as no native calls are invoked, console bots should run everywhere
Native calls are managed by (dot)net. You can access the file system just fine in both Windows and Linux with the exact same code. Just make sure you handle special directories (like the user directory) correctly.
And when you want to use features that other systems don't have (for example the new MacBook touchbar), make sure your UI has alternatives. And again, handle it in your code when the feature doesn't exist.
This allows the bots to be used on command-line-interface [...] servers
Generally server applications are meant to be configured, ran and left alone on the server. You'd then use this application through other applications or interfaces (like through commands in EE).
The reason behind this is because a server is a server. You don't sit behind a server and use an application. You open the application to your home computer through, for example, a website.
I do not deny the fact that there are some cluttered GUI applications which feel suffocating. But generally speaking your choices are displayed more clearly in apps which use a GUI .
I would like to add to this, that if a GUI application isn't comfortable to use, that's a problem of us developers we'd have to (and can) fix.
Now I don't mean to say that CLI is per definition inferior over GUI. Both just have pros and cons. Just know that generally, the biggest audience will prefer a (good) GUI.
Now I'm broke, no more cents left...
Offline
Pages: 1
[ Started around 1734008675.0358 - Generated in 0.060 seconds, 18 queries executed - Memory usage: 1.52 MiB (Peak: 1.67 MiB) ]