toadicus

Done. I'm not home to release it and I'm working a bunch this weekend, but I'll get it out ASAP.

Just thought some of you might want to know...

In the editor, that is what this line means: But only when you click this button: In flight, it's always already done that. I think that VesselSimulator hasn't always correctly worked with mods like KIDS that change Isp, but they've recently added proper support for that, which is included in the latest VOID release.

VOID has been updated to version 0.17! This update brings a new module, more information, and less weirdness. The new module is VOID_CareerTracker, a "ledger" that documents all of your currency transactions (after installing it; it can't recreate past transactions in a pre-existing save). Don't like it? Don't unpack it! VOID_CareerTracker uses VOID 0.17's improved modular architecture to be completely optional; if you remove or just don't unpack VOID_CareerTracker.dll, it won't even exist. CHANGELOG: v.0.17 [2015-02-26] * NEW MODULE: The first independent module, VOID_CareerTracker provides a "ledger" for every currency transaction in your career. * VOID_DataLogger: Added a 'wait for launch' configuration option that will wait until the situation is not PRELAUNCH before logging any data. * VOID_DataLogger: Added Periapsis, Apoapsis altitudes. * VOID_Orbital: Added time to ascending & descending nodes. * VOID_StageInfo: Added burn time column. * VOID_StageInfo: Added an option to use sea-level values when relevant while in the editor. * VOID_SurfAtmo: Shortened the name a bit to avoid / reduce clipping. * VOID_VesselInfo: Resource mass now reported more reasonably and reported to 3 decimal places. * VOID_Orbital, VOID_SurfAtmo: Variable-precision values now using new ToSI method to improve behavior in many situations. * Downrange distance now calculated using an alternate formula to avoid exceptional conditions at antipodal points. * VOID applauncher icon now appears in map view while in flight. * Core modules: Made the toggles a little prettier under some skins. * Added close buttons to all windows. * Biome readouts now report special Kerbin-surface biomes like KSC. * Burn time readouts will now account for staging. * Skins: Forbade "KSP Window 1" and "KSP Window 3", because they make VOID look super ugly sometimes. * VesselSimulator updated to latest KER release. * ToadicusTools: New custom ToSI method using significant figures instead of weirdness. * Under The Hood Changes to make VOID work in scenes other than flight and the editor. * Under The Hood Changes to make dealing with time intervals slightly more sane on my end. * Under The Hood Changes to make the configuration really only save when it needs to. * Behind The Scenes Changes to help me keep track of and release non-code things more reliably.

So, I confess to being pretty baffled by the problem not correcting after deleting the VOID folder. That exception should only fire when the number passed in Int.MinValue (-2,147,483,648), because it has no positive counterpart in a 32-bit signed integer. The way my logic is set up, the number being passed there should only ever be 2, 5, or 8. It's seeded to 5 in the constructor and saved in a bitwise collection in VOID/PluginData/VOID/config.xml. If that file is deleted (or you use the "factory reset" trigger, which deletes that file) it will necessarily reset to 5. If it's being corrupted between the constructor or the config load and actually running the GUI... I'm afraid the root of this problem is out of my hands. With that in mind, your debug log is so full of exceptions that I can't be surprised at all. KerbCam appears to be packaging its own copy of KSP's Assembly-CSharp (or maybe it has its own?) which Unity is shutting down for security, kOS is failing to load its xml config during the loading screen, FinePrint, HaystackContinued, Kethane and KittopiaSpace are failing during the loading screen because directories is missing, and AutoSave is complaining about a missing save file in DestructiblesTest. There are literally dozens of other apparent failures, and I have no idea what any of those might be doing. Now: the one I think might actually be specifically relevant is DockingPortAlignment, which is complaining about its Xml file. I have done some troubleshooting before that has led me to believe that when one Xml file is particularly anomalous, all of the Xml loads happen incorrectly. In this load, VOID isn't complaining about it, so in theory that shouldn't have anything to do with it... but this is already far enough removed from anything that I think makes sense that I'm not sure what else to think. All that to say, "Can't Duplicate". But, I ought to be able to guard against this weirdness anyway, and believe I have done so in this commit. I have to jack in to the matrix to build and release the fix; watch this post in the near future for an edit containing notification that I have done so. Edit: There is no spoon, but there is a new dev build: [zip] [tar.gz] [tar.xz] Edit #2: Please standby while I reconsider my position. Apparently, I'm not good at recalling my own code while waiting in my kid's dentist's office. Edit #3: I have good news and I have bad news. The good news is that this is an easy fix on my end, and still to do with numbers of unusual size. The bad news is that your save has the NaNovirus. It turns out that C# allows some very strange things to happen in double->integer casting of which I was previously unaware, which resulted in my thinking that this problem was something that it was not. Considering this, it's no wonder that the NaNovirus is so easy to spread. The best news is that the dev builds (still at the links above) should now protect VOID's variable-precision values from infecting their panels.

OK, I updated my local KER code to reflect the fix that Padishar pushed for our Resource Mass issue, and wrote my own sig-fig based SI abbreviating format function. It should behave more reliably for essentially all values, and lets me remove some hokey logic in the panels with variable precision that was probably actually the source of the weirdness. I consider this a release candidate. I've refreshed the development downloads ([zip] [tar.gz] [tar.xz]), with these changes: CHANGELOG: Pre 0.17 Testing Release [2015-02-22] * VOID_Orbital, VOID_SurfAtmo: Variable-precision values now using new ToSI method to improve behavior in many situations. * VOID_DataLogger: Added Periapsis, Apoapsis altitudes. * VesselSimulator updated to latest KER release. * ToadicusTools: New custom ToSI method using significant figures instead of weirdness.

DaPatman, I just tried your steps and it looks like that's fixed in my Big Update, which I'm hoping to release this weekend. Thanks!

As you might imagine I also have both those mods, but don't have this problem. So, if you've got more log output to share it could still be useful. No, I've not done any work on supporting nodes in different places.

Can you recall when, or after what, or anything else that might help me track it down?

Whoops, here it is: http://ksp.hawkbats.com/dev/AdaptiveDockingNode.dll

Gaiiden, I think I've found where Squad keeps the "distance traveled" number, and unfortunately it's not someplace I can get to it. Failing that, I'd need to do a reflection wrapper for PersistentTrails to go get theirs, or write a watchdog to track it myself. The latter probably wouldn't be a big deal, but it's not going to make it into this update. Currently, the precision settings pick how many digits you want to see. So, the idea is that you pick "I want to see 3 digits before decimal place," and if you're moving 300 mm/s the units will be in mm/s, 3 m/s will be in m/s. One of the reasons for this is that it's how the function I inherited that converts numbers into smaller numbers with SI prefixes works. Another is because it lets me put an easy cap on how long numbers get (literal horizontal length when drawn), which is important because at this point I don't have a way of making windows wider to accommodate long numbers. For example, if we use an absolute magnitude fix and you pick "meters" on the semi-major axis, when you're out at the edge of the system and that number is 11 digits long, we run out of space and the number wraps to the next line. It also gets messy if you pick a big unit like "megameters/second" and then do something really slow, like drive a rover. Should I just show 0.00? Display it in scientific notation? Saying that you're going "3.78e-6 Mm/s" is pretty silly looking. In general I still like the idea of picking how many actual digits you want to see on the screen. I'm not stuck on it, but it has some practical and aesthetic benefits. It lets you say "I always want to see 8 significant figures for this number, no matter what it is." If semi-major axis is something that you want to see in pretty high precision all the time, you set that and forget it. It doesn't matter if you're in a low orbit around Minmus or a high orbit around Kerbol, you still see 8 significant figures. It gives a consistent presentation and the user doesn't have to tweak the settings every time the situation changes. I know sometimes the current system does weird things for no apparent reason. I'm not sure why that happens; if we stick with it I'll try to iron it all out. So, all that to say: make a case for what you want and why it's a good idea. I'm genuinely interested and happy to listen.

I can't duplicate this problem. It's a little hard to tell, because the log is just so big that it's easy to get lost, but this is very probably happening because of a very slow startup in flight mode, probably owing to the 169 mods (or so) you have installed. When startup happens much more slowly than KSP expects, it stops waiting for it and starts running Update and FixedUpdate. Meanwhile, some things are still starting. It's pretty likely that in fact this problem would just go away once your install finally finished starting up in flight mode, and that the mod would work normally during play. Further, it's really hard for me to conjecture which thing might be null to attempt a fix because I don't know what hasn't started up yet. That said, I don't like having my mods fail to handle exceptions under any circumstances. So if you want to help out, this debug-activated DLL will spam your log and screen full of horrible noise, which ought to help me see where the specific failure point is. To keep the size of the log down, please test this way: Copy the DLL over the existing DLL in your AdaptiveDockingNode folder. Run the game. Load directly to the ship you used in your last test if you can. Wait several seconds after the world starts drawing for everything to settle down. Force close the game (Alt+F4, click the "X" in the corner, etc). Upload ye debug log.

I'm surprised that rolling back fixes it... the problem in the log suggests that you have malformed config.xml files in TweakableEverything/PluginData such that Mono's XmlTextReader refuses to even parse them. There are similar errors for MechJeb. Did you happen to delete TE's PluginData when you rolled back (but not when you upgraded, maybe)? Edit I added some exception protection to the ToadicusTools method that was failing because of the XML issues; feel free to try this development DLL and see if it helps.

Well, I know it's possible; just use an MM patch or similar to set acquireTorque or captureTorque to an insanely large number. It's a float, so the number can't be bigger than 3.4028234E+38. It's probably going to be multiplied by something, so realistically you probably want to be well short of that number. I would suggest to you, though, that such a change is unlikely to have the effect that you want.

I've gone ahead and responded to their issue, though it looks like they've got things well in hand. I'm pretty sure I'm not doing anything to call the event except by adding extra tweakables to things... which is the whole premise of the mod so I can't really change it. That said, I've invited Magico13 and company to ask me to look closer if there's still something to look at.

Gaiiden, I'm still mulling how to fix the units bug. The issue is that the value you pick is relative. You pick "I want it to be 3 orders of magnitude bigger / 6 orders of magnitude smaller" than it really is." On the pad, velocities and distances traveled are all 0 with an exponent of 0, so you set relative to that. Then when you start flying and your downrange distance, for instance, starts being measured in millimeters, it looks different because it is different. I don't really want to pick absolute values, because then you could pick things that don't make any sense and the mod wouldn't help you make them make sense... but I'm not sure how else to change the behavior. Feel free to keep letting me know what you see and what you'd like it to do; I'll mess around with it and see if I can make it happier, myself. I just added Apo/Peri altitude: http://git.toad.homelinux.net/projects/VOID.git/commitdiff/5e14cae. Also, when you say "Distance Traveled", are you talking about the equivalent of the number in the flight results pane? I'm not sure where to find that, but I'll see if I can dig it up. So seyss, when you run with the same set of mods in the 32-bit version, everything works fine? Sounds like you've got the solution right there. Squad is dropping the Windows x64 version of KSP at the next release; I'm not going to chase phantom bugs for a deprecated build of the game in the meantime. If you can either duplicate the bug in 32-bit, or find a case in the log that shows it really is a coding problem on my end, I'll happily try to fix it.

Sorry for the wait folks; it's been a crazy week. Nerezza, my decouplers don't do that, so I'll need more information. A log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) would be great; a list of other mods you have installed is a distant second. Steps to reproduce are always handy. jefferyharrell and Gaiiden, I think that if you can do that by adding a line to TweakableEVA.cfg like this: EVA_MODULE { name = ModuleTweakableEVA [B]thrusterPowerThrottle = 0.2[/B] } thrustPowerThrottle is a ratio from 0 to 1. It's been a while since I looked at the EVAManager code, but I think I made that possible. If not let me know and I'll take another look. gamelord1994, you can do that with an MM patch via TweakableStaging. For example: @PART[*]:HAS[@MODULE[ModuleEngines]]:AFTER[TweakableEverything]:NEEDS[TweakableStaging] { MODULE { name = ModuleStagingToggle defaultDisabled = false activeInFlight = false activeInEditor = true } } To include all of the engines you'd need to OR ModuleEnginesFX into the patch as well, but my ModuleManagerFu is rusty right now and I can't remember the exact syntax. You could also just duplicate the patch and substitute ModuleEnginesFX for ModuleEngines. jefferyharrell, the last version included some fixes that should have made TE and Procedural Fairings play nicely together. I play with KCT, so MechJeb seems like the odd one out. I have no idea what would make it churn like that... but I'll try to take a look soon. Can you check if removing MechJeb also makes the problem go away? You're welcome, Albert VDS! I'm glad you're enjoying it.

Sorry for the delay; I'm gasping for breath trying to get my head above water after a crazy busy week at work. Gaiiden, I can do Peri and Apo heights (I assume you want altitudes?) very easily. For the fuel ratios, do you just want that for the actual first two stages (e.g. for launches), or would that apply to "current" and "next" stages always? If the former, do you have a concept for how I might know that you are launching right now, and not flying or suborbital for some other reason? I could pin it to time or try to detect "new flights", but both of those methods are relatively unreliable (for example, if you left the ship on the pad, did some time warping, and came back to it, a time-based detection might not work). It's possible I could only run those in a session that started with PRELAUNCH... not sure if that would ever fail or not. FAR integration is out of scope for this update, but coming in the not-too-distant future. Sorry for the trouble, seyss, but I don't think that's being caused by this mod. If you get me a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log), I'll take a look and see what I can see.

So, I had stage and total resource mass plugged in backwards, which was part of the trouble. Beyond that, I was getting numbers from KER that I couldn't really figure out. So, I've filed an issue and reintroduced a hack that I used in the past, and at least always now get a reasonable number, even if it's not always exactly what you want (e.g. it will show the "current stage" resource mass in an SLS-style craft as just the resource mass in the SRBs, even when the SRBs and the central stack are burning, because they will be discarded first). Resource mass does include everything that is handled as a resource; AblativeShielding is among them. I've refreshed the development downloads (same links as above), with these changes: CHANGELOG: Pre 0.17 Testing Release [2015-02-08] * VOID_SurfAtmo: Shortened the name a bit to avoid / reduce clipping. * VOID_VesselInfo: Resource mass now reported more reasonably and reported to 3 decimal places. * Downrange distance now calculated using an alternate formula to avoid exceptional conditions at antipodal points. * VOID applauncher icon now appears in map view while in flight.

Hey folks! I don't do this often, but the time has come for me to ask for some testing. No, I still haven't got the configurable panels in... but I've done a lot in preparation for that, and I've changed so much under the hood that I hesitate to release without a bit of testing beyond my usual testing group of 1. So! If you're both interested and brave, you can grab the development release here: [zip] [tar.gz] [tar.xz] If you're super nerdy and like ascii graphs, here's a git diff stat of the changes: .gitattributes | 10 ++ API/Attributes/AVOID_SaveValue.cs | 47 ++++++++ API/Attributes/VOID_GameModesAttribute.cs | 47 ++++++++ API/Attributes/VOID_ScenesAttribute.cs | 47 ++++++++ API/IVOID_DataValue.cs | 43 +++++++ IVOID_Module.cs => API/IVOID_Module.cs | 10 +- API/IVOID_SaveValue.cs | 39 +++++++ API/VOIDCore.cs | 87 ++++++++++++++ API/VOIDMaster.cs | 159 +++++++++++++++++++++++++ VOID_HUDModule.cs => API/VOID_HUDModule.cs | 26 ++--- API/VOID_Module.cs | 549 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ API/VOID_SingletonCore.cs | 68 +++++++++++ API/VOID_SingletonWindow.cs | 72 ++++++++++++ GameData/VOID/Textures/ATM_VOID.cfg | 15 +++ GameData/VOID/Textures/fundsgreen.png | Bin 0 -> 670 bytes GameData/VOID/Textures/fundsred.png | Bin 0 -> 670 bytes GameData/VOID/Textures/repgreen.png | Bin 0 -> 956 bytes GameData/VOID/Textures/repred.png | Bin 0 -> 964 bytes GameData/VOID/Textures/science.png | Bin 0 -> 799 bytes GameData/VOID/Textures/void_appIcon_dark.png | Bin 0 -> 1211 bytes GameData/VOID/Textures/void_appIcon_dark_glow.png | Bin 0 -> 2205 bytes GameData/VOID/Textures/void_appIcon_light.png | Bin 0 -> 1097 bytes GameData/VOID/Textures/void_appIcon_light_glow.png | Bin 0 -> 2175 bytes GameData/VOID/Textures/void_icon_dark.png | Bin 0 -> 880 bytes GameData/VOID/Textures/void_icon_dark_glow.png | Bin 0 -> 1362 bytes GameData/VOID/Textures/void_icon_light.png | Bin 0 -> 783 bytes GameData/VOID/Textures/void_icon_light_glow.png | Bin 0 -> 1336 bytes VOID_DataValue.cs => Tools/VOID_DataValue.cs | 49 ++++---- VOID_Localization.cs => Tools/VOID_Localization.cs | 0 VOID_SaveValue.cs => Tools/VOID_SaveValue.cs | 69 +++-------- Tools/VOID_StageExtensions.cs | 37 ++++++ VOID_Tools.cs => Tools/VOID_Tools.cs | 23 +++- VOID.csproj | 52 ++++++--- VOIDCore_Editor.cs | 45 ++++++++ VOIDCore_Flight.cs | 50 ++++++++ VOID_Core.cs => VOIDCore_Generic.cs | 765 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------- VOIDCore_SpaceCentre.cs | 38 ++++++ VOIDEditorMaster.cs => VOIDMaster_Editor.cs | 73 +----------- VOIDFlightMaster.cs => VOIDMaster_Flight.cs | 81 ++----------- VOIDMaster_SpaceCentre.cs | 61 ++++++++++ VOID_CBInfoBrowser.cs | 61 ++++++---- VOID_CareerStatus.cs | 141 ++++++++++++++--------- VOID_ConfigWindow.cs | 75 ++++++++++++ VOID_Data.cs | 393 ++++++++++++++++++++++++++++++++++++++------------------------ VOID_DataLogger.cs | 38 +++--- VOID_EditorCore.cs | 155 ------------------------- VOID_EditorHUD.cs | 9 +- VOID_HUD.cs | 14 +-- VOID_HUDAdvanced.cs | 12 +- VOID_Module.cs | 309 ------------------------------------------------- VOID_Orbital.cs | 25 ++-- VOID_Rendezvous.cs | 58 +++++----- VOID_StageInfo.cs | 127 +++++++++++++++----- VOID_Styles.cs | 2 + VOID_SurfAtmo.cs | 17 +-- VOID_TWR.cs | 15 ++- VOID_Transfer.cs | 33 +++--- VOID_VesselInfo.cs | 8 +- VOID_VesselRegister.cs | 63 ++++++---- 59 files changed, 2615 insertions(+), 1502 deletions(-)$ git diff --find-renames --stat=180 0.16.4 > /tmp/diff; cat /tmp/diff CHANGELOG: Pre 0.17 Testing Release [2015-02-07] * NEW MODULE: The first independent module, VOID_CareerTracker provides a "ledger" for every currency transaction in your career. * VOID_DataLogger: Added a 'wait for launch' configuration option that will wait until the situation is not PRELAUNCH before logging any data. * VOID_Orbital: Added time to ascending & descending nodes. * VOID_StageInfo: Added burn time column. * VOID_StageInfo: Added an option to use sea-level values when relevant while in the editor. * Core modules: Made the toggles a little prettier under some skins. * Added close buttons to all windows. * Biome readouts now report special Kerbin-surface biomes like KSC. * Burn time readouts will now account for staging. * Skins: Forbade "KSP Window 1" and "KSP Window 3", because they make VOID look super ugly sometimes. * Under The Hood Changes to make VOID work in scenes other than flight and the editor. * Under The Hood Changes to make dealing with time intervals slightly more sane on my end. * Under The Hood Changes to make the configuration really only save when it needs to. * Behind The Scenes Changes to help me keep track of and release non-code things more reliably.

CKAN won't install EVAManager until I get it into distribution somewhere more official and write a NetKAN file for it. AntennaRange uses it, too, so I can't just tell TE to unpack it. You'll need to do it yourself until I get that sorted.

Good catch, jefferyharrell, and thanks for that stunningly-thorough bug report! I broke EVAManager out of ToadicusTools, thinking I might distribute it on its own, but totally forgot to include it in the TweakableEverything package. You can go grab the DLL here; just put it anywhere in GameData and you should be good to go. I'll update the TE packages shortly.

The Source folder does not need to be unpacked, and is included only for some rather specific rules-following minutia.

TweakableEverything has been updated to version 1.8! This version features a couple of bug fixes, the latest version of ToadicusTools, and a new module to provide action group items for fuel tanks as requested by Scott Manley. As with many of the simpler modules, TweakableFuelPumps is entirely stand alone and may be used without any of the other modules or ToadicusTools. CHANGELOG: v.1.8 [2015-02-05] * New module! TweakableFuelPumps provides Enable, Disable, and Toggle action group items for stock and predictably-stock-alike fuel tank resources. * TweakableRCS: Fixed for proper 0.90 compatibility. * TweakableEngineFairings: Added protection against certain Exception circumstances previously caused by interactions with ProceduralFairings.

I'm glad you're enjoying the mod, PickledTripod! That's what it's here for. Visualization of the various connections is an oft-requested feature. It's on the list of things I'd like to do, but there's some technical obstacles to overcome (read: I tried it once and my solution made the game crash, so apparently I don't know how to do it right ). I'm slammed at work right now, so development time is at a premium, but it's something I'd like to get to sooner rather than later.