[1.2] VOID 1.1.0-beta - Vessel Orbital Informational Display

[Drew Kerman]

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.

Pe/Ap altitude, yes - exactly what the orbital stats window shows. Fuel ratio is trickier than I actually thought. For now, forget about that until I figure out exactly how I want to do that. For example the first launch I "tracked" with telemetry updates I displayed the fuel as what remained in the current stage, and the second launch I tracked (so far just two) I displayed the current level of total fuel for that resource. Still not sure which I like better.

FAR integration is out of scope for this update, but coming in the not-too-distant future.

cool

Also, the units settings are still randomly going whacky on me and not staying to what I set them last. Last launch I had downrange distance set to km on the pad and as soon as I launched it started displaying millimeters

[seyss]

toadicus, this bug only happens when I run the x64 version of KSP...

[toadicus]

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.

Edited February 14, 2015 by toadicus
Added discussion about data logger values.

[seyss]

Yes everything works on 32-bit. Too bad they're dropping x64 cuz it runs significantly faster here. Thanks!

[Drew Kerman]

The issue is that the value you pick is relative.

I'll be honest I don't really get the reasoning behind that. The point of being able to pick your measurement unit I thought was so you (as in you the developer) didn't have to worry about relative behavior. Seems like VOID is trying to show me the best unit for a given situation and I'm fine just setting them myself as needed for my situation.

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.

thanks! Distance traveled equivalency would be to what you get from a mid like Persistent Trails that tracks your crafts actual distance along its route of travel. Not completely sure if that's what the F3 window shows

[toadicus]

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.

[Drew Kerman]

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.

No biggie. Persistent Trails does a good job in the meanwhile.

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.

It's primarily this. And really it's Surface Velocity, Vertical Speed and Horizontal Speed that I keep having to reset for some reason. I agree with your reasoning behind the current system now that I understand it better (I did not intuitively understand it, to be honest) it's just annoying to click and reset the numbers to a measurement I'm more comfortable with every now and then when I could have sworn I set it last time

[toadicus]

And really it's Surface Velocity, Vertical Speed and Horizontal Speed that I keep having to reset for some reason.

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

[Drew Kerman]

it's really only been a pain during launches so I will try to remember to keep an eye on it next time. Also in general just to see how it's behaving.

[DaPatman]

I have a bug regarding the interaction between VOID and Blizzy's toolbar I've been meaning to tell you about for several months, but tonight I finally got around to creating a fresh copy of KSP so I could get you a clean log:

KSP: 0.90 Windows 32bit

Problem: After telling Blizzy's toolbar to display the VOID button in the VAB/SPH, the button disappears from it on subsequent visits to either building.

Mods installed:

Toolbar 1.7.8

VOID 0.16.4

Reproduction steps:

1. On a save where Blizzy's toolbar is not configured to display the VOID button in the VAB/SPH, enter one of these buildings.

2. Click on the Command Pod Mk1.

3. Make sure VOID is configured to use Blizzy's toolbar.

4. On Blizzy's toolbar, click on "Configure visible buttons" and select the VOID button. The VOID button should now appear on Blizzy's toolbar.

5. Click on Launch.

6. Revert to VAB/SPH. The VOID button no longer appears on Blizzy's toolbar and cannot be added back to it.

Visual representation of the above steps:

Javascript is disabled. View full album

Log: output_log.txt

[toadicus]

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!

[toadicus]

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.

[Drew Kerman]

Surface Info window is borked. Output log.

Everytime a new version comes out I delete the old one after copying it to an Outdated folder. So this new version was working initially, because I was able to move the window to the portion of my screen where I normally put it. But then when I loaded up onto an uncontrolled asteroid it blanked out and lost its close button and I couldn't re-position it. So I deleted ToadicusTools and VOID folders and re-installed from the dev zip above. The Surface window now shows up already borked, and I can't move it off from atop the resource panel where it appears by default

[toadicus]

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.

Edited February 25, 2015 by toadicus
To infinity, and beyond!

[Drew Kerman]

Thanks, that fixed it, surface window is back up and operational.

I know the log file is filled with exceptions. If I had the time, I'd chase them all down but as it is I can't do anything until they impede my gameplay. For all the exceptions that get thrown KerbCam works fine, as does Haystack, AutoSave, etc

[toadicus]

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.

[Shania_L]

Does this mean that VOID will now calculate Thrust/Weight ratio and Dv correctly in atmosphere, due to variable engine ISP?

[toadicus]

Does this mean that VOID will now calculate Thrust/Weight ratio and Dv correctly in atmosphere, due to variable engine ISP?

In the editor, that is what this line means:

* VOID_StageInfo: Added an option to use sea-level values when relevant while in the editor.

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.

[toadicus]

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

[Drew Kerman]

veeeryyy interesting! Look forward to seeing more examples of what we can do with this.

[damerell]

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).

I have circa 150,000 entries in persistent.sfs of this form:

CURRENCY_TRANSACTION
                {
                        reason = ScienceTransmission
                        fundingDelta = -7.174909E-06
                        scienceDelta = -2.011657E-07
                        reputationDelta = 0
                        timeStamp = 2740906.0948175
                }

From the number, the recent RAM issues I've been having, and the tiny Delta amounts involved, I suspect some sort of "sorceror's apprentice" mode is multiplying these every time the save is loaded.

I don't know if other people are affected. I used to use the "Sane Strategies" mod, which gives regressive gains at higher commitments - that might be what makes me unusual. But I suspect there's a bug at work here.

[damerell]

I have circa 150,000 entries in persistent.sfs of this form:

It turns out to be (sigh) a bit more complicated than that. Something _else_ carries out these transactions on vessel load, over and over again, several a second. VOID unfortunately exacerbates the situation by faithfully recording them, causing persistent.sfs to grow without limit.

So, sorry for the initial assessment being wrong. I suggest VOID should decline to record entries where all three Deltas are lower than some small value and/or throttle the rate at which transactions are being recorded.

(FWIW, if anyone else is having the same problem and Google-chasing it, it's not Sane Strategies, but completely removing currency conversion strategies does put a stop to it, as one might expect. I now suspect ScienceLibrary...)

[toadicus]

Thanks for the report anyways, damerell. I'm absolutely buried in my day job, but when I am able to come up for air I'll try to implement a throttle so that if many similar transactions come in within an impossibly short period of time, VOID will rate limit them into a single transaction.

[Drew Kerman]

two things to report from my latest launch. First, an apparent discrepancy in time:

And second when I opened the CSV in Excel there are two column headers missing. Apoapsis column header is there, but I don't see Periapsis

Edit: additionally still see incorrect numbers for total resource mass. Check my math:

((57.18+69.88)*.005)+(100*.004)=1.0353t

There are no other resources besides waste heat that are hidden from view. Stage resource mass is correct, there is a decoupler between the LF/O and MP tanks

Edited March 10, 2015 by Gaiiden

[toadicus]

Gaiiden, are you using Earth Time or Kerbin Time in your KSP settings? I know I have a couple of inconsistencies versus KSP's numbers (somewhat intentionally; we've discussed it before), but I'll take another thorough look at it once I know what you're looking at.

I don't see that I'm missing any column headers, but I did have Orbital Velocity in the wrong place, which would have had three of the headers looking obviously wrong. I'll test it more thoroughly as soon as I get a chance.

I'll take another look at the resource masses. It's all in KER's code, so it takes some extra doing on my part, but I'll try to get to it soon.

In general, sorry I haven't been as consistent as usual lately. I've been working a whole lot, and there are something like 6 family birthdays in Feb and March, so my weekends have been busier than usual themselves. I also bought Crusader Kings II... so there's that. I'm trying to get my schedule back in order and hope to be more responsive in the near future.