ShotgunNinja

@CatastrophicFailure Thanks. If that was posted here before, i totally missed that! Just add a RadiationBody (and optionally a custom RadiationModel) definition in any .cfg file. As long as is inside GameData it will work.

@Enceos It would be much faster. That may be relevant or not depending on the amount of droplets you want to render. The speed gain is not in the rendering (well, sure is not going to be any slower) but in the simulation. The fact is, you don't need simulation. You don't need to do a vector3 add for each individual droplet. Consider that a vector3 add take on the order of a microsecond in our environment (that is 3 orders of magnitude higher than in the 'real world' of c++ move operators, gcc aggressive optimizations and simd intrinsics, where a vector3 add take a couple nanoseconds instead). So, assume you have a thousand droplets, that is a thousand vector3 additions per-frame. That could be a full milliseconds, and only for 1k particles. And that is assuming unity is not wasting any other cpu time there (let's be frank, that's probably not the case). I did some simple stupid infographic on the method (stole your rain graphic )

By the look of the image it seems a problem of space in which the normal map is authored, versus space in which it is interpreted to be by the shader. Usually normal maps are in tangent-space. Here's some background on this, that can be useful to know:

Guys anybody can share a link to this radiation config for GPP? @Galileo I can include the GPP radiation config, no problem (I got some other planet packs configs already included). You can also include it yourself if you think the celestial bodies are going to change (or more are going to be added), and/or if you want to author the radiation fields of your bodies. @Daniel Prates Some features are turned on/off automatically based on the profile used. More precisely, based on the modifiers used by that profile. If the one you are using doesn't use the comfort modifier in any rule, then the comfort mechanic is turned off. The gravity ring get disabled in that case, because it is a comfort provider and will have no reason to exist if there is no comfort mechanic. I had a look at the TAC profile you mention, and it seem to be using the comfort modifier. So there must be something going on here. Can you send me your log? You can find it in KSP folder, with the name KSP.log, and you can upload it somewhere and post a link here on the thread. @Tech_96 It is a bug, that I can't reproduce on my install however. Questions: are you using mechjeb? what other mods are you using? can you send me your savegame?

For rain maybe you could bypass the unity particle system (because, why not, lets render a million droplets instead of a few thousands). Create a single mesh including a random set of individual 'droplets' (as two triangles each, then a degenerate zero-area triangle afterward to separate the quad from the next one). Alternatively use point sprites. Then, render the mesh (oriented and) moving 'down'. 'Down' could be determined simply by the current vessel -> main body center vector. To have an infinite loop, render two instances of the same mesh, one at the top and one at the bottom, both moving down, and re-start the bottom one (above the top one) when it goes below some negative threshold from ground level.

See here for some basic skeleton code that may get you started writing and compiling plugins. You create a module class, inheriting from PartModule. Then you add an Evacuate() KSPEvent, and an EvacuateAction() KSPAction that simply call Evacuate(). Tweak both methods metadata (the KSPEvent/KSPAction properties) so that they show the string you want in the UIs, and so that the event button is only available in flight (and not in editor). using System; using System.Collections.Generic; using UnityEngine; namespace REKT { public class REKTpod : PartModule { // this is the event: it add a button on the part UI [KSPEvent(guiActive = true, guiActiveEditor = false, guiName = "Evacuate!", active = true)] public void Evacuate() { // TODO: (1) find first available kerbal // TODO: (2) move available kerbal inside REKTpod // TODO: (3) find decoupler module in this part or the parent one // TODO: (4) trigger decoupler module 'Decouple' event } // this is the action: it add an available action to the part, for use in action groups [KSPAction("Get the hell out of here")] public void EvacuateAction(KSPActionParam param) { Evacuate(); } // this function is called to generate the part tooltip info public override string GetInfo() { return "hey, this actually work!"; } } } // REKT Now you only need to implement Evacuate() itself (note that the following has not been tested at all). // (1), (2): get first crew member, move it into REKTpod // here we scan all the parts in the vessel foreach(Part p in vessel.parts) { // we skip parts with no crew if (p.CrewCapacity == 0 || p.protoModuleCrew.Count == 0) continue; // we get the first crew member ProtoCrewMember crew = p.protoModuleCrew[0]; // remove it from the part p.RemoveCrewmember(crew); // and add it to the REKTpod part.AddCrewmember(crew); // we moved the crew member, no reason to keep scanning other parts break; } // (3) find decoupler module // first we try to look in the REKTpod part itself ModuleDecouple decoupler = part.findModuleImplementing<ModuleDecouple>(); // then we fallback to look in the parent part if (decoupler == null && part.parent != null) decoupler = part.parent.findModuleImplementing<ModuleDecouple>() // (4) decouple // if a decoupler module was found if (decoupler != null) { // simply call its 'Decouple' event directly // this is equivalent to the user clicking on 'decouple' in the part UI decoupler.Decouple(); }

It is possible to move crew from a part to another one in-code. It is also possible to trigger decoupling (or any other action) in other modules (even if these are in other parts). The 'abandon ship' event in your module can be triggered by action groups (abort, or custom ones). Personally I would go like this: have a REKTpod module added to all your emergency pods have a 'get the hell out of here' event in the pod module, and associated action can be triggered by the player, clicking on a button in the part UI can be triggered by action groups (it may even default to the abort action group) when the 'get the hell out of here' event is triggered: scan the vessel for kerbals move the first one inside the pod look for a stock decoupler module in the emergency pod itself, or in the first parent part trigger the decoupler module 'decouple' action

When I detect a rescue mission vessel/kerbal, I gift them all supply resources as defined in the profile in use. The case where the vessel/kerbal has no capacity for these resources is also taken care of: I just add capacity for them on-the-fly. So in your case, that must have not worked. Send me savegame/log when that happen again.

@astroadrian99, @Algiark Can you send me your savegame file, so that I can do some testing? @CatastrophicFailure The problem is that the galileo's pack bodies have no radiation definitions (yet?). That is why you don't see them or you can't toggle the rendering on/off. @Su33 I agree, oceanic resources will be interesting. I didn't add them yet mostly due to lack of an adeguate part. The harvester module itself already support oceanic resources however, albeit that wasn't really tested (but it should work). @Rhedd Inflatable habitats are disabled, unless they are fully pressurized (with some tolerance). This mean that an non-inflated hab (or even one that is not fully pressurized) will be de-facto disabled. The gravity ring is not an habitat. Instead it act as a comfort-provider for the 'firm-ground' bonus. So, the gravity ring doesn't add to the living space nor it need to be pressurized. I deduce volume and surface from the BB, if not specified. To specify it, simply define a 'volume' and/or 'surface' field in the Habitat module definition. They are expressed in m^3 and m^2 respectively. The full specs of the Habitat module is here. It would be definitely better to have the volume and surface defined for every part, past present and future. But that is not realistic. What is realistic instead is that some part may end up getting the volume/surface explicitly defined, and for all the others to have a relatively acceptable fallback (automagically deduced from the BB). It is still possible to specify 'ratio' of consumed/waste resource in a rule. If not specified, the ratio is deduced automatically from the two resources densities (with perfect mass conservation). Full specs for Rule is here.

Not a bad idea. New processes are very easy to add, so you could start adding and testing some new one yourself. Then share these here or on github and I will probably include them in the next release. I'll look into this. The configure module doesn't 'initialize' any module. What it does, is it set isEnabled to false for those modules that are (A) included in a Configure setup and (B) whose setup is not the selected one. You are doing nothing wrong, there is a fundamental issue here. The greenhouse require to be pressurized (in the default profile), as it is an habitat itself. The crop will not grow without a pressure above 0.1 atmospheres (if I'm remembering correctly). However, the greenhouse doesn't include a pressure control process, so it has to rely on the ones in manned modules (that I'm assuming are not present in your case). In next version I will add some small pressure control capacity to the greenhouse to solve this issue. Also probably relevant, the crop can only be harvested by the crew at the moment. That too may change in next version.

Long time no see guys That has changed in version 1.1.5, now the scrubber sequester carbon dioxide from the internal atmosphere of habitats, but doesn't recycle it to oxygen anymore. As such, there is no efficiency. Instead, each scrubber has a capacity, expressed in how fast it can sequester the co2. The CO2->Oxygen conversion is then taken care of by a dedicated process, available in the chemical plants in the late-game. That's an interesting take on the matter. It is technically possible. I'll consider this in future for the engines and other modules that could benefit from use-dependent aging, but the issue is that I don't want to write 'in use' detection code for all modules. Hence the move toward generic module-disabling reliability system. Right now, as you discovered, I only vent Atmosphere. Honestly I don't remember why I don't also vent WasteAtmosphere (that would make sense overall), but there must have been a subtle reason. Maybe it was exploitable by the player. Anyway, I'm going to add it in a next version. Yes this is intended. Now you have a single habitat per-vessel, that can as well be non-contiguous and/or include parts that have no crew capacity at all. And the habitat can be reconfigured in flight, by enabling/disabling individual hab parts. The 'storm shelter' scenario still work: the user move all crew to the storm shelter, then disable all habitats except the storm shelter one. Interstellar Extended modules are not simulated in background. This may change in future. Constellations (that I'm assuming is a multi-star mod?) will probably have issues because I assume there is only one star, and that star has index zero This bug has been reported multiple times. However, I can't reproduce it myself. This complicate fixing it. Send me the savegame with the issue, after it happen. Press 'B' in map-view/tracking-station to make the body info window pop out. From there, you can toggle the fields rendering without numeric keypad.

@podbaydoor 1) Bakground data transmission will work with Signal, RemoteTech or CommNet. 2) I'll take a look, but can you try to see if that's the case in 1.1.8? 3) The reliability has no concept of a module being in use or not. Also, manufacturing quality is not influenced by technology anymore (from 1.1.5+), instead it is selected per-component in the vab (the 'quality' button, in part UI). @ragusila Yes of course. @PART[*]:HAS[@MODULE[Reliability]]:FINAL { @MODULE[Reliability] { @mtbf *= 4.0 } }

@ragusila Each rule is executed every interval seconds. If interval is zero (the default), it is executed continuously. So rate is the amount of resource consumed per-second (if interval is zero) or per-interval (if interval is more than zero). When the rule is executed, if the resource amount required is not available (or, if the rule doesn't require a resource) then an internal accumulator (of a specific kerbal, for that specific rule) is incremented by degeneration value. So, degeneration is expressed as increment of this accumulator per-second (if interval is zero) or per-interval (if interval is more than zero). When the accumulator reach fatal_threshold (that default to 1.0) then the kerbal die (or an unplanned event is triggered on the vessel, if breakdown is true). Both rate and degeneration are multiplied by modifiers before being used. For example, the breathable modifier value is 0.0 if the vessel is inside a breathable atmosphere, and 1.0 otherwise. So a rule using the breathable modifier will effectively have a rate and degeneration of 0.0 when inside a breathable atmosphere. The pressure control ECLSS module use Nitrogen to produce Atmosphere (an invisible pseudo-resource). The level (as in, the amount divided by capacity) of Atmosphere in a vessel determine the pressure. The capacity of Atmosphere in a vessel depend on the internal habitable volume. So bigger vessels require more Nitrogen to stay pressurized. In Default.cfg, the pressure control ECLSS module include a little amount of Nitrogen, that is only okay for very small vessels and very short missions. The player is expected to add Nitrogen tanks to bigger vessels and/or longer missions (there is a configurable radial tank included that can store it, available in 3 sizes).

@ragusila It should work without problems with RealFuels (don't know about RO itself, but I don't see why it shouldn't). Probably you want to create a custom profile, especially for the ISRU chemical processes. I had to compromise and stock-ified the sabatier, anthraquinone and hydrazine production processes. But I left notes about them (it is all in Default.cfg). So for instance here I stock-ified Methane as LiquidFuel. Process { name = sabatier process modifier = _Sabatier input = CarbonDioxide@2.030166581 input = ElectricCharge@0.5 input = Hydrogen@1.0 output = Water@0.003242754 output = LiquidFuel@0.001443825 // (Methane@2.013702929) } Also, perhaps most importantly, the Default profile is really assuming Kerbin day length. You could tweak the kerbal rules consumption rates (and/or intervals) to adapt them to 24h day length. Shouldn't be terribly hard. It is okay if you post the custom profile here (or the set of patches, or whatever turn out to be necessary), no problem.

@mikegarrison I understand perfectly. I don't like the biome grinding either. My whole plan for revamping the science system is about making it less LOLkerbal. Hoppers are an abomination in my eyes. I am working on some custom science situations (together with the collection over time), but is still a WIP (and probably will be for some time). We could say it is still in the design phase. Right now in my tests I made only landed situations biome-related (doesn't make sense at all to be inside the inner belt over kerbin grassland...). Perhaps I could remove the biomes entirely instead? Maybe replacing them with latitude zones or something like that? I'm looking for some ideas on this. There is a new Experiment module with the custom situations already. It is currently unused, and as I mentioned is all very WIP at the moment. To try it you can rename Experiment.disabled to Experiment.cfg inside Kerbalism/System folder. But do not expect to have a meaningful user-experience yet. @pslytely psycho No problem, and thanks!

@JediRangerkendor Right now these antennas are supported directly: stock ven stock revamp J2X Antenna Origami the little transmitter of SurfaceExperimentPack SampleReturnCapsule get an embedded antenna the antenna in Tundra parts pack one of the cupolas in Stock-alike Station Parts Expansion get an embedded antenna I am open for contributions of other patches. It's not hard to write these (the Antenna module specs are here, for instance). The ones in the list above are either things that I used personally at some point, or patches that users wrote for themselves and then shared with all other users.

@JediRangerkendor This mod CAN REPLACE the stock signal system with its own. All stock antennas will then be converted to use this new signal system. Some antennas from other mods are also supported. So, in all honesty, I don't know what you are referring to.

@Captain Dax Therein lies a problem. My Hydrogen is not a gas or a liquid per-se. Rather, the matter state depend on the pressure at which it is stored. Ergo, it is implicitly a liquid or a gas depending on the storage density of the container.

@mikegarrison I see the lab as something you want on somewhat more permanent stations in orbit or on surfaces. So you send the lab (and a scientist, and the means to keep it alive) because you can't return the samples, and the only option you got is analyzing them in-place. Personally I despise the stock lab mechanics very much, but if you want it instead the only option is disabling Science feature completely I'm afraid. I will consider making the fuel cell not dump overboard anymore for next version. Meanwhile it is very easy to change that: just go in Default.cfg and change the fuel cell process to this: Now I don't know about cryorocket fuel tank at all, but any container will work as long as it has the right resources. Yes that can also be used to turn fuel cells on and off automatically. Isn't the automation system awesome? @APlayer I can't really disagree with your point of view here. It make sense, and I'll think about that for next version. Meanwhile you could make the extra cost/mass not proportional to part cost/mass by dividing both fields with the part cost/mass. Example (untested but should work):

New version released 1.1.8: - the science dialog is back (but can be hidden with settings) - stop disabling Science if ScienceRelay is detected - new API functions to deal with science data - better support for SSPX by Yaar Podshipnik - telemetry env readings require sensor parts - kerbin magnetotail now extend just beyond mun orbit - SCANsat support in automation - show BodyInfo window automatically the first time user enter map view or tracking station - tweak antenna distances on supported planet packs - fix: popup message about data when entering from EVA - fix: configure window is closed when related part is deleted in editor - fix: minor fixes in Science.cfg - fix: heliopause crossing contract - fix: pass credits instead of data size when firing OnScienceReceived event - fix: do not throw exception during data hijacking if science container is not present - new Experiment module with custom situation support (WIP, currently disabled)

I finally wrote the documentation for the Configure module, you can find it here on the wiki.

@raptor_xxl What you describe is not happening on my install. EC is removed from pods like the other resources, and then added back when re-entering the pod. I suggest you press ALT+F12 => Debugging => Toggle on the 'Show all log errors/exceptions on screen' options. Then check if you see a red message on top right of screen when you go out on EVA. @APlayer High-quality extra mass/cost is defined as a proportion of the part mass/cost. This was added in 1.1.6 to make cfg files easier to write. @mikegarrison Send me the log when this happen. @Jade_Falcon Thanks, that exception is thrown to let me know when the code can't find a container. Probably catceye is opening the science dialog, but has no data container at all. I have an idea how to make the hijacking work anyway in that case, will implement it in next version. @pslytely psycho If you want you can send me the log and I'll try to figure out what's going on, no problem @Meroni First click on the 'heartbeat' icon in the toolbar, then on a vessel name. That will show you the details panel. Left-Click on 'info', 'data', etc... to switch the details panel mode. Middle-click on 'info', 'data', etc... to pop out that panel as a window. @MaxZhao Absolutely, they are not concept art. Press 'B' when in map-view or tracking-station to show a window where you can toggle the individual fields rendering. Alternatively you can alsu use KEYPAD 0/1/2/3 to quickly toggle them. I reckon this is not obvious to new users, so in next version I'm going to show that window automatically again. @ValynEritai I got an update almost ready, just waiting to find some free time to clean it up. I would say a few days, a week max. @Yaar Podshipnik I do not touch KerbNet at all (I'm referring to ModuleKerbNetAccess). The Harvester module doesn't support asteroids, but that is okay because the stock asteroid drill is fully supported in background simulation. Anyway the real reason is that I kind of ignored asteroid mining for the moment. I like the pyrohydrolisis Ore + Water + EC => Lithium a lot. For xenon and argon it could be harvested directly from atmosphere like the other gasses, all of them technically are extracted using some kind of air distillation in the end. I think these new things should be put in a support cfg, so that if the user doesn't have NFT it doesn't see these processes. But yeah I like this and I want to thank you for all your contributions, really!

@William516 Ok, lets find out what's causing this. Here is what you have to do (follow exactly please): load the savegame that's causing this problem go on EVA and reproduce this issue take a screenshot (hit F1) close the game send me: the screenshot (it will be in KSP/Screenshots) the savegame (it will be in KSP/Saves/YourSaveGameName/default.sfs) the log (it is the file KSP/KSP.log) a list of mods you are using (make a screenshot of your GameData folder in explorer)

@bpilgrim Thanks for the report. The screenshots helps a lot, but I need to be able to reproduce this myself to fix it. Please send me a savegame that I can load and where the issue manifest itself right away.

@William516 I installed Kerbalism and TAC, tried to go on EVA: all good and normal, monoprop is here. So at this point we can exclude that TAC is somewhat involved. Can you tell me what other mods are you using? @StupidAndy It is already on CKAN...