ShotgunNinja

@herman When you unlock better 'signal processing', the effective ranges of antennas increase but there is no unlocking of parts. And kerbalism re-use the stock antennas, it doens't add any other except the communotron 8.

If USK is using the stock converters they should work out of the box. This mod doesn't suffer from 'high timewarp problems' anymore. So more details are needed: it is happening on loaded vessels? on unloaded ones? do you have some ec producer/consumer that is not supported by this mod? And the usual log+savegame. You need to prove that what you say is happening and is related to this mod, or I can't do nothing about it. I am doing some serious working on ISRU, that will allow the user to produce Oxygen in situ among other things. Namely, you will be able to produce it using Molten Regolith Electrolysis (out of Ore) and Solid Oxide Electrolysis (out of atmospheric CO2). There will be a full stack of interesting transformations available for a Duna colony . And both the scrubber and greenhouse are changing, moving a bit more toward realistic mechanics. I'm timing these changes for KSP 1.2.0 public release, together with some savegame-breaking ones. Contributions are welcome, and I definitely want the greenhouse to consume some tiny bit of carbon dioxide and to produce a tiny bit of oxygen. Consider that right now I'm in the middle of a big refactor that is not on the version in Github, but I didn't touch the Greenhouse yet. You will need to add some fields to the greenhouse module, andchange its FixedUpdate/BackgroundUpdate functions to produce oxygen (look in the resource cache for how to do it). Then you will need to change how the greenhouse is simulated in the planner (there is a resource simulator there).

I can't fail to note that you provided no information about the concepts themselves. Add a very short, concise description of each one of them. Precision and abundance of details are not relevant. The designs ideally should give clues about the scope of the project, the major mechanics, what the core user interactions are and where the major problems in implementation could arise from. At the very least they should give the reader a feeling about what the game is about. This is something i wrote in another, more innocent era. Digged out from some ancient stuff of mine for the purpose of showing you how a very early and crude design could be written down.

Made my day I am looking at the code of both SSTUSolarPanelStatic and SSTUSolarPanelDeployable: they should be doable. I'll add them to the todo list. I also see a whole lot of goodness in SSTU code: converters, lights, and fuel boiloff modules. Definitely need to try it out.

@lajoswinkler Send me the log, the savegame, a list of part mods you are using and the name of the vessels that are showing this problem. @ss8913 I want to show you something: this is the data stored in the KSPIE nuclear reactor module: Now, I believe that alternatorPowerKW could be the EC production for the module, but who knows. I don't really have time to dig in all of this, and this is just one among twelve types of reactors.

@inigma It does. Kerbalism use CRP resources (well, mostly), US added esplicit support a while back, and recently I added a MM patch to address some minor balance issues with the US containers. @Captain Dax The TAC-emulation profile is only meant to mimic TAC rates, and as a bonus unlock TAC related parts in other mods by tricking them into believing that TAC is installed. But there is obviously no implementation of the TAC modules. EDIT: Oooops, I didn't read it was the KPBS Elektron. You'll have to get your hands dirty Here is a patch made by DarkonZ that do a similar thing, but for the Realism profile. Maybe it can work as a starting point.

But but... KerbNET man!

@Yaar Podshipnik I will be using the stock ModuleResourceConverter like now, except that you select one or more of them in the VAB. Making my own converter would have been possible, but in this way I can support other converters added by mods: they'll just appear on the list of available chemical processes. So trait and experience level can just be specified in the module config of the converter, like it is in stock. But I would not be using that for the processes I'm adding. Unfortunately reseach can't be used to effect the efficiency, as the stock converter doesn't have that feature. Perhaps I could hack together something to only unlock certain modules after a technology has been discovered... that's not terribly hard to do. I'm going to leverage CRP as much as I can. The part packs you mention could definitely get an MM patch to have the 'module selector' and a common set of processes. Also, animation of how it work.

You need to start from the beginning. Learn how a microprocessor work, how the stack is used in function prologues/epilogues, how to write code in low-level languages. In this order. I see many failing because they skip these steps and go straight to high-level languages, but without the base they will never understand how things really work and will take stuff as magic blackboxes. Those that succeed instead, they learned that magic do not exist and that blackboxes must be ripped apart. Gamedev is a nice incentive to learn, especially when you are young. It also has graphical feedback, that is quite satisfing when learning. Even in this sense, start from the beginning. Don't fire a modelling/animation software and expect to learn by trial. They are too complex, they grew organically along with the technologies involved. Most of them are just messy. Start from learning how meshes are stored and animated instead. How bone-based deformable meshes work. Think of data. This is not the big issue, you are just an engineer in being. Is not like somebody is born as an 'idea guy' and another is born as a 'make things happen guy'. You need to make conscious choices in how you want to relate to everything.

I figure it may be useful to brainstorm about what I'm doing in these days. While some stuff is waiting for KSP 1.2, I'm looking at the sorry state of ISRU and got a plan to make it more interesting. It is central to life support for missions beyond the home system. It is central for fuel on manned missions that plan to actually return home. The stock ISRU system is: trivial, boring, not interesting, doesn't teach anything. Only good thing are the parts. If you don't agree then feel free to virtually append IMO to my sentences whenever you see fit. First, I just finished a 'selector module' that can be added to part and allow selecting between modules in the VAB, sort of like InterstellarFuelSwitch but for modules. It can enable 1 to N modules, and has a simple UI to select them. Then I refactored the stock ISRU converters. I wiped out the existing conversions and replaced them with chemical reactions I found in ISRU literature such as: molten regolith electrolysis, solid oxide electrolysis, sabatier, etc. Still working the numbers. Also, I found out about PLANETARY_RESOURCE & company. Useful stuff, I wonder why stock don't really use it more. Also found out that the atmospheric harvesting is broken in stock. I guess nobody is really using that. Not surprising that some mods developed their own atmospheric harvesting modules. So the plan is for the user to select one or more chemical processes from the available ones, in the VAB, and assign them to the ISRU converters. Similar thing to assign resources to extract to drills. The small versions got 1 module they can select, the big ones 2 or 3. And I got the idea of re-using the atmospheric analysis experiment part as an atmospheric harvester. Seems ideal. I would like to find one part that may be used as oceanic harvester too, but doesn't seem to be anything in stock that look like one. What's left to decide is what kind of ISRU processes are interesting, what body should provide what resource and where, and how to do all of this without adding other resources. Except maybe Hydrogen. I would like to keep the LiquidFuel as a representation of Kerosene/Methane if possible. Oh, and I started reading Ignition!, later to be followed by The Martian, to kickstart me into the subjects.

@steve_v The fact is that sensor is consuming 0.2 ec/s. Stock sensors consume 0.0075 ec/s. So it is consuming 26 times more than the stock sensors. It is consuming a big portion of a small fixed panel in stock. Don't know if that is intentional. Maybe nobody noticed in stock because EC is practically irrelevant there. If I could restart this mod from the beginning I would certainly spare me the pain that derived from reducing panel outputs by a factor of 4.

@steve_v Nice detective work. You probably want to send a bug report to the author of Orbital Science. Kerbalism does nothing to the DMEnviroSensor module.

@steve_v It could be that on the vessel is present some EC consumer that I do not simulate in background (or in the planner). Or a bug. Need the usual log/save to find out. No, but you can set ShowRates to true in Settings.cfg to see the overall consumption/production rates for the vessel, in the info window. That may help perhaps. I have no idea.

@inigma It is possible, by just adding an Entertainment module to those parts like this: @PART[KIS_ghettoblaster] { MODULE { name = Entertainment rate = 1.1 description = Pump up the volume, maybe you'll be able to ear in vacuum. } } Note that they will not provide entertainment when stored inside a KIS container. Also, if you are using CLS they will not be detected as being part of any internal space and so they'll not provide any entertainment. I'll think of something to fix it for next version. @lajoswinkler Could you provide more details?

The outer belt is composed mostly of mid-to-low energy lightweight ions, and shielding is effective. Its thickness is not uniform and is very small near the poles. All manned missions that had the need to cross the outer belt did so at the less thick areas. It is also possible to launch from the poles and completely avoid the outer belt, but that is not really practical. The inner belt can be avoided. You especially want to avoid putting living matter through the inner belt in all cases, as it is composed mostly of very high energy ions and shielding in not that effective. Absorption levels vary with space and time, but 500 rad/day for the inner belt and 100 rad/day for the outer are good estimates.

@bananashavings Essentially, there are two things you can configure: features and rules. Features are things like Malfunction or Signal. Rules are things that determine what resource kerbals consume, and how they die. Both features and rules are defined in what I call 'profiles': these are just glorified .cfg files. The installation already include a set of profiles inside the Kerbalism/Profiles directory. All of them are disabled by default, except the one called 'Default.cfg'. There are these profiles included: Default: enable all features and contain rules for food, oxygen, radiation and quality-of-life Realism: like default, but with water TAC: emulate TAC-LS Snacks: emulate Snacks! Barebone: only enable radiation and quality-of-life RadiationOnly: only enable radiation StressOnly: only enable quality-of-life I suggest you look into the Default.cfg profile to see how it work, is very easy. At the top you got the features: @Kerbalism:FOR[EnableSignal] {} @Kerbalism:FOR[EnableReliability] {} @Kerbalism:FOR[EnableScrubber] {} @Kerbalism:FOR[EnableShielding] {} Just delete or comment out the lines with the features you don't want. Then, immediately after, you got the rules: Rule { name = Climate [...] } Rule { name = Food [...] } Rule { name = Oxygen [...] } Rule { name = Stress [...] } Rule { name = Radiation [...] } Just delete the ones you don't want, or change their values, or create new rules.

@bananashavings Yes, look on the wiki. Also the last 2 pages have some info in that regard.

@gamerscircle No problem at all. In future I'll try to make the process of selecting features more user friendly. Have fun.

@gamerscircle The mod will pick it from any file with extension .cfg, anywhere inside the GameData directory. So you could store it in GameData/my_custom_profile.cfg for instance. Anywhere you like as long as it is inside GameData and has the .cfg extension. Changing extension to something else than .cfg (like .cfg-disabled or .whatever) is just a simple way to have the file not parsed, without deleting it.

@gamerscircle You could do that, but then risk to lose it when the mod is updated. Instead: rename the file Profiles/Default.cfg to Profiles/Default.cfg-disabled, or just delete it, to disable the default profile. put the content of the custom one in a file with extension .cfg anywhere inside GameData @ss8913 Unfortunately Interstellar has a lot of modules, a custom electric charge resource, and complex ISRU. It is also constantly evolving. Supporting it in the background simulation will be a major effort. I mean serious work: I will have to basically reimplement it for unloaded vessels, as I've done with the supported mods. However, these had a couple of modules at best and were relatively stable. So I'll be frank and say that I don't see me implementing background simulation for Interstellar any time soon, if ever. Maybe when I exaust the other things I'm planning to implement I'll look into supporting some of its modules.

@gamerscircle Here you go:

@aluc24

@aluc24 I can see this in the log: Module ModuleTweakableDockingNode threw during OnStart: System.IO.FileNotFoundException: Could not load file or assembly 'ToadicusTools, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'ToadicusTools, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 Try this: install ToadicusTools, or check that it is installed correctly cleanup the savegame by resetting CO2 amounts to 0.0, like you did the other time try to reproduce the problem Then this: create and launch a manned vessel without the tweakable docking port try to reproduce the problem If the above doesn't solve it: use only Kerbalism and its dependencies start a new savegame try to reproduce the problem Let me know.

@aluc24 Mmm, maybe you are right about KAC interaction. I have a question: do you have RelativisticTime set to true in settings.cfg? Because I found a potential issue with that, in case the orbit is not properly set. And that may be the case for one simulation step when KAC load the vessel, maybe.

Make sense. It only act as 'vessel-wide' radiation for the vessel it is attached to. Eventually I could extend it in future, but is not a priority.