[1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)

[Wyzard]

I notice that the 1.8 update of KER includes a subdirectory called "temp", containing some settings XML files.  Is that intentional?

[jrbudda]

7 hours ago, Wyzard said:

I notice that the 1.8 update of KER includes a subdirectory called "temp", containing some settings XML files.  Is that intentional?

nope, oops

[Wyzard]

Speaking of settings XML files, here's an oddity.  Using KER 1.1.6.0 in KSP 1.7.3, I tried to open the KER settings in the VAB, but when I clicked the settings button, the KER window disappeared except for a tiny gray square near the top-left of where the settings window should've been.  I figured it might be something wrong with the settings files, so I moved my whole Settings directory aside to make KER regenerate the defaults, which fixed the problem.  Then I tested moving individual files back to see which one made the problem reappear.  It turns out that the problem was caused by having this in my GeneralSettings.xml file:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfSettingItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SettingItem>
    <Name>FlightAppLauncher_IsHoverActivated</Name>
    <Value xsi:type="ArrayOfXmlNode">
      <XmlNode xsi:type="ArrayOfXmlNode" />
      <XmlNode>
        <XmlNode xsi:type="ArrayOfXmlNode" />
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode xsi:type="ArrayOfXmlNode" />
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode xsi:type="ArrayOfXmlNode" />
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode xsi:type="ArrayOfXmlNode" />
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode xsi:type="ArrayOfXmlNode" />
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode>
                  <XmlNode xsi:type="ArrayOfXmlNode" />
                </XmlNode>
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode>
                  <XmlNode>
                    <XmlNode xsi:type="ArrayOfXmlNode" />
                  </XmlNode>
                </XmlNode>
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
    </Value>
  </SettingItem>
</ArrayOfSettingItem>

So, a weird bogus value for the FlightAppLauncher_IsHoverActivated setting.

Notably, the reason why I wanted to open the KER settings in the first place was to check on that option, because it had stopped doing the "hover activated" thing a few days ago when I accidentally clicked the Revert button in KSP's own settings (the screen you get to from the game's main menu).  I thought maybe the "hover activated" option value was somehow stored in KSP's settings data instead of KER's, and that my revert had changed it back to its default.  Instead, it appears that reverting the KSP settings may have somehow corrupted this KER setting.

Edit:  Actually, it might not be the KSP settings revert that did it.  When 1.8 came out, Steam updated my installation, and I launched it just to see how much would work (since most previous game updates haven't broken lots of stuff).  It turned out that I couldn't even click on stuff at the game's main menu, so I quit with Alt-F4 and told Steam to revert back to 1.7.3.  I didn't load my save or enter the VAB or even the space center in 1.8, but if KER does any writing to its settings files as part of just booting the game, that could be what did it.

Edited October 19, 2019 by Wyzard

[jrbudda]

6 hours ago, Wyzard said:

Speaking of settings XML files, here's an oddity.  Using KER 1.1.6.0 in KSP 1.7.3, I tried to open the KER settings in the VAB, but when I clicked the settings button, the KER window disappeared except for a tiny gray square near the top-left of where the settings window should've been.  I figured it might be something wrong with the settings files, so I moved my whole Settings directory aside to make KER regenerate the defaults, which fixed the problem.  Then I tested moving individual files back to see which one made the problem reappear.  It turns out that the problem was caused by having this in my GeneralSettings.xml file:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfSettingItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SettingItem>
    <Name>FlightAppLauncher_IsHoverActivated</Name>
    <Value xsi:type="ArrayOfXmlNode">
      <XmlNode xsi:type="ArrayOfXmlNode" />
      <XmlNode>
        <XmlNode xsi:type="ArrayOfXmlNode" />
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode xsi:type="ArrayOfXmlNode" />
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode xsi:type="ArrayOfXmlNode" />
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode xsi:type="ArrayOfXmlNode" />
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode xsi:type="ArrayOfXmlNode" />
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode>
                  <XmlNode xsi:type="ArrayOfXmlNode" />
                </XmlNode>
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
      <XmlNode>
        <XmlNode>
          <XmlNode>
            <XmlNode>
              <XmlNode>
                <XmlNode>
                  <XmlNode>
                    <XmlNode xsi:type="ArrayOfXmlNode" />
                  </XmlNode>
                </XmlNode>
              </XmlNode>
            </XmlNode>
          </XmlNode>
        </XmlNode>
      </XmlNode>
    </Value>
  </SettingItem>
</ArrayOfSettingItem>

So, a weird bogus value for the FlightAppLauncher_IsHoverActivated setting.

Notably, the reason why I wanted to open the KER settings in the first place was to check on that option, because it had stopped doing the "hover activated" thing a few days ago when I accidentally clicked the Revert button in KSP's own settings (the screen you get to from the game's main menu).  I thought maybe the "hover activated" option value was somehow stored in KSP's settings data instead of KER's, and that my revert had changed it back to its default.  Instead, it appears that reverting the KSP settings may have somehow corrupted this KER setting.

Edit:  Actually, it might not be the KSP settings revert that did it.  When 1.8 came out, Steam updated my installation, and I launched it just to see how much would work (since most previous game updates haven't broken lots of stuff).  It turned out that I couldn't even click on stuff at the game's main menu, so I quit with Alt-F4 and told Steam to revert back to 1.7.3.  I didn't load my save or enter the VAB or even the space center in 1.8, but if KER does any writing to its settings files as part of just booting the game, that could be what did it.

Ya this is what the majority of my time updating was spent on: fixing the XML serialization issues.

[Azzinoth]

Hello @jrbudda,

Thanks for developing and maintaining this mod. I have a small request: Would it be possible to add readouts for accumulated delta V losses due to drag and gravity? Gravity losses can be calculated by summing up dV=g-v^2/r dt every timestep. Drag losses by summing up dV=F_drag/m*dt.

It would be really useful for optimizing my ascent for efficiency.

Edited October 23, 2019 by Azzinoth

[DerGolgo]

@jrbuddaThank you thank you thank you!

I hadn't actually been following this thread and had just kept using the last version of Kerbal Engineer that had been released through the more official channels.
Then, after updating to 1.8, I found the editor unusable. Either with or without Engineer.

You're a lifesaver, man! I'll be following this from now on!

[Azalen]

Is there any reason why the updated version for 1.8 from jrbudda is not on CKAN?

[Brigadier]

1 hour ago, Azalen said:

Is there any reason why the updated version for 1.8 from jrbudda is not on CKAN?

I see KER v1.1.7.1 for KSP 1.8.0 to 1.8.9.  Are you allowing CKAN to see KSP 1.8 mods as compatible?

Edited November 6, 2019 by Brigadier
Corrected a version number

[nwillard]

I don't see it either for some reason, marked 1.8 and 1.8.1 and the latest version as compatible.

[Jognt]

Just to make sure: Are you looking for “KER” or “Kerbal Engineer Redux”?

[linuxgurugamer]

@cybutek

KER 1.1.7.1, in a 1.8.1 game

Getting the following errors:

ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null
 
ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null

Quick n dirty solution is to rename the KerbalEngineer.Unity.dll to +KerbalEngineer.Unity.dll

Better solution is to add the following to the AssemblyInfo.cs:

[assembly: KSPAssemblyDependency("KerbalEngineer.Unity", 1, 0)]

 

Edited November 16, 2019 by linuxgurugamer

[micha]

On 11/16/2019 at 10:11 AM, linuxgurugamer said:

Better solution is to add the following to the AssemblyInfo.cs:

[assembly: KSPAssemblyDependency("KerbalEngineer.Unity", 1, 0)]

 

THANK YOU! I've been seeing dozens of similar issues all over the place and haven't figured out how to fix it despite spending quite some time with Mr Google.

[linuxgurugamer]

3 hours ago, micha said:

On 11/15/2019 at 8:11 PM, linuxgurugamer said:

Better solution is to add the following to the AssemblyInfo.cs:

[assembly: KSPAssemblyDependency("KerbalEngineer.Unity", 1, 0)]

 

THANK YOU! I've been seeing dozens of similar issues all over the place and haven't figured out how to fix it despite spending quite some time with Mr Google.

Yes, this really needs to get communicated to all modders.  Using directory sorting is not cool.

[Hotel26]

Love KER and is one of a very small set of Core must-have mods.

There was a feature that operated in KSP 1.3.1 that has been u/s ever since, which is the Target distance read-out when you are sitting on the launchpad.

I would say this depended upon some method in KSP itself that abandoned the facility.  I.e. target distance is now shown to be 0.0 WHEN you are landed.  Too bad, because this is incredibly convenient for knowing when to launch from the pad.  A distance of something like 383kms indicated the target was uprange over about the tip of the western desert sub-continent.  The alternative I have been using is to place the launch vehicle on the pad; then switch to the target vehicle and ride with it visually confirming its approach; then switching back to the pad and launching.  The context switches are painful and contribute to memory leak, hastening a KSP reboot.  Lately, I've tried to gauge this from the position of the target marker on the  navball and have found this to be wildly inaccurate.

Is there an alternative KER metaphor now?  Or can the original capability please be restored?  Has anyone else noticed this lapse?

Edited November 23, 2019 by Hotel26

[dok_377]

@jrbudda Can this be addressed? The landing marker renders behind KSC buildings, making it invisible. This can be very annoying when you try to land the first stage of your rocket. Previously I was using Trajectories, but for whatever reason it refuses to work normally for me in 1.8.

Edited November 29, 2019 by dok_377

[RoboRay]

On 11/22/2019 at 9:26 PM, Hotel26 said:

target distance is now shown to be 0.0 WHEN you are landed.  Too bad, because this is incredibly convenient for knowing when to launch from the pad.  A distance of something like 383kms indicated the target was uprange over about the tip of the western desert sub-continent. 

I use Phase Angle to Target for this.  I launch when the phase angle is 340 degrees (target is 20 degrees west of the launch pad) and I usually reach Ap no more than 100 km behind the target.  I don't completely circularize, just bring Pe up out of the atmosphere then continue easing Pe upward until I get a close rendezvous on the next orbit.

Edited November 30, 2019 by RoboRay

[Hotel26]

7 hours ago, RoboRay said:

I use Phase Angle to Target for this.

Very good tip and I will try it out.  Thank you.  I'll select a phase angle that is equivalent to 383kms.  Because..........  and this is the tip @Atkara gave me....

If you raise your AP after launch to the altitude of the target, e.g. 90kms, you should get a rendez-vous prediction open up (from e.g. Better Burn Time) and you can then tune it.  Then forget about circularization by going Target Retrograde and cancelling relative velocity when you are closest to the target.  The result is instant rendez-vous straight out of launch with a separation typically around 2kms.  Think about how much that shaves off Mission Control payroll...  (It's enough to pay for year-round junkets for the Top Brass at KSC.  )

If I miss the window, I'll open KAC Closest Approach and tune the number manually in real-time for a rendez-vous down-range.

Edited November 30, 2019 by Hotel26

[razark]

1 hour ago, Hotel26 said:

I'll open KAC Closest Approach and tune the number manually in real-time for a rendez-vous down-range.

That's what I generally use to get a close encounter within ten or twenty meters.

I'll have to try the phase angle thing, though.

[Hotel26]

6 hours ago, razark said:

the phase angle

I was happier with Target Distance, when it worked, because it's in my HUD and is useful elsewhere.  (I won't be putting Target Phase in my HUD (because: "clutter").)  Still a good work-around.

Important to note that 2km is pretty good straight off the ascent especially as most of that will be unavoidable inclination incurred on the hell-ride to space.  With a closing speed in excess of 1km/sec, slightly less precision is acceptable, too.

Riding with my Pole Star space station, I can report that the nominal Phase Angle desired is 328 degrees.  (Arguably phase angle is better than distance as it doesn't depend upon altitude, but then...  your ascent time will vary, with altitude, too.)

So to amplify my description in my previous, the launch time from the rule-of-thumb is going to work best for a particular ascent-duration-to-target-altitude, but your actual ascent time will vary by vehicle & payload.  However, pretty early during the ascent (after the gravity turn has commenced), KAC C/Approach should be showing a predicted closest arrival (make sure it's showing Orbit 1).  Tune this to the minimum and, if it is within 10km (it should be)), Better Burn Time should start indicating time until firing Target Retrograde (= circularization!).  A 3-step procedure.  That's pretty immediate/precise but don't expect much better than however well your launch inclination has "matched" the target.

UPDATE: just ran a highly successful test with a heavy lifter.  The 328 deg phase angle (32) is based on latitude of southern tip of the western peninsula (106W) and KSC (74W).  Immediately after the vehicle left the pad, Target Distance began reading just above 383km...

Edited November 30, 2019 by Hotel26

[Hotel26]

7 hours ago, RoboRay said:

the phase angle is 340 degrees (target is 20 degrees west of the launch pad) and I usually reach Ap no more than 100 km behind the target

My estimate of 328 degrees (12 deg different) now suggesting why you are may be lagging your target?

Edited November 30, 2019 by Hotel26

[RoboRay]

On 11/29/2019 at 10:14 PM, Hotel26 said:

My estimate of 328 degrees (12 deg different) now suggesting why you are may be lagging your target?

I lag my target on purpose to ensure I never reach Ap ahead of it.  This way, I can maximize fuel efficiency with the "once around" rendezvous technique I described above.  I burn only as much propellant as I would use to circularize normally, with none wasted pushing my Ap higher to enter a slower orbit and drop back to a target behind me.  (Or waste time having to wait a lot of orbits for my phasing to cycle all the way around the planet and catch up to the target the long way around.)   

Trying to launch directly to rendezvous requires perfect timing and ascent profile, and usually some additional propellant expended on corrections, which is why we don't try to do it in the real world.  Soyuz flights to the ISS used to do a similar but longer, three-orbit approach to rendezvous, but started doing once-around just a couple of years ago.

On 11/29/2019 at 10:03 PM, Hotel26 said:

I was happier with Target Distance, when it worked, because it's in my HUD and is useful elsewhere.  (I won't be putting Target Phase in my HUD (because: "clutter").)  Still a good work-around.

I have Phase Angle in my "Target Info HUD" (everything in it hides itself when I don't have a target selected for automatic decluttering) and find it useful for all kinds of things, not just launches.  YMMV, but I find it a really critical parameter in understanding situational awareness of your positional relationship with your target.

Edited December 1, 2019 by RoboRay

[DeadJohn]

I noticed a discrepancy in my reported DeltaV and TWR. KER says one set of values while the default KSP display says something else. I also noticed that the KER suicide burn estimates are less reliable than normal.

This is only happening with one lander already in flight. Screenshot and log file are linked below. Data from the screen shot:

• DV
  • KER = 5648 m/s
  • KSP = 3857 m/s
• TWR
  • KER = 4.72
  • KSP = 3.88

The problem does not seem to be widespread. Other ships in flight seem okay. The craft with the problem seems okay if I look in VAB; KER and KSP agree there. I also copied the lander to a new sandbox save, cheated it into orbit, and KER and KSP agree on the DV in flight.

Further testing with Hyperedit shows that as I add and remove ablator and monoprop, KER refreshes the new mass, TWR, and acceleration. The DV does not change, though, unless I change the Liquid Fuel or Oxidizer amount.

Any idea what's happening here? Is this an obscure KER bug, corrupted savefile, or something else?

I'm using KER 1.1.6 under KSP 1.7.3. Mods include the JNSQ planet pack; that's a 2.7x sized system.  The ship with the problem uses parts from Blue Dog Design Bureau.

Log file: https://drive.google.com/open?id=1m3H64R_VIKoXeyIN-F-FFf8UzQ23Af-G

Screen shot: https://drive.google.com/open?id=1YmvhkKDvP1D8MSY5Vdn7mukLs0T1bSLa

 

[Einarr]

Using the latest build I have GUI issues with the darkened backgrounds vanishing, particularly in the editors, specifically for the pull up resources and veseel info panels (usually located along the bottom of the editor window). From just starting KSP up and loading my savegame, I can pop into an editor and do whatever I want, make or edit as many craft as I want, but the moment I leave the editor (to launch something, for example) the problem shows up. Returning to the editor, and the dark translucent background used for those pull up windows, or for the middle click part info windows is entirely transparent, making the white text difficult to read depending on camera position/angle.

I seem to recall Science Alert having a similar issue just after it's initial 1.8 update as well.

[Folkhoer]

Can you add "time till encounter"? Because I really can't seem to find it.
I mean when you are, for example, going to Minmus and are waiting till the gravity grabs you.

[Stone Blue]

@jrbudda Not sure if you are still around, but tagging you as an FYI on this post by LGG... Might be something for you to look at if you continue to provide updates. vOv
THANX for what you've done so far