ShotgunNinja

There are two ways to do it. One is the so-called 'catch-up simulation'. It is very simple: you just keep track of time elapsed since the module was active the last time, and when it become active again, you 'catch up' with the missing time. You practically do one (or more) simulation steps when the module is loaded, using the unloaded-time (or a fraction of it) you tracked in place of the usual elapsed time of a simulation step. You can understand how that's not going to work unless the set of producers, consumers and storage is trivially simple. But its advantage is simplicity. Then there is the 'full blown background simulation'. In essence, you need to 'emulate' the module in question when the vessel is not loaded. This mean you will have to emulate its behaviour using only data available in the part prototype (for non-persistent data) and in the serialized structure of the module (for persistent data). You can even change the latter during the simulation if required. Now, some modules are not 'self-contained': eg: they may interact with other systems. Some of these systems may not be available for unloaded vessels. So you'll have to 'roll your own' replacement for these systems. The most frequently used is obviously the 'KSP resource system'. So in emulating a module that consume/produce resources, you will also need to emulate the KSP resource system. And so on and so forth to all systems used by the module.

Hi, I may have found a problem in the source code here. The function in the link is meant to calculate PhysicsGlobals.SolarLuminosity (the star radiosity, in W) from the active star irradiance at 1 AU ('luminosity', in W/m²). Now, in that function 1 AU is interpreted to be the home body SMA. However, someone along the way added a 'sunAU' field to the body specifications. That field was probably meant to allow to set a star radiosity to a precise value indirectly, given that there is no way to specify it directly. In any case, the sunAU field value is not being considered in the linked function. This will lead to incorrect radiosity any time that the sunAU field value of any star doesn't match the home body SMA.

@MaxL_1023, @AG5BPilot I tried to replicate the greenhouse issue, without any luck. You can see on the screenshot below that natural lighting is correct here on Gael. Indeed I was puzzled by the fact you reported different solar irradiance for stock solar panels and greenhouse, as these are re-using the same calculation. @JadeOfMaar I assume the issue was happening with Kerbalism. It does assume there is only one star, at index zero. Lifting this limitation is planned. But after some investigation on Kopernicus source code, the specific issue you are seeing is probably an interaction between the two. When determining irradiance at an arbitrary position, Kerbalism use two informations about the star: its radiosity (PhysicsGlobal.SolarLuminosity) and its position (FlightGlobals.bodies[0].position). Kopernicus constantly set the former to match what he consider the 'active star', so Kerbalism get fooled to the right value. But the latter is always wrong for stars that are not at index zero. Honestly I don't know how Kopernicus determine the 'active star', if it is exposed to third party mods, or maybe if it does change planetarium sun to reflect the active star. In Kopernicus body specs: - 'luminosity': solar irradiance at 1 AU (in W/m²) - 'sunAU': how many meters 1 AU is to be considered, for the sake of radiosity computation Then star radiosity is correctly computed as: irradiace at 1 AU * (meters in 1 AU)² * 4PI So, the sunAU parameter is here because radiosity can't be specified directly. But by manipulating sunAU you can set radiosity indirectly. In any case, I suggest to keep sunAU to match semiMajorAxis of the home body. Because for example this piece of code of Kopernicus here does assume "sunAU == homeBody.SMA"

@karst45 Update the mod to last version: 1.2.5

@blakemw All sources of radiation will emit in certain EM bandwidth and various plasma elements, including local emitters. This will allow for example the RTGs to emit in the infrared, or nuclear devices to emit atom nuclei and gamma radiation. Or the active shield to absorb plasma elements to varying degrees. Then shielding may get just a bit more involved with multiple types (high-z, low-z) and secondary effects (eg: high-z re-emit gamma when it absorb electron). In fact any resource on the vessel can be made to interact with the radiation fluxes. So it will be possible to have water or fuel on-board absorb something, for example. But I haven't decided yet about secondaries, they are possible to implement but maybe that's too complex to manage. About taking locality of emitter into account: it has been on the todo list for a long time and honestly I would like to add it. But that is more work than it look, even without taking occlusion into account. So it could be included or not.

@Drew Kerman It is like that from the beginning. I didn't know what to put in it, both 'Life support' and 'mod name' seemed wrong. So it was left empty. @fourfa I started designing 'thermal control', but then did the same with the new 'solar wind' simulation, and that lead me to research 'radiation' and 'shielding' in deep. I had some nice idea along the way. So now I'm designing a new 'Fast Flux Simulation' to unificate many things under a single simulation: electromagnetic and plasma emissions, radiation fields and even the signal system. As this changes a lot of stuff, I'm taking some time to think before going into coding. Thermal control is on hold for now.

@Magzimum Your station need a low-gain antenna to communicate with other vessels. The two RA-2 antennas it has can only communicate directly with kerbin.

@Magzimum I increased the amounts recently, way too much probably. The co2 poisoning is because as of now there is no way to 'gift a process'. But I'm looking at ways to make it possible. @Skylon Food: 15 days, Water: 3 days, Oxygen: 3 minutes Pressurization only slow down stress.

@Magzimum That 'gift pack' was a bit too generous for an EVA suit... I'll make it smaller.

@New Horizons Ok I understand now... so, you have no connection on an unmanned vessel. The vessel is in fact not controllable, including all experiment parts. But [x] Science allow you to collect them anyway. That is not intended. It is a consequence of the two mods being completely unaware of each other.

What you mean precisely? Collecting data and transmitting it are different actions. Are you able to transmit without a connection? @Jozay Mmm, just an idea but try maybe adding ModuleAlternator with an output of Atmosphere resource. @Skylon It is possible. Just add a module Habitat to a part and it will be considered habitable. @PART[MyCrewTubesPartName] { MODULE { name = Habitat // these are deduced from part bounding box, but you can specify them precisely if you want surface = ... // surface in m² volume = ... // volume in m³ } } That seem like a good idea. Can you send me a screenshot? I can't figure out what you are not seeing. @Magzimum Check out the wiki, in particular the page about how signal work. To answer your questions: if you enable the Signal feature, the stock CommNet system is disabled the surface network of DSN antennas is simplified as a single omnidirectional antenna high-gain antennas can only communicate with DSN (implicitly pointed) low-gain antennas can also communicate with other vessels to receive data from another vessel, a low-gain antenna need to be 'flagged as relay' in the part UI

@woeller I'll investigate the nitrogen issue. There is no flow graph of the resource processes, but there is some info on the wiki.

PartModule.enabled is not serialized. You will need to re-disable the modules every time the vessel is loaded. So even if you 'configure' only in the editor, you will still need to 'enforce that configuration' in flight. You need to use PartModule.isEnabled instead. When it is false, KSP disable the fields and actions of that module.

What I know: PartModule.isEnabled is the KSP PartModule flag indicating if the module fields should be added to the part UI PartModule.enabled is the MonoBehaviour flag indicating if the update()/fixedUpdate()/onGui() functions should be called - it isn't serialized, so you have to set it to false after load Most modules only do work inside update()/fixedUpdate()/onGui() and don't manipulate animations or rendering objects, so they stop doing whatever they usually do For the others, you need special hacking. These are the ones I'm aware of: ModuleEngines*: just call the Shutdown() method when disabling it ModuleDeployable*: stop all animations on the part ModuleLight: if animation-driven reset it to frame 0, else set enabled=false in all Light objects.

@Mikki That's cool. Also consider sending a 'return vehicle' beforehand, with a co2 atmospheric extractor and a chemical plant that can do sabatier and anthraquinone in situ, like in 'the martian'.

@Andrea Galimberti I had a look at your profile, there is nothing wrong that is evident. Anyway, be advised that the waste compressor is very slow. It takes 120 kerbin-days of waste from 1 crew to create 1 Shielding unit. @Rhedd The proportions of inputs and outputs are correct, but the scale may be too high. And the EC output is completely arbitrary. Also, the monoprop fuel cell is always producing at full capacity, instead of adapting to EC required like the standard fuel cell. I'll fix both issues next version. @SpaceX, @Gotmachine, @DavidHunter Maybe a little LOG section in the monitor showing the last N messages about that vessel.

@AG5BPilot It is a limitation in Kerbalism, it has no concept of multiple samples. An experiment is either repeatable, or is locked after first use. This is deduced from the 'rerunnable' field in ModuleScienceExperiment (and derivates, like all the modules of Orbital Science). The experiments you mention all have it set to false, so they get locked after first use. But if you set it to true, like in this example @PART[dmReconLarge]:FINAL { @MODULE[DMReconScope] { %rerunnable = true } } then Kerbalism will not lock the experiment after first use. At that point, theoretically, the Orbital Science module should lock itself after N uses. So you should get the right behaviour. Try it and let me know if that worked.

Assuming it is a black body: it will radiate photons 86% in the infrared, 12.5% in the visible, and what little is left in the ultraviolet.

@Russos Solar panels too have changed in last version, and their output will not be recognized by AmpYear. Now that I checked, there is also an error in the Planner. I'll fix in next version.

@garwel You can use a wrapper like this one below. public static class MyWrapper { static MyWrapper() { foreach(var a in AssemblyLoader.loadedAssemblies) { if (a.name == "Kerbalism") { _KerbalismAPI = a.assembly.GetType("KERBALISM.API"); _Radiation = _KerbalismAPI.GetMethod("Radiation"); _Shielding = _KerbalismAPI.GetMethod("Shielding"); break; } } } public static bool HasKerbalism() { return _KerbalismAPI != null; } public static double Radiation(Vessel v) { return (double)_Radiation.Invoke(null, new Object[]{v}); } public static double Shielding(Vessel v) { return (double)_Shielding.Invoke(null, new Object[]{v}); } static System.Type _KerbalismAPI; static System.Reflection.MethodInfo _Radiation; static System.Reflection.MethodInfo _Shielding; } @Russos The problem is that AmpYear is unaware of the ProcessController module, that the RTG now use from last version.

@Galileo Replace the dll with this one here. Note that whatever ECLSS configuration in the pod you made was lost, and it will reset to the default selection (scrubber + pressure control). I didn't find out why the configuration was lost in the first place. Question: was this vessel created in the VAB in a previous version? Can you share the .craft file? Thanks. The weird thing is that creating a new vessel and launching it doesn't show any issues.

@Galileo I installed GPP (amazing, BTW), including all the optional mods, and tried to replicate the issue without luck. But I found this in your log: It seem that configure setup data wasn't parsed at part compilation time, for some reasons. But there is nothing about that in your log. Can you send me a savegame that reproduce the issue?

@garwel There is a simple API here. The function 'double Radiation(Vessel v)' return the level of environment radiation at vessel position, in rad/s. The function 'double Shielding(Vessel v)' instead return the proportion of radiation blocked by the shielding of the vessel habitat.

New version released: 1.2.5 Changelog - detect and avoid issues at high timewarp in external modules - hack stock solar panels and RTGs to use resource cache - RTGs decay over time, with an half-life of 28.8 kerbin-years - corrected all chemical reactions, some were very wrong - fix: solar panel sun visibility sampling error at max timewarp for loaded vessels (#95) - fix: impossible to guarantee coherency in resource simulation of loaded vessels (#96) No more insta-death by CO2 poisoning or climatization at high timewarp This is fixed, rejoice. If you want more details about it, and disregard your own mental sanity, read below. RTGs decay over time This apply to the stock RTG part, and to the ones included in VSR, NFE, RLA. Half-life is set to 28.8 kerbin-years. For the curious, this was implemented as another 'self-consuming' process. Rebalanced chemical reactions Some of the rates were very wrong, and mass-conservation was violated with impunity. The rates are now correct down to 1e-10. Molten Regolith Electrolysis is now based on a real reaction. If you have some complex ISRU going on in your savegame, please review the new rates before updating to the new version. FAQ has been updated Go read it in the OP.

@blakemw What if instead we make use of the new Experiment module. It is able to collect data over time, from custom situations. We could find 8 representative experiments that make sense to be in a lab. Then the laboratory part could get a Configure module, to act as a 2-slot configurable container for these experiments. They can be unlocked progressively, and running them can require a Scientist, and a reasonably long time. If these experiments are exclusive of the lab, it will definitely incentive its use. The Configure module 're-configuration in flight' can be exploited to somehow 'install new equipment' in the laboratory. That way we'll get a replica of what happens on ISS. You get this new science that require the user to put a scientist and a lab somewhere for months/years. In the new Experiment module the data is generated constantly, so you can even 'stream' it home while it is collected. It will practically act as the 'generic science from lab' you describe. The 'lab analysis' mechanic can remain in the lab along the new experiments, at least for the time being. This will require little to no extra code. I just need to finalize support for the new situations, and somehow improve the reconfiguration in flight. The bulk of the work would be finding these 8 experiments. What you think? BTW: I do share your sentiment for 'biome hopping'. It's an abomination. People that do biome hopping should feel dirty inside.