• Content Count

  • Joined

  • Last visited

Community Reputation

47 Excellent

1 Follower

About DasSkelett

  • Rank
    Rocket Researcher

Contact Methods

  • Website URL Array

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay, this will be a bit harder. Cake itself doesn't download the runtime dependencies, it tells NuGet to do so. NuGet downloads .nupkg zips, those are saved in "~/.nuget/packages/" and "CKAN/_build/lib/nuget". First folder is the global installation directory, in there are all packages downloaded by NuGet. It's somewhat of a cache Packages referenced with "PackageReference" in .csproj files, can only be found there. Packages referenced in "packages.config" files are also "copied" to the second folder. Beware, the folder structure is different: "<package_name>/<package_version>/*" in the first directory and "<package_id>.<package_version>/*" in the second. For more information, see https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders You can get a list of the called URLs when building CKAN with both folders empty. It will look something like this after piping through grep: GET https://api.nuget.org/v3-flatcontainer/cake/0.34.1/cake.0.34.1.nupkg GET https://api.nuget.org/v3-flatcontainer/log4net/2.0.8/log4net.2.0.8.nupkg GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/12.0.2/newtonsoft.json.12.0.2.nupkg GET https://api.nuget.org/v3-flatcontainer/commandlineparser/1.9.71/commandlineparser.1.9.71.nupkg GET https://api.nuget.org/v3-flatcontainer/autofac/4.9.2/autofac.4.9.2.nupkg GET https://api.nuget.org/v3-flatcontainer/ini-parser/3.4.0/ini-parser.3.4.0.nupkg GET https://api.nuget.org/v3-flatcontainer/icsharpcode.sharpziplib.patched/ GET https://api.nuget.org/v3-flatcontainer/njsonschema/10.0.19/njsonschema.10.0.19.nupkg GET https://api.nuget.org/v3-flatcontainer/namotion.reflection/1.0.5/namotion.reflection.1.0.5.nupkg GET https://api.nuget.org/v3-flatcontainer/awssdk.core/3.3.103/awssdk.core.3.3.103.nupkg GET https://api.nuget.org/v3-flatcontainer/awssdk.sqs/ GET https://api.nuget.org/v3-flatcontainer/chinhdo.transactions.filemanager/index.json GET https://api.nuget.org/v3-flatcontainer/chinhdo.transactions.filemanager/1.2.0/chinhdo.transactions.filemanager.1.2.0.nupkg GET https://api.nuget.org/v3-flatcontainer/castle.core/index.json GET https://api.nuget.org/v3-flatcontainer/moq/index.json GET https://api.nuget.org/v3-flatcontainer/nunit/index.json GET https://api.nuget.org/v3-flatcontainer/nunit3testadapter/index.json GET https://api.nuget.org/v3-flatcontainer/system.runtime.compilerservices.unsafe/index.json GET https://api.nuget.org/v3-flatcontainer/system.threading.tasks.extensions/index.json GET https://api.nuget.org/v3-flatcontainer/castle.core/4.4.0/castle.core.4.4.0.nupkg GET https://api.nuget.org/v3-flatcontainer/system.runtime.compilerservices.unsafe/4.5.2/system.runtime.compilerservices.unsafe.4.5.2.nupkg GET https://api.nuget.org/v3-flatcontainer/system.threading.tasks.extensions/4.5.2/system.threading.tasks.extensions.4.5.2.nupkg GET https://api.nuget.org/v3-flatcontainer/nunit3testadapter/3.13.0/nunit3testadapter.3.13.0.nupkg GET https://api.nuget.org/v3-flatcontainer/nunit/3.12.0/nunit.3.12.0.nupkg GET https://api.nuget.org/v3-flatcontainer/moq/4.11.0/moq.4.11.0.nupkg However there are also build dependencies (see "#addin" and "#tool" at the beginning of build.cake), but Cake downloads them in a different process and doesn't output the URLs during build. But they shouldn't be too hard to handcraft. The files are also cached in "~/.nuget/packages/". So in the Nix package build process, you should download those .nupkg files, extraxt them to "<package_name>/<package_version>/*", copy the .nupkg zip again in the extracted folder (so "<package_name>/<package_version>/<name>.<version>.nupkg" ), and bundle them all together in the package. It will take some string manipulation to get the package name and version from the zip filename. During installation of the package / before building CKAN, either put those files in "~/.nuget/packages/", or set the env var $NUGET_PACKAGES to a folder you want (see the link above). NuGet then will do everything automatically and install each nupkg where it belongs when running "./build".
  2. All the dependencies are cached in "_build/cake/", "_build/lib/" and "_build/tools/". If they are already installed, neither NuGet nor Cake should try to download them. Not sure how the Nix packaging works, but maybe you can just include those directories in the package? Dependencies are only updated with new CKAN releases, so you don't have to worry about in-between dependency (version) changes.
  3. @bcink CKAN now takes the folder "DSSHU" as is and puts it into GameData, without picking out any config files: https://github.com/KSP-CKAN/CKAN-meta/commit/4b1307eccf2fa9317d6544475dc9144b44b2826d The new forum thread URL has also been picked up already: https://github.com/KSP-CKAN/CKAN-meta/commit/1df73bda55b414dc24da99d34392c5916902ae2a
  4. Ah I see, you moved all the config files from "/DSSHU/Optional Configs" to "/DSSHU/GameData/Patches" in the zip, this results in some of the being installed twice. This should be an easy fix, hang on.
  5. No, I meant the "Homepage" link on SpaceDock. It's pointing to the WIP thread in Add-on Development, not this one. You might want to change this.
  6. Hey @bcink, can you update the mod website/forum thread link on SpaceDock to point to this thread? It is currently still pointing to the thread in Add-On Development. Thanks! Oh common @GJNelson, again faster than me? @bcink it's the homepage link on SpaceDock that's outdated, that's where CKAN gets it from.
  7. Hey all, a few of you already noted the issues with downloading and indexing mods from CurseForge. I've got some news: https://github.com/KSP-CKAN/NetKAN/issues/7446#issuecomment-548458430
  8. Best of all would be, if you first try to contact the mod uploader and ask him if he has permission to do so. Second, contact those affected by the potential copyright infringement, so that they (in the best case) contact the uploader themselves and try to find a solution. Third, the copyright owner should contact the SpaceDock team/VITAS on the SpaceDock Discord or Matrix server or via forum DM to either tell him that everything's ok (because the uploader had permission to do so), or to ask for removal. In short, the SD team needs a copyright claim by one of the affected copyright owners to act.
  9. Will it be the same build which is then compatible with all those versions, or will it be different builds each compatible with a specific KSP version? The first one would be easy, just change the (remote) .version file to include the previous KSP versions too. But I suspect you mean the second case... Then you need to give them different version numbers. You are currently appending a ".0" to each mod version without counting it up. You could use that to indicate the different builds. As long as each build has its own KSP version range, not overlapping with the one of another release, CKAN will install the right one. So your .version files could look like this (shortened a bit, and each part should be included in a different build): // .version file included in the first build, with version number for KSP 1.6.x { "VERSION":{ "MAJOR": 1, "MINOR": 1, "PATCH": 20, "BUILD": 1 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 6 } } // .version file included in the second build, with version number for KSP 1.7.x { "VERSION":{ "MAJOR": 1, "MINOR": 1, "PATCH": 20, "BUILD": 2 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 7 } } // .version file included in the second build, with version number for KSP 1.8.x { "VERSION":{ "MAJOR": 1, "MINOR": 1, "PATCH": 20, "BUILD": 3 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 8 } } The zips on Jenkins also should be named accordingly, with the different "BUILD" number. The cache is not intended to be managed by hand. It has a well thought out cleaning mechanism built in IMHO, just set the upper size limit: https://github.com/KSP-CKAN/CKAN/pull/2536
  10. Thank you! Sorry for the long wait. We did a metadata update: https://github.com/KSP-CKAN/NetKAN/pull/7441 Now CMES should no longer force you to install KJR Continued, thus no conflict anymore. Can you try it?
  11. Oh dear, I see. ChakaMonkeyExplorationSystems depends on KerbalJointReinforcement, but KerbalJointReinforcementNext doesn't provide it anymore since https://github.com/KSP-CKAN/NetKAN/pull/7221. So ChakaMonkeyExplorationSystems pulls in KerbalJointReinforcementContinued to satisfy the dependency, but this conflicts with KerbalJointReinforcementNext and InvernalRoboticsNext. Regarding the metadata side, probably easiest to solve this is to change the dependency of ChakaMonkeyExplorationSystems to "any_of": [ "KerbalJointReinforcement", "KerbalJointReinforcementNext" ] (pinging @HebaruSan), but I don't know if ChakaMonkeyExplorationSystems will really work with KJRNext. I suspect it does, since all KJRs should work in the "background", but you never know. ...maybe @Rudolf Meier or @YANFRET know?
  12. That's this bug: https://github.com/KSP-CKAN/CKAN/issues/2852 It's fixed here: https://github.com/KSP-CKAN/CKAN/pull/2854 To workaround this issue until the next release is out, clear your search bar before you select the mod to install. Yes, the dependency will be seen as satisfied, your described scenario should work.
  13. @linuxgurugamer thanks for the note! @Xyphos I added it manually (https://github.com/KSP-CKAN/CKAN-meta/commit/5c71b1f91590af9ac550da566e3da3016ca148b9).
  14. I blame all translation errors on my Bavarian background CKAN is free and open source, it depends on contributions made by volunteers. That means, if you spot an outright wrong translation, you are very welcome to correct it and create a pull request!
  15. @Wjolcz with the help of good connections to the admins of SpaceDock (i.e. @HebaruSan again...) I/he got your account activated. Can you confirm that? Edit: two minutes too late...