pjf

Like this? Run the ckan client without any arguments, and that's what you get. (With many thanks to nlight for all his hard work!) Just to be clear, the CKAN is absolutely not a bundler. It's a package management tool similar to apt for Debian. But I fear this may de-rail the thread, so back to talking about tech trees... ~ Paul

Yeah, this bothered me too, so I went and wrote a spec on how to solve mod installation problems with decades worth of packaging experience, and then went and wrote software to implement it as a single download, cross platform, statically linked, no dependencies client. As of last night we ticked the last box what was required for a RealismOverhaul install. We're still in pre-release, but the following on the command-line should fetch and install everything required to have RealismOverhaul work: ckan update ckan install RealismOverhaul RSSTextures2048 (The client won't pick an RSS texture pack for you, so you have to choose one). While users *can* install things by hand, I'm hoping that once we go live (which means sorting out some issues), we'll see widespread adoption of the CKAN. That means installing the CTT and other dependencies will simply mean including them in our mod's package descriptor. Our list of supported modules is increasing every day. Yes, and it's already packaged for CKAN. ~ Paul

Having spoken to Nathan on IRC, I suspect we're actually in argumentative agreement on a number of points. I believe we should: * Adopt the Community Tech Tree, as a "better than stock" tree, which is already gaining wide support from other mods (including all of RoverDude's mods, and KSPI). * Alter the titles, descriptions, and science costs on the CTT nodes as required (eg: stability -> early probes), and move a bunch of parts around to fit with RealismOverhaul. I understand this is one of the intended uses of the CTT. * Comment on the CTT thread if we need any new nodes added *now*. If capsules are a later game addition, we may need nodes to support that. (Or we might not, but asking for new nodes now is really good.) My hope is that this will minimise the work required overall, and maximise compatibility with future mod development by: * Not requiring a new tech tree to be developed from scratch. * Easing the support transitions for new mods which already support the CTT, as we only need to code the changes in part placement. I believe that the CTT is a super-set of the stock tree, so many mod that places its parts in stock will place its parts somewhere in the Realism Tree by default. This means if the user installs any unsupported mods (and they will), then they at least have those parts available via career mode, even if they're not balanced. I believe this view is compatible with Felger's view that we should "retain the current nodes, but re-arrange parts to match a realistic progression". It also means that if we aim for a stock-tree re-arrangement, we are CTT compatible going forward. (Although I think the CTT gives us more flexibility by providing new nodes.) I'm happy with us requiring one parts pack as core, but I'm hesitant to *require* more than that. If we can get away with requiring only stock parts, that would make me happy. ~ Paul

Hey all, I'm pushing for use of the Community Tech Tree in the Realism Overhaul Career thread; I think it will not only improve interoperability a lot with late-game tech, but also save an enormous amount of work in developing Yet Another Tech Tree. However I wanted to check if we can modify (preferably via MM) the title and description of nodes as displayed to users? We might want to change the names of some of the early nodes (eg: Stability -> Early Probes) and re-arrange the parts in each, but have the underlying techID identifiers would remain the same. This should ensure continuing CTT compatibility, but give custom tree developers the ability to customise the flavour of each node. Ditto for will it be possible to change the science cost using MM? I'm not sure how much we'll need this, but it would be very nice to have. Edit: I'm expecting both the answers of this to be "yes", but wanted to make doubly sure now, rather than being further along in development. May thanks! ~ Paul

The fact that CTT favours parts which add to KSP, rather than change KSP, is one of its appeals to me. It means that mods which do things on the right hand side of the tree (KSPI, MKS, etc) are likely to "just fit", rather than needing to have all their tech redistributed. It also saves having to make Yet Another Tech Tree, where everything has to be placed by hand and from scratch. If the CTT is unsuitable, then I imagine the stock tree is as well. With regards to tree management, TechManager seems to be the most promising right now (and `ckan install TechManager` just works). With regards to dependencies, while I'd love us to support everything that RO does, I think career should be playable with a much smaller core. The full RO support list is quite large, and is a serious amount of work to install.

No no no no no no no. The whole point of the CTT is that we don't have every tree re-organising the nodes and making it harder to integrate with new mods. This is what the tech tree looks like right now; if we need that changed at all, we should hop in the thread and ask for it, and I'm quite sure it will happen. Re-organisation of parts inside the nodes is absolutely fine. I am interested in what we consider "core mods" for the experience. I'd love it to be possible for players to enter an RO career game with as little work doing mod installs as possible. For me, that means having all mods being installable via the CKAN. (The RealismOverhaul core already is.) I'd also really love to have a required mods list that's shorter than that of RPL. ~ Paul

This sounds like two different projects. And as I said, that's cool, but I think they're different enough they shouldn't be conflated into the same name. (In which case I'd *really* love to keep RP-0 as stock with real physics and gameplay balance.) Having two completely unrelated branches in the same tree doesn't feel at all right at all. Being able to time warp to the point where the tech one wants is available sounds like a less friendly version of sandbox, so I'm personally not taken by this idea. ~ Paul

v0.20 aka Vacuum Polarization has been released. This fixes a bug whereby Windows users were unable to install mods with default stanzas, and also stops missing recommended or suggested modules from preventing an install from going ahead. (They'll stop produce warnings, and missing dependencies will always block an install.) There's also a few tweaks to the GUI, and the netkan inflater also has basic support for AVC files. Also of great personal satisfaction to me is that the entire core of RealismOverhaul can now be installed via the CKAN, which is another big milestone towards me being able to play KSP again. Enjoy!

As it happens, we have a developer working on this right now. We're using AVC metadata for KSP compatibility as for a few hours ago, and both SRL and QuickRevert are now having their min/max KSP versions set by the embedded AVC files we find. (You would also not believe how many broken/corrupt/malformed AVC files there are out there!) We don't use AVC files for anything else besides checking KSP version compatibility, but we may expand that in the future (patches very welcome here!); my current focus is on improving the client to a point where it's both doing everything the spec requires it to (proper relationship resolution is anything but trivial), and is resilient enough to handle most things typical users will throw at it. ~ Paul

Justin: We can't figure out what's going to be installed from a mod without downloading it. A lot of metadata systems come with some sort of a manifest, which describes everything that's found in a distribution, but I suspect that would be overkill at this stage in our development. Our original plan was something along a Debian-like packaging system, where .ckan files are included in the mods themselves. That's still supported by the indexer, but we've found it's a huge pain to have to make a new release if one wishes to change the metadata. However there are plans for checksumming, so we can better detect if we've got the wrong file. These are likely to be auto-generated by our indexer. We do sha1 fingerprints of the files we install, so we can detect if they've changed, although right now we don't actually use those for anything. ~ Paul

Hey everyone, just a quick status report. We've continued to work like crazy on the CKAN, and v0.19 has just gone up on the releases page. While this release may not look very different from the outside, there's a lot more internal consistency states on the inside, so it should be much harder to end up with installs which are forbidden by metadata (no more removing a mod's dependencies, or installing conflicting mods). Download of the new release is encouraged, because if there are any serious bugs, they're much less likely to cause any damage. We know there's a bug in the GUI that can cause it to lock up on complex operations, but we're still trying to track down what's causing it. The command-line should be reasonably solid, and now produces less spam than it once did. Run with `--verbose` if you want to see more of what's going on, or `--debug` if you really enjoy watching scroll. I'm also very happy to say that we've got the full Karbonite stack available for download via the CKAN now, along with a number of other modules. As always, you can do a `ckan update` or hit the refresh button in the GUI to get them. ~ Paul

I'm going to suggest quite the opposite. While I want realistic physics and bodies in my game, I don't care at all for historical accuracy. What I want is a career progression which is fun, challenging, lets me progress towards cool tech that I want (orbital colonies, resource exploration, science labs, etc), and has nothing to do with historical governments trying to muscle each other because if they're trying not to escalate into nuclear warfare. As someone who wants to be able to play with RO + Vanilla resources, we don't necessarily have historical engines. If we do, it's because the player has installed them. I don't want them being unlocked in a historically relevant fashion, I want them unlocked in a fashion that is *fun*. RPL felt like it had a lot of engines with duplicate functions, and I'm completely fine with MM code that detects and removes engines that have similar specs to keep things relatively simple. Why do I want this so much? Because it means I can pick up the game, with realistic physics, and play it for fun. I don't have to worry about it being unbalanced in certain points because it was "historically accurate", I don't have to worry about needing sixteen different part packs which I'll never get working correctly with each other, I only have to care about how I can have fun and achieve my in-game goals. We may have entirely different goals here, and that's okay, it's totally cool to have multiple different tech trees for RO. But I'd be silly not to try and nudge you towards the tech tree that I want to play. ~ Paul

Just a quick question regarding the version file format, as I'm presently adding preliminary CKAN support for reading embedded .version files. The spec says that in order to use KSP_VERSION_MIN and KSP_VERSION_MAX, the KSP_VERSION field has to be defined. Am I correct that KSP_VERSION is essentially the version a mod was compiled for, but MIN/MAX are to be taken as the range it's known to work with? Many thanks! ~ Paul

So, I have some thoughts about career mode, and it's my dream that someone else will run with these. My working name has been "Realistic Progression Zero¹", and the goals in a nutshell would be: - Targets either the stock tree, or more likely, the community tech tree (CTT). - Has no requirements other than the RealismOverhaul core. - Is smart enough to detect new installs and place them in the tech tree appropriately, but does not require any other mods. In other words, it's something which can be *very* easily picked and played with, with minimal barriers to entry. My reasons for favouring the CTT is because it seems to be getting a lot of support from many mods which I wish to use, which will hopefully reduce the friction of integrating those into RP-0. In some cases, that might just mean adding RO support for the mods, and they work in RP-0 out of the box. In other news, I've working pretty darn hard on the Comprehensive Kerbal Archive Network, and we're almost at the point where you can get the entire RO core with ckan install RealismOverhaul. We've got a couple of sticking points, but nothing which we can't work around. Help on the CKAN is very much appreciated; we're not short on things to do or mods to package. All the best, ~ Paul ¹ Mainly so we can make puns about RP-0 being a precursor to RP-1.

Just a quick note to say that v0.18 "Sabiter" is out. This adds support for filters when installing files, which allows us to support some very rich relationships and install processes. Note that older clients won't understand mods which have filter requirements, so this is very much a recommended upgrade. Your existing registry and installed files will continue to work fine. Also, Firespitter is now installable via the CKAN (v0.18 and later). I've been flying planes around all afternoon. ~ Paul

Hooray! I've opened a bug because we used to display a big message if mozroots could fix your problem, and clearly we've regressed somehow. (Luckily `git bisect` and test cases are great for discovering how and when.) As for the netkan, it's useful for testing your configurations. You've told it to process the SRL.ckan file, but if that's not present, then it'll fail. (You're encouraged to make one though! The top post of this thread has instructions on how.) If you do have a SRL.ckan file in your directory, then obviously something is up if it can't read it, and I'll need to take a closer look. Thanks again for testing, I really appreciate it!

Malah: Hmm, this feels *very* familiar. Can you running mozroots --import --ask-remove on the command-line, which should update mono's https certificate registry, and then try a straight mono ckan.exe update ? It might not help, but I've got a hunch that our code that detects an empty certificate store may no longer be doing its job. As for netkan.exe, it's could certainly do with a better message if it can't find the file you've asked it to process. (netkan.exe is mostly used by our bots to index mods from these fragments, but it really should look nicer on a file-not-found.) ~ Paul

This is very much a problem I'm working on solving with the CKAN. Mods depending upon the CTT can simply include that dependency in their metadata. That means we don't end up with everyone bundling the same resources, and it means it can be kept up-to-date without releasing new versions of the mods that require it. Mods which support (but do not require) the CTT can state they recommend, suggest or support the CTT, which means the user has the option of installing it, but it's not required. For example: { "identifier" : "RemoteTech", "$kref" : "#/ckan/kerbalstuff/134", "suggests" : [ "CommunityTechTree" ] } While we're still in pre-release, the dependency code for the CKAN is quite stable, and works very well. Even when a mod bundles another mod, the CKAN still fetches the authoritative version of the bundled mod (which can be restricted by version, if desired), and installs that. (In fact, the spec will soon be updated to deprecated bundled mods altogether.) So I'm *very* much hoping to provide the tech here to solve the dependency hell. (For more info, we've got a forum thread and github project, and further CKAN discussion is best done over there so we don't de-rail this thread). All the best, ~ Paul

Wow. From my skimming of this thread, I'm loving this. I have a desire to make a "Realistic Progression Zero" (RP-0) tech tree, which is to take the RealismOverhaul side of the of the modosphere, with as few dependencies as possible, and apply it lightly onto an existing (formally stock) tech tree. That means keeping the same nodes, but potentially moving the tech around a little (Mk1 pod would likely come in with survivability, Mk1-2 with recycling, etc). My expectation is that most later-game tech won't change location at all. I would love to do this with the CTT, and am generally happy to work with whatever design comes out of the discussions (it's looking great so far!). While I'm currently working full-time on the CKAN, and so it's likely to be a while before I can pick up tech trees at all, but I am *very* excited about what's going on here. Thank you. <3

Just a quick announcement that we found a serious bug whereby the CKAN could write corrupted files to disk in the v0.15.1, and v0.16 releases. It's recommended that all users upgrade to the latest release, and if you installed a mod using one of the affected clients, that you re-install that mod. Many thanks to Darklight for finding this. ~ Paul

Recommends mods will be installed by default; that's the whole point of recommends. Suggested mods will only be installed when the user indicates they want suggested mods, and we only process the suggests list of mods directly requested by the user. We don't install the suggested mods which we've added because of a depends, recommends, or suggest; this does avoid the kitchen-sinking we see in Debian when someone specifies '--with-suggests'. If you want the kitchen sink, there's '--with-all-suggests'. We've always supported parts mods; the main question has been regarding ensuring we have a consistent naming scheme. This is a hard problem, but it seems pretty clear that we should let people have CKAN identifiers which differ from what ModuleManager would use, with the understanding that we won't be able to detect such mods being installed unless they were installed via the CKAN (which we certainly hope will become the de-facto standard for mod installations). I know you've got AMEG outstanding, so since we've figured out the naming issue I'll go add that now. (Although we also need to add a 'license' URL to our resources stanza at some point, so we can handle non-standard licenses.) ~ Paul

Welcome back, MN! It's good to see you posting again! I'm very much looking forward to playing with RPL in 0.25 and beyond! <3

Oh hey magico13! I love KCT! You're correct that you don't need to include anything in your zip file. If you do, it will override anything we have in our NetKAN directory, but we've found it's overwhelmingly easier to leave them out of the zips entirely. With regards to naming, its a hard question. The CKAN itself doesn't care what identifier you use, as long as it's unique and you're consistent. If someone has a pre-CKAN copy of KCT installed, that will be detected as "Kerbal_Construction_Time", but we're already seeing a move away from supporting pre-CKAN mods in terms of naming schemes. For example, "FirespitterCore" is what one would add as a dependency to get "Firespitter.dll", whereas "Firespitter" gives one the entire mod. I would probably go with KerbalConstructionTime, as there seems to be a de-facto standard of using PascalCase for identifiers. With regards to Depends vs Recommends vs Suggests vs Supports, that's definitely a thorny situation. I've seen mods with things marked as "depends" when really they're "recommends", and I also fear the general habit mod authors will be to declare relationships which are stronger than they really are. However, if it puts your mind at peace, users of the GUI client will almost certainly end up with a screen which presents them with dependencies (which can't be unselected), recommends (which are selected by default), and suggestions (which are unselected by default), which will mean that they're more aware of what's being installed, and will be able to adjust their choices before anything is installed. I even believe some of this functionality is in the GUI right now, but I haven't tested it extensively (nlight is our GUI wizard, I've been focusing mostly on the CKAN.dll core). Folks using the command line can already specify `--no-recommends` or `--with-suggests`, and we always confirm with the user before installing anything. However it would probably be a good idea if our relationship resolver indicated why it came up with a particular solution, so we can more easily display to the user what they can choose to go without. As for your mods, I would have: * StageRecovery suggests KCT (I agree with you here) * KCT recommends StageRecovery The reason for this is that it's going to be totally normal for folks using StageRecovery to not worry about construction time, but for the full (and typical) KCT experience we want users to have a way to recover stages for re-use in future projects. All the best! ~ Paul

I am delighted to see this. Thank you *so* much. I've scanned the last eight pages of activity, and have just a question and an understanding check: 1) Is this up on GitHub anywhere? I can find FractalUK's fork, but not the original. 2) Is my understanding of existing discussions correct that we'll be moving towards a ModuleManager accessible approach, and it won't require a tree.cfg in the user's save directory? The second is something I'd desire greatly, because it means that mods can supply updated tech-trees with each version, allowing tech-tree developers to not have to get everything right on their very first go. For those folks using the CKAN pre-releases, this can now be installed with `ckan install TechManager`. Our cloud of bots should pick up new releases from KerbalStuff automatically. Many thanks! ~ Paul

Oh my! I have to stop looking at all the pretty pretty pictures in this thread to report the easiest bug to fix. The current release on KerbalStuff has a release version of "Kerb-fu_v0.20a", whereas previous versions have versions like "0.19a". This is making the CKAN indexer sad. I don't suppose you can pop over to KS, and edit the mod info to have a version of "v0.20a"? Many, many thanks! ~ Paul