ShotgunNinja

User Quartz101 released an MM patch to make USI Kolonization parts work with Kerbalism, you can find it here. @RedParadize I got some ideas for new mechanics and extension/improvements on the existing ones, but keep in mind this is a long-term todo list: magnetopause / belt / CME rendering complex magnetopause / belt shapes inter-planetary CME active radiation shielding local radiation emitters atmospheric weather events move some of the computations to a c++ DLL

@JPLRepo I think the reason for that NaN exception is that you are resolving the orbit to obtain vessel position in a robust way (that is good), but landed vessels have an invalid orbit. I use this little wrapper function to get the position: Also I've improved the raycast function that was included in my 'interim' version, making it more robust in general. In case you want to use it, this is the updated one:

@Nertea Sure, that was just an idea. In your case it can be useful, perhaps, as spherical harmonics are merely an easy and cheap way to encode a low-resolution approximation of a function over the sphere and then to query it. They can be understood in a certain sense as 'very blurry environment cube maps' that can be stored in a bunch of floats. They especially excel in encoding static (or semi-static) visibility information. The code seem complex, but is very simple (hence their use in realtime computer graphics). To give you an example, this is the whole 2nd order SH related code that would be required to store the coefficients, project the visiblity/opacity function on the basis, and then resolve the resulting spherical function on an arbitrary direction (this is c++):

@leomike You get the radiation belt warning only with manned vessels, with the exception that the first time you cross one you will also get the warning for unmanned vessels.

Version 1.0.0 released, have fun Changelog: - optimized everything - improved planner calculations, thanks Barrin! - contracts: put a kerbal in orbit for 30 days, cross the radiation belt, harvest food in space - temperature simulation and storm mechanic will work for arbitrarily deep body hierarchies - made the telemetry experiment more interesting - only show belt warnings if a radiation rule is present - MM patch for Tundra Exploration - tweaked entertainment factor - realism profile has been tweaked - barebone profile now also include radiation mechanic - science tweaks support for Dmagic and Universal Storage experiments - coverters and drills background simulation consider trait bonus - fix: correct sunlight evaluation at extreme timewarp - fix: problem with interval-based rules at extreme timewarp - fix: resource-related breakdown events - fix: muting messages will also prevent stopwarp - fix: resources given to resque mission when claw is used - fix: geiger counter is considered for satellite contracts Contracts Some landmark contracts related to Kerbalism mechanics are provided: - put a Kerbal in orbit for 30 days - cross the radiation belt - harvest food in space Extreme timewarp fixes Some issues with resource consumption at high timewarp speed have been resolved. Optimization A good portion of the code has been optimized sensibly.

@RedParadize I'm aware of that bug and is fixed already in next unreleased version. Shielding (and quality of life) is averaged over the whole vessel, if you want Kerbalism to calculate those values for different internal spaces just install ConnectedLivingSpace.

@leomike Thanks for the contract patches, I'll include them in next version. The relay cost is applied when the vessel is relaying signal from at least one vessel. Consuming EC on the vessels in the relay path when science is transmitted was considered earlier but it has negligible effects overall, and complicate how that path is determined in the first place (as now the network is specific for some particular vessel and change depending on the amount of data transmitted, that in turn influence EC required and determine if a vessel is a valid relay).

@Kartoffelkuchen Please check these: you have ModuleManager 2.6.24 or greater you have CommunityResourcePack you either download Kerbalism from spacedock, or you installed both Kerbalism and Kerbalism-Profile-Default from CKAN If that is already the case, I'm out of ideas... please send me log and savegame so I can check what may be causing this.

I was thinking about how to speed up or even avoid raycasting altogheter and had an idea, that I figured could be useful to post here. It looks to me the problem is mostly related to eva kerbals and inter-vessel radiation, as in all other cases the inter-part visibility can be precomputed on vessel change events (eg: staging, docking). So the problem reduce to precomputing a static visibility/opacity function per-part, that can be queried from arbitrary directions. A possible solution is to approximate the visibility function using spherical harmonics: on vessel change event: for each part: initialize SH coefficients storage for each other part: project bounding sphere visibility+opacity on the SH coefficients and accumulate them on each simulation step, for the active vessel for each kerbal/instrument: initialize total incoming radiation to zero for each radiation emitter: resolve the visibility/transparency using SH use the result to scale emitter radiation, and accumulate that Total storage for 2nd order SH per-part would be 9 floats. Total computation cost of projection would be relatively high, but only necessary at vessel change events: 11 additions and 24 multiplications for each part pair. Total computation of SH resolution would be relatively low: 10 additions and 22 multiplications per-simulation step for each kerbal/instrument -> radiation emitter pair, in the active vessel.

@Tokamak I found a problem with how i detect CLS internal spaces in the pre-release you are using. Will fix and send you a build for testing. @Apurva Kawthalkar Geiger counter should be there, try reinstalling the mod. Make sure to delete the old directory first. Next version include fixes and optimization mostly.

@Bonus Eventus I totally want to see space invaders in an iva monitor! To add entertainment, you just add it to the part like this: @PART[my_part] { MODULE { name = Entertainment desc = Something funny here rate = 1.2 } }

@Bonus Eventus Yes, practically the living space factor is the number of 'seats' available for each kerbal. @John Nowak That's correct. I'm going to experiment with a different formula for the entertainment factor.

@Gotmachine, @John Nowak For the quality of life, this is the formula:

@casper88 Kerbalism update every simulation step, 50 times per-second at default game settings (if i'm not mistaken). The stutter you see every 5-10 seconds is the garbage collector. Some of the optimization in next release try to minimize the temporary objects created and you should see less dramatic GC spikes. @John Nowak That's correct, there is no recovery from stress. This is to force the player to rotate the crew.

@Gotmachine Thanks for the detailed testing and investigations! Some throughs: There was a problem with the sun visibility being evalued at discrete point in times at high timewarps, so anything that used sun visibility was in sunlight/shadow at random at extreme timewarps (fixed in next version by doing a poor man integration of sun visibility at extreme timewarps). The EC level problem is probably related to this (also mentioned as reason for squad to not apply EC consumption at high timewarps): a simulation tick at max timewarp is 2400 seconds in game time, so with EC capacity of 400 any consumer/producer with a rate exceeding 0.1666 EC/s will make the numbers inconsistent. (can't fix this, or at least the fix elude me at this time). Quality-of-life has 33% variance per-kerbal, so the time to instability can be considerably different for each Kerbal. Note that the planner doesn't consider the variance at all (this is intended). All rules can have a variance per-kerbal, but it is only set for QoL in the default profile. For food consumption being slightly off, I think to know what's happening: food being the only 'interval-based' rule in the default profile, the problem is related to how I reset the time since last interval. This is an almost trascurable error at normal speed, but apparently start mounting up at higher timewarps. Will fix for next version. @Bonus Eventus A radiation emitter module is planned for post 1.0. Can't guarantee it will be shielded by vessel parts (but it may) but it surely its effect on the crew will be scaled by distance from the manned pod. @New Horizons With CLS you have to move the kerbals manually. Also the CME warning doesn't require anything from the player at this point. It would be cool to have something like the STEREO mission and only enable CME warnings if the player got them.

I haven't tested it, but this should make the KPBS converters count as ISRU for the contract system: @Contracts { @Base { @PART_REQUEST[#Part[ISRU]] { Part = KKAOSS_ISRU_g } @CREW_REQUEST[#Part[ISRU]] { Part = KKAOSS_ISRU_g } } @Station { @PART_REQUEST[#Part[ISRU]] { Part = KKAOSS_ISRU_g } @CREW_REQUEST[#Part[ISRU]] { Part = KKAOSS_ISRU_g } } }

@Razorfang The next version include some optimizations, roughly 300% speedup.

Made some infographic about what may be the problem at high timewarp:

@Tokamak The plan is to provide 1.25m and 2.5m inline oxygen containers with much more capacity. Meanwhile I will increase the capacity of the large radial tank.

@g00bd0g Send me the savegame, I'll take a look. What I think may happen is this: the vessel is simulated at some point in time, and the elapsed time from the last point is correct. However, at high timewarp it can happen that, by chance, the majority of points in time occur when the vessel is in shadow. To confirm this it will be enough to have an RTG powered vessel in the same orbit and check if that is instead simulated correctly at extreme timewarps. If this turn out to be the case I have a fix in mind: do a poor man integration of sun visibility at extreme timewarps by taking the shadow-time of the current orbit in consideration.

@MemeBeam Is possible you are using the Realism profile, and have little EC capacity in that vessel? I'm asking because as soon as there is some waste water in that case the water filter kicks in and consume a lot of EC. We are tweaking the rates for next version to avoid this problem. @SkyblueX Thanks for the report. The problem is that the stock game preserve some data even after you remove a mod. So it would be useful if you can try to replicate the issue using only Kerbalism & dependencies, in a new save game. Make sure to also clear the ModuleManager cache.

@IGNOBIL I was considering adding 'active radiation shielding' for the late game, but this 'artificial mini magnetosphere' idea is even better! If you do the model, I would be happy to do the coding

@John Nowak It does

@eightiesboi Thanks for the kind words, and for your offer. As accepted really I will have to check how KCT is manipulating time. Any use of the 'revert flight', that I suspect is what the KCT simulation is using, will probably have the whole set of vessels simulated as normal and then reverted back at simulation end (so no big problems here, it will be like you are simulating all the vessels during the test flight). For the 'fast-forward' when you leave the VAB, honestly I don't know. What purpose does it serve? Does it manipulate planetarium time? I can't seem to find relevant info from the KCT thread.

@Tokamak Some more good stuff is coming, including an inline oxygen container. Maybe not in next version but soon (tm).