scp-fs2open
Proposed text-based "advanced mode" events editor for QtFRED
FRED's traditional hierarchical menus for creating and modifying mission events is great for making sexps discoverable and accessible to newcomers, but for people who already know many sexps, all the hunting and pointing and clicking and having to remember where the sexp you want is located in the menu system is a huge drain on productivity, much like many other "friendly" graphical interfaces for largely text-based tasks. Since QtFRED is a comprehensive rewrite of FRED, now is the time to consider an alternate event editor--a text editor, with which you would write events, manage variables, etc. the same way you would write the Lisp code that FreeSpace sexps are inspired by. Such an editor could be specially tailored to the needs of FreeSpace events, with syntax highlighting and keybindings for common tasks, and sanity checking to prevent passing garbage data to the other parts of the editor. This could greatly streamline mission design for intermediate and advanced users and eliminate what is probably the most boring and tedious part of using FRED.
We should really finish qtFRED before we think about adding such elaborate and expansive features as this. Besides, it is already possible and in fact pretty easy to make the necessary edits in Notepad. A program like Notepad++ already has far more features than any SCP coder could be expected to implement.
We should really finish qtFRED before we think about adding such elaborate and expansive features as this. Besides, it is already possible and in fact pretty easy to make the necessary edits in Notepad. A program like Notepad++ already has far more features than any SCP coder could be expected to implement.
So uh, first of all I apologize for the timing being late and awkward but I object to discouraging ideas from being set forth even if the product they're for isn't ready for them.
The basis being, is that ideas come when they want to, regardless if we're ready for them or not and regardless if they can be applied right then and there. Ideas do need some place to be jotted down and stored, and they do need some curation in order to see if they can be fit into the projects, if they need modification, or if they have to be scrapped.
Now, with that said, the github issue tracker is not the best of platforms to keep track and curate all ideas, especially since tieing together issue cards as a sort of dependency network can get messy. I do understand the stance that the workers should focus on the basics first and new ideas can disrupt that focus when they pop up during implementation, but there needs to be a balance between dreaming up new ideas and making them fruition.
I've been pushing towards using github for feature requests and idea management, because its what I've been using the manage the controls code project through the use of note cards and issue cards, something similar could be done here, but unfortunately I don't yet have my own system of creation that I can stick to consistently so I can't offer a clear insight into a solution.
I don't strictly want to discourage ideas, but the path from idea to working product is a long one. Ideas are great, but they are also cheap. I don't want to see this section turn into a giant wish list. It's also discouraging to coders to see the long-term of issues going up instead of going down.
Those are fair points about platforms and trackers. It would be nice if we had a way to partition issues into "wish list", "near term feature request", and "bug". And not just using github's labels, but actually visually isolating the categories.