Also I think the launcher should provide a sane default for your FSO install directory — what is that sane default, though?
If we wanted to a provide a Current User/All Users type of option on certain platforms, that could be the difference between ~/games and /usr/share/games (I think that's a pretty typical location for *nix anyway). Macs should probably do ~/something. Not sure of a good place for Knossos content there, but I imagine this and many other problems have already been solved by Steam, since we're nearly duplicating that behavior. In fact, many questions being asked here could be answered by asking "How does Steam/Galaxy do it?" They are already solved problems, so no need to reinvent the wheel. If we have a good reason to do it differently, so be it, but I think doing the research into how those clients behave will at least help us answer the majority of questions about how a system like this should behave. People getting paid to figure this stuff out have already been doing it for years. And where there is room for improvement or something that better fits our ecosystem, we can diverge.
Also, as for documentation, I'd prefer the UI flow be intuitive enough that reading a lot of text isn't necessary - that, even more so than translations, would be a huge boost to the ability for international users to pick up on it. The more that can inferred simply from graphics and near-universal keywords, images, etc, the better. Aside from configuring the actual purchase transaction, how much reading is required to install a game on steam? See a pretty looking game, look at some screenshots, click the comically large Buy button, and once you pay it is installing. GOG Galaxy goes a step farther with their visual library presentation, which allows you to pick your game from a large picture of its box and then just hit Play. Lots to be learned from these UX examples and room for improvement too. Looking forward to mjn.mixael's ideas here.
No mod ever needs the 3D selection flags enabled; if the 2D art isn't present/defined, the 3D model is used automatically.
Hear hear. I'd love to see that option gone. And many others. I'm sure there's a few people that like 'forcing' these behavior changes on, but many of these are probably not worth the CLI clutter. Especially if we want to streamline FSO's configuration into a new environment.
Alternatively: Knossos/FS2 so you have a clean folder to have those TCs in.
I don't particularly like that idea, myself; imagine if your current FS2 install was in wxLauncher/FS2 and you wanted to switch to Knossos.
If we are planning on copying the retail FS2 data from wherever it might already be installed into the Knossos environment, this would actually be fine. I think starting with support for GOG, Steam, and manual install location is a pretty critical requirement, as getting FS2 itself configured and/or installed into Knossos is pretty much a dependency for anything else, and supporting the different means it could have been acquired by a newcomer is therefore a high priority. I still think copying the VPs into Knossos and leaving the existing install behind, if using a Steam install or a separate retail or prior install will result in the sanest environment for Knossos to work with. My previous suggested structure sounds in line with what Joshua was suggesting. One giant Knossos content folder (separate from the Knossos install itself probably) with folders for each TC, with FS2 itself being treated as a TC, with simply a special case for how its root content is acquired. After that, FS2, Diaspora, TBP, etc can all be on equal ground. Minimizing the amount of special treatment, and additionally keeping it to just the initial setup process, should lead to an easier to maintain project, that can have features added more rapidly.
I'm not fully caught up on the thread yet, but I do just want to bring up something about fsnebula.org. I do think it would be useful to have it look pretty, just so we could throw a weblink to a mod's page to people or in like in social media posts. So someone who might not have FS or Knossos installed might happen across a link, be impressed with the quality and start their way to the world of FreeSpace modding. With Steam, store pages render the same in your own browser or in steam itself (obviously because its all just html anyway). Just a thought anyway!
Agree. Mods should be able to publicly showcase on the website as well as within the client. However, if one has to take priority over the other initially, that would probably be ok. I think the web appearance can be focused on after the client look, but if it makes sense to try to unify them somehow, that might work best. Since both are presented via html, that might not be impossible.
Knossos should be able to directly open the Debug Logs or the folder to the Debug Logs.. or for bonus points, automatically upload them to somewhere and offer players a link they can post to the forums.
Useful idea, but I think this one is not as critical as some other core functionality for the most viable product offering. It doesn't mean much to someone just wanting to install and run games. Debugging features that help us out can probably be in a later revision. But now that I think about it, an influx of new users will almost certainly mean an influx of bug reports...so maybe it's not such a bad idea. But I'm really hoping we can design something that, by design, minimizes the possibility of 'user error', which has often in our case really been design error.
Where is Nebula hosted? Are we taking advantage of anyone here? If ngld died in the next 15 seconds, would we be able to mourn and then still maintain Nebula?
I had also attempted to set up the nebula on my own server at one point to see how hard a mirror, etc would be to set up.
Didn't quite get it.Oh, this is really cool! Is there a way to import the installation lists and stuff from the old java launcher/installer so Knossos is fully-featured to download more campaigns?
Personally I am hoping that each mod will be brought over one at a time, as I think there will be more information needed than what the old installer files provided. Although an importer on the Nebula portal to get what data is available (file locations, hashes) might be nice, if that data would be useful to Nebula.
There isn't (not yet anyway) but whenever you install a new mod, Knossos checks if you already have the required files and only downloads missing or changed files.
That said Knossos can still launch already installed mods. It won't be able to notify you about updates or repair the files.
EDIT: Damn. Can you please post your %APPDATA%\Knossos\log.txt?
This is nice that it is already complete, although I would have argued that supporting existing mod installations could have waited or been omitted entirely. I mentioned this in IRC earlier, but I feel like solving problems that only exist now, but won't after Knossos is considered widely adopted and won't exist anymore, don't need to be solved at all. I don't think people will avoid using it simply because it wouldn't work with existing FS2 and TC installs. But if it already can to some extent, that's cool too. If we did move to a system that groups all installed content under a single Knossos directory space, that could still come in handy if we wanted to support people taking existing downloaded data and placing it into the right folder name. I think following the KISS principle and not worrying about supporting edge cases like that is still going to be the more maintainable option though. Down the line, supporting things to help modders create new mods could probably be built in, taking much of the initial mod bootstrap out of the hands of the user. A button that makes a new mod folder for the given TC, with a mod.json or mod.ini or whatever basic field editor (or even a default template), a data folder, and an option to open that folder in your Explorer/Finder/etc. A link to a good wiki page on what to do next then would probably suffice. Then maybe even a VP packager and uploader integration to your Nebular account. Those last things could probably be a later phase. The first part would let people start working, without having to really manually muck with the rest of the filesystem.