Mihara

NullReferenceException: Object reference not set to an instance of an object at Romfarer.Util.LightTexture (UnityEngine.Texture2D texture, Single v) [0x00000] in <filename unknown>:0 at Romfarer.Util.get_LazorSkin () [0x00000] in <filename unknown>:0 at Romfarer.RuntimeLogic.OnGUI () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in <filename unknown>:0 at UnityEngine.GUILayoutUtility.DoGetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayoutUtility.GetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.DoToggle (Boolean value, UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.Toggle (Boolean value, System.String text, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at Romfarer.RuntimeLogic.GUIwindow_SpaceCenter (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1) I'm pretty sure Romfarer, which actually kills your KSP, has nothing to do with SCANsat.

Speaking of part cost workarounds. Is this (and subsequent discussion) the workaround you had in mind? Because if it is, it would be best for everyone if that is coordinated.

Possibly. More likely, a specific patch made it go crazy... Try this: https://github.com/taraniselsu/TacPartCfgLogger (check the releases tab) If it works under 0.24 (there's no reason it shouldn't, but I didn't try it yet) it will dump all the configs as they are after ModuleManager is finished processing them. Looking through them might provide clues.

If all else fails, it's always possible to eradicate the resource from ResourceDisplay structure directly, but that's a route that is likely to break something, finding a saner way to create a completely invisible resource would be best. Come to think of it, even KAS can use the same trick, it just would need to change the amount of funds resource and the size of the tank every time something gets inserted into a container or removed from it even during gameplay -- procedural and scaled parts would only need to do this in editor.

Simple resource. It's only role is to cost actual funds to launch. The only thing I'm not sure how to do is how to completely hide it from view and prevent it from showing up anywhere in the UI. If that can be solved, I'm sure it would work quite well.

Actually... I've been thinking about the impossible-to-change-cost problem, and I think there is a simple enough workaround. It's not very suitable for KAS, which also has that problem, but should be good enough for TweakScale, as well as any procedurally sized part. Introduce a new resource, let's call it simply Funds. It's massless, can't be pumped or transferred, and if possible, hidden from view in resource lists. (That bit might be complicated but should be possible.) Every unit of it costs one kerbal monetary unit. Straight part cost is the cost of the cheapest part variation. Every other variation's cost is affected by dynamically adding a Funds tank to the part and increasing the amount of Funds it contains.

Far from pointless, actually... The stumbling block with using FAR for me was always not that it's complicated (pfft) but that things that rely on stock drag produce results that are not just inaccurate by a little, or a lot, or over time, but outright insane here and now. If NEAR is just "FAR without interface or dialogs", it makes it as much of a detriment as FAR to playing nice with other plugins, but without the pretty graphs. Which is what I would call pointless.

It isn't closed, but it's intentionally obscure, check the front page of the GitHub wiki. The link from there goes to a build-in-progress in my dropbox that literally gets updated every time I push the 'build' button, which is why I avoid publicizing the link too far -- there's no guarantee whatsoever that it works, and I get enough support requests from people who struggle with the releases.

...One thing that merits explaining in the OP. Is this a full-blown "stock value for drag is always zero, deal with it" setup with less intricacies than FAR, or "stock value for drag is modified in real time based on shape and orientation but not mass" setup like Stock-Drag-Fix?

Was it this one? PartLoader: Compiling Part 'RealChute/Legacy Parts/drogue_main_combo_chute/RC_combo_large' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[RealChute.Parachute].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at RealChute.RealChuteModule.GetInfo () [0x00000] in <filename unknown>:0 at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 Dies when loading. That's the 64 bit build, clean install.

Well, I've just recompiled it, so if it didn't, now it is. Too simple to break.

Ok, bump for release. RasterPropMonitor v0.18 This is (mostly) a maintenance release corresponding with the release of KSP 0.24 and includes certain minor renovations. A minor change in version numbering policy -- version numbers now change after a release, not before. This should not affect anyone. MechJeb version 2.3 is now required if you want interfacing with MechJeb. (That's the earliest version that runs with 0.24 anyway, I believe.) KSP-AVC version-file format is now supported for stating the version of RPM. SCANsat will support RPM directly in the release that should be uploaded very soon. As such, SCANsatRPM.dll is no longer supplied -- if you have the appropriate version of SCANsat installed, it will Just Work. If you still somehow have any copies of SCANsatRPM.dll in your game, get rid of them. Bundled version of ModuleManager updated to current. Bugs fixed: The lost texture on the primitive camera model has been returned. The model for the internal flag plate prop has been updated with a new one that correctly handles transparent flag textures, but is otherwise identical. New features: FUNDS, REPUTATION variables show what you would expect.

Ok, I'm back and looks like I can't find any fault with 0.18. Looks like nobody was brave enough to download the dev build and test it, though. I'm still waiting on a few things before release: I would like to know if I should remove B9 patches from the distribution or not, i.e. whether the B9 rerelease is upcoming any time soon. Alexustas to fix the model for the flag plate so that it correctly works with transparent flags. Well, the aforementioned SCANsat release, but I guess I don't need to worry about that.

Helpful, thanks. What about RLA Electrical though?

http://forum.kerbalspaceprogram.com/threads/86406-Stock-Parts-Costs-and-Balance-Spreadsheet-for-0-24 The spreadsheet therein should be helpful.

...Ok, gentlemen and ladies, I've made the requisite changes to readjust RPM to match the new full release of MechJeb, and even added a couple new variables, but I can't fully test it immediately, since I have work tomorrow. I also can't release it for a few more reasons: ModuleManager is required, and I'm not entirely certain it works correctly in the current build yet. Well, it seems to work, seems is not enough. SCANsat is scheduled to come out with a build that embeds SCANsatRPM into it, which means that I could finally get rid of it, which would be awfully nice, and I'd rather have this settled before pushing out 0.18. There's probably something broken deep inside. Any brave souls can download the dev build from the usual location, exhaustively testing it and telling me what's broken (I suspect per-stage showing of resources might be) and I'll fix it when I'm back.

Which particular buttons do you mean? The ones on the new model? You can't, you would need a different model, sorry.

...considering that it was in development before the pack-rat rover was ever publicized, no.

...You humans and your languages. Ok, we'll figure something out.

We're currently discussing SAMOKAT, and yeah, that's an acronym. If anyone can find a fault with that, please don't hesitate to say so.

...I was the one who suggested the name, and, well... I don't get which racial slur do you mean regardless of pronunciation. ^^;

We're Russians, we wouldn't know.

http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-17%29-27-Jun?p=1241015&viewfull=1#post1241015

"Should do this with one launch."

Did you check the actual KAS dll and whether it got corrupted or misplaced? Because what the error message says is that it can't be found, not that your patch is somehow wrong.