ShotgunNinja

Members
  • Content count

    971
  • Joined

  • Last visited

Community Reputation

1315 Excellent

About ShotgunNinja

  • Rank
    Rocket Scientist
  1. Seeing that aurora match the outer belt brought a tear to my eyes.
  2. 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.
  3. 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.
  4. @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
  5. 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.
  6. 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.
  7. Unfortunately if I include DX11 shaders, the Unity editor bork when creating the asset bundle, and also include DX11_9 shaders. These in turn don't have support for 'point-sprites' stuff I'm doing in the shaders code, and somehow get selected on some particular GPUs, resulting in the players with these GPUs having no radiation field rendering. I found out the hard way. You will have to switch back to DX9/OpenGL, or live with the pink... The airlock dynamics we were talking about. To do it proper, support for multiple separed habitats would be necessary (even if one is just a tiny one meant to be a simple airlock).
  8. Crap, no that's a mistake. I've released a new version 1.2.2 with the hotfix. Thanks for letting me know - fix: remove stock antenna from probe cores
  9. New version 1.2.1 released: - new ECLSS component: Waste Compressor, compress Waste into Shielding - new ECLSS component: Monoprop Fuel Cell, burn Monoprop and has Water+Nitrogen by-products - atmosphere is breathable on all bodies containing oxygen, when pressure is above 25 kPA - proper experience bonus calculation in stock converters and harvesters (@Gotmachine) - MOLE solar panels support in planner and background simulation (@Gotmachine) - support patches for SXT & HGR, improved patches for VSR & HabTech, and more (@Eberkain) - support patch for OrbitalTug (@PiezPiedPie) - fix: cache stop updating after planting flag (#50, #52, #75) - fix: exception in main loop when space weather is disabled (#78) - fix: exception in planner analysis when comfort modifier is used in a process (#79) - fix: greenhouse harvest ready message spam - fix: missing configure setup descriptions in some cases
  10. I found the issue with control loss and flags. Flags are vessel, and apparently they have vesselID = 0. The vessel cache is a FIFO one, the oldest entry is removed and recomputed. The code that checked the oldest entry had a special meaning for vesselID = 0. So as soon as a flag became the oldest entry in the cache, the whole cache stopped recomputing. This was evident after EVAing a vessel without antenna. Before the EVA, the vessel cache entry was controllable (because manned). When it went outside, the vessel cache was updated to uncontrollable (because unmanned and no antenna). After planting the flag, the cache stopped being update shortly afterward. Then on re-entering the vessel, it still figured as uncontrollable according to the cache, leading to control loss. Special thanks to @blakemw for providing me with a test case, and to Bob Kerman for landing on the mun a hundred times.
  11. @John Nowak This is rather complex, and I just woke up, so please bear with me. Suppose it was possible to split a vessel into multiple habitats, even if only an 'airlock' and a 'main' one. Now all habitat properties have to be valid and defined for each one of them. This is not possible with the stock resource system, as you would effectively have multiple 'sub-vessels'. The next logical step would be to throw away the pseudo-resources in habitat, and implement the same in a more complex way instead. That would be possible, but it would also be a less flexible system. How much less flexible? I'll make an example: you can create a 'waste compressor' that produce shielding, using a stock module resource converter or equivalent, right now. This kind of thing would not be possible anymore if I go this route. Another solution would be to implement 'sub-vessel resources'. The resource cache system could be extended in such direction. However, what about anything that doesn't use it, like for example non-kerbalism modules in loaded vessels? Those will be unaware of the sub-vessels. That's why I didn't dwelve futher in this matter at the time the pressurization was introduced. Instead, I went around these issues with some minor tweaks: the habitat part 'lock/unlock' was renamed to 'enable/disable' there is only a single habitat in the vessel at all time, composed of all enabled habitat parts transfering crew inside a disabled habitat will automatically enable it you can't disable an habitat where some crew is inside it
  12. That was my reasoning. Essentially I went for 1 kerbin day = 1 earth day, and kerbal = human. I could rescale rules automatically from day-lenght. However, all process/module would have to be rescaled as well. There will be subtle changes in balance too, for example EC consumption reduced to 25% against unchanged solar panels, etc. Is probably best to write a new profile for RSS. There is a small list in the OP, but most mods should work without issues. Some aren't simulated in backround (like KSP-IE), but otherwise work.
  13. It doesn't, that's probably the issue. In default profile each kerbal eat 1.77 Kg of food every 6h. Irregardless of your KSP day-length setting. Also everywhere the UI is telling you 'days', it mean 6h or 24h depending on your KSP day-length setting. So in your example: crew of 1, consume 1.77 Kg every 6h pod has 27 Kg with 6h day-length setting, the estimate say 15.25 'days' left (it mean: 91.52 hours) with 24h day-length setting the estimate say 3.81 'days' left (it mean: 91.52 hours)
  14. @eberkain I'm using NASA estimates for a human.
  15. There is no scaling of the rates in code, rather they are specified in the configs. In there you can do some scaling using MM-fu. For example I scale the ECLSS rates using crew capacity. Multiple profiles can coexists, but only the one selected in Settings.cfg is used. @podbaydoor Yeah, sorry about that You could also switch setup in the configure window, that should re-setup the right amount of resource in theory.