ShotgunNinja

There would be no difference for the mod author if their mod was installed by the user selecting it on CKAN manually, or as part of the automatic dependency selection of CKAN packages. The end result is that the 'modpack curator' is only shipping metadata, and the individual mods can still be kept updated using the facilities CKAN offer.

@blakemw, @Gotmachine Thanks guys, I'll check it. @Citizen247 That looks like the 'resque mission gift package' I give to kerbals from resque mission. Somehow, TakeCommand is triggering it. I'll check this too.

Modpacks could be implemented as simple CKAN packages 'requiring' a set of mods.

If an exception is thrown inside the background simulation of a vessel, the symptoms will be partial or no simulation. So, only some modules may be simulated. This may be what you are seeing, @John Nowak. To confirm this, can you go in the debug menu of KSP (ALT+F12) -> Debugging -> Enable both 'Show all errors on screen' and 'Show all exceptions on screen'. Then when you see the problem happening, notice if there are yellow or red messages on the top right of your screen. If there are, kill KSP and send me the full log.

@JWS Unfortunately the stock lab require a stock science container to work, so it can't work with the Science feature of this mod. And working around it is not really possible, at least at the moment.

@blakemw Thanks to your reproduction steps, I was able to reproduce the issue with control loss, after planting the flag. There seem to be no exceptions, and the flag appear in the list of valid vessels in the monitor (and it should not...). I'll dig this and hopefully fix it for next version. All parts with tags containing '_kerbalism' are shown in the custom category in the vab. They should be...

The two experiments mentioned are implemented using custom modules (DMModuleScienceAnimate and derivates), that Kerbalism has no specific knowledge of. In fact, the Science system has been designed to not require specific knowledge of third-party science modules. The data is captured in some generic way instead. This has advantages (no need to support custom modules explicitly) but also disadvantages (no way to support extra features added by those custom modules, such as the 'run the experiment up to N times' provided by DMModuleScienceAnimate). There is no science value boost. Instead, the lab is used to transform non-transmissible data into transmissible data, over time. This make returning samples to Kerbin more convenient, provided that you can return in the first place. Or that you don't need the science credits before the mission return. From next version I'll consider atmosphere of bodies with 'atmosphereContainsOxygen == true' as breathable.

The Habitat feature is turned on if any other features that depend on it is enabled (such as Shielding, Pressure, Poisoning, Living Space). Only resources in use are added to the habitat, so with only Shielding enabled, the habitats only get Shielding resource capacity. Removing habitats completely is possible, but it mean disabling all the dependent features mentioned above.

Ehm... that error you see is 'fake': it is made to look like a real kind of error, but is just here because the vessel in question ('Test Craft') has no connection and is not manned. Before the EVA, it was manned so that fake error message wasn't shown. @CatastrophicFailure You got an extra '{' on line 2. I separe experiments in two categories: 'data-producing' and 'sample-producing'. The distinction is made automatically from the 'xmitDataScalar' property of stock science experiments. If the property is less than 1.0 (even 0.99), I just consider the experiment 'sample-producing'. Maybe I can make these experiments produce both data and samples, together, in proportion of xmitDataScalar. Example: an experiment has xmitDataScalar=0.9, it will produce 90% data and 10% samples on collection. Could that improve the situation?

To: All the people with 'loss of control after eva bug' I can't reproduce this bug for the life of mine. Can some of you guys that are experiencing this issue be so kind as to try to reproduce it only using MM + Kerbalism? Can you also try to reproduce it only using MechJeb (and dependencies)? Thank you. To: All the people with 'science loss after docking bug' If you attach a docking port using KIS, somehow the vessel science data is lost. I am aware, I'll find a fix for it. It is probably related to KIS creating a new vessel under the hood, or something similar. If the above doesn't apply in your situation (eg: you got science data lost after docking, and you are not using KIS) then please by all means send me the usual savegame/log. I understand. Unfortunately, this 'replace the science system without anybody noticing' stunt didn't really work out as plain as I imagined. So consider it experimental. Can you elaborate? Yes, there is: I have to implement it .

I checked what the code is doing (this was stuff added long time ago...) and it use the homebody orbit period to determine the length of the year. You only need to scale the antenna 'dist' property by 6.4, look in the support patch for RSS as an example how to do it. The radiation fields are expressed in body radii, so they always scale automatically with the body radius. Yes. It work like this: take all the parts with an enabled habitat module, sum their Shielding amount AND capacity, calculate the level of shielding as 'amount' divided by 'capacity', the result is how much radiation is blocked by shielding for that vessel.

New version released 1.2.0: atmosphere leak rate reduced, fuel cells adapt to required EC, and some other minor stuff.

@Daniel Prates I appreciate the feedback and brainstorming. I have no time for an articulate answer, but in short: I tried everything you mention, either conceptually or practically, and there was always some reason to not implement it / discard it. In future I may change how it work @schrema Thank you so much for both the US patch and the 24h profile. It should use 24h days if that is set in the game config. Isn't that working? @DavidHunter I am interested, PM me. @podbaydoor I agree, let's try 80% reduction in next release. That would be impossible to implement with the current incarnation of Reliability. If it ever get rewritten, I'll totally consider this. Can you provide me: the log file (KSP/KSP.log), the savegame (KSP/savegame/{yoursavename}/persistent.sfs), anything else you think is useful. Sorry, that is due to me changing how much a '_Scrubber' unit is worth in terms of 'scrubbing power'. Vessels saved in the VAB in versions prior to 1.1.9 will have the wrong amount. Reconfiguring fix it to the right amount.

Guys, first of all I apologize for the scrubber rebalance mess in last update. It just slipped... Kerbals died, but that's okay: we can buy other ones. Hey! Thanks. the stock lab is supported in planner/background. However, it doesn't work with the HardDrive. That's why I had to implement my own. The only way to get back to the stock lab is to disable Science, setting Science=false in settings. @kananesgi Nice

New version released, 1.1.9 Enjoy Changelog

When the vessel is simulated I use the vessel orientation stored in the proto vessel. If Persistent Rotation costantly change that, it should work. In theory.

I'm considering adding the scrubber process to the small chemical plant. What you think? I'm going to make the color configurable in future. The render_quality only control how 'marked' the shape border is. I'll think about it. CO2 & pressure are modelled with resources, and in background these are still consumed/produced from the first part found (that will change eventually to emulate ALL_VESSEL_BALANCE instead). More details here You can't, I have to emulate these in-code. This is planned but no ETA I understand what you are asking. That parameter is hard-coded at the moment, I'll make it configurable. It is not possible. It was implemented in the past for a few versions, but then it became evident that planning against it is a mess. So I don't think I'll add it back again.

It has been merged, will be in next version. @MaxZhao It can't be done right now, maybe in future. @schrema Man, nice stuff really. Thanks a lot for sharing it, I'll include ASAP

Fixed panels orientation is taken into account, and traking panels are simulated around the pivot. A portion of the flux is blocked by the atmosphere, depending on density and path length. Probably I should check what's wrong with the low_power script trigger. Anyway, from next version fuel cells will 'smart up' so that they consume in relation to how much is required. Meanwhile just go in Profiles/Default.cfg at line 212 so that it looks like this (changes in bold): Process { name = fuel cell modifier = _FuelCell input = [email protected] input = [email protected] output = [email protected] output = [email protected] dump = false // <<< add this line }

@Climberfx Yes, pretty much. @klugeh01 It is in a custom group, the 'heartbeat' icon. But be advised that parts in Kerbalism are only enabled if the respective features are enabled, and that depend on user settings and profile in use. Can be anywhere in GameData. @podbaydoor Can you check the volume/surface of the parts involved in your case? Right-click them in VAB to see the values. Report anomalous surface/volumes, and suggest more proper ones if you like. I could be wrong here, but the CRP definition of Nitrogen use STACK_PRIORITY_SEARCH as flow mode. So maybe you can only transfer it between same-stage parts? I'm not sure. The latter.

@Drew Kerman NearFuture RTG module is fully supported, but JDiminishingRTG is not supported at all. That entry in changelog refer to an option that was added in Settings to disable the NearFuture RTG decay simulation. Then later realized that it made no sense to be able to disable it (as in, the user can just not use decaying RTG in the first place if he don't want it). So it was removed ASAP in the following release.

It may be of interest: check out project starshot, that want to propel very small scale probes to fraction of the speed of light, using a light sail and giant 1.21 gigawatt lasers on the earth surface.

@Enceos Ahhh But seriously, that's a good start. I forgot to mention something: consider not using alpha blending, there will be too many droplets overlapping and the blending equation will simply oversaturate everything. If the droplets are small enough, the lack of transparency in the individual droplets will hardly be noticed. @sarbian Let's hope the human brain can't recognize the patterns. It should not been able to if the droplets are enough. Good point on the camera rotation. My idea was to have the rain fixed on screen, invariant to 'horizontal' rotation, with the user not noticing it too much during rotation. And to not orient them 'vertically' at all.

@APlayer Your take on the matter is interesting, but the 'patch-clutter' there only cost a trivial amount of CPU time at KSP loading time, where they are parsed. Then MM test for NEEDS[] fail and everything proceed happily. (unless I am misunderstanding what you wrote... that could be possible). But a part author should ideally add support himself because he can choose the terms (like, how far its antenna range should be, and similar) and also he is always on top of his own work and so the patch have lower chances to get obsolete as parts are added/removed/changed. For planet packs, a similar consideration can be made: the author can choose the terms (of radiation, resource definitions, etc) and it is less likely that the patch is not updated when a celestial body is added/removed/change. I already got 22 individual support patches included, that's a lot of mods to monitor for changes. A few can easily become obsolete without me noticing. That being said, I reckon that this mod changed a lot during time and I have no problem including more support patches. @Tech_96 Sorry buddy, I can't replicate the 'control loss after EVA' issue. I installed KIS, loaded your last backup save, loaded the Mun Lander vessel. EVAd out, EVAd in, control is here. Here's a video of the thing:

@CatastrophicFailure These are RadiationModels. The ones you mention have been authored by me, for the stock bodies, and are available in general to use with other planet packs. However you can create new ones (!!), as these are just defined by a RadiationModel node in a .cfg file somewhere. Here on the wiki there are the full specs of both RadiationBody and RadiationModel. I think some people consider the distance-fields system I'm using as some kind of 'voodoo'..., maybe I should improve the documentation or write a tutorial. Anyway, feel free to ask for clarifications if you want to try create a custom model.