ShotgunNinja

@Gordon Fecyk You need to use ModuleResourceHarvester, with HarvesterType=2. Also, on the atmospheric resource definition, be advised that PresenceChance is scaled by difficulty setting. So to assure that your atmo resource is present in any case, even when difficulty setting is 10% (the min allowed), set PresenceChance to 1000.

First get a basic setup going (see here). The basic idea may be simply to add a force to the vessel that negate acceleration in a direction (eg: toward the planet surface, to negate gravity). So lets call the acceleration you want to negate "A", and the acceleration you are using to negate it "B". If you set "B" at every step to match "A", you have perfect hovering (gravity negated perfectly and instantly) If you put an upper boundary on how much "B" can change per-second, you'll get a 'suspension-like' effect (vehicle can scrape the ground) Lower "B" when vessel altitude is above target, and viceversa Specify the above mentioned boundary in an appropriate thrust metic (eg: newtons) Each simulation step, add some small random variance to the direction vector and re-normalize it, to get a 'slight instability' effect Authoring the acceleration direction can be implicit, eg: you can simply use one axis of the part frame of reference. So rotating the hovering engine in the VAB will allow for other acceleration-negation uses. Consuming EC is trivial. Playing audio should be easy enough. Note that this is like an engine module, but with automatic throttle and consuming mass-less fuel.

Not possible, sorry.

@nascarlaser1 You are asking how to design a (manned) payload that could work in this mod, without using the planning facilities it offers. Why not just give this mod a shot instead? Is not has hard as it looks.

You decouple the number of experiments from the number of parts. Writing a new experiment then is trivial compared to authoring a new part. Also some kind of experiments don't really have an hardware that fit in the concept of KSP parts at all.

@John Nowak The current science system is half-finished. The original plan was to have a different take on situations, and use some of the existing science related parts as configurable 'experiment containers'. So the laboratory would have some slots to carry experiments that can make sense in that context. That was the plan. This can be used to some degree right now: add a Configure module to the laboratory, with one or more slots, then specify a set of Experiment modules to be choosen, their tech requirement, extra cost and mass, etcetera. Look in Extra/Experiments.disabled for a primer on the Experiment module, and to understand how the 'new situations' are organized. This wasn't included in the mod at that time for various reasons, especially because I hit a wallI: if you really change the science system, you will have to rebalance the whole career mode. I wasn't ready to do that. Add to this the fact that users seems to resist changes. So the plan stalled, then I went on other things.

Mmm, it should have. Maybe existing contracts have the module name hard-coded after generation, and so you will see it working only at the next lab/station contract. Unfortunately I can't test it directly because generating contracts from the debug menu doesn't appear to work for me. The stock contracts have some specs, located in KSP/GameData/SQUAD/Contracts/Contracts.cfg. On these there also are things like the name of modules to check against in contract conditions. I'm replacing ModuleScienceLab with Laboratory as ModuleName in appropriate PART_REQUESTS subnodes of the base and station contract specs. @Gotmachine Yes, it's a bloody mess... In these cases I usually go back and redesign the whole thing from scratch. But I like how third-party profiles are popping out, so need to be careful and change things gradually. I was thinking for now to to the following.

Update 1.2.4. - SMURFF compatibility patch (@eberkain) - Laboratory module satisfy stock contracts - fix: resource amount not clamped to capacity - fix: script editor window UB after scene changes About insta-death by co2 poisoning and climatization I now know what cause this (#96), and will fix it in next version. Meanwhile, don't warp too fast .

@PieBue Add this somewhere in GameData, inside a file with .cfg extension. @Contracts:NEEDS[FeatureScience]:FOR[Kerbalism] { @Base { @PART_REQUEST:HAS[#Module[ModuleScienceLab]] { @Module = Laboratory } } @Station { @PART_REQUEST:HAS[#Module[ModuleScienceLab]] { @Module = Laboratory } } }

I'm sorry, but at the moment that is not possible. The reason is that settings and profiles are parsed before the MM loader start applying patches. I went this way to detect features from modifiers used, and then inject these as MM patches of the form '@Kerbalism:FOR[FeatureXXX] {}'. But now I reckon this limitation is not worth the benefits, so it will be lifted soon. And ideally environment-related settings will be specified in the profile directly. The space weather system is going to change a lot in the near future (see here), and 'EM/plasma' emissions are going to be specified per-body similar to how radiation fields are defined now.

@Simon91 Yes, there is a panel in the monitor called 'cfg'. In there you can change some options per vessel, including what messages to get from each vessel.

@Uace24 This is compatible with RSS, in the sense that there are radiation fields definition for the celestial bodies, and that antenna transmission distances are scaled. About RO, I don't really know. @IggyHitokage All values of a kerbal should be freezed in time, including radiation, when a third-party mod call the API.DisableKerbal function. DeepFreeze is calling that function when it hybernate kerbals. But from what you describe it seem that something is 'destroying' the kerbal at some point, leading to the values being forgotten.

@bpilgrim Thanks for your cooperation. I think you are seeing two separate issues, one that I can reproduce (better described here), and another that I can't. Maybe because you have a different set of mods installed than me. I'm going to ask one last favour: show me your log. It is the KSP.log file in your KSP directory. Zip it, upload it somewhere, then send me the link.

@bpilgrim I think to have fixed the 'EC level above 100% or below 0% issue', was a stupid mistake in last update. However I'm doing some tests, and I see the issue with EC dropping to zero for a single simulation update, but only for loaded vessels. The CO2 insta-death is simply an indirect consequence of that. Help me out on this: I've updated the dll posted above, redownload it. Can you confirm that the EC/CO2 issue is only happening for loaded vessels? That should be the case. Anyway, if you confirm that, I'm almost sure what is going on: this is caused by the stock solar panel module. The issue is not reproducible 100% of the time. What happen is the same thing I fixed for unloaded solar panels a few months ago, namely that the sun visibility calculation is sampled very few times per-orbit at max timewarp.

@smckamey19, @bpilgrim Can you guys try this replacing Kerbalism.dll with this one? Let me know if that fix the issue(s).

@theJesuit, @fourfa The 'resque gift' resources are generated from profile specifications, so they should work with any profile as long as Supply nodes specify an 'on_resque' value. So maybe the code isn't working as expected, I'll do some tests. @smckamey19 The laboratory analyze samples so that you can transmit them. So it make sense to bring one when you plan on staying for long time, or even permanently. In that case, you can't easily return the samples and the lab is useful. If you go to duna in a week-long mission, then obviously you don't need a lab. If instead you go there for a year, and meanwhile want to get the science credits all the while the mission is still there on duna, then bring the lab. If you don't like how it work, you can go in Settings.cfg and set Science = false. For the bug reports, please provide savegame, logs, list of mods, screenshots, reproduction steps, etcetera. @Drew Kerman (1) Right now, the experiment xmitScalar is used to deduce if some data is a transmissible file or a physical sample. I've set the threshold to 0.66 in last version, so any experiment with xmitScalar below 0.66 will be considered a sample, and all the others will be considered files. When the xmitScalar is not available (because data is hijacked from somewhere else than a stock experiment module) I assume it to be transmissible. (2) For transmission rates, I tried to model the real-life rates we got on similar antennas at conceptually similar positions in the solar system. For EC consumption I just went with something that could make sense balance-wise with progressively better antennas consuming more EC, but the rates are probably very wrong compared to reality. There are some save-breaking changes incoming in a few weeks, so if we want to use more realistic values this will be the right time to change them. Or even calculate them automatically as you suggest.

New version 1.2.3 has been released, enjoy. Changelog: - resource cache production/consumption simulate ALL_VESSEL_BALANCED - added Waste Incinerator process to ISRU chemical plants - moved Waste Compressor process from manned pods to ISRU chemical plants - EVA kerbals now have a non-regenerative scrubber, with fixed duration - increased amount of EC and Oxygen on EVA kerbals - improved description of configure setups - scale low-gain and high-gain antenna distances differently in supported planet packs - lowered xmit scalar threshold used to deduce if data is file or sample - safemode malfunctions don't stop timewarp anymore - support patch for RLA Stockalike Continued (@YaarPodshipnik) - NearFuture PB-AS-NUK emit radiation (@YaarPodshipnik)

Kerbals go back to their pristine status after they are 'recovered'.

@Not Sure You see the 'monitor', on the app toolbar. Click on it, it will show a list of vessels. Click on a vessel, it will show one 'panel' for that vessel (the telemetry one). There is a list of panels just below it. Click the vessel config one (labeled 'cfg'). Now you are shown a list of options for that vessel, including some to enable/disable various warning messages (and the relative stopwarp). Enable/disable these as you see fit, for each vessel. The values persist in your savegame. So to recap: Monitor -> Select the vessel -> Select 'cfg' panel -> click on options to change them @fourfa Resque missions are detected and ignored by the simulation, until you approach them to physical range. Then a bunch of resources are gifted to them. If the vessel has no capacity for these resources, I give it capacity too. Only then the simulation is enabled for them. The amount of resources to gift is specified in the Supply definition in the profile, in the field 'on_resque'. These are the amounts in default profile: 1000 EC 1000 Food 1000 Water 10000 Oxygen that are enough for a few days. So from the moment you approach the resque vessel under 5Km the first time, you got a few days to save its crew. Is this system not working in your case?

Seeing that aurora match the outer belt brought a tear to my eyes.

Absolutely. Find out the unique name of the part (eg: 'spaceXpod'), then create a .cfg file like this: @PART[spaceXpod] { RESOURCE { name = Food amount = 100 maxAmount = 100 } RESOURCE { name = Water amount = ... maxAmount = ... } // ... } All antennas are used at the same time, each one with its current data transmission rate. So we can say that the transmission rate 'stack', in that sense. But transmission distance doesn't. @JWS Thanks, I'll check it out. I got a number of issues with KIS on my TODO list for next version.

Ah ok. So simply lose atmosphere from an hab part when going out on EVA, that could be interesting: simple to implement, and will incentive the player to use small habitats as airlocks. I'll think about it. In my replies I was talking about a more complex mechanic where: you enter the airlock hab, isolate it from the rest of the vessel, equalize the airlock pressure to the external one, and finally go on eva. Then invert the process when returning from eva. @Iso-Polaris, @CatastrophicFailure You can disable the reliability warning (and associated stopwarp) from monitor -> vessel config panel. You can also 'kind of retire' vessels by setting them to debris, that has the additional advantage that you will not see them in the monitor list anymore (and they aren't processed at all by the mod, so some performance benefit too). I see what you guys meant. If you have an hundred vessels and you didn't the above gradually, it will be a pain to change all of them at once. But I got a 'solution' : the warning configs are in the savegame, and you can change them all with a text editor: replace all occurrences of the string 'cfg_malfunction = True' to 'cfg_malfunction = False'. You can do the same for all other warning configs (cfg_ec, cfg_supply, cfg_signal, cfg_storm, cfg_script). @popos1 As explained above, that is how the signal mechanic of this mod work. A clear distinction is present between low-gain and high-gain antennas. More info is on the wiki. If you don't like how this work, you can disable the signal mechanic completely by going in the file Settings.cfg and setting signal = false.

@blakemw, @DavidHunter The 'insta-death by CO2 poisoning' was probably caused by the 'have a flag and cache stop updating' issue (#75). I'm going to make sure about it for next version, using blakemw text case. What happened was this: the level of co2 in a vessel is stored in cache. If you had a flag in your savegame, anywhere, the level was not updated anymore. So you had kerbals dying of co2 poisoning irregardless of the real state of WasteAtmosphere in the vessel. The issue was made to look 'a bit random' by the fact that after booting KSP and loading a savegame all cache entries were calculated correctly, but just once. So the starting values in cache were correct, but then stopped reflecting the environment and resource state. Also, #75 that was probably the cause of all bug reports about vessel incorrectly in sun/shadow, and by extension of all bug reports about solar panels not producing EC in background when they should have (because sunlight status is also in cache, so if you booted KSP when a vessel was in shadow). All for those damn flags... the fix was perhaps the most productive two-liner ever

I'm doing some experiments on new ECLSS stuff, and come out with a way to exploit the current process system to implement non-regenerative scrubbers, the kind used before the 2-bed vacuum-exposing ones used in these days. I'm not sure that I should add it to the default profile, mostly because 2 new ECLSS setups were already added in last version, and because this is a dirty hack. Anyway, I'm sharing it here in case somebody want to experiment with this.

I agree. I'll include the tweak in next version. Similar for RSS, I'm keeping the x16 scale on high-gain, and using x10 on low-gain. Distance is in meters, I've clarified in the wiki.