ShotgunNinja

@cy4n In the model assign an emissive texture to some object. Test how it look with intensities from 0 to 1. In the greenhouse module definition, indicate the name of the object with the emissive texture in 'emissive_object' property. Then in-code I set the emissive intensity. If you want to use some other techniques like animations or lights I could extend the greenhouse code to do that. @PieBue Thanks I'll check that. NEW TEST: mini_particle.compiled Move-replace it in Kerbalism/Shaders and try to see the fields.

@BashGordon33 You did it right. Too bad they aren't working. Yes that is intended behaviour. If you focus on a moon without fields (or a vessel orbiting that moon), then the fields that interest you are the one of the parent body.

New test for those with GPU problems: these archives contain two variants of the file 'mini_particle.compiled': one and two. Try replacing the file in Shaders directory with each one of them, in turn. Then test the field rendering and report if it work and which of the two variants you were using in that case. I'm sorry this is a bit of a painful process.

@MinimumSky5 Their effects sum. Yes the numbers are in radii. The zone raditation is in rad per hour.

@BashGordon33 There is no need to remove planet packs. Download the two test builds some posts above. Temporarely move Kerbalism directory out of GameData. Uncompress test build 1 and put it in GameData. Run KSP, start a new game, go in map view and zoom out. You should see particles all around you, of different colors. Then do the same all over again for test build 2. Finally you can remove the test build from GameData and put back the Kerbalism directory you moved out at the start. Then report if you saw particles and of what color.

@MinimumSky5 The new system require authoring for every celestial body. I wrote the configs for stock bodies, OPM and RSS. Contributions for other planet packs are welcome. Writing these configs is not hard, some documentation is here. At a minimum you can just copy Jool to the other gas giants like this: +RadiationBody[Jool] { @name = YourGasGiantNameHere } Set the name of your gas giant and put this in a file with extension '.cfg' inside GameData.

@BashGordon33 To clarify, you have a GTX 960 and you tested both builds, but you didn't see anything unusual in the mapview around kerbin?

@Bersagliere81 Technically unless the part is removed or disabled using MM, the greenhouse will always work producing the resource specified in its module config. Look like that particular profile is not disabling it, contrary to what is written at the top of the file. So you should be fine.

@raxo2222 I'll change that icon to an 'eye' or something on that effect. Another tip: you can use keypad 0 to toggle all fields rendering on/off, and keypad 1/2/3 to show them individually.

Ok, these are special builds for testing purposes: one and two. Test only if you have an Nvidia GTX 960/970: Try the first one, go in map view and zoom out: you should see red, green and blue particles. Try the second one, go in map view and zoom out: you should see yellow particles. Let me know if you see some particles and of what color. Do not use these with your savegames.

@DarkonZ With hardware I meant GPU. Without that GPU I can't replicate the problem, debug it, develop and test solutions. The only way I could proceed is by eyeballing the problem speculatively and handing out test builds to people with that GPU. Meanwhile there is ZERO logical reason why that shader shouldn't work on that particular GPU, giving that is working on all others. The shader in question is particularly simple, here is the Unity mumbo jumbo of the CG shader: and that's it. Minimal, texture-less, 1-pixel wide point sprite rendering. This shader will run in any programmable GPU since 2006, probably even before that. Note also that this isn't the first shader I wrote in my life (but the first unity mumbo jumbo cg thing, yes). There are a grand total of 3 lines that do something, and all of them are extremely basic.

Consider the previous magnetic field models were sphere, the new one are more complex. For example for a part of a perfectly circular orbit you may be inside the magnetopause (rad = 0.01) and for another part outside (rad = 0.02). Is to manage the complex shapes that I added the field rendering. Press 0 on the keypad to see the fields in mapview, unless you are a fortunate owner of a Nvidia GTX 960/970. Working on it, I'll send you a debug build to test it. @Bersagliere81 Is the vessel unmanned? I just realized I'm only checking against manned vessels by mistake. Fix in next version.

For anybody that had problems with this mod and SCANsat: the author just released an updated version 16.6 that fix the issue. Also I can confirm there is an issue with BackgroundProcessing and the new resource cache. I'll fix in next version if possible.

Radiation now is greater than zero everywhere. And now it is blocked by atmosphere depending on where you are inside it and how dense it is. But those values are not looking right. What radiation value does the 'vessel info window' say? Also the geiger counter indicator is not linear: it has to represent values from 0.001 to 10.0. Radiation values you usually encounter in normal activities are below 0.02, but are represented in the first third of the indicator space, graphically. That's the reason I added the 'motivational notifications' you see when a Kerbal die.

@EasyAce When BackgroundProcessing is installed, the simulation of solar panels, command pods and generators (like the rtg) are left to it. Now, maybe the recent 'resource cache' I implemented in version 1.0.4 is messing with it. Please try to remove BackgroundProcessing and see if the problem manifest again. @Bersagliere81 Will check, maybe the contract condition broken with the new belts.

If with that you mean "have you fixed it" then the answer is no. Will I fix it? The problem is that I lack the hardware to replicate the issue myself. Maybe I will try some speculative fix and use some of you guys for testing it, but first I need to get a clue on what is the problem. Because, on paper, it should just work as it does on all other GPUs.

Dang. These things happen, and by chance you got me to solve some issue with SCANsat. @Solarflare1234 Check that you have ModuleManager 2.6.25+ and CommunityResourcePack installed as well, those are required. Also double-check that the file Profiles/Default.cfg exist and is named in this way. If the above don't resolve your problem then send me the log file {KSP directory}/KSP.log that I'll take a look.

@kR105 I committed it just now, so you can help me test if it work. Use it with SCANsat 16.5, let me know if there are still problems.

@Espartanus Install CommunityResourcePack. @kR105 Ok I digged, turn out it was subtle stuff. You are right the sensors are not (de)registering in background at all. But the scanner EC consumption is working flawlessly. Anyway I dropped a line to SCANsat author, and in the meanwhile I'll use a workaround. To be released in next version.

@kR105 Alright, thanks a lot! I'll dig in SCANsat changes and fix this for next version.

@kR105 No no, thank you for helping me Those warnings in the log are unrelated unfortunately... I have another request: can you try using SCANsat version 16.3 (two versions ago) and see if the problem still persist? I starting to think something changed in SCANsat in last two versions that broke the system I have in place to disable/re-enable its sensors in background.

@kR105 Is the log showing anything unusual? Did this problem start appearing after you installed 1.0.9 first time?

@kR105 Uncheck the flag 'Check for arithmetic overflow/underflow' in the compiler. That bit of code is perfectly safe to overflow. In fact I don't want any overflow/underflow checking at runtime both for speed (the checking is not free) and for functionality (sometimes your code exploit integer overflow/underflow, like in this hash function).

Next in line, a simple 'automation system' is being implemented. It will serve multiple purposes: allow some form of automation on the state of vessel devices store 'files' per-vessel: text notes, scripts will be used by the incoming science system to store and manage data, and to transfer it to other computers/vessels There will be a predefined set of 'script files' in the computer, that the user can edit. These files will be executed as scripts automatically when some events happen such as: [auto/landed] vessel just landed [auto/unlinked] vessel lost signal [auto/linked] vessel regained signal [auto/lowpower] vessel is low on ElectricCharge [auto/crewhazard] crew health is low [auto/space] vessel is in space [auto/atmosphere] vessel is in atmosphere [auto/eva_out] crew went out on EVA [auto/eva_in] crew reentered from EVA [auto/sunlight] vessel is in sunlight [auto/shadow] vessel is in shadow The devices that can be controlled will include: scrubber enable/disable recycler enable/disable greenhouse set lighting gravity rings set speed active shields set intensity sensors (coming soon in science system) stock lights turn on/off ... The commands are simple: list {dir} list directories, or files in a directory info [file] print status of a device ctrl [file] [value] enable/disable/throttle a device run [file] execute a text file as a script send [file] [target] send a file to another machine in the network name [machine_name] rename this machine print [msg] print a message on console log [msg] append a line to doc/log message [msg] show a message on screen Some motivating examples: ========================================== auto/shadow ========================================== // turn on all the lights as soon as the sun is not visible anymore ctrl lights on ========================================== auto/linked ========================================== // send all data as soon as we are linked send data net/home ========================================== auto/lowpower ========================================== // turn off non-essential systems when battery is low ctrl lights off ctrl sensors off ctrl activeshields off // make sure only one scrubber is enabled ctrl scrubbers/0 on ctrl scrubbers/1 off // set the greenhouse lights to half intensity ctrl greenhouses/0 0.5 // shut down all the gravity ring ctrl rings off

I'm thinkering with an automation system, but is more focused on enabling/disabling components when some conditions apply. But in general, the signal system here was never meant to evolve into a full RT clone. In your example, you could plan the burn(s) so that they are possible without a relay for the first vessel, then on successive ones you exploit the first one as relay. @Sutima You can do something like that already, by adding the Emitter module to the part you want as a shield: @PART[my_fuel_tank_or_whatever] { MODULE { name = Emitter radiation = -0.0002 // rad/h tooltip = This part offer some shielding against radiation } }