[ngld]

@JeffPearson: Yes, the modsync logic currently doesn't work (unless you run Nebula locally) because the server hasn't been updated, yet, and doesn't serve the files that NuKnossos is looking for.
The Play tab is empty because you haven't selected a library folder and thus no installed mods. The Build tab tells you that the page couldn't be found because it hasn't been implemented, yet. If you're looking for a functional mod manager, you have to use the old Knossos source. I'm currently rewriting Knossos from scratch and it'll take a while before it's finished (as stated in the GitHub project and previous posts).

@praseodym: That's a bug that I fixed in my last commit. And once again: Why are you running each step separately? Why are you running the configure step in the middle of the build? That's not how the build system is supposed to be used and can end up causing the whole build to fail depending on which state your build directory is in before you start.
I'm trying to work with you but you keep ignoring what I say. I'll just ignore your future posts until you start listening (I'm fine with people using different approaches but I'd at least want to know why you're not doing what I ask you to do).

EDIT:
Here are the necessary steps to build and launch NuKnossos on most Linux distros (assuming Go 1.16+ is already installed):

Code: [Select]

git clone https://github.com/ngld/knossos.git
cd knossos
./task.sh configure build=Release static_deps=false
./task.sh client-run


[praseodym]

Did that and it worked so far. However, if I want to browse the folder

Code: [Select]

[0514/201824.120295:INFO:knossos_resource_handler.cc(142)] [65536;0  # 0/0]
[0514/201824.147077:INFO:knossos_resource_handler.cc(142)] [65536;2  # 2/2]
[0514/201824.147236:INFO:knossos_resource_handler.cc(142)] [65534;0  # 2/2]
Failed task client-run:
exit status 139Ideas?

[JeffPearson]

I didnt have any luck with d257775c

I did get it to build and launch after last update but...

@ngld OK cool I do have a working build of old knossos

[ngld]

@praseodym: Exit code 139 indicates a segmentation fault. I've figured out why it crashes and I'll push a fix tomorrow.

[praseodym]

If it helps: Today I got

Code: [Select]

/task.sh configure build=Release static_deps=false
Building build-tools...
Failed to parse tasks
Traceback (most recent call last):
  //tasks.star:112:43: in configure
Error in getenv: getenv: got 2 arguments, want 1

[ngld]

Should be fixed now.

[praseodym]

That worked, thanks.

However

Code: [Select]

[00:00]: Fetching remote index
[00:00]: Failed with error: failed to fetch index mods.UpdateRemoteModIndex.func1:github.com/ngld/knossos/packages/libknossos/pkg/mods/modsync.go:149 remote mod not found mods.UpdateRemoteModIndex:github.com/ngld/knossos/packages/libknossos/pkg/mods/modsync.go:139 storage.ImportRemoteMods:github.com/ngld/knossos/packages/libknossos/pkg/storage/remote_mods.go:33 bbolt.(*DB).Update:go.etcd.io/[email protected]/db.go:694 storage.ImportRemoteMods.func1:github.com/ngld/knossos/packages/libknossos/pkg/storage/remote_mods.go:42 mods.UpdateRemoteModIndex.func1:github.com/ngld/knossos/packages/libknossos/pkg/mods/modsync.go:149


[ngld]

Yes, the modsync logic currently doesn't work (unless you run Nebula locally) because the server hasn't been updated, yet, and doesn't serve the files that NuKnossos is looking for.

[praseodym]

Ok, understood. One question: When I run "client-build" separately, I am asked to run this command manually:

Code: [Select]

EXE="/home/$USER/knossos/build/client/launcher/Release/chrome-sandbox" && sudo -- chown root:root $EXE && sudo -- chmod 4755 $EXEObviously, "client-run" in the first place "only" does not ask this, as it doesn't ask for the PW. Is that command necessary, and why?

[ngld]

The instructions regarding the SUID binary come from Chromium and shouldn't be necessary on any modern Linux system. The chrome-sandbox binary is only used as a fallback if seccomp-bpf isn't available (any Linux kernel older than 3.5). For reference, here's the relevant Chromium doc.

Slight correction to the above: Chromium uses user namespaces (a kernel feature introduced in 3.8) instead of the setuid binary in modern kernels. Seccomp-BPF is used in addition to that if it's available to further harden the sandbox (with Seccomp you can restrict the available syscalls).

To clarify: chmod 4755 sets the setuid bit which means that the executable will always run under the user that owns the binary. Since you change the owner to root, that binary will always run as root. This was necessary before proper kernel APIs were available since only root had the necessary permissions to create a usable sandbox. However, this has the obvious drawback that any vulnerability in chrome-sandbox would allow privilege escalation. Since it's not needed for modern kernels and a potential security issue, I'd rather not use it which is the reason the build system skips that step.
The console message is printed by CEF's CMake script. I'll probably have to patch that script to remove the message. It's very low on my todo list since it only affects people that build Knossos themselves and in most cases, the binary isn't even used so following those steps doesn't really affect anything. While a vulnerability in chrome-sandbox could theoretically exist, it's very unlikely considering the state of the Chromium project (the amount of people looking for security issues, bug bounties, etc.).

TL;DR: You can run the command but it's unnecessary unless you're using a very old Linux kernel.

[R1PPER5]

Knossos 0.14.3 is only showing about a dozen mods.

I've deleted the .json file etc but not joy at all.

Running on Win10 It was all fine until a few days ago, I think!

[Trivial Psychic]

So I was using Knossos under Windows 7-64bit, but I recently upgraded my PC with an SSD and installed Windows 10-64bit onto it.  It unfortunately prevented me from booting Win7 after that, so I copied my FS2 core over to the SSD and reinstalled Knossos.  Now however, whenever I update to a new build of FSO, I not only lose the ability to access older builds, but I lose all of my command-line settings.  The older builds are still in the bin folder, but Knossos won't read them.  What am I doing wrong?

[jr2]

So I was using Knossos under Windows 7-64bit, but I recently upgraded my PC with an SSD and installed Windows 10-64bit onto it.  It unfortunately prevented me from booting Win7 after that, so I copied my FS2 core over to the SSD and reinstalled Knossos.  Now however, whenever I update to a new build of FSO, I not only lose the ability to access older builds, but I lose all of my command-line settings.  The older builds are still in the bin folder, but Knossos won't read them.  What am I doing wrong?

If you installed to separate partitions, try EasyBCD to re-add Windows 7 to your boot menu.  If you installed Win 10 over Win 7, well, not much you can do about that (besides un-install Win 10, then re-install to a separate partition as dual-boot).

[Trivial Psychic]

At this point I'm not concerned with reviving Win7, and to be clear, Win7 was installed on a 4TB hard drive, which is still connected and accessible, while Win10 is on a 1TB SSD.  I'm trying to find out why my Knossos (the copy I've installed on the SSD) seems to want to deny me access to any but my most recently installed build, any why it wants to forget all of my command line settings each time I update to a new build.

[ngld]

If you switch to the Home tab, click Details on the FSO entry and open the versions drop down on the Details page, do you see more than one version? The Update button by default installs the new version and deletes the previous version (since it handles FSO like any other mod). The easiest way around that is to switch to the details page for FSO (from the Explore tab), select the version you want to install and click the Install button.

The command line settings are stored separately for each version because each FSO version supports a different set of flags and fails if you pass unsupported flags. You can go to Knossos' settings screen, open the section for global flags, select a version you previously installed and click "Apply to all". Knossos will then copy those settings to all currently installed FSO versions (and will ignore unsupported flags for each version).

All of this is far from ideal but I'm fixing this in NuKnossos.
Quick status update regarding that: The updater is working which means I'll be able to publish the first alphas next week. Installing and launching mods is mostly working with a few bugs that I'll fix over the weekend.

[Trivial Psychic]

If you switch to the Home tab, click Details on the FSO entry and open the versions drop down on the Details page, do you see more than one version? The Update button by default installs the new version and deletes the previous version (since it handles FSO like any other mod). The easiest way around that is to switch to the details page for FSO (from the Explore tab), select the version you want to install and click the Install button.

THANK you!  That was the missing piece of the puzzle.  During my previous Knossos install, I had not installed FSO as a mod, but rather would update it through another mod's modify options.

[jr2]

Glad you got it sorted!

At this point I'm not concerned with reviving Win7, and to be clear, Win7 was installed on a 4TB hard drive, which is still connected and accessible, while Win10 is on a 1TB SSD.  I'm trying to find out why my Knossos (the copy I've installed on the SSD) seems to want to deny me access to any but my most recently installed build, any why it wants to forget all of my command line settings each time I update to a new build.

Oh this is (probably) even easier: activate one-time boot menu (F12 sometimes) during boot and choose the 4TB and you'll be in Win 7. But yeah adding is easier, and all you really have to do is

from an elevated command prompt, type the following, replacing D:\Windows with your actual path to your old Windows install:

Code: [Select]

bcdboot D:\Windows
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/repair-the-boot-menu-on-a-dual-boot-pc

If you had FreeSpace installed to a protected folder (User folder or Program Files) you might have to grant access by browsing there in File Manager.  But I imagine if that was the case it would have been an issue already.

[kellzverde]

I've been trying to get this to work on pop os for weeks now i keep getting exit status 1

Failed task client-run:
Task client-run failed due to its dependency client-build: exit status 1

[MachManX]

It's been a long time and I suddenly had the cravings to play some Freespace 2!   

I'm on Ubuntu 20.04 and wanted to try knossos but the one in the repository is the older 0.13.3 .  So I set out to compile this.  I tried "./task.sh configure static_deps=false"
 and got the following error:

//tasks.star:151:9: found inputs but no outputs

Can someone tell me what I need to do?

Thanks.

[jg18]

I've been trying to get this to work on pop os for weeks now i keep getting exit status 1

Failed task client-run:
Task client-run failed due to its dependency client-build: exit status 1

I'm not clear on the differences between Pop!_OS  and Ubuntu, but to be honest, I'm a bit doubtful you'll be able to get the game working on it. That said, if you'd still like to try, see my other response below.

It's been a long time and I suddenly had the cravings to play some Freespace 2!   

I'm on Ubuntu 20.04 and wanted to try knossos but the one in the repository is the older 0.13.3 .  So I set out to compile this.  I tried "./task.sh configure static_deps=false"
 and got the following error:

//tasks.star:151:9: found inputs but no outputs

Can someone tell me what I need to do?

Thanks.

There are slightly outdated build instructions that should point you in the right direction. The list of dependencies is a bit long, but I think you should be able to get everything from the Ubuntu repositories (plus the required Python modules using the pip tool).

Hope that helps. BTW, you'll likely have better luck getting help on the HLP Discord than on the forums.