Jump to content

CKAN (The Comprehensive Kerbal Archive Network); v1.28.0 - Dyson


politas

Recommended Posts

Hey there

I'm trying to install some additional mods into a 1.4.5 RSS/RO installation and I get the following error from CKAN 1.26.2 for two of the mods

One or more downloads were unsuccessful:
	Error downloading NearFutureLaunchVehicles 1.1.6: No connection could be made because the target machine actively refused it 5.9.16.54:443
Error downloading SCANsat v18.7: No connection could be made because the target machine actively refused it 5.9.16.54:443

Any thoughts on these? All other mods I selected downloaded fine (including other Near Future components). I've also posted individual errors to each of those mods forum threads, so hopefully wherever the problem is can be identified.

Thanks

Link to comment
Share on other sites

@strudo76 Currently, spacedock is down so CKAN cannot download mods which are hosted there. VITAS (creator and maintainer of spacedock) already knows about the issue so we just need some patience :)

You can still download the .zip file from github or curseforge and import it into CKAN though :) 

edit: Spacedock is back online :)

Edited by 4x4cheesecake
Link to comment
Share on other sites

Maybe someone of you can help me. I haven't found the info (my fault, I guess it must be written somewhere) ...

1) if I update my mod... is it enough to put a new .version file online and create a new release? (it's done via Github)

2) ... what if I have 2 zip files of my release online (one contains the "normal" release, the other one is the "debug" release) ... do I have to specify this in the .netkan file??

Link to comment
Share on other sites

2 minutes ago, Rudolf Meier said:

Maybe someone of you can help me. I haven't found the info (my fault, I guess it must be written somewhere) ...

1) if I update my mod... is it enough to put a new .version file online and create a new release? (it's done via Github)

Yes, there's a bot that crawls all known netkans and checks for new releases every 4 hours.

https://github.com/KSP-CKAN/CKAN/wiki/How-does-CKAN-work%3F

2 minutes ago, Rudolf Meier said:

2) ... what if I have 2 zip files of my release online (one contains the "normal" release, the other one is the "debug" release) ... do I have to specify this in the .netkan file??

Yes, this is done by adding "asset_match" to the end of your $kref, followed by a regex to match the desired asset:

    "$kref"        : "#/ckan/github/krpc/krpc/asset_match/krpc-[0-9]+\\.[0-9]+\\.[0-9]+\\.zip",

https://github.com/KSP-CKAN/NetKAN/blob/8b30c2d959e8371d6e1acf5fdabf1529b88f79c7/NetKAN/kRPC.netkan#L4

Link to comment
Share on other sites

Hey, I am a beginner with CKAN and have been moving my modlist to it. However, a few of my mods (they are all from Wild Blue Industries) aren’t there. Is there a way I can set it so that I can toggle the mods (and maybe their dependencies) from CKAN?

Link to comment
Share on other sites

26 minutes ago, MoonstreamInSpace said:

Hey, I am a beginner with CKAN and have been moving my modlist to it. However, a few of my mods (they are all from Wild Blue Industries) aren’t there. Is there a way I can set it so that I can toggle the mods (and maybe their dependencies) from CKAN?

What do you mean with toggling? CKAN can't turn mods on and off, it's not a modloader. The CKAN client is only a installation utility.

You have to download and install unavailable mods manually, however it should work if you install dependencies via CKAN, provided that they are available on CKAN.

The CKAN client will show manually installed mods as "AD" - auto-detected. But you can't interact with them. To remove those mods again, you have to manually delete the files from GameData.

Link to comment
Share on other sites

7 minutes ago, DasSkelett said:

What do you mean with toggling? CKAN can't turn mods on and off, it's not a modloader. The CKAN client is only a installation utility.

You have to download and install unavailable mods manually, however it should work if you install dependencies via CKAN, provided that they are available on CKAN.

The CKAN client will show manually installed mods as "AD" - auto-detected. But you can't interact with them. To remove those mods again, you have to manually delete the files from GameData.

What I basically mean is, can you have CKAN cache manually downloaded mods?

Or is there a different mod that allows you to toggle mods without deleting them or having to start up KSP?

Or, is it possible to make a “fake” GameData folder to put the mod into, and then make KSP look a that instead for mods?

Link to comment
Share on other sites

3 hours ago, MoonstreamInSpace said:

What I basically mean is, can you have CKAN cache manually downloaded mods?

If you only downloaded those mods yourself, but they would be available via CKAN, you could use the "Import downloaded mods" option, and if I'm not mistaken, this adds them to the CKAN cache.
But in your case the mods are not available on CKAN, so you can't use the import function. So unfortunately no way that CKAN can save those mods in its own cache.

If you want, you can move the zips yourself in the same folder that CKAN caches its downloads in, so you know where to search them later on.
Go to Settings > CKAN Settings > Under "Download Cache" click "Open".
Make sure you are using the current CKAN version, v1.26.2 if you do this, there was a bug with non-CKAN files in the cache folder that got fixed.

But this still doesn't allow CKAN to (un)install those mods. :/

Edited by DasSkelett
Link to comment
Share on other sites

is there something like a "max_version_exclusive" ?? so that I could say, my mod is compatible with mod xy max_version_exclusive 4.0 which would then be everything before 4.0? ... instead of writing 3.9 or 3.99 or 3.999 or 3.999999... I mean... how many 9 do I have to add until it's enough? :) ... or "max_version" to "<4.0" ?

Edited by Rudolf Meier
Link to comment
Share on other sites

1 hour ago, Rudolf Meier said:

is there something like a "max_version_exclusive" ?? so that I could say, my mod is compatible with mod xy max_version_exclusive 4.0 which would then be everything before 4.0? ... instead of writing 3.9 or 3.99 or 3.999 or 3.999999... I mean... how many 9 do I have to add until it's enough? :) ... or "max_version" to "<4.0" ?

You could set ksp_version_max just to 3, this includes every 3.X.

So for real KSP versions, set ksp_version_max to 1.3: All 1.3.X are included as compatible, 1.4(.0) not.

This is only possible if the min_version is a different minor, let's say 1.4(.X). But if the requirements haven't changed for KJRNext, this shouldn't be a problem for you

See for example this commit.

Edited by DasSkelett
Clarified that I meant KSP versions
Link to comment
Share on other sites

20 minutes ago, DasSkelett said:

You could set max_version just to 3, this includes every 3.X.

oh... interesting... thanks

(I need it for mod versions, not for ksp... because IR Next conflicts with mods of version prior e.g. 4 ... and what I also don't know is if I can include a max_version in the "conflicts" part)

Link to comment
Share on other sites

Just now, Rudolf Meier said:

oh... interesting... thanks

(I need it for mod versions, not for ksp... because IR Next conflicts with mods of version prior e.g. 4 ... [...])

Oh I thought you meant KSP versions, overread the mod part.

Honestly I don't know right now, I'll take a look. EDIT: Not possible.

Quote

and what I also don't know is if I can include a max_version in the "conflicts" part

Yep, you can, I think.

Edited by DasSkelett
Link to comment
Share on other sites

11 minutes ago, DasSkelett said:

Oh I thought you meant KSP versions, overread the mod part.

Honestly I don't know right now, I'll take a look.

Yep, you can, I think.

I also think this :)... we will find out if it works when I've tried that... I will send my file to ckan this evening, then we know more...

Link to comment
Share on other sites

Just now, Rudolf Meier said:

I also think this :)... we will find out if it works when I've tried that... I will send my file to ckan this evening, then we know more...

So I tried out a max_version in conflicts, per se works.

However, using generalized mod versions doesn't work :/
The problem is that CKAN handles mod versions only as strings, it doesn't parse/interpret them (in contrast to KSP versions).
This is nearly impossible because there are a lot of different version naming schemes out there, and in a lot of cases mod authors don't even stick to one.
Wwe also have some mods with versions like "v1.4.8" > "v1.5" > "v1.5.1" > "v1.5.2"...
At the latest it would fail there.

So you have to write one exact version as max_version.
In my opinion that's also a safer way to handle conflicts. Else you would have to make sure the mod author names the next version how you expected it.

Edited by DasSkelett
Link to comment
Share on other sites

16 minutes ago, DasSkelett said:

So I tried out a max_version in conflicts, per se works.

However, using generalized mod versions doesn't work :/
The problem is that CKAN handles mod versions only as strings, it doesn't parse/interpret them.
This is nearly impossible because there are a lot of different version naming schemes out there, and in a lot of cases mod authors don't even stick to one.
And we also have some mods with versions like "v1.4.8" > "v1.5" > "v1.5.1" > "v1.5.2"...
At the latest it would fail there.

So you have to write one exact version as max_version.
In my opinion that's also a safer way to handle conflicts. Else you would have to make sure the mod author names the next version how you expected it.

*hmm* ... I can also tell you directly what the problem is... IR Next, it recommends KJR Next... and KJR Next "provides" KJR... als well as KJR continued does... and IR Next is not compatible with KJR ... so, how to solve that? :) 

KJR / KJR continued -> prov KJR / KJR next -> prov KJR

IR next -> recom KJR next / IR next -> conflicts KJR

... I don't know what would work... ok, we could just ignore the IR next problems with the old KJRs, but... we have a lot of questions already because of that... distributing this problem via CKAN might be not the best idea

Link to comment
Share on other sites

Actually, some more testing revealed, it works in some cases, probably because how versions are compared in CKAN.
But still, I don't think it's a good/stable/reliable way.

2 hours ago, Rudolf Meier said:

*hmm* ... I can also tell you directly what the problem is... IR Next, it recommends KJR Next... and KJR Next "provides" KJR... als well as KJR continued does... and IR Next is not compatible with KJR ... so, how to solve that? :) 

KJR / KJR continued -> prov KJR / KJR next -> prov KJR

IR next -> recom KJR next / IR next -> conflicts KJR

... I don't know what would work... ok, we could just ignore the IR next problems with the old KJRs, but... we have a lot of questions already because of that... distributing this problem via CKAN might be not the best idea

Thanks, that helps.

Does IR Next work with KJR Continued?
If yes, you could set (in IR Next's netkan):

"conflicts"      : [
        { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" }
],

This would only trigger a conflict with the original KJR, and KJR Next/Continued can still be installed.

If no, this should work:

"conflicts"      : [
        { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" },
        { "name": "KerbalJointReinforcementContinued" }
],

 

Edited by DasSkelett
Link to comment
Share on other sites

19 minutes ago, DasSkelett said:

Actually, some more testing revealed, it works in some cases, probably because how versions are compared in CKAN.
But still, I don't think it's a good/stable/reliable way.

Thanks, that helps.

Does IR Next work with KJR Continued?
If yes, you could set (in IR Next's netkan):


"conflicts"      : [
        { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" }
],

This would only trigger a conflict with the original KJR, and KJR Next/Continued can still be installed.

If no, this should work:


"conflicts"      : [
        { "name": "KerbalJointReinforcement", "max_version": "v3.3.3" },
        { "name": "KerbalJointReinforcementContinued" }
],

 

no, it only works with KJR Next (which is v4.0.0 and higher)

but it does not work with KJR and KJR continued

that's why I thought trying "max_version" v3 ... and, because KerbalJointReinforcementContinued provides KerbalJointReinforcement, it doesn't have to be listed separate... they've told me :) ... not that obvious, but... somehow it should work

Edited by Rudolf Meier
Link to comment
Share on other sites

55 minutes ago, Rudolf Meier said:

no, it only works with KJR Next (which is v4.0.0 and higher)

but it does not work with KJR and KJR continued

So my second solution should work.

55 minutes ago, Rudolf Meier said:

that's why I thought trying "max_version" v3 ...

Even if it would work, problem is we don't know if KJR Continued won't go to v4.X.X one day.

55 minutes ago, Rudolf Meier said:

and, because KerbalJointReinforcementContinued provides KerbalJointReinforcement, it doesn't have to be listed separate... they've told me :) ... not that obvious, but... somehow it should work

Normally you don't need it, but since you don't want KJR - Next to be a conflict, which also provides KerbalJointReinforcement, we have to fiddle around a bit.

What my second solution does, is marking every mod that provides KerbalJointReinforcement as conflict up to version v3.3.3 > i.e. only the original KJR, because neither KJR Next nor KJR Continued have a version number that low.
Now we still want to have a conflict with KJR Continued > Add its identifier too. KJR Next is still not a conflict.

Edited by DasSkelett
Link to comment
Share on other sites

Can we please have an option to disable the intrusive "It might not be safe to launch KSP" warning? Either a config option or a "do not show again" checkbox on the warning dialog itself would be fine.
 

Link to comment
Share on other sites

I think that we are getting into too much complicated half solutions.

The "one size fits all" solution doesn't cut it anymore.

I think that two metadata are in need to be added to CKAN:

PROVIDERfor people that likes the forks of a given Maintainer. User sets the provider on CKAN client, and CKAN resolves to the fork for that guy every time it finds more than one fork doing the same thing.

REPLACES: where a list of mod names are specified (some guys like to join Add'Ons) so the user can reach the replacements by specifying the original one  .

These would solve a lot of problems we have now.

Link to comment
Share on other sites

[snip]

I opened github issue NetKAN#7131 on Apr 15 because I perceived a need for CKAN to index the Harmony C# patching library. This request was driven by the fact that I would soon be using it in my mods. My goal was (and still is) to have CKAN index it so that it can be installed once and then used as a shared dependency by multiple mods; this would conserve disk space and forestall any potential problems with having multiple copies of the library, possibly of different versions (a known issue in some other games).

In response to a question from CKAN project members about how Harmony behaves when multiple copies exist, I put in the effort to run some tests and reported back the results on Apr 18. A discussion ensued over the next few days about whether or not it should be indexed; I continued to state the case for indexing with concrete reasoning and use cases, and countered what I saw as flawed arguments from the other side.

Discussion ceased after Apr 20 with no formal decision or resolution on the matter.

More than two weeks passed, during which time I continued to make progress on developing my mods. As they the point of release gradually approached, on May 6 I offered to take additional steps to assuage concerns expressed by CKAN team members about perceived risks if they indexed the Harmony library.

No response was forthcoming.

On May 10 I completed updates to the AirlockPlus mod, such that it now has Harmony as a dependency. Since making it available as a full release would break installations for existing CKAN users, I opted to temporarily offer it as a pre-release, while pointing out to CKAN that the the lack of progress on issue #7131 had become a blocker preventing me from releasing the next version of my mod.

Still nothing.

After a further >10 days had passed, I decided to attempt to spur some on progress the matter and submitted PR #7200 on May 21 to make the necessary changes so that I could properly publish the next version of AirlockPlus. @DasSkelett was quick to help fix a problem I had with the CKAN syntax, but after that, nothing again.

Before anyone counters that the PR has only been up for a bit over 48 hours -- let me reiterate that I had provided notice about the urgency of the matter on May 10, and as of right now, AirlockPlus v0.0.11 has been delayed by almost two weeks. Furthermore, for over a month (since Apr 20) I might as well have been talking to a wall. Throughout this time, CKAN project members have been active on other issues and pull requests, as well as on the KSP forums.

This morning, I even interacted with a CKAN team member in a different github issue to discuss other unrelated things -- but when I made an aside appeal to have PR #7200 looked at, it was quickly shut down as off-topic. That would not be unreasonable in any other circumstance, but suffice to say I am frustrated and all out of patience after [snip] so long.

So, here we are at the end of the day and there is still no progress on #7131 or #7200.
How hard is it to merge a PR, or drop a quick message explain the delay, or provide some reassurance that it will be looked at soon?

I understand we all have other commitments outside of modding, and CKAN's priorities are different from my priorities [snip]. If a delay is needed, you should inform me and explain why. If you've decided to turn down my request, let me know so that I can proceed accordingly. [snip]

 

For the record: I am not be a CKAN user myself, but I understand and appreciate its place in the modding ecosystem for trying to make it easy and convenient for end users to install mods (albeit that is not always the goal of the modder, and CKAN has been known to mess up installs to the point that some modders refuse to support or allow CKAN installs.)
In CKAN#2732 when I asked for explicit opt-out of my mods from CKAN to prevent prototype code from being distributed outside of my control, it was correctly observed that I was "not antagonistic to CKAN" like most people on the opt-out list. I am well aware of the circumstances of the controversy back 2016 that led to that opt-out list. I was not personally involved in those events and so bore no ill-will against CKAN, but was cautiously hopeful that the CKAN organization had improved since then. Notice the use of past tense. My stock of goodwill for CKAN has now been depleted.

 

To cite some of CKAN's policies:

CONTRIBUTING.md:

Quote

Please report bugs and open issues generously. Don't be afraid that your idea is silly, or you're reporting a duplicate. We're happy to hear from you.

CKAN purports to welcome ideas and contributions. I have freely shared ideas and use cases in various threads in CKAN's various GitHub repos. I have no problem with being told that I am wrong when I've made a mistake (See NetKAN#7144). In the past I have even considered contributing code to CKAN, although that has not happened due to time constraints.


Code of Conduct

Quote

Attempt‭ ‬collaboration‭ ‬before‭ ‬conflict.

I believe I have made all reasonable effort to reach out and collaborate, and have behaved in a civil manner throughout.
Unfortunately, that has failed, so things have now come to this [snip].

I do not enjoy having to do this.

[snip]

If this matter cannot be resolved in a timely fashion, I reserve the right to unilaterally publish the next version of AirlockPlus without the necessary fixes in place for its CKAN metadata, thereby breaking installs for CKAN users when they attempt to upgrade the mod. I've tried everything I can, so at that point the fault would lie squarely with CKAN.
[snip]

Note: I consider NetKAN#7201/#7202 to be an unrelated matter, and will deal with separately after this is resolved.

Edited by Snark
Redacted by moderator
Link to comment
Share on other sites

I'm trying to get CKAN to work with a fresh 1.7.0 install but when I try to add a new instance of KSP it seems to want me to select a file rather than a folder, and I can't see KSP.exe in the KSP folder. What am I doing wrong?

 

EDIT: Nevermind, selected the BuldID file.

 

EDIT 2: Alright, new issue. I get a massage saying:

One or more downloads were unsuccessful:

Error downloading HeatControl 0.4.11: The remote name could not be resolved: 'spacedock.info'
Error downloading KerbalAtomics 1:1.0.1: The remote name could not be resolved: 'spacedock.info'

this message continues to about half of the mods I've selected. What's the problem?

Edited by Hoddd9000
Link to comment
Share on other sites

4 hours ago, Hoddd9000 said:

EDIT 2: Alright, new issue. I get a massage saying:

One or more downloads were unsuccessful:

Error downloading HeatControl 0.4.11: The remote name could not be resolved: 'spacedock.info'
Error downloading KerbalAtomics 1:1.0.1: The remote name could not be resolved: 'spacedock.info'

this message continues to about half of the mods I've selected. What's the problem?

See

The Spacedock servers are moving currently, it comes to outages.  Just wait and retry :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...