ShotgunNinja

I admit I didn't ever use RT so I can't confirm or deny it. But this mod is not simulating their EC consumption in background. And I have the suspect RT isn't doing it either, because from a design point-of-view no mod can consume EC in background without also giving the user some way to produce it in background.

@TheSaint Every zone (belts, pauses) has a radiation (that can be negative). For each vessel, I determine the set of zones they are in (considering the whole body chain) and sum their radiation. Then I add the 'extern' radiation (from outside all the zones, out of the heliopause). Then storm radiation if that is the case. Finally, I add the sum of all emitters in that vessel. So they are acting as 'vessel-wide' radiation. @aluc24 Well the planner only consider things that are also considered by the background simulation, that doesn't include RT modules. It may be implemented in future, eventually.

Thanks guys, amazing work. I don't know what's special about Nvidia 9xx, in the meanwhile opengl work as noted above.

@BashGordon33 Vall should have the 'surface' model, a mistake that will fix in new version. Laythe is inside Jool magnetopause all the time, never touches its rings... so is quite a nice place already ALL THOSE WITH GPU PROBLEMS download this file and copy it in Shaders/ directory, replacing existing file try to replicate the issue with only this mod installed make sure this mod is installed correctly try setting quality to low in Settings.cfg do you see the lines rendered from signal link are you using DirectX or OpenGL, win/linux/mac? what GPU are you using The gpu is important if I see that only people with a particular vendor (NVIDIA) and/or a particular generation of GPU have the issue. Please understand that I can't replicate it myself with the hardware I got.

Possible. The log show that the fields have been generated. Can you try to go in Settings.cfg and set LowQualityFieldRendering to true and let me know if that change something in your case.

@Xira1234 When you click the checkmarks, is a message displayed that say 'calculating fields, come back in a minute'? If yes, wait a bit. If not, send me your log.

@lajoswinkler You can do it pretty easily, just need to tweak the 'irregular' model a bit: @RadiationModel[irregular] { @pause_radius = 1.0 // set magnetopause radius equal to body radius @pause_compression = 1.0 // no dayside compression @pause_extension = 1.0 // no nightside extension @pause_deform = 0.1 // deform up and down by 0.1 body radii using sum of sin functions } Or you could even create a new model and assign it to Duna/Mars RadiationModel { name = my_model has_pause = true pause_radius = 1.0 pause_deform = 0.1 pause_quality = 60 } @RadiationBody[Duna] { @model = my_model } @RadiationBody[Mars]:NEEDS[RealSolarSystem] { @model = my_model } @IggyHitokage Yes if there is RealFuel installed, Hydrazine is used instead of Monopropellant. Probably should write this somewhere...

@brusura It does matter if you are using ConnectedLivingSpace. But even in that case the planner evaluate the whole vessel average. Something to improve in the future.

@brusura Is not a bug, it is by design. The average shielding level goes down in that case.

@brusura Is a bit subtle. The active shield is no replacement for Shielding, that scale incoming radiation. Instead, it remove a fixed amount of incoming radiation. This has big consequences on low radiation environments (eg: in atmospheres, in magnetopauses, in interplanetary space) but little to no consequences in high radiation environments (eg: belts, storms).

I'll add another function to inject the radiation in a neightborood, that also consider shielding too. So custom emitters can be implemented just with a single function call. @lajoswinkler Ah right, I forgot! The sun has an heliopause now. Also, mostly to showcase the model flexibility, Vall surface emit mild radiation and Dres has two 'polar anomalies'.

Version 1.0.9 released. Changelog New radiation model Celestial bodies now have more rich radiation environments. Multiple bodies can share the same model if desired. Some documentation on how to customize this is available here and an example here. Definitions for stock, OPM and RSS bodies are already included. Magnetic field rendering You can press ALT+N in the map view / tracking station to show a little control panel to toggle the fields rendering. You can also use Keypad+0/1/2/3 to quickly toggle between the fields. Radiation Emitters A new module is available to implement parts that emit radiation, and parts that reduce radiation. You can find some documentation here. The stock nuclear engine now emit radiation. The old 'high-tech' food container has been repurposed as a late tech-tree active shield. That's all for now, have fun.

@DarkonZ Maybe it is a float issue, as 1.5x3 would give exactly 4.5. Try setting it to 1.51 and let me know. BTW there is also an hard-coded, undocumented limit on max entertainment. The entertainment on a vessel can't be more than 5.0.

Ah ok, sorry I misunderstood. Here are the values, note that they are not on the wiki. [0] none [1.25] boring [2.5] tolerable [4.5] good Some issues are present, those that I am aware of are fixed in next version, I didn't release yet as I'm finishing. Here they are: support SCANsat 16.4+, fixed Cryotank simulation, stock converters background simulation detect when they are full, and some minor issues with greenhouse and KIS interaction. If you are aware of something that is not in this list, let me know.

@smysha Try deleting the MM cache files. If that doesn't work either try deleting Kerbalism folder and reinstall it.

@autumnalequinox The water filter require some WasteWater capacity to function. This mod automatically add that to any manned pods. However RF then remove all resources from all pods. So you need to manually add WasteWater capacity. @Thegamer211 Thanks for the report. fixed in next version. You updated to SCANsat 16.4+, and one of your vessels somewhere has a SCANsat module. Next version will work with SCANsat 16.4+ only.

@harleyquinneth When you encounter this problem, exit the game and then upload the file {KSP Install dir}/KSP.log to an upload service of your choice (eg: google drive, dropbox, filedropper, ...). Then post the link here, or send me a PM.

@harleyquinneth From what you describe chances are an exception is being thrown in the planner, resulting in the 'empty gray window' you see. Send me the log when that happen again. Quick question: does it happen only on vessels that have a SCANsat module?

@smysha Double check the file name. It should have extension '.cfg'

Essentially you store a pyramid of logarithmically lower resolution versions of the texture, on layers. So that you go down to some limit (eg: 1x1 texel) but the overall space occupied by the texture is always less than 2 times the non-mipmap one. Then, during texture sampling, the hardware determine the (possibly non-integer) layer number it should sample from based on a clever trick (using derivate of sampling texture coordinates). Then hardware filter linearly first between adjacent mipmap levels, and then it filter linearly on the texture layer too. The result is less aliasing and most importantly less bandwidth (and indirectly more texture cache coherency). Meaning that using mipmap is almost always faster than not using them. Now, KSP is using mipmapping for the parts. If you do not author the mipmap pyramid yourself (eg: in the DDS) then KSP/Unity will build the mipchain automatically at load time. This is done in hardware (the GPU does it), note that I'm guessing but its a good guess. Your mipchain authored look 'worse' to you probably because the image editor you are using is not filtering in linear-space, or some other crap. So avoid generating the DDS mipchain and rely on the gpu driver to do it. They are. In your case you need to add more crew, as the first scrubber/recycler find its waste resource but the second one doesn't. Or, you can wait next version where pressing ALT in the VAB will make the planner consider full crew capacity. Here are the values: [0]- cramped -[1.5]- poor -[2.5]- modest -[3.5]- good Yes. List of supported modules (both in background and in planner): @Torgo Send me the log, I'll take a look. If you are not using many mods send me the savegame + modlist.

@xandertifft54321 In the Profiles/ directory, there is the Barebone profile that only has radiation and quality-of-life. You can delete the quality-of-life rule inside it. @BashGordon33 Great! I'll include some documentation about the parameters.

Experimenting with magnetic fields for other planets: this is the Mercury/Moho one, that is speculated to be just about powerful enough to trap particles, but the scientists are not sure. So I made its outer belt highly deformed, with holes. Sorry for the small gif, video uploaded here. The model right now include: magnetopause, inner and outer belts solar wind pressure compress it on dayside, and extend it on nightside outer belt extension vary with distance from body use GSM coordinates, aligned with sun direction, can be skewed arbitrary magnetic poles axis all elements can be deformed by a sin function I'm trying to map this to the old heuristic function used to determine the magnetosphere for an arbitrary body, but it seem that it will be a pain. Also will somehow not leverage all the aspects of the new model. So I'm thinking of authoring all of them in ConfigNodes. I'm willing to author them for stock bodies and OPM, for this version, then later RSS and RSS-Extended. The parameters are all in body radii, so they should work for all planet scale mods without further changes. The rest of the Kerbal mod universe will have to be authored by third parties.

@Kerbos No background simulation of any MJ part. To be fair, I never used it and don't know if some of its inner workings can interfere with this mod. I hope not. I'm not a 3d artist by any means, but I guess the mobile lab shape may be a good starting point for a MedBay. Balance is something that can come later, as usually require a big deal of testing and tweaking. The texturing process, as far as I know, goes like this: you start from the model and 'project' its polygonal surface over a 2d texture (this is called UV unwrapping and is done by algorithms in programs like Blender, some of them require varying degree of user intervention like eg: marking 'seems' between some vertex pairs). Then you paint on the 2d texture using image editing software, or use Blender to paint over the model. The greenhouse author is @zzz. I did just some minor tweaks to the texture to make it look a bit less 'high-tech'.

@Mcflow195 I have a rather strange question for you: in your base, are the solar panels located relatively near the body surface? Is your base located at an altitude near zero (eg: Minmus flatlands)?

@Mcflow195 Maybe you have some power production that is not simulated by Kerbalism in background. What kind of power generation you have no that base? @Kerbos Thanks for the info on (1), Kerbalism does nothing to panels in loaded vessels so this one was puzzling. Also very unfortunate. Could you elaborate on (2)? EDIT: I found out the exact cause of (1), and is stock and not solvable by a mod. I'll leave the findings here for reference. If a re-orienting solar panel is a few meters above the zero-altitude surface of a celestial body, the stock raytracing system is not able to detect that the celestial body is occluding the sun. The bigger the panel, the higher it has to be above ground to not trigger this bug. The reason this is a rare occurrence is due to the fact that solar panels are rarely placed very near the surface, and that there are only a few places where you can land above the zero-altitude surface. Most notabily, the Minmus flatlands. The workaround is to avoid placing re-orienting solar panels too near the surface. Now Issue 10338 on the squad bugtracker.