ShotgunNinja

@Bersagliere81 In that case you just install RemoteTech and the signal system disable automatically. Here is some help for configuring and disabling stuff.

@Bersagliere81 Ah ok then, just install the package "Kerbalism - Default Profile" and you are good to go. This was also the reason you didn't have any EC consumption or no Food and Oxygen at all. Cheers.

@Bersagliere81 By the look of it, seem that the signal system is disabled. Some suspects: - you disabled it in the profile you are using and forgot about it - you are not using any profile (happen when you install using CKAN and don't also install the DefaultProfile package) - you have RemoteTech installed - you have the Origami Antennas installed (that provide RemoteTech as far as other mods are concerned, due to a mistake by its author)

@jlcarneiro No, just a new launched vessel. I believe you launched this vessel before my updated 1.03 DLL (eg: you launched it using leomike build for KSP 1.1.3). Please confirm if this is the case. The reason then is that the planner is showing estimates with the correct scrubber efficiency (greater than 50%), while the vessel reverted to 50% efficiency due to a bug in previous version. This I suspected from the beginning and that's why I'm asking you to launch a new vessel using the official build.

@jlcarneiro By 'warp' I mean any speed greater than 1x. Your picture has the speed at 15x. Honestly, I can't reproduce the issue you are reporting. Lets do this: use the official 1.0.3 DLL (this is important!) launch a new vessel (you may have not used the official DLL in the past and something may have been messed up in the launched vessel) compare estimate in planner with one in the mission if the problem is still here, send me the savegame and the craft file for that vessel Also, to clarify: when the warp speed is changed the estimates became instable for a short bit, then restabilize. It happen because the game 'blend' between warp speeds gradually. This has no effects on real consumption/production, just on the estimates displayed.

@brusura No need for that, I'll add support for greenhouses without shutters in next version.

This is related to the fact that some part of the greenhouse code assume it has a 'shutter door'. Will be fixed in next version, for now right click on the greenhouse and then on 'Open shutters' to enable natural light on that greenhouse.

@Bersagliere81 You need line of sight with the home planet, not with the space center. So there isn't a 'dark side' of Kerbin. Antenna range can be seen by right-clicking the antenna, or in the planner Signal panel. @Kerbos I can't show the antenna range in the part tooltip because the ranges are generated from the solar system features, and those aren't in the game yet when the parts are compiled (and the tooltips generated). Mods that use hard-coded range antennas don't have these problems. @yorshee, @Zeroroller I'll do some tests on the relay stuff. Can one of you send me their savegame? @leomike You need the 'using' directive. Then the Dispose() function is called at scope exit. @jlcarneiro When you change warp speed the depletion estimates oscillate for a little bit, then return to the right level. It is due to the way I calculate them. It is normal, don't worry. Real consumption/production isn't influenced at all.

@leomike I had a very quick look at the Processor, but is really interesting. One of the reason i implemented this new cache is that it may allow me to let the resource amount 'overflow/underflow' and then get clamped at the end of the background simulation step, to try to solve that high timewarp inconsistency (pretty much the solution you proposed a couple months ago). However, I realize that a lot of subtle problems can emerge if I do it that way, like: how do you evaluate if a resource is available for lets say a converter if the amount can underflow? And so your processor may be the solution for that. It basically is a 'deferred consumption/production', if I got it right.

@leomike Its okay I will take a better look, it seem a lot of work went into it. BTW in next version I modified heavily the cache system: now it is a FIFO eviction cache, and only 1 vessel is evicted every simulation step. The resource cache instead was rewritten and now is a layer that manage two caches: a 'foreground' (for loaded vessels) and a 'background' one (for unloaded vessels). The foreground one work pretty much like Cache.Resource* right now, the background one instead is also a FIFO eviction cache and 1 vessel/resource pair is evicted every simulation step. It does avoid accessing the KSP serialization data structure for consuming resources, instead relying on 'synchronizing back' with it at eviction time. Right now it work like a charm and should practically decouple all environment/resource calculations from the number of vessels.

@leomike I noticed you are not using the ProfileScope how it was meant to be used. You need to use it in this way: void my_function() #if PROFILER { using(var prof = new ProfileScope("my_name")) #endif { // do stuff here } #if PROFILER } #endif so that the Dispose() method is called automatically at scope exit (function return, exceptions, etc). Alternatively you just use Profiler.Start()/Stop() directly, but then you have to call Stop() at any potential scope exit manually. @subyng Yes, take a look here. In the Features section. Open Kerbalism/Profiles/Default.cfg and delete the line that read "@Kerbalism:FOR[EnableSignal] {}" to disable the signal system. To disable storms instead, set "StormDuration" to 0 in Kerbalism/Settings.cfg

@brusura I got some optimizations coming in next version. I had a quick look at some of leomike changes and there is interesting stuff there for sure, but also most changes are widespread and he changed the formatting style and naming conventions too. If they were in form of github pull requests and atomic it would have been easier to evaluate and eventually integrate them. @Kerbos I don't see any of the problems you report. Please try if the problems are present in the official DLL and let me know.

@jlcarneiro I am unable to reproduce your issue. What DLL are you using? Try the official one, and to be sure launch a new vessel and let me know.

New version released: 1.0.3 Changelog: - recompiled for KSP 1.1.3 - interplanetary coronal mass ejections - fix: scrubber efficiency reverting to 50% - fix: 30 days manned orbit contract not generated again after completion - patch to allow Shielding production on Extra Planetary Launchpad, by Enceos

@leomike, @nosscire Anybody is free to do anything with this mod. Not only the license allow it, but I'm also totally fine with it. Else I would have choosen a more restrictive license. Unfortunately I had zero time to dedicate to this project in the last month. Looking forward I don't know if I will be able to give this the love it deserves. I will probably put this on life support (phun intended): bugfixing, some optimization and porting to newer ksp versions. Derivative works and forks are welcome.

Guys this is a I'm not dead post. Sorry for the hiatus but I'm about to meet some serious deadlines in my real work. Special thanks to @leomike to recompile it for 1.1.3 and for attempting some more optimizations. I'll be free to do some coding for this project in some weeks. Hold tight and keep having fun, cheers!

@DarkonZ The scrubber work, at least as far as I can tell. Every kerbal produce waste resources, in this case CarbonDioxyde. Then all eventual scrubbers in the vessel are going to pick it up and convert a portion of it back into Oxygen. So you can create a bigger scrubber like in your example, that just have a bigger co2_rate. The rate of co2->oxygen will be related to scrubber efficiency tech. You can post screenshots here, no problem. Maybe you found a bug. Background processing will have the same inconsistency at high timewarp speed (also stock game has it, for the loaded vessels). @TeeGee Yes, absolutely. This mod is agnostic about the solar system features: antenna ranges will scale appropriately, and magnetosphere details are generated from celestial body parameters.

@nosscire Ah ok. Lets see if I manage to solve or minimize the problem in next versions.,Disabling EC consumption at high timewarp will be a drastic solution, and want to try to avoid it if I can.

@leomike That's a good point. The accumulator start filling as soon as the resource is exhausted. At max timewarp, this mean that it will get filled immediately in a single step. Even at 10,000x warp speed, 4 of the 6 minutes will be filled immediately. Didn't think about this. The threshold warning+stopwarp was meant to avoid these kind of issues at high timewarps, but consider that only stopping timewarp from max to 1x will take a long time (maybe 1 hour in-game, or something like that), and I'm doing it the fastest way possible. Doing it any faster will cause weird issues with orbits changing (this is also the reason the stock game 'blend' between timewarp speeds). In general, time is moving too fast relative to the small amount of time you have until oxygen deprivation kill the kerbal. The only thing standing between instant death for suffocation at high timewarps is the resource depletion warning+stopwarp, that's why this problem wasn't noticed until now.

@leomike The capacity requirement surprised me too, the reason for such high values is the number of seconds that there are in a simulation step at max timewarp (2400 seconds per-step). Actually the solution you propose is still on the table and probably I'll end up implementing it. My concerns with it are these: [1] resource requirements of various modules are checked against the amount in the previous simulation step (not a big problem, but may have subtle consequences), [2] need to unify all background consumption/production in a single place (working on it) and [3] the problem will still be present for stock modules in loaded vessels (as I have no control on them). From the positive side, it also has the additional advantage of making the background simulation slightly faster (as background resource consumption/production involve working directly on the serialized structure of the game, and doing it once will be faster than doing it multiple times).

@nosscire The sun visibility problem was fixed already: I'm doing a poor man integration of sun visibility over the whole orbit, if there are not enough samples per-orbit (meaning at high timewarp speed). The inconsistency that's left (and that you get the little warning in the planner) is unrelated to sun visibility, but only to capacity. Most users can just ignore it, as you have noticed it has little to no practical effects. Anyway, in a few versions I'm going to refactor the background resource consumption once more to minimize this problem further (to the point that basic EC capacity will be enough to hide that warning).

New version released, 1.0.2: - planner: warn the user if resource capacity isn't enough to avoid inconsistencies at extreme timewarp - tweaked MOLE solar panel output - realism and tac emulation profiles presence can be queried using NEEDS[] - fix: typo in EC amount checking for relay antennas - fix: resque missions getting hydrazine instead of monoprop when RealFuel isn't installed

@sfhq Thanks for the report, a fix will be in next version.

@BashGordon33 You can see how far in space the magnetosphere and radiation belts are for every celestial body, in the planner. Look in radiation panel tooltips. @odya-kun I think what you are seeing is just how this mod signal system is supposed to work. Is similar to AntennaRange, but with explicit relaying, background EC consumption and a different transmission cost model.

@Rik Radiation accumulated by kerbals is reset when they go back home at the KSP. Magnetospheres only stop more radiation from being accumulated. So Jeb is fine For the antenna ranges, you can customize them by putting this in a .cfg file somewhere in GameData: AntennaScope { name = orbit range = 1e6 } AntennaScope { name = near range = 1e9 } ... to redefine the default ranges, and is also possible to define new ones. You will find more information about this here.