ShotgunNinja

I can't do that because it will be 'one way only': user flag vessel as hidden, vessel disappear from the list and can't be de-flagged anymore. You could try to exploit the vessel filtering to hide the ones you want. It will be a lot of work. For instance, I would have to switch to the new Unity UI framework (I'm using the old one, that doesn't support non-latin characters as far as I know). Then, the whole UI layout was fine-tuned by hand, exploiting string lengths that were known beforehand. That would not be the case if I were to support arbitrary languages. Also, 'composing' multiple strings on the fly for an arbitrary language is impossible (and we'll lose little things like the sex of a kerbal being taken into account when generating a message, for example). These issues could be solved with enough time, maybe redesigning the UI around a bit. But that's a lot of work, and not of the fun type but of the very boring "you don't pay me enough for this" type. I prefer to work on adding new features and improving existing ones, instead. That is fun. So there will be no localization support, my apologies to the international community of KSP. @Enorats Some code has changed in the cryotank module, and the emulation in background need to be updated to reflect those changes. I'll add it to the ever-growing list of things todo for version 1.3.0 @CatastrophicFailure I'll investigate the issue, probably related to the 'bootstrap' signal network calculation that is done on-load. Seem to degenerate into O(N²) complexity, where it should not. Can you try a little test for me, disable Signal and try to load a savegame with many vessels, then let me know if it still hang on load. @APlayer Oops. A mistake in the Experiment module. An operator should be required only if 'crew' is specified in the config node. I'll fix in next version. @ItCameFromDuna In emitter, radiation is expressed in rad/s. The comment you refer to is out of sync with the actual value (probably changed and I forgot to update the comment), and should read '0.015 rad/h' in your case. @gietek The ISRU part of this mod is inspired by real chemical processes. I am open to suggestion for new processes, provided that they are based in reality.

@Nils277 Maybe relevant. This assume the CO2 presence on Duna atmosphere is from the CRP definition. Looking at it here, the presence chance is 100%. That will be scaled by difficulty settings (the 'resource abundance' slider in advanced difficulty settings). So people playing above normal difficulty (or tests conducted above normal difficulty anyway) will have some chance of having no CO2 in the atmosphere of Duna. This could be the issue here. If that's the case, a solution may be to set presence chance to 1000% for atmospheric resources, to compensate for the minimal resource abundance slider value possible (0.1). That way all players are guaranteed to have CO2 in Duna atmosphere irregardless of their difficulty settings.

@Keefe You are using RemoteTech. That in turn disable Signal irregardless of what you write in Settings. So no blue spheres with RT. @STHedgeHog Per-second. @OhioBob Sure. @zxxzzxxz Thanks for the report. From what you describe, it seem some kind of endless loop in the signal network calculation. I'll take a look at your savegame.

@Keefe Just to be clear: are you actually transmitting data? The balls only show up when transmitting.

@Enorats Is not due to the rescale. Press B in mapview/tracking station and toggle the field rendering on/off in the window that pop out. Or in alternative press 0-1-2-3 on the numeric keypad to quickly toggle them. @Keefe Hold on, you also need the Science system. Do you have both Signal and Science set to true in your settings?

@Keefe If you use the Signal system, there are really tiny blue spheres moving on the link lines. I swear!

@Enorats, @CatastrophicFailure Correct, it is an interaction with KIS. It seem to trigger KSP callbacks related to vessel destruction every time you add/remove parts from a vessel. Or something to that effect. This in turn wipe out the HardDrive of the vessel. Transfering the data to an EVA kerbal is a nice workaround for now. @Daelkyr When Supplies are 'installed', their amount/capacity is added on top of the resources already in the part. So simply add the resources you want to the part: @PART[MyPart] { RESOURCE[Food] { amount = 20 maxAmount = 20 } } @ISE Thanks guys, I'll include it in next version. @Enorats I made a mistake in setting the LiquidFuel/Oxidizer/Monoprop weight per-unit in the spreadsheet I use to calculate the process rates. Will fix in next version. You are currently producing 5 times more LiquidFuel than you should.

Anywere you want, as long as it is inside the GameData folder. Probably is better to not put it in the Kerbalism folder, or else you may delete it at the next update.

@nascarlaser1 Radiation is only enabled when used in the profile. So you would need some custom profile instead. Profile { name = radiation-only Rule { name = radiation degeneration = 1.0 // just use the modifier variance = 0.1 // add per-kerbal variance modifier = radiation,shielding warning_threshold = 25.0 danger_threshold = 37.5 fatal_threshold = 50.0 warning_message = $ON_VESSEL$KERBAL has been exposed to intense radiation danger_message = $ON_VESSEL$KERBAL is reporting symptoms of radiation poisoning fatal_message = $ON_VESSEL$KERBAL died after being exposed to extreme radiation relax_message = $ON_VESSEL$KERBAL has recovered from radiation exposure } } Put it in a .cfg file inside GameData. Then on your Settings.cfg, set Profile to radiation-only.

16 EC/s is a lot. Can you share your savefile, I would like to see in details how it is consumed. Maybe something can be balanced better. Meanwhile, some obvious suggestions: try to minimize EC consumption in every way you can stop something at night and resume it at day, using automation scripts don't do everything at once: extracting and processing Ore can run at a different time than data transmission, for example if everything else fail, find yourself some big EC generator (not included)

He is... slowly. US fuel cell is not touched, what you see are its original rates. The relative orientation between the vessel and the sun change over time. Fixed panels will not be in the right orientation for long. The obvious solution is to use tracking panels, if possible. Or use multiple fixed panels at different orientations. Set Profile = none in Settings.cfg, that will disable life support and anything else related to it.

Go in Settings.cfg, and use these settings: Profile = none // effectively disable life support, eclss components and isru mechanics Reliability = true // you want part failures Signal = false // you don't want the rest Science = false SpaceWeather = false Automation = false Reliability should really take into account when a component is in use (and things like that should not happen), but unfortunately it doesn't in its current incarnation. Maybe in future. I can't do it, because some MM patch need to be applied depending if the Science system is enabled. So these options have to be known at game launch time. I am aware there are some issues between the Science system and some third party mods. I'll see what I can do. There is no fading in/out based on distance from camera (that's why you can't find it in code). Instead, as all particles are rendered as 1pixel-wide points irregardless of distance from camera, what you are seeing is the particle density on screen getting below some threshold, at which point your visual cortex filter out the sparse white dots (that are still there). This is a minor issue with the method I've used to render these fields. No to both questions. The background transmission will work with CommNet/RemoteTech, but the transmission spheres are ony rendered if you are using Signal.

Set EnforceCoherency to false in Settings.cfg. That is most weird, I'll check it. Maybe some interactions with KCT. But then why it doesn't happen on the launchpad baffles me. You could change it to check for modules of type Antenna instead of the stock data transmitter. However, you can't really detect if one antenna is set as relay without custom code. There is a wiki here, but unfortunately it is just some summary description of things and a few lists. I have plans to add some in-game guide in future. Meanwhile feel free to ask anything.

@The-Doctor You don't make whole parts. You only make 'components' inside already existing parts that can host components, like the ones you configure in the VAB. So, it is a glorified 'reconfigure while in flight' mechanic.

@The-Doctor Essentially, there are these 'components', that are the things you can install in pods, chemical plants, etcetera. Each one has a 'value' in Hardware units, deduced by mass or specified in the component specs. You can dismantle a 'component' and get half of its value in Hardware units. You then spend this resource to install new components when you are in flight. So, let's make a practical example to explain the meaning of this. Assume something goes wrong with your crewed mission, and you organize a rescue but it takes time. Time that wasn't planned in your mission, and they have not enough Oxygen to last until rescue arrive. You realize that if only you brought a Water Electrolysis unit you could make up some Oxygen, from the remaining Water and the plenty of solar power you got. But hey, you did bring Bob the engineer. Now you can dismantle a few secondary components and use the resulting Hardware to install a Water Electrolysis unit and survive until rescue. Hope that this clarify it a bit.

There is a set of API functions that was added a while back, when a forum user (forgot the name, sorry) was working on adding repair functionality to some kind of robotic arm. I don't know how that ended up. Anyway, I like the idea and maybe I'll add a dedicated module to do unmanned repairs. My objective is to somewhat reproduce 'on the field hacks' such as dismantling a scrubber from a vessel to install it in another vessel (think Apollo 13), or even doing more crazy stuff in order to survive (think The Martian). I can't allow to produce Hardware in-situ (or use a resource that I don't have total control of, and that may be produced in-situ for what I know), or else this mechanic cease to be a 'last resort' choice for the player. I see something called 'DynamicBatteryStorage' in your log. Maybe that's interacting with the background simulation in some weird way. To clarify, the cost of data transmission is the same for loaded and unloaded vessels. Hi. Unfortunately, things that produce electricity in Interstellar (reactors, etc) are not emulated when the vessel has no focus. So when you focus on another ship, your base effectively behave like it had none of the parts from Interstellar. I'm sorry about that.

@CatastrophicFailure Yes, just copy the new one in the Support folder and overwrite the old one. @Galileo For now I just disabled KopernicusSolarPanel, some of the rationale is outlined here. I'll add multiple star support in next version.

New version released: 1.2.9 Changelog: - ported to KSP 1.3.0.1804 - improved SSTU support patch (@Maxzhao1999)

@APlayer No models in the mod are made by me. The gravity ring model was contributed by @mehka. There are two animations: 'extend/retract' and 'rotate one loop'. Both are driven in-code by a dedicated GravityRing module.

@Waxing_Kibbous Ok, I understand. I'll see what I can do about that. @ItCameFromDuna These are the possible consequences after a mental breakdown: @APlayer An inflatable ring? I like the idea, and it sound like a realistic design. But I have very low modelling skill, and zero experience in making models for KSP. If you come up with something and want to contribute it, I'll be flattened to include it in the mod. @drtedastro You middle-click on one of the monitor panel icons ('info', 'auto', 'cfg', etc) and that panel pops out as a window, that you can then move by dragging it by the title.

I finished porting the mod for KSP 1.3.0.1804, only thing missing is adding support for the new Kopernicus solar panel, and that should be it. It may take a couple days. Meanwhile the last build on github is already compatible with KSP 1.3 for those interested. @Waxing_Kibbous The only keys used by this mod are: B (to show the body info panel), Keypad 0-1-2-3 (to toggle radiation field rendering), and PAUSE to mute/unmute all messages. Tab is not used at all.

Guys I just noticed KSP 1.3 New Markets has been released. Unfortunately (for you) I am also in the middle of some real life changes... so there will be a quick and dirt porting of the mod to KSP 1.3, in about a week or two, without any of the changes planned. But these are coming afterward, that much I promise. Hold tight and keep having fun.

Mmm, no that is not intentional. I didn't think of this. The greenhouse has to be an habitat for the pressure threshold of growth, but the implementation was a bit rushed at the time. The only solution available for now is to disable the greenhouse during the storm. The crop will not grow during those few hours but that's it, there are no other side effects.

Consider this: radiation when CME hit a vessel is 5 rad/h, so in 5h they were subjected to environment radiation of 25 rad before shielding is applied. With max shielding, you get only 5% of the environment radiation. So they accumulated 1.25 rad during the storm. Given the tolerance of 50 rad total that a crew member has, it means they were supposed to degenerate only 2.5% on their radiation bar, so to speak. So something must be wrong, can you please double-check that you are not using custom settings for the storm radiation? With the default settings, the mean time between storms is 250 days. That's as much as you are going to get in term of information about solar events, the actual ejection time is generated at random. It does already, with the exception that it doesn't take into consideration free Food capacity at time of harvest. If you bring some Food to get the crew up to time of harvest, that container alone should have enough free capacity when the time comes. If you are seeing an error in planner instead, then provide a test case and I'll look at it. @chaoseclipse01 No problem. In fact the lighting icon is not really appropriate, I'm thinking of changing it to some kind of 'spiral' icon at the next refactor (to represent solar plasma in general). Also the enabling/disabling of habitats is maybe the least intuitive aspect of the mod.

@chaoseclipse01, @aluc24 Some clarifications. The storm problem indicator (the lighting icon) appear after a CME has been ejected from the Sun and is predicted to hit the vessel (yellow icon) and then when it actually hit the vessel (red icon). It isn't related to ElectricCharge. There was never an alternative indication for this, is has been in this form since the beginning. Also there is no difficulty setting in the KSP menu, for various technical reasons. To deal with storms, you need a small pod dedicated to be a 'storm shelter'. Choose a small one, and set its shielding to the max. For the rest of the vessel you can choose a lower amount of shielding. When the CME is ejected, you are notified by warning message and by the yellow storm icon. Both of these also show the estimated time to impact. In that time, you have to move your crew to the 'storm shelter' pod. Then 'disable' all other habitats in the vessel. You will see in the telemetry panel that the shielding factor is now entirely determined by the Shielding amount in that storm shelter pod. In this way, the crew can survive quite a few storms. You can reuse the shelter approach even when crossing radiation belts. You don't simply keep the crew in the shelter all the time because living space is also determined from the set of enabled habitats. For greenhouse, the current one is in fact overpowered. It will take a much bigger biomass to sustain even a single crew. A single greenhouse can now sustain 2 kerbals, provided that you have enough free Food capacity when it is harvest time.