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

[rynak]

@Toadicus:

Well, obviously the problem is that some people prefer your GUI over KER, but on the other hand you respect KER having functional dominance in a certain area. Notice room for an "powered by KER"-arrangement?

Anyways, looking forward to the new version.

[Renegrade]

Your request is one I've got several times, and my answer has generally been: I license KER code to do all the engineering calcs. Out of respect for the kindness of cybutek and his team, I am intentionally not competing in a few realms that really make KER what it is, and this is the big one. I know this isn't an answer many of you like to hear, but at this point I continue to feel like it is the right one.

Actually a little question about that - would it be possible to have both installed? If so, are there any caveats people should watch out for?

VOID absolutely dominates in space, but KER definitely still has the upper hand in the VAB...

[toadicus]

@Toadicus:

Well, obviously the problem is that some people prefer your GUI over KER, but on the other hand you respect KER having functional dominance in a certain area. Notice room for an "powered by KER"-arrangement?

Anyways, looking forward to the new version.

I'll think about it. I'm going on vacation this weekend through next Wednesday; I'll see if I can't pick a direction by then, and ask cybutek / let you guys know / whatever next week.

Actually a little question about that - would it be possible to have both installed? If so, are there any caveats people should watch out for?

VOID absolutely dominates in space, but KER definitely still has the upper hand in the VAB...

I haven't ever tested it. I make a few custom tweaks to the KER code I license, but they're pretty minor and don't break the API... so, it's really up to how Squad's assembly loader resolves multiple instances of the same code. It might work well, but it might not. If you test it, I'm sure there's others here who would appreciate hearing your experience.

So, tell you what. Regardless of what I decide regarding providing an editor GUI, going forward I will make sure that VOID and KER will play nicely in the editor. If I can find a "best of both worlds" solution that both cybutek and I are OK with, so much the better.

But none of that will happen before next Wednesday. I might have a little unrelated update before I go, though.

[diomedea]

Actually a little question about that - would it be possible to have both installed? If so, are there any caveats people should watch out for?

...

...

I haven't ever tested it. I make a few custom tweaks to the KER code I license, but they're pretty minor and don't break the API... so, it's really up to how Squad's assembly loader resolves multiple instances of the same code. It might work well, but it might not. If you test it, I'm sure there's others here who would appreciate hearing your experience.

So, tell you what. Regardless of what I decide regarding providing an editor GUI, going forward I will make sure that VOID and KER will play nicely in the editor. If I can find a "best of both worlds" solution that both cybutek and I are OK with, so much the better.

...

I keep installing both VOID and KER alongside with all my main installs, each version of KSP since 0.22 (back to VOID 0.9.17 and KER 0.6.1.4 for sure, possibly even earlier). I never noticed any incompatibility because of them. If any issue exists, it has to be such a minor one that easily isn't spotted. Many other addons show serious issues while running multiple instances of a plugin (so, of the same code); but VOID and KER have always played nice together for me. It's not my call to say if the two instances of KER code are kept apart, or the variables used are perfectly matched; or else: but both seem to always show the same results for anything displayed in both VOID and KER.

To be honest, I never even considered to have two copies of the same code running...(which can only be considered my fault, from a software engineering standpoint ). But then, this brings to one question:

@ toadicus: so I understand KER code is pretty much the same in VOID. Would there be any benefit if VOID could recognize the Engineer.dll is running (from KER), and use that directly instead of creating another instance for the same calculations? (If that is worth the effort, as few kB of data and a few CPU cycles at each time interval may not be enough for a change, unless you like it because of other intrinsic benefits, e.g. to only use the most advanced code available among the two).

[toadicus]

I keep installing both VOID and KER alongside with all my main installs, each version of KSP since 0.22 (back to VOID 0.9.17 and KER 0.6.1.4 for sure, possibly even earlier). I never noticed any incompatibility because of them. If any issue exists, it has to be such a minor one that easily isn't spotted. Many other addons show serious issues while running multiple instances of a plugin (so, of the same code); but VOID and KER have always played nice together for me. It's not my call to say if the two instances of KER code are kept apart, or the variables used are perfectly matched; or else: but both seem to always show the same results for anything displayed in both VOID and KER.

To be honest, I never even considered to have two copies of the same code running...(which can only be considered my fault, from a software engineering standpoint ). But then, this brings to one question:

@ toadicus: so I understand KER code is pretty much the same in VOID. Would there be any benefit if VOID could recognize the Engineer.dll is running (from KER), and use that directly instead of creating another instance for the same calculations? (If that is worth the effort, as few kB of data and a few CPU cycles at each time interval may not be enough for a change, unless you like it because of other intrinsic benefits, e.g. to only use the most advanced code available among the two).

KER compiles all of its goodies into one library. VOID dynamically links to VesselSimulator.dll, which is my compile of just the bits of KER that I use. It's likely that there's no conflict in part because KER's code is all in one assembly: it never goes looking for the classes elsewhere, so there's no opportunity for conflict.

I could probably write a wrapper that would resolve the KER classes I use at runtime and use the KER assembly instead of my compile when I have to. And, if you have big, heavily-modded ships out in flight with VOID up and a KER part attached, that might have some performance benefit. But, in my testing the KER code doesn't really slow things down all that much; KER intentionally throttles itself to avoid running more often than it needs to and to keep load down: if you build a big 3m launcher lifter under a Kerbal X (I call it the Kerbal XX! ) KER still does the whole pass in a <2ms on my machine.

So, at this point, if they're playing nicely together, I'm going to leave that part alone. If someone notices a huge performance hit in the editor when both VOID and KER are installed, I'll think about it, though you could always just disable VOID's engineering calcs in the editor since you're using KER's anway.

[Renegrade]

KER compiles all of its goodies into one library. VOID dynamically links to VesselSimulator.dll, which is my compile of just the bits of KER that I use. It's likely that there's no conflict in part because KER's code is all in one

assembly: it never goes looking for the classes elsewhere, so there's no opportunity for conflict.

So, at this point, if they're playing nicely together, I'm going to leave that part alone. If someone notices a huge performance hit in the editor when both VOID and KER are installed, I'll think about it, though you could always just disable VOID's engineering calcs in the editor since you're using KER's anway.

Ah, if it's entirely separate code then we shouldn't have anything to worry about, that's cool. I had the impression that VOID was actually calling upon like a.. KER.dll or engineer.dll or something that they both had that could end up with version conflicts etc. If that's not the case, we can turn either of them off to recoup any performance loss as you say.

Just one question though - was that 2 milliseconds or microseconds? :S

[Drew Kerman]

I keep installing both VOID and KER alongside with all my main installs, each version of KSP since 0.22 (back to VOID 0.9.17 and KER 0.6.1.4 for sure, possibly even earlier). I never noticed any incompatibility because of them. If any issue exists, it has to be such a minor one that easily isn't spotted. Many other addons show serious issues while running multiple instances of a plugin (so, of the same code); but VOID and KER have always played nice together for me.

Ditto here since .23 - no issues at all. Have not noticed any performance issues either

[Renegrade]

I keep installing both VOID and KER alongside with all my main installs,

Ditto here since .23 - no issues at all. Have not noticed any performance issues either

Thanks, everybody, I'll give it a whirl in dual mode

Actually I just realized there's one tiny area where KER has an advantage in space -- I don't see any way of getting an exact phase angle between my currently controlled ship and another ship..?

[rynak]

Possible regression:

When a target is selected, and the redevouz info windows is enabled, it will at first have only the neccessary height (no space wasted). If one enables extended info, the window becomes taller to accomodate the extra info. However, it then will keep this height - disabling ext info, hiding/showing the rendevouz info window, or even unsetting the target, will not get the window back to its original compact size.

I don't remember this happening before, but i also didn't pay close attention to this in the past. I'd wager a guess though, that this was recently introduced.

[toadicus]

Thanks, everybody, I'll give it a whirl in dual mode

Actually I just realized there's one tiny area where KER has an advantage in space -- I don't see any way of getting an exact phase angle between my currently controlled ship and another ship..?

I think that's available in the rendezvous window when you have the other vessel targeted or selected in the Vessel Register. If it's not, I'll find a spot for it.

Possible regression:

When a target is selected, and the redevouz info windows is enabled, it will at first have only the neccessary height (no space wasted). If one enables extended info, the window becomes taller to accomodate the extra info. However, it then will keep this height - disabling ext info, hiding/showing the rendevouz info window, or even unsetting the target, will not get the window back to its original compact size.

I don't remember this happening before, but i also didn't pay close attention to this in the past. I'd wager a guess though, that this was recently introduced.

That's the same bug I addressed here; it's fixed internally.

[SmiteZero]

I'd just like to say, to make the Data Logging tool more useful I think it needs the ability to customise the CSV fields and needs a latitude and longitude in the output! At very least lat/lon. Please!

[drtedastro]

It would REALLY help if we had some method to customize / edit / alter what is output.. Some kind of ?????.cfg that would let us pick what we wanted, format the output.

Love the mod, need the mod....

thanks.

[toadicus]

VOID has been updated to version 0.14! This is the "quality of life" update I hoped to release before my holiday but didn't. It includes a new Career Status module, fixes to the HUD skin and window resizing, and updated vessel simulation code.

This does not have any changes to the CSV logger. I'll try to work on that before too long.

v.0.14 [2014-08-03]
* NEW MODULE!  VOID_CareerStatus is a nascent module that displays a few vital Career Mode statistics: Funds, Reputation, and Science, including the most change (that happened during this flight session).
* VOID_VesselInfo: Resource mass no longer a combo line.
* VOID_HUD/AdvancedHUD: Fixed an issue where certain changes in the game and other mods would cause the HUD skin to change.
* Now supporting the application launcher with a new button that will be used in lieu of the old standalone button when the Toolbar mod is not present or VOID's Toolbar support is disabled.
* Fixed an issue where modules with "extended" toggles would not reset to their condensed size when the extended data was toggled off.
* Miscellaneous code "improvements."
* Updated underlying VesselSimulator code to the latest from KER & padishar.

[SmiteZero]

...This does not have any changes to the CSV logger. I'll try to work on that before too long.

Excellent. Before Mapsat was developed far enough to feature in-game map displays etc, I wrote my own program to display the data. I'm really interested to dig back in and modify it to display a 3d point map of the datapoints for mapping of magnetospheres, etc. (Unless someone is going to burst my bubble and say that the magnetospheres are pretty boring to look at).

https://dl.dropboxusercontent.com/u/19231999/ISA_Kartographer_Topo_0.png

(zoomable & scrollable map, polar ortho views, custom markers...)

Thing is, to map the data correctly, of course one needs to know where it should be put on the map. Unfortunately the data collected right now in the data logger isn't able to give that crucial info. Really it's just missing a latitude and longitude for this purpose.

Edited August 6, 2014 by SmiteZero

[diomedea]

VOID has been updated to version 0.14! This is the "quality of life" update I hoped to release before my holiday but didn't. It includes a new Career Status module, fixes to the HUD skin and window resizing, and updated vessel simulation code.

Nice improvements, as always . So much to make me give KSP 0.24.2 a go just to see VOID 0.14 in action (still playing on 0.23.5, and can't port my main game to 0.24.2 due to some required mod in it "breaking game" with the new version).

[Renegrade]

Uhoh - I'm tracking down some random freeziness with my various installs, and it seems like it MAY be VOID related (problem is intermittent so hard to isolate and playing for extended time without VOID is incredibly painful :/ )

The symptom is that upon loading ships in the VAB/launching them (either VAB or Launchpad style)/early staging events, KSP itself freezes and stops responding.

Removing VOID seems to clear up the issue.

Platform: ia32 / x86 / 32-bit KSP 0.24.2 on WinNT 6.1 64-bit.

VOID: 0.13 and 0.14 seem to share this issue. KER calculations enabled.

The only thing of note is that when it DOESN'T lock up, I see this in output_log: [VOID_HUDAdvanced]: ArgumentException caught during window call.

(when a lockup happens, the log isn't updated with current events :/ )

It seems to be related to any ship I build that's kinda .. SRB-happy (multi-stage pure-SRB designs, with a single decoupler in between stages).

I'm investigating further, but I thought I'd make a preliminary report.

[Drew Kerman]

hrm, interesting. I've had a few lockups recently as well heading out to the pad from the VAB, or reloading a flight to the launch. I really should have a look at what the logs say afterwards...

[toadicus]

Nice improvements, as always . So much to make me give KSP 0.24.2 a go just to see VOID 0.14 in action (still playing on 0.23.5, and can't port my main game to 0.24.2 due to some required mod in it "breaking game" with the new version).

Thanks!

Uhoh - I'm tracking down some random freeziness with my various installs, and it seems like it MAY be VOID related (problem is intermittent so hard to isolate and playing for extended time without VOID is incredibly painful :/ )

The symptom is that upon loading ships in the VAB/launching them (either VAB or Launchpad style)/early staging events, KSP itself freezes and stops responding.

Removing VOID seems to clear up the issue.

Platform: ia32 / x86 / 32-bit KSP 0.24.2 on WinNT 6.1 64-bit.

VOID: 0.13 and 0.14 seem to share this issue. KER calculations enabled.

The only thing of note is that when it DOESN'T lock up, I see this in output_log: [VOID_HUDAdvanced]: ArgumentException caught during window call.

(when a lockup happens, the log isn't updated with current events :/ )

It seems to be related to any ship I build that's kinda .. SRB-happy (multi-stage pure-SRB designs, with a single decoupler in between stages).

I'm investigating further, but I thought I'd make a preliminary report.

hrm, interesting. I've had a few lockups recently as well heading out to the pad from the VAB, or reloading a flight to the launch. I really should have a look at what the logs say afterwards...

That VOID_HUDAdvanced log entry is not actually a problem: it's a handled exception that I couldn't clean up any other way. For reasons which escape me, VOID_HUDAdvanced winds up changing GUILayout things in a way that Unity does not expect, in the very first frame of a flight scene. None of the other modules have the issue -- VOID_HUD doesn't have the issue, and the modules are fundamentally identical -- so for want of a solution I'm just catching the Exception and letting everybody go about their business. It doesn't interrupt anything (except that first frame of VOID_HUDAdvanced), and unless Unity or KSP have some really, really funny ideas about Exception handling, basically could not be responsible for the crashing. If you ask around, everyone, everywhere with VOID installed will get that message when they open up a flight.

I'm not going to say VOID or the KER code can't be implicated in your crashes, but considering what VOID/KER do (GUI elements) and how they do it (maths), the odds seem pretty low. That said, I'm very interested to hear where your investigation leads.

[Renegrade]

It doesn't interrupt anything (except that first frame of VOID_HUDAdvanced), and unless Unity or KSP have some really, really funny ideas about Exception handling, basically could not be responsible for the crashing. If you ask around, everyone, everywhere with VOID installed will get that message when they open up a flight.

KSP and Unity could very well have strange ideas about exception handling - they seem to have strange ideas about other things

Note that the process isn't actually crashing, it just locks up and fails to respond to WM_ messages from Windohs. Like as if it's stuck in a busy loop or it's iterating over an internal structure that isn't supposed to loop back on itself but does etc etc.

I'm not going to say VOID or the KER code can't be implicated in your crashes, but considering what VOID/KER do (GUI elements) and how they do it (maths), the odds seem pretty low. That said, I'm very interested to hear where your investigation leads.

I'm trying to recreate the scenario with a purely stock ship to make for easier diagnostics - no luck so far. Err, actually, scratch that, something did just happen (like, right there..)!

One of my two-stage SRB based ships caused a staging-based lockup, and just prior to launch I had this (which does not normally appear in the log):

Exception in StartSimulation: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

  at System.Collections.Generic.Dictionary`2[System.UInt32,System.Collections.Generic.List`1[ModuleEngines]].get_Item (UInt32 key) [0x00000] in <filename unknown>:0 
  at ModuleDB.ModuleDB`1[ModuleEngines].getModules (.Part part) [0x00000] in <filename unknown>:0 
  at ModuleDB.ModuleDB`1[ModuleEngines].getModules (System.Object obj) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at ToadicusTools.ModuleDB`1[ModuleEngines].getModules (.Part part) [0x00000] in <filename unknown>:0 
  at ToadicusTools.Tools.getModulesOfType[ModuleEngines] (.Part part) [0x00000] in <filename unknown>:0 
  at Engineer.Extensions.PartExtensions.GetModules[ModuleEngines] (.Part part) [0x00000] in <filename unknown>:0 
  at Engineer.VesselSimulator.PartSim.CreateEngineSims (System.Collections.Generic.List`1 allEngines, Double atmosphere, Double velocity, Boolean vectoredThrust, Engineer.LogMsg log) [0x00000] in <filename unknown>:0 
  at Engineer.VesselSimulator.Simulation.PrepareSimulation (System.Collections.Generic.List`1 parts, Double theGravity, Double theAtmosphere, Double theVelocity, Boolean dumpTree, Boolean vectoredThrust) [0x00000] in <filename unknown>:0 
  at Engineer.VesselSimulator.SimManager.StartSimulation () [0x00000] in <filename unknown>:0 

Note that that happened somewhat before the crash. I've zipped up (alternatively 7zipped up) the craft (just in case), the KSP.log, and KSP_Data\output_log.txt, in the event that any are helpful.

EDIT: The situation was that I had launched the unmanned R5 Rescue II craft, but Bill decided that sitting around in the lounge watching TV was boring and hopped in. I didn't notice until after I'd launched, so I reverted, removed him, relaunched, burned out the first SRB and then stage-and-uhhh frozen. Restarting and trying a launch again resulted in KSP using up 98% CPU...

EDIT2: The same craft doesn't seem to have any problem in a totally pure stock KSP install. Well any problem other than that the stock UI is terrible info-wise.

I did notice something interesting though - the VOID icon for the built-in toolbar (err.. do they call it the 'app launcher'?) replicates itself over time in the VAB interface. Only the leftmost one seems to operate. I didn't notice that previously as I usually assign it to Blizzy's toolbar, where that doesn't happen (Blizzy's bar might look a little out of place compared to the rest of the stock UI, but it's a lot better..).

Another thing is that VOID 0.14 claims to be 0.13 in it's UI. Somehow I doubt that's causing any problems though hehe.

EDIT3: Turning off the KER portions alleviates the lockup problem it seems, although that causes this (it starts right after a maneuver node is placed, presumably relating to the burn calculations for the advanced HUD):

ArithmeticException: NAN
  at System.Math.Sign (Double value) [0x00000] in <filename unknown>:0 
  at VOID.VOID_Data.<burnTimeHalfDoneAtNode>m__3E () [0x00000] in <filename unknown>:0 
  at VOID.VOID_DataValue`1[T].Refresh () [0x00000] in <filename unknown>:0 
  at VOID.VOID_DataValue`1[T].get_Value () [0x00000] in <filename unknown>:0 
  at VOID.VOID_HUDAdvanced.rightHUDWindow (Int32 id) [0x00000] in <filename unknown>:0 
  at VOID.VOID_Tools+<GetWindowHandler>c__AnonStorey0.<>m__0 (Int32 id) [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)

It doesn't cause any direct harm, but it does fill up the log rather quick

Edited August 14, 2014 by Renegrade

[Jacke]

I appear be getting this too, as after coming back to KSP / BTSM last week and starting with 0.24.2 I've had a lot more crashes that in 0.23,5, mostly of the type Renegrade has: freezing while switching scenes, loading quicksaves, and massive parts changes upon first staging in a flight. I use both KER and VOID among my mods, but I disable the VOID advanced HUD with its config.

I haven't tracked down the logs to see if they had anything helpful, but I'll do that next time it occurs (should be soon). I did install the latest AdvancedTextureManagement and it seems to help, its Basic version almost better than its Aggressive one. Which points to it not just being a memory growth issue but sometime else affected by the differences caused by the different graphic features memory footprint.

EDIT: And here's the link to the 7zip of KSP.log and output.txt from the next crash. Skimmed them but not familiar enough with them to catch anything. Hopefully they'll be helpful to you.

Edited August 14, 2014 by Jacke

[Renegrade]

I appear be getting this too, as after coming back to KSP / BTSM last week and starting with 0.24.2 I've had a lot more crashes that in 0.23,5, mostly of the type Renegrade has: freezing while switching scenes, loading quicksaves, and massive parts changes upon first staging in a flight. I use both KER and VOID among my mods, but I disable the VOID advanced HUD with its config.

I've found that if you turn off all KER parts of VOID, the crashes stop, FYI (it's actually up there in my post before, but that thing has become a horrible wall of text). VOID itself seems fine, it's just something to do with the KER calculations it does. The advanced hud spams the logs with the KER calculations off, but you have that turned off anyways (which cures the spam)

I've paired it up with KER 1.0.5 now and I'm using KER for dv-related info and VOID for orbit/altitude related info. Hopefully it's an easy fix though; I really like the VOID HUDs better than KER's window whilst flying.

[Padishar]

There appear to be a few issues with how the KER simulation code is integrated into VOID. I will talk to toadicus and help him resolve these.

[toadicus]

I've made a bit of progress independently last night, and am talking with padishar today; I'm slammed at work and won't be able to code here today, but hopefully we'll find a resolution this weekend.

[Renegrade]

There appear to be a few issues with how the KER simulation code is integrated into VOID. I will talk to toadicus and help him resolve these.

Ah, excellent, thanks Padishar!

The new 1.x series of KER is quite nice, by the way. The new configurability is quite good, and my VAB is more productive than ever with that overlay and enhanced stage view. The partless option is nice too.

I've made a bit of progress independently last night, and am talking with padishar today; I'm slammed at work and won't be able to code here today, but hopefully we'll find a resolution this weekend.

I know that feeling

I've found a stable combination so it's not some dire emergency. Thanks for your help, BOTH of you

(and sorry for my horrible wall-of-text messy post heh... )

[Jacke]

There appear to be a few issues with how the KER simulation code is integrated into VOID. I will talk to toadicus and help him resolve these.

I've made a bit of progress independently last night, and am talking with padishar today; I'm slammed at work and won't be able to code here today, but hopefully we'll find a resolution this weekend.

Thanks, guys! I really appreciate this.

I've found that if you turn off all KER parts of VOID, the crashes stop, FYI (it's actually up there in my post before, but that thing has become a horrible wall of text). VOID itself seems fine, it's just something to do with the KER calculations it does. The advanced hud spams the logs with the KER calculations off, but you have that turned off anyways (which cures the spam)

I've paired it up with KER 1.0.5 now and I'm using KER for dv-related info and VOID for orbit/altitude related info. Hopefully it's an easy fix though; I really like the VOID HUDs better than KER's window whilst flying.

By turning off all KER parts of VOID, I take it you mean turning off the entry "Enable Engineering Calculations" in VOID Configuration, correct? For both flight and VAB. I'll try that as I have access to delta-V info from KER and MJ2 during build and flight. It effectively disables the VOID build HUD, which was useful, but I can add in Parts Count to the MJ2 Vessel window and have it all.

And this might have done it. Just after I turned off both, I went to Launch from the VAB and it paused (giving a Windows not responding on the Task Manager in my gaming laptops panel; I use an external monitor for KSP)--but didn't lock up and came back.

Aside: I use all 3 engineering info mods: VOID for the original HUD, KER for the Build Engineer, and MJ2 for everything, build info, and a lot of windows and custom windows for flight. I have used KER more in flight in the past (wrote a MM script to make it partless before it was standard on the mod) and may do so again.

Edited August 15, 2014 by Jacke