[ngld]

I've implemented that and it seems to work well. The only downside I've discovered is that the download speeds can be very random since the mirrors have different download speeds. Depending on which mirror Knossos uses I can get a download speed of 700 KiB/s, 3 MiB/s or 11 MB/s for the same file.

[niffiwan]

@niffiwan: That's not an error, what you're seeing are the remains of the "Last Played" page. Did you try to click on "Home" or "Explore"?

Yes, no matter what button I click on nothing changes (i.e. help, refresh, settings, home, explore, development).  If I click on Play, my "Last selected mod" plays, but that's the only change I currently get   (and if that's expected, no worries! I was just hoping to marval a bit at the awesome UI )

[Hunter]

Thanks for the offer! Would you mind if I automatically mirror every uploaded mod? (Whenever a user adds a new mod, I would upload the files to FSFiles and link them in addition to dl.fsnebula.org and the links the user entered?)

Sure.. just be sure to place them in the right sections and check if they already exist. If the mods aren't finished or are just test builds, just pop them in the WIP folder.

[jr2]

IIRC if you wish to automatically port forward, you use UPnP, which of course might be disabled (link to discussion on that).

Looks to be a how-to on requesting a UPnP port forward in Python here.

Of course, it might be a lot more trouble than it's worth, I don't know.

[ngld]

@niffiwan: I think you've found a WebKit related bug, I'll look into it. (Ubuntu doesn't package QtWebEngine which Knossos uses on most platforms so it has to fallback on QtWebKit which is deprecated.)
@mjn: I've integrated your last changes and I managed to do the dropdown toggle using CSS only which solves the JS problems and is a nicer solution IMO.


I need to decide how (and where) to store the installed files considering the proposed concepts, I've come up with the following:
Knossos has one "content directory" which is where installed content will be placed. The first time you start Knossos, it will ask you for this location and will offer a default which should be fine for most users.
On Windows that default will be C:\Users\<user>\My Documents\Knossos, on Linux and macOS it'll be ~/Documents/Knossos. Afterwards, the user can use Knossos to install TCs and FSO. If they try to install a mod (which depends on retail files), a dialog will be shown which tells them as much and allows them to select the GOG installer or an existing FS2 directory. If they already have installed FS2 through either GOG or Steam, Knossos should be able to detect it and will offer to copy the neccessary files.

The content directory will contain a subdirectory for every TC installed and one directory for FS2. All mods which depend on a TC will be installed into the TC's folder (i.e. Aerilon is Burning would be installed into Diaspora's folder).
Another subdirectory will be "bin" which contains a folder for every installed FSO build (official releases, Nightlies, custom builds).

To allow for more specialized installations and to support existing FSO or TC installs, Knossos will allow the user to specify a list of additional base directories. Each directory is assumed to contain a TC unless it contains the retail files at which point it's assumed to contain FS2 mods.

If you don't use the additional directories, your content directory will look something like this:
Knossos_content
 -bin
  --3.8\
  --nightly_YYYYMMDD\
 -FS2
  --retail .vps
  --BPC
  --BtA
 -Diaspora
  --Diaspora_mod1
 -TBP
  --Zathras

If you want to use your existing FSO installation and have Diaspora installed, the directories could look like this:

Knossos_content
 -bin
  --3.8\
  --nightly_YYYYMMDD\
 -TBP
  --Zathras

FS2
 -retail .vps
 -BPC
 -BtA

Diaspora
  -Diaspora_mod1

I hope this makes initial setup simple while still allowing for custom configurations. Any thoughts or suggestions?

[niffiwan]

@niffiwan: I think you've found a WebKit related bug, I'll look into it. (Ubuntu doesn't package QtWebEngine which Knossos uses on most platforms so it has to fallback on QtWebKit which is deprecated.)

Doh! How do you distribute Qt on other platform? Do you bundle it into Knossos? Is it possible to consider the same approach on Linux?

I hope this makes initial setup simple while still allowing for custom configurations. Any thoughts or suggestions?

Seems like a good layout to me.

[mjn.mixael]

Sounds good to me to. The only thing I might add is a first-run prompt. (with better wording than the following) "Do you want to install the base Freespace2 game right now?" Yes/No.

Given that option.. we should add a filter to the filters list... "Doesn't require FS2" (Not Total Conversion because that's a non-intuitive title)

[m!m]

If you don't use the additional directories, your content directory will look something like this:
Knossos_content
 -bin
  --3.8\
  --nightly_YYYYMMDD\
 -FS2
  --retail .vps
  --BPC
  --BtA
 -Diaspora
  --Diaspora_mod1
 -TBP
  --Zathras

How would this work with different versions of the same mod (e.g. Mediavps 3.6.12 and 2014)? Would it require that these different versions are separate mod entries or would it put the different versions into different subfolders?

[ngld]

The MediaVPs are a special case. I treat the two versions as separate mods because a) most people here would be confused if they were displayed as a single mod and b) 2014 is a horrible version number.

For other mods the current installation logic checks if the mod folder exists (only happens if you install more than one version) and then appends _kv_<version> to the new folder. If you install a mod called Example, then install versions 1.0.0 and 1.0.2 of that mod, you'd get:

Knossos_content
 -FS2
   --Example
   --Example_kv_1.0.0
   --Example_kv_1.0.2

I've thought about subfolders before but that can become complicated unless I always use subfolders.

[chief1983]

This is another reason why I feel like trying to work with existing installs as anything more than a source to copy VP files from, is going to make this project complex to the point of likely failure.

I'll reiterate that, I think that for the success of this launcher/installer, it needs to work with an ecosystem built from the ground up.  Any support for existing installs needs to be minimal, like I said, maybe we scan for VP files we need to download and copy them into the new structure if necessary, but beyond that, the added complexity seems to me to outweigh any benefits.

The MediaVPs are not really an exception here, I don't think.  They need to be manually converted into a Knossos style dependency format just like any other mod.  But as there are different major revisions of the mediaVPs, I think we might need a concept of slots.  Or at least, as stated, we don't treat 3.6.12 and 2014 as the same mod with different versions, but yeah, different mods.  They could both be selected as primary mods, or individually be a dependency of other mods.

We will probably run into the need for this with other mods as well, so I am hoping there is a framework for this that can be applied as necessary.  If people want to play "Media VPs FS2" they probably shouldn't be provided with multiple versions by default, just the latest.  But there would be cases where someone might need to launch an older 'slot' of a mod, maybe someone wants to launch Diaspora R1 after R2 is released, an old MediaVPs version, etc.  That might be better kept under the developer section or something.  But to keep the initial interface clean, we need to ensure we don't overflow it with deprecated slots of mods.

I agree that 2014 is a bad version number, which is why I think each mod needs to be brought into Knossos with entirely new versioning where possible.  We may not even be able to go that far back in time to find mods that currently work in the new ecosystem without some work cleaning them up, so reusing old VP files, and worrying about old version numbers is something I think we can avoid.

My main hope is that this new system looks so promising that it reinvigorates the Campaign Restoration Project and other people to start updating mods to the point of at least getting them running on recent builds so they can be added to Knossos and made available.  It would be a significant undertaking perhaps, but that's what the CRP was created for.  Karajorma has been working on TBP for instance, and may be interested in using Knossos for its next release.  I would still very much love for this to be the platform for FotG when it is publicly released (hopefully very soon), and I keep hearing that Diaspora is approaching R2 (seen the new eyecandy shots?).  There's three different total conversions that could very possible be on the coattails of the 3.8 release.  If all of this can fall together it would be a huge incentive to get FS2 mods updated to working with recent FSO releases for inclusion in Knossos.

[mjn.mixael]

So, the MediaVPs versioned the way we did precisely because something like this installer/tool did not exist. We needed it to be absolutely clear that mods built for MediaVPs 3.6.12 probably wouldn't work well with MediaVPs 2014 until that mod was updated. Basically, because of what the MediaVPs does, it made more sense that each release be it's own mod to ensure the broadest compatibility, both forwards and backwards, so that people would keep both versions around.

However, if Knossos treated the MediaVPs as a single mod and could handle using older versions as a dependency (using version'd subfolders or whatever) without displaying that older version as a primary playable mod.. then there's no reason for the MediaVPs to continue on as such. Mod X that uses MediaVPs 3.6.12 can run, because Knossos knows how to handle that gracefully and the player doesn't even need to know or care. The only "MediaVPs" that should be selectable on the Home tab is the latest version.

If this becomes the case, then I'll recreate the MediaVPs mod on Nebula so that it includes versions as early as 3.6.10 ensuring broad compatibility with older mods going forward. (We could add those old mods to Nebula by simply making sure their mod meta data is updated to fit into Nebula's newer standards, minimizing the work to make these mods accessible.)

EDIT: To clarify... since versions would be essentially invisible to the average player, I would re-version MediaVPs 2014 to 3.6.14 for the sake of Nebula's graceful handling of it. Nebula would have 3.6.10, 3.6.12, and 3.6.14 available for mods. (I don't have 3.6.9 or anything prior to that... Zeta3.6.8?, but 3.6.10 should be enough for backwards compatibility.)

[m!m]

IIRC, the new mod format supports restricting which version of a mod it depends on. Furthermore, it allows to specify a dependency that says "everything that is compatible with version x" where "compatible" means that the major version of the dependency must be the same. If mods follow the Semantic Versioning theme then a mod could specify a dependency on version 4 (which could stand for the 2014 version) of the MediaVPs and Knossos would use the most recent 4.x release of the MediaVPs but not the 5.x version.

This probably sounds very complicated to people who don't know about semantic versioning but IMHO it would be a great way to ensure that mods always use the most recent version of a dependency that works with this mod.

[mjn.mixael]

Pretty much what I was trying to say but you did it more clearly.

[mjn.mixael]

ngld, a note about the rollouts.. they currently only close when the user clicks anywhere outside of them. They should probably also close under theses other two conditions..

1. The user clicks on the rollout button again.
2. The user's mouse leaves the rollout for a few seconds.
3. The user's mouse is no longer hovering over the mod. (Currently, you can open a rollout, mouseover a different mod, then mouseover the previous mod and the rollout will still be open.)

These are things I'm not quite sure how to do with CSS only, but they are also small nitpicks that can be dealt with later. It's more important to start getting the meat of Knossos Nebula working.

[pim]

Hi ngld.
 How about us with two GPUs on Linux? Playing at 4 fps with integrated card is more painfull than watching Fifty Shades Darker with own ex:-).
 Is there any way to use primusrun for running fso from within Knossos?

In any case - Knossos looks promising. Good luck with further development.

[Phantom Hoover]

Have you tried running Knossos itself with primusrun?

[pim]

Sure. Didn't help.

[Phantom Hoover]

OK, well, if you need a stop-gap, launching FSO from Knossos, quitting, then directly running 'primusrun <your FSO binary>' from the command-line should work.

[pim]

No problem. I'm used to start fso from shell. I just thought that public beta is here to find possible issues so I reported the only problem I've encountered:-). Bye.

[karajorma]

That's exactly what it's for.