drhay53

I installed straight from github, two different times before posting. But, I was just allowing the files to be overwritten instead of wiping out the full DSEV folder. This time I wiped out the whole DSEV folder and re-installed, and it seems to be working correctly. Generally I don't wipe out mod folders willy-nilly because some of them store settings in there and I've screwed myself over that way before. I probably should have realized with the deprecated parts and texturing changes that a fresh install would have solved this one.

Strange. I installed and then re-installed from the github release, and copied over the craft files. Even if you click "previous variant" you never get to an invisible texture? DSEV.version is 2.3, WBITools.version is 1.27 In the Debug Console, when I click "Prev variant" to get to the invisible texture, I do get an Exception (pulled from output_log.txt):

KSC Sunset

Thanks for stuff like this:

Discovery II - Assembled Discovery II Fuel Tank

Just wanted to report something; On the example craft included in the release, some of the tanks start out invisible. If you click "next variant", the textures show up. Clicking through "previous variant" can get you to the invisible texture. I'm guessing it's because it's still using the "FLM" versions of the parts, which are deprecated by this release, of course, and something about their textures is being wonky. It doesn't really bother me, I just wanted to let you know. Big thanks for releasing example craft at all! Really helps to understand how the pack is 'meant' to be pieced together.

I live in the Bay area and last saturday night at 1 AM it was still 89 degrees in my apartment....

I'm not sure if you understand the particular bug that I'm talking about, because this method is not a workaround. The issue is: 1) MJ launches with the correct inclination, at the correct time 2) After reaching the target apoapsis and coasting to space, MJ creates a circularization burn that mirrors the inclination. i.e., if the inclination at launch was -6, instead of circularizing at -6, MJ circularizes to +6, doing a 12 degree inclination change along with circularization at the same time. My experience is that setting the launch into plane angle to 0 always works to launch at the right time, meaning that the bug is in the calculation of how long to lead the line of nodes, but this is a totally separate bug from the "circularization inclination flip" that I'm seeing when the initial launch inclination is negative.

I'm having a weird issue. I have a craft that is simply a ground construction space crane with a rover hangar underneath it, with 4 LV-909 terriers. I am landed on minmus and want to hover so I can move a few hundred meters. When I click hover and follow terrain, after several seconds TCA turns the engines to full throttle and burns until I forcibly turn AutoThrottle off. The engine limiters are all locked at 100%, which seems odd for TCA which usually oscillates around 99.something when at full power. It basically burns me on an escape trajectory out of minmus then stops because I haven't unlocked orbital control in career yet. I went to test the craft back at KSC on the launchpad, and it worked fine (after adding engines with enough thrust to hover). Then I hyperedited that test craft to minmus and it worked fine too; when I switched to the craft that was acting wonky, suddenly it started working fine. I feel like something got stuck somewhere and TCA didn't really have control over the engines like it should have. I was using it to execute the maneuver nodes on the way to minmus, but then I used mechjeb to land. Anyway, has anyone seen this before?

Thus far, every time the circularization inclination-mirror bug has happened, it's occuring under the following scenario: - Set launch into plane angle to 0 (probably not relevant). Click launch into plane. If the inclination is negative, the circularization burn will be incorrect, and will burn in such a way as to mirror the desired inclination.

Launch into plane automatically launches just fine most of the time; you still have to click 'engage autopilot'

I have now seen MJ do this inclination mirroring in other scenarios, but it doesn't happen all the time. For instance, I had a polar satellite that I tried to launch into plane; it correctly launched due south, but as soon as it created the circularization burn, it was for a complete flip of the orbit (burn retro at apoapsis to flip the inclination). However, I just did a launch to minmus where it worked fine. I can't find the rhyme or reason there. Launch into plane usually does give a timer, but as established from recent posts and my experiences dating back at least to May 2016, it does not properly calculate the angle (I do think it is a leading angle, and not an angle based on any absolute frame of reference). I have occasionally seen it not give any countdown timer, but I also don't know what's causing that. My diagnosis is that ascent guidance is quite broken when using launch into plane.

This has happened to me in the past when I've accidentally deleted the Squad folder out of GameData.... did that happen somehow? If you're using steam, you can right click on KSP, click properties, click local files, then click verify integrity of game files to re-install the Squad folder, if that's the problem. Unless you've moved the installation (never installed RO myself so I don't know exactly the process you went through).

edit2: Ok, so something weird is happening; even though the ascent guidance says -6 for inclination, it keeps launching into a +6 inclination orbit, thereby of course resulting in a large plane change burn for minmus. I have manually set the leading angle to 0, the inclination is properly set to -6, then for some inexplicable reason it keeps launching into a +6 inclination orbit. Perhaps it's an issue with directions on the device that's controlling the craft... edit3: tried many different control points and it's still launching into the mirrored inclination. It appears to be happening at the circularization burn... It launches into the correct plane, then at the circularization burn, it inexplicably creates a node that mirrors the inclination into the wrong plane.

After testing this: while this is a solution to get the planes pretty close, I do think it's now quite obvious that something in the estimated leading angles is what is broken. MJ would do way, way better if it just always set the number to 0 and never tried to estimate anything. My guesstimate is that setting the value to 0 simply ignores all of the 'learning' that MJ is supposed to be doing when you launch and then revert; so whatever is happening in that "learning" is probably what's broken. Hopefully @sarbian will be able to find the bug and fix it; with a workaround that gets me pretty close I no longer have to waste a ton of delta-v changing planes in-orbit, so I won't complain anymore, I'll just hack the number to 0 until hopefully a fix comes around in the future.

Ok, but haven't you just proven that MJ cannot calculate the leading angle correctly, hence, there is still a bug? You have overridden the most important part of the launch.

Aren't those basically just times (expressed as angles, in the sense that the conversion is controlled by the the rotation rate of kerbin and the current position w.r.t. the line of nodes)? MJ used to get those times basically right; even if it wasn't timed perfectly, even without reverting, you'd get fairly close to the right plane. However, I doubt the initial values of these has anything to do with MJ learning the ascent properties of the launch vehicle properly. Now, it basically never approaches the right plane. It behaves as if it can't properly calculate where the line of nodes passes through kerbin. I am testing the craft I was trying to launch to the plane of minmus yesterday: 1) first launch, 107 m/s dv for plane change after reaching orbit. That's not too bad, actually. I forgot to write down the angle but it was ~5 hours of time warp. 2) revert to launch, launch into plane again. The angle for launch into plane was 12 degrees. 406 m/s plane change burn after reaching orbit. The orbit is basically 90 degrees rotated from minmus. 3) revert a second time. the angle this time is 120 degrees. after clicking launch into plane there was no countdown timer. Engaging autopilot launched immediately. after reaching orbit, 279 m/s dv plane change burn required. I can keep going, but the behavior is identical to what I posted in the github issue. The timing of launches behaves erratically across different revert's and never approaches being even remotely correct.

sorry, double post

Did you actually read the github issue? In it, I present an imgur album showing that it's just plain broken. It's not about fine-tuning the time of launch; it frequently launches either off by several hours, or with exactly the opposite inclination for the chosen time. In the album I explain it pretty clearly and also revert 3 times. Basically, it appears that whatever in mechjeb calculates the time to launch into the plane is totally broken... and it didn't used to be this way. The reason I posted this yesterday was that I tried to launch into the plane of Minmus with 3 reverts and every launch required a 300+ dV plane change maneuver after circularization. So clearly it's still completely broken. edit: just to say that yesterday, when trying to launch into plane for minmus, it didn't even bother to set a countdown timer to try to time anything. It would just launch into a +- 6 orbit from wherever I currently was w.r.t. the correct plane. One of the time I randomly happened to be close to the right spot, and I thought maybe MJ had been fixed. But several later launches showed that to definitely be false.

Launch into plane / rendezvous still does not select the right time to launch to actually come anywhere close to the right plane. Is there any hope that this will ever be looked into? It is still behaving exactly as in this github issue: https://github.com/MuMech/MechJeb2/issues/739 , and I also even tried looking for previous commits that might have broken the timing of the launch, which always used to be reliable.

Thanks for pointing out where they're stored, but what I really mean is, why do they sometimes get saved as a default and sometimes not? It feels totally random.

Does anyone know what exactly causes the settings on the Ascent Guidance module to get saved as a certain default? I had a launch where I had some non-standard settings, and for some reason now Ascent Guidance always defaults to those settings, which I have to undo.

I opened a github issue about launch into plane being borked quite a long time ago. I have never trusted them since. I haven't played in a little while so I don't know if it's been fixed. I did a bunch of testing, with images provided, and basically the phase angle for launch time was completely inconsistent. Sometimes it would work, some people would claim they had no problems at all, but with the exact same build and mechjeb only installed, I would see launches that either went to the opposite inclination (-69 instead of 69, for instance), or were just launched at completely the wrong time. To me it sounds like whatever was causing that behavior has not been fixed. Edit: Here's the github issue I was talking about: https://github.com/MuMech/MechJeb2/issues/739 And here's the imgur album:

@katateochi thank you for creating and supporting this wonderful tool