B9 Aerospace about netkan

[gertsonderby]

AFAIK, FAR/NEAR aren't required, they're just needed to make the included vehicles work as intended. The parts themselves are perfectly stock-compatible.

[Ippo343]

While that is true, the forum thread has this line:

The stock drag model is no longer supported. FAR or NEAR are now required.

So the authors do consider it a requirement, although it's no for technical reasons.

[gertsonderby]

That line has caused all manner of discussion on the thread, though. I followed a good bit of that discussion, and the upshot, from Taverius and K3|Chris, was that the parts themselves are fine, and work without issue on Stock (though you'll find the jet engines anemic at best), but the included craft are not expected to work meaningfully without one of Ferram's grand works. I'd say it belongs in recommended, not required.

[Ippo343]

Okay, I just finished bothering K3|Chris on IRC. Quick summary of the discussion:

• He didn't know about CKAN, but did not object to B9 being on it;
• They don't use github, they have their bitbucket repo, which might be useful in the future;
• Here are the repos for ResGen and KineTech: unfortunately they don't have any release.
• FAR/NEAR should be only recommended, not depended upon.

[madadam]

Hi guys,

Here is my attempt at the CKAN file for B9: https://gist.github.com/madadam/c70f8aeb026e96115e41. I tested it and it seems to work. I made a couple of decisions in it which may or may not be ok, so I want to discuss them here:

• B9 has a bunch of dependencies. Those that already have CKAN packages I added to the depends field: ModuleManager, CrossFeedEnabler, FirespitterCore and RasterPropMonitor-Core. The rest I'm not too sure how to handle the best way:
  • I think that KineTechAnimation and ResGen are used only by B9, so I think it should be fine to bundle them. I also added them to the provides field just in case.
  • Klockheed_Martian was recently abandoned by its author (as far as I know), so not sure what its future is. I think the safest for now is to bundle it too. (and add to the provides).
  • Virgin Kalactic seems to be actively maintained (https://github.com/Greys0/Virgin-Kalactic), so it would be best to CKANize it and add as a dependency. But for now I bundled it, just to have something workable quickly.
  • The GameData/MP_Nazari folder contains just a dummy config for HotRockets which is there for backwards compatibility I assume, but serves no other purpose. I ignored it.
• I added FAR and NEAR to suggests. It may be better to put them to recommends, but I'm not sure. Also not sure if it is ok to put both of them there, as they seem to conflict with each other.
• I had to add a custom license field, because the one pulled from KerbalStuff was invalid.
• I added "optional" : true to the Ships install stanza, which I saw that in FAR.netkan, but I don't know if it has any effect, as I haven't seen it documented anywhere.
• I haven't contacted B9 authors about this yet, but seems @Ippo343 took care about it.

[pjf]

Uh oh, I better work on making the docs clearer on provides. It's almost always a mistake to use it, except when:

• Providing a virtual mod, such as TACLS-Config, which can be satisfied by a number of different options.
• Providing a common alias to a mod.

To quote from another discussion:

While it's very tempting to do so, we don't want to be providing bundled mods. KSP-CKAN/CKAN#113 gives some background on this, but the end result is that if now if any mods depend upon other-mod, they now end up installing your-mod instead (which the user didn't ask for). By installing the bundled version of other-mod, we've pushed the responsibility of keeping that up to date on to your-mod-author (which is really opposite to what our dependency model is striving for), and if anything else bundles other-mod (including other-mod itself), then it will conflict with your-mod.

I'm a bit under the weather right now, but when I'm feeling better I'll try to update the guides appropriately. Even though it's very tempting to use provides for bundled mods, it breaks the future, and we don't want that.

Thank you so much for all your hard effort on this, though; it's very much appreciated, and while some things like making sure each mod has its own correct metadata document can be a bit of extra work, the beauty is we only have to write them once and then they're solved forever.

[gertsonderby]

So in principle, for things like VirginKalactic and Klockheed_Martin, what you'd want to do is add a metadata file for them separately that refers the B9 archive, since that appears to be the only source for them at this time, and then have the B9 mod depend upon those. Hell, I'd be tempted to do some cutting work inside B9 itself, carve it up into chunks and have those depend on the DLLs they need, but that's rather more work. Off the top of my head, the HX parts are the only ones that need VirginKalactic, for example, while KineTechAnimation is used solely by a few intakes.

IIRC the HotRockets config is supposed to configure that mod - if found - and supersedes the B9 config that HotRockets has included. Or had, at least, when B9 R5 launched.

I would put AerodynamicsModel as a recommended mod (it's provided by either NEAR or FAR IIRC, and I may misremember its name) and HotRockets as a suggested mod.

[madadam]

Guys, thanks for your great suggestions! I think I now understand much better how to approach this. This is what I think I'll do:

• Create separate metadata for ResGen and KineTechAnimation, which both will refer to the B9 archive, since they have no releases of they own. I'll probably check with their respective authors to make sure they are ok with that.
• Create a proper metadata for Virgin Kalactic, referring to its github repo and also checking with its author.
• As for the HotRockets config - So if I understand you correctly, it is there to overwrite the obsolete B9 config that is bundled with HotRockets? I checked, and it doesn't seem the current version of HotRockets bundles it anymore. Besides, CKAN does not support overwriting files anyway. So I would ignore it.
• @gertsonderby, I was also thinking the same thing you seem to be suggesting and that is to split the HX parts into a separate package which the main B9 package would recommend. Problem is, this requires CKAN to support something like "install_to" : "GameData/B9_Aerospace" which I don't think it does currently. So this is something for the future. Then we can make only this B9-HX package depend on Virgin Kalactic, as opposed to have the main B9 package depend on it.

What do you guys think about it? I'm going to work on this sometime later today/tonight (CET) and post the results here. Thanks again for your ideas!

[gertsonderby]

There's further subdivision of the (very large) pack that could be done, but as you say, this requires a feature that hasn't landed yet. But yeah, that all sounds good.

[madadam]

So I wrote ResGen.netkan, but hit one small issue. ResGen contains a .version file, so I wanted to add the $vref field so the version information is pulled automatically. But netkan keeps using version of the whole B9 package instead. Not sure if I'm doing something wrong or this is a limitation of netkan. I worked around it by adding a hardcoded version field, but that is not ideal, as it would have to be updated each time the mod is updated. This is the file so far: https://gist.github.com/madadam/c70f8aeb026e96115e41#file-resgen-netkan. Any advice?

[AlexanderDzhoganov]

@madadam
NetKAN only supports archives with one KSP-AVC .version file, related issue - KSP-CKAN/CKAN#269

[madadam]

@AlexanderDzhoganov OK, so hardcoded version is it then, for now.

[madadam]

OK, I finished writing metadata for all the dependencies: https://gist.github.com/madadam/c70f8aeb026e96115e41.

Couple of things:

• It seems that B9 uses only a subset of the KlockheedMartian mod. What I did is I created a metadata for a package called "KlockheedMartian-Gimbal" which refers to the GameData/Klockheed_Martian directory in the B9 archive. It has a "conflicts": [ { "name" : "KlockheedMartian" } ] clause, so when someone writes metadata for the whole KlockheedMartian mod, they can just add "provides" : [ "KlockheedMartian-Gimbal" ] and it should be fine (if I understand it correctly).
• I did the same thing for the VirginKalactic mod. In this case B9 uses only the NodeToggle plugin, so I created VirginKalactic-NodeToggle package.

Not sure it this is the right approach, please let me know if it should be done differently. Otherwise, should I submit a pull request?

[AlexanderDzhoganov]

Looks good :) I haven't tested the files yet, but will do so when you make a PR, so go for it.

[madadam]

Here is the pull request: #81.

[pjf]

Since this is merged as of #81, I believe this is resolved. Congrats.

[starikki]

B9 pack has custom files for JSI Rasterpropmonitor, the current package on CKAN does not include that thus all B9 cockpit does not have working MFDs

[madadam]

@starikki the B9 package does not include RasterPropMonitor, but it does depend on it. I was under the impression that the JSI folder in the B9 archive is just a copy of the RasterPropMonitor mod and does not include any additional files. Therefore simply depending on the core RasterPropMonitor package should be enough. If this is not the case, could you tell me which are the custom files you are talking about?

[starikki]

@madadam I'm pretty sure the original B9 Package contains extra files other than normal JSI contents.
It's mainly a folder called RPMPodPatches inside JSI folder. If you install B9 outside CKAN and without the RasterPropMonitor Mod (just use the JSI folder included inside B9 Package), everything will work just fine. B9 mod page also mentioned that its not compatible with original RPM mod.