DesTroy

Master Tao, sorry, but you are incorrect. The code for generating electricity is the "ModuleAlternator" module block: MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 5.0 } } Which, as I stated in my first post, still works without the completely separate: RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 } That resource code seems, for all purposes, useless.

This is something I have been wondering for the longest time, as it causes so many issues. Whenever an engine has this in it's cfg: RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 } It will cause a NaN bug to occur on the ElectricCharge tweakable if one right clicks the part... which then screws up the mass of the part, which affects things like fund costs, CoM marker from showing up, and all sorts of other calculations. The fix is simple, remove that resource block from the cfg. The question I have is.... why do modders KEEP ADDING THIS IN? It's completely useless, it's max charge is 0, so why even list it? I don't understand. Even some stock parts still have it? Why? Some modders (And also some MM 'fixes') add "isTweakable = false" & "hideFlow = true" to the code block to negate this problem. But WHY? Why are you so insistant in keeping that block at all? I always delete these code blocks.... Is there something I am not aware of? Is it needed for some crazy, unforeseen reason or bit of code that uses it? I have not noticed any ill affects thus far... Alternators still work on the engine too, so that's not an issue. Can anyone answer these questions? I am interested to know the reason If it is indeed unneeded (Which I totally suspect) Then let this be known to all modders... Stop wasting everyone's time, including your own, and just don't include this code block! PS NOTE: I am not talking about the ModuleAlternator code block: MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 5.0 } } It is not the problem, and I don't mean to remove this.

I'm not quite sure what the problem was because one of the MFD entries was listed as ExampleMFD for me... and I was using the latest version that you put up (1.2.1). The problem monitor was the middle one on the far right. In any case it is fixed now.... Quite strange... but if it's fine in your package, then it should be ok. Though you should change it to the HUD to "RasterPropMonitorBasicHUD" as well (Since that has been changed). The reason that still worked was because of the compatibility MM patch RPM includes.

I believe this was mentioned way earlier in the thread, but buried between 300 some odd posts, I thought I might bring attention back to it: With the latest DLL version, in both 32-bit and 64-bit, when using it to change the atmosphere color to say remove the white part of the sky, as in Better Atmospheres or Proot's Renaissance Pack, it will work on first starting up, at the Space Center scene. However, after changing scenes or launching, the sky then becomes black. The post earlier in the thread mentions that it has something to do with the atmosphere either glitching to a very small radius or extremely large. Even though the settings initially work on every startup, and are not changed. I do not use RealSolarSystem fully, I was just trying it for the white atmosphere removal, but I can only assume that this might affect a full RSS user as well. Just FYI. You should into this ASAP.

Found this when sorting out a bunch of issues with internals and RPM: In your internal_RPM config, you have one MFD still calling the old "RasterPropMonitorExampleMFD" This has been changed in RPM 0.18 (and if people are using a new RPM skin, it wont display) or breaks entirely. Just adjust it to "RasterPropMonitorBasicMFD" like the others. You should fix this ASAP in your download archive

I have also posted this on the RPM and KSO thread: The glitch where the HUD and ADI overlays become super dark is caused by OpenGL rendering. This is why it occurs on Linux and Mac. I am using Windows 7, and was using the 64-bit version to allow for all my mods. The HUD and ADI was fine during this time. (I am using Wari Complete KSI 2014-7-10) The instability, glitches, and enormous memory usage caused me to switch the the 'amazing' openGL switch. I can run all my mods with only a 2.6 GB RAM footprint in 32-bit KSP with the -force-opengl command parameter. However, this is when they problem occurred with the super dark overlay. I have confirmed this by running the game with no OpenGL switch with the exact same install, and they magically work again with the default DirectX (I have not tried DX11 though). As to why this occurs I have no idea whatsoever. Also: It may be unrelated or not causing the problem, but I also noticed that the files that ARE the ones that become dark have a Y dimension size of 2044 pixels (Instead of say 2048, as in some of the other image files) Could this be the problem? Maybe OpenGL freaks out when an image isn't a power of 2 size? Can you do a check by reworking ladder.png and ADI_ladder.png to be a power of 2?

Issue #1: I have also posted this on the RPM thread: The glitch where the HUD and ADI overlays become super dark is caused by OpenGL rendering. This is why it occurs on Linux and Mac. I am using Windows 7, and was using the 64-bit version to allow for all my mods. The HUD and ADI was fine during this time. The instability, glitches, and enormous memory usage caused me to switch the the 'amazing' openGL switch. I can run all my mods with only a 2.6 GB RAM footprint in 32-bit KSP with the -force-opengl command parameter. However, this is when they problem occurred with the super dark overlay. I have confirmed this by running the game with no OpenGL switch with the exact same install, and they magically work again with the default DirectX (I have not tried DX11 though). As to why this occurs I have no idea whatsoever. Also: It may be unrelated or not causing the problem, but I also noticed that the files that ARE the ones that become dark have a Y dimension size of 2044 pixels (Instead of say 2048, as in some of the other image files) Could this be the problem? Maybe OpenGL freaks out when an image isn't a power of 2 size? Can you do a check by reworking ladder.png to be a power of 2? Issue #2: *EDIT* I just discovered that the KSO MFD's need electrical power to actually display (Through my perusing of all the RPM configs in KSO) It may be useful to explicitly mention this in the KSO FAQ. It isn't 'exactly' intuitive because the rest of the lights are on. I was testing quickly so just added the cockpits to check. ISSUE#2 is solved, but ISSUE#1 remains at large...

I registered just to relay this information: The glitch where the HUD and ADI overlays become super dark is caused by OpenGL rendering. This is why it occurs on Linux and Mac. I am using Windows 7, and was using the 64-bit version to allow for all my mods. The HUD and ADI was fine during this time. The instability, glitches, and enormous memory usage caused me to switch the the 'amazing' openGL switch. I can run all my mods with only a 2.6 GB RAM footprint in 32-bit KSP with the -force-opengl command parameter. However, this is when they problem occurred with the super dark overlay. I have confirmed this by running the game with no OpenGL switch with the exact same install, and they magically work again with the default DirectX (I have not tried DX11 though). As to why this occurs I have no idea whatsoever. Also: It may be unrelated or not causing the problem, but I also noticed that the files that ARE the ones that become dark have a Y dimension size of 2044 pixels (Instead of say 2048, as in some of the other image files) Could this be the problem? Maybe OpenGL freaks out when an image isn't a power of 2 size? Can you do a check by reworking ladder.png to be a power of 2?