Author Topic: PUBLIC BETA: Knossos 0.13.3 (combined launcher/installer)  (Read 33058 times)

0 Members and 1 Guest are viewing this topic.

Offline Fire888

  • 23
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Hm... do you have a log in C:\Games\FreespaceOpen\FS2\data\fs2_open.log ?

Yep! Here it is.

 

Online ngld

  • 29
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Is there a fs2_open.ini in the same folder as the log file? If there is, delete it and try running FSO through Knossos again.

 

Offline Fire888

  • 23
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Is there a fs2_open.ini in the same folder as the log file? If there is, delete it and try running FSO through Knossos again.

There isn't. The .ini is in appdata. I tried to delete that and then Knossos tells me "Failed to save the configuration" and crashes.

 
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
@Novachen: Sounds like the version requirements on FSO are conflicting. I should improve that error message. In the meantime, can you open the %appdata%\knossos\log.txt and check if it contains a message like "No version of mod "FSO" found for these constraints: ..." ?

No, unfortunately there is no entry in the log for this problem.
"This account was hacked.

'HLPisaverydetailedFS2communitymodcentre' was not a good password."

To the unknown hacker:

Because i am able to hack myself, i was able to break into my own account again.

Your changed password was not better in the end.

 
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
I can't use my joystick with Knossos. What am I missing?
I have attached fs2_open.log and fs2_open.ini. Please let me know if you need any further information.

Code: (fs2_open.ini) [Select]
[Default]
VideocardFs2open=OGL -(1920x1080)x32 bit
TextureFilter=1
Language=English
CurrentJoystick=0
CurrentJoystickGUID=6d0415c2000000000000504944564944
EnableHitEffect=0
SpeechVolume=100
SpeechVoice=0
SpeechTechroom=0
SpeechBriefings=0
SpeechIngame=0
SpeechMulti=0
LastPlayer=test
ScreenshotNum=8

[Sound]


 
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
It seems 3.8.1-20171118 (Revision dfdfd59) is OK. Latest Nightly 3.8.1-20180611 (Revision 15bda8c) doesn't work.

 

Online ngld

  • 29
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
@Fire888: Not sure what's going on in with your problem... Knossos is doing exactly what it's supposed to but for some reason FSO is trying to load its configuration from the wrong location. I've asked the FSO devs about it but they didn't have any ideas either... Sorry.

@Novachen: I'll look into it.
@Nikogori: At some point the nightlies got a newer SDL version which uses different GUIDs for the joysticks. Now I have to update Knossos to automatically detect which GUIDs to use based on the SDL version. It'll get solved eventually (I already have a solution in mind) but it'll take some time unit it's done. Until then you can either use an older build or put the correct GUID infs2_open.ini manually (your joystick's GUID appears in fs2_open.log).

 

Offline Fire888

  • 23
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
That sucks... D:

I've tried uninstalling and reinstalling, too, but to the same results. I guess I gotta use the old launchers ^^;

  
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
@Nikogori: At some point the nightlies got a newer SDL version which uses different GUIDs for the joysticks. Now I have to update Knossos to automatically detect which GUIDs to use based on the SDL version. It'll get solved eventually (I already have a solution in mind) but it'll take some time unit it's done. Until then you can either use an older build or put the correct GUID infs2_open.ini manually (your joystick's GUID appears in fs2_open.log).

Thank you! I have modified fs2_open.ini and now I can use my joystick with latest Nightly. Keep up the good work.

 

Offline Spoon

  • 212
  • ♪ ♬ ヾ(´︶`♡)ノ ♬ 淫画
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
So I installed the latest and greatest knossos to get inferno from it. And sure enough, it all works so nicely and smoothly. Exceeeeept...

For reasons I don't really understand, it somehow overwrites where the engine looks for all of its pilot and config files? Even in my completely seperate WoD dev folder where I use the good old 5.5g launcher, it somehow stops looking in the local installation but in effing AppData\Roaming\HardLightProductions\FreeSpaceOpen\data which is 7 folders deep onto my c: drive (which is a completely seperate drive from where I have any and all of my freespace stuff installed). This is super inconvenient and made me just uninstall knossos completely, because it messes with my workflow and it seemingly can't be configured anywhere.
Not to mention I just plain old hate having to look for things in appdata, its so far removed from everything and is just straight up inferior to just having things nicely in the local installation.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Online ngld

  • 29
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
That was a change introduced in FSO 3.8.0. I never was involved in that decision. IMO it was a very bad idea to silently introduce it and keep support for the old location.
I had to explain the same stuff so many times by now that I'm getting tired of it.
The FSO devs changed the settings location and Knossos (just like wxLauncher) uses the path dictated by the engine. If you don't like it, complain to the SCP. There's nothing I can do about it.

EDIT: Updated warning in the first post to make this fact clearer.
« Last Edit: June 17, 2018, 02:30:08 am by ngld »

 

Online m!m

  • 211
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Well, I submitted a change which fixes that behavior over a month ago but no one approved the code so it was never merged. I merged the change just now so it should appear in the next nightly build.
The engine will then select the config location which was changed most recently.

Just FYI, there is a good reason for keeping the config data in AppData since that location is always writable by the engine which may not be the case for the local installation directory. I can understand why that change might be annoying to some users so the changes I merged should make FSO work more consistently if a user still wants to use an outdated launcher.

 

Offline Spoon

  • 212
  • ♪ ♬ ヾ(´︶`♡)ノ ♬ 淫画
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
That was a change introduced in FSO 3.8.0. I never was involved in that decision. IMO it was a very bad idea to silently introduce it and keep support for the old location.
I had to explain the same stuff so many times by now that I'm getting tired of it.
The FSO devs changed the settings location and Knossos (just like wxLauncher) uses the path dictated by the engine. If you don't like it, complain to the SCP. There's nothing I can do about it.

EDIT: Updated warning in the first post to make this fact clearer.
Well you don't have to feel personally attacked or anything. I posted it here because I sort of assume that most of the relevant SCP members would look at this thread too.
You've done amazing work with knossos.

Well, I submitted a change which fixes that behavior over a month ago but no one approved the code so it was never merged. I merged the change just now so it should appear in the next nightly build.
The engine will then select the config location which was changed most recently.

Just FYI, there is a good reason for keeping the config data in AppData since that location is always writable by the engine which may not be the case for the local installation directory. I can understand why that change might be annoying to some users so the changes I merged should make FSO work more consistently if a user still wants to use an outdated launcher.
Sure, I get why appdata is picked, but I don't really get why this isn't just a thing the user can configure somewhere.
Either way, thanks for working on it.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Online m!m

  • 211
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Sure, I get why appdata is picked, but I don't really get why this isn't just a thing the user can configure somewhere.
Either way, thanks for working on it.
When I wrote that code I underestimated how many people would be using old and new launchers at the same time. My thought process was that someone would use an old launcher and then upgrade to a new one and never switch back. That was accurate for most (but not all) users until Knossos appeared which supported the new location but some users still wanted to use their old launcher at the same time. Since, in my mind, the situation was that everything would be done automatically, there would be no reason to have a config option to customize this behavior.

Also, since FSO needs to determine from where to read the configuration data before actually reading that data it was impossible to check what the user specified in the launcher.

Anyway, this should hopefully be fixed now. Please let me know if the next nightly still shows the buggy behavior.

 

Online ngld

  • 29
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
@Spoon: Sorry, I was in a bad mood yesterday and the frustration got to me.
You've done amazing work with knossos.
Thanks!

If I added support for FSO's "-portable_mode" in Knossos, wouldn't that also solve the problem? The config files would once again be stored in FSO's root directory (which is already managed by Knossos anyway). I would just need to figure out how this would affect TCs since they use a different root directory than FS2 mods. Most likely I can just solve this by copying the config files.

 

Offline Spoon

  • 212
  • ♪ ♬ ヾ(´︶`♡)ノ ♬ 淫画
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
When I wrote that code I underestimated how many people would be using old and new launchers at the same time. My thought process was that someone would use an old launcher and then upgrade to a new one and never switch back. That was accurate for most (but not all) users until Knossos appeared which supported the new location but some users still wanted to use their old launcher at the same time. Since, in my mind, the situation was that everything would be done automatically, there would be no reason to have a config option to customize this behavior.

Also, since FSO needs to determine from where to read the configuration data before actually reading that data it was impossible to check what the user specified in the launcher.

Anyway, this should hopefully be fixed now. Please let me know if the next nightly still shows the buggy behavior.
Gotcha, I understand your thought process.
I'll let you know.

@Spoon: Sorry, I was in a bad mood yesterday and the frustration got to me.
You've done amazing work with knossos.
Thanks!

If I added support for FSO's "-portable_mode" in Knossos, wouldn't that also solve the problem? The config files would once again be stored in FSO's root directory (which is already managed by Knossos anyway). I would just need to figure out how this would affect TCs since they use a different root directory than FS2 mods. Most likely I can just solve this by copying the config files.
No worries, I understand it can be frustrating when you keep hearing the same issue that you can't do anything about.
When I tried the portable mode in the 5.5g launcher it didn't solve anything for me. No idea how or what it would do when added to knossos.
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
If I added support for FSO's "-portable_mode" in Knossos, wouldn't that also solve the problem?
-portable_mode is kind of not working right; it should work if you combine it with -parse_cmdline_only, though.

EDIT:
When I tried the portable mode in the 5.5g launcher it didn't solve anything for me. No idea how or what it would do when added to knossos.
It can't work with the 5.5g launcher, because portable mode still doesn't use the registry; in fact, FSO being in portable mode will specifically make sure it doesn't use the registry.
« Last Edit: June 18, 2018, 03:25:39 pm by AdmiralRalwood »
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Online m!m

  • 211
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
I'm trying to play Trimurti but I get the following error message:
Code: [Select]
"<Mod "Trimurti" 1.1.0 (shv)>" requires "FSO" which is missing!
I definitely have an FSO build installed but I use the nightly stability in the settings so it may be related to that. Where does Knossos store its log file on Linux? I looked for it in ~/.local/share/knossos but that directory does not exist in my case.

 

Online ngld

  • 29
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
Sorry for the late reply... The log should be in ~/.config/knossos. Solving the problem will be much easier with a proper log. My guess would be that either you no longer have the stable version of FSO installed (3.8.0) or Knossos somehow got confused with the various FSO versions and their stabilities.

 

Online m!m

  • 211
Re: PUBLIC BETA: Knossos 0.10.1 (combined launcher/installer)
I do have both versions of 3.8 installed but my stability setting is "nightly". When I set it to "Stable" the same error appears.

Here is the log:
Code: (log.txt) [Select]
INFO:MainThread:launcher.main: Running Knossos 0.11.0-dev+61b73bf on PyQt5 and Python 3.6.5 (default, Mar 29 2018, 18:20:46)
[GCC 8.0.1 20180317 (Red Hat 8.0.1-0.19)].
INFO:MainThread:launcher.main: OpenSSL version: OpenSSL 1.1.0h-fips  27 Mar 2018
DEBUG:MainThread:launcher.main: Loading resources from data/resources.rcc.
DEBUG:MainThread:launcher.main: Loading settings...
DEBUG:MainThread:util.call: Running ['7z', '-h']
WARNING:MainThread:integration.init: Failed to specify Unity version. Most likely Unity is not available.
INFO:MainThread:integration.init: Activating generic Linux integration...
DEBUG:MainThread:windows.watch_task: Task "Loading installed mods..." (139718982286792, <class 'knossos.tasks.LoadLocalModsTask'>) started.
DEBUG:MainThread:windows.watch_task: Task "Fetching mod list..." (139718982286936, <class 'knossos.tasks.FetchTask'>) started.
DEBUG:MainThread:windows._forget_task: Task "Loading installed mods..." (139718982286792) finished.
DEBUG:Thread-10:connectionpool._new_conn: Starting new HTTPS connection (1): fsnebula.org
DEBUG:Thread-10:connectionpool._make_request: https://fsnebula.org:443 "GET /storage/repo.json HTTP/1.1" 200 None
INFO:Thread-10:repo.add_mod: Mod "DWA1" (2.0.0-A) from "https://fsnebula.org/storage" overwrites an existing mod version!
WARNING:Thread-10:repo.add_mod: Mod <Mod "FSO" 3.8.1-20171029 (FSO)> is empty, ignoring it!
WARNING:Thread-10:repo.add_mod: Mod <Mod "FSO" 3.8.1-20180302 (FSO)> is empty, ignoring it!
WARNING:Thread-10:repo.add_mod: Mod <Mod "FSO" 3.8.1-20180419 (FSO)> is empty, ignoring it!
DEBUG:MainThread:windows._forget_task: Task "Fetching mod list..." (139718982286936) finished.

EDIT: I ran Knossos in a debugger and saw that in runner.py, line 301 an exception is thrown with the error message "No version of mod "FSO" found for these constraints: >=3.8.0-3 (FSO),* (FSO),>=3.8.0-2 (FSO),==3.8.0-2 (FSO)". It looks like there may be an invalid version specifier somewhere.

EDIT2: I found the package with the wrong configuration. The fsport "Content" package has a version specifier for FSO which says "3.8.0-2" but Trimurti has a specifier which says ">=3.8.0-3". Setting the fsport version requirement to ">=3.8.0-2" fixes the issue I reported.
« Last Edit: June 26, 2018, 07:51:07 am by m!m »