Closed Ippo343 closed 9 years ago
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.
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.
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.
Okay, I just finished bothering K3|Chris on IRC. Quick summary of the discussion:
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:
depends
field: ModuleManager, CrossFeedEnabler, FirespitterCore and RasterPropMonitor-Core. The rest I'm not too sure how to handle the best way:
provides
field just in case. provides
). 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.license
field, because the one pulled from KerbalStuff was invalid."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.Uh oh, I better work on making the docs clearer on provides
. It's almost always a mistake to use it, except when:
TACLS-Config
, which can be satisfied by a number of different options.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 installingyour-mod
instead (which the user didn't ask for). By installing the bundled version ofother-mod
, we've pushed the responsibility of keeping that up to date on toyour-mod-author
(which is really opposite to what our dependency model is striving for), and if anything else bundlesother-mod
(includingother-mod
itself), then it will conflict withyour-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.
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.
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:
"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!
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.
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?
@madadam NetKAN only supports archives with one KSP-AVC .version file, related issue - https://github.com/KSP-CKAN/CKAN/issues/269
@AlexanderDzhoganov OK, so hardcoded version
is it then, for now.
OK, I finished writing metadata for all the dependencies: https://gist.github.com/madadam/c70f8aeb026e96115e41.
Couple of things:
"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).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?
Looks good :) I haven't tested the files yet, but will do so when you make a PR, so go for it.
Here is the pull request: https://github.com/KSP-CKAN/NetKAN/pull/81.
Since this is merged as of #81, I believe this is resolved. Congrats.
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
@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?
@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.
Assuming we get permission, B9 has a long list of bundled mods:
Update: on the forum thread it's stated that FAR/NEAR are considered requirements:
Additionally it also provides a custom config for Hot Rockets, which maybe isn't worth a package on its own.