drhay53

Not sure how much I'd like sitting right in an external seat right in front of the air intake for a jet engine But like usual, enjoy watching your videos of your designs

I ended up here looking for a way to get Contract Pack: Field Research to ignore MOLE LDEF experiments, so for the purpose of other people searching this thread for keywords, here is a link to the Field Research thread with a MM patch to do that:

Is there something weird going on with the Hover/Follow Terrain settings? When setting hover with follow terrain on, positive numbers are turning red, and mousing over the Alt. (m) word says that the desired altitude is below the ground. TCA is complaining about ground collisions and maintaining an extremely high altitude relative to the desired setting. Just not behaving in the way I was used to at all. Anyone else seen weird behavior here? Edit: Looks like I'm seeing this: https://github.com/allista/ThrottleControlledAvionics/issues/46 Major bummer; guess AVP has to go.

Back in September I believe I isolated the rover waypoint following issue to this PR: https://github.com/MuMech/MechJeb2/commit/65eafbe720bfa20150ebb71594ac18fbd7d73fde It would be great if @BloodyRain2k could take a look into why the rover autopilot no longer sets and follows headings properly (assuming that the username here and on github are the same)

I get it, totally. I just tend to autopilot as much as possible for the routine type of stuff. I never really have gotten my HOTAS setup for KSP, perhaps if I did that, I would use spaceplanes more. I've just found that if I want to get some flying in, I prefer other games with more consistent framerates. So I did some more testing of my SSTO strategy; I think ~$3000-4000/ per ton, before Stage Recovery, is probably going to end up being the true number. I'm still fairly early in a career though, so my engine options are somewhat limited; I don't have Mainsail's yet, for instance. Stage Recovery shaves off ~$1000/t; if I try to optimize where it re-enters so that it's closer to KSC, I think I could increase the number. But normally I just do the de-orbit burn wherever I reach orbit. So let's say for now my method costs $2000-3000 / t, but costs me a very small amount of time, and is flexible to any mods (I simply keep ascii files with the available tanks and engines, and then my code runs easily). So I'm paying a little premium for speed and flexibility.

The thing that has kept me away from spaceplanes is just that it takes way longer to launch and recover. A big thing for me in KSP is that time is a resource; I want to spend more time assembling space stations and bases, and doing science, instead of launching/landing spaceplanes. I have strongly considered using a fleet of spaceplanes from KerbalX though, and I probably will do it again at some point

yes, I use stage recovery to recover ~50% of the cost of the LV, also, I like to keep debris super clean for FPS reasons, so I don't like to have a bunch of junk to clean up. I am going to do a better test of my cost/t, using the NRAP test weight and some larger payloads. I think the $3000/t for a small payload is a bit of an overestimate. edit: also, it's super fast to build SSTO's, vs. playing around with the TWR and delta-v by hand when using SRBs. I just find it much faster to build rockets using SSTOs with my program that tells me which rockets and tanks to use.

Haven't played in a couple months, so I updated everything and fired KSP up. It looks like no matter what I put in the inline hangar fairing, when I try to jettison the payload, nothing comes out. I have used hangar forever, it's not a problem with the object not fitting; it's clearly there in the VAB. Is this a known issue? I saw some perhaps-relevant discussion a page back, but I'm using hangar 3.3.3 and I'm still having the issue. edit: it looks like the craft shows up on the map view, and can be switched to from there, it just doesn't seem to show up visually, and can't be cycled through with the usual square bracket keybinding right when it is jettisoned.

I checked my launch from last night and it's $3000/ton; I'm not really min/maxing cost though, just making sure that I am using the cheapest engine / engine cluster that can go SSTO and has enough thrust to get the job done. Also, the payload was very small, only 3t.

FWIW, I used to build payload-rated subassemblies, but I found that it tied me down to the mods I built them with. So I wrote a script that calculates the cheapest engine/fuel tank combination that can lift a given payload to LKO. My restrictions are 1.2 < TWR < 1.3, and dv > 3300. Also, every launcher I build is SSTO, so I prune all SRBs. Usually I require 1 reaction wheel of the same size per engine, and use at least 3x symmetry tail fins for stability. I launch them with the default mechjeb ascent guidance settings.

@DMagic FWIW, I had my computer die recently, thinking it was the power supply, but it turned out to be something shorted out inside my graphics card that was causing the PSU to fault. If the PSU doesn't work, investigate that! That one had me stumped for a few hours.

So, in practice, how do people actually get things accurate enough in KSP to execute a mission you've planned? Like, can someone walk through the actual execution of a mission with MechJeb? Do you use the real orbit you're in, and re-run things in MA? Do you compute mid-course corrections on the fly? In trying to execute my first mission, it seems nearly impossible to get things accurate enough in-game. Edit: FWIW, here's my own experience. This is for a Kerbin-Eve-Duna gravity assist 1) Try to reach initial orbit from MA in KSP. Use MechJeb for inclination and longitude of ascending node. Burn radially to shift argument of periapse. 2) Once the orbit is as close as I can get it, import the orbit into MA. Re-run the optimizer with the 'real' orbit, but only for satisfying the constraints at Eve. 3) Upload the maneuver to KSP 4) Execute it with MJ; small corrections are needed when burn finishes (note to self; use RCS on future missions for extremely fine-tunable maneuvers). 5) The gravity assist wasn't quite as powerful as the one I had in MA; apoapsis fell a little short of Duna. Used Mechjeb to set up a "fine-tune closest approach" burn, which was about the same size as the burn I had calculated with MA. All-in-all, I was fairly pleased with the mission. Although, if I needed to use Duna for another assist, I'm not sure how I would get everything accurate enough. I guess it would look something like importing whatever 'real' transfer orbit I got in KSP into MA, and then optimizing a mid-course burn to get the correct flyby orbit from MFMS. However, I don't feel like I could plan out a super-long chain of assists with MA and then execute them accurately enough without this procedure.

I downloaded v1.5.8, did the exact steps listed above to my file, and now I'm getting the Eve encounter properly. This is certainly worrisome to me.

Well it's just not working. I do the following, starting from the file I sent you: 1) Change initial state: ecc=0.005, arg. peri=354.507, true anom=0 2) change coast to TEI, True Anomaly = 0, opt bounds -2.5 to 2.5 3) change DV maneuver: radial=0, uncheck opt, normal=0, prograde=1010, bounds 1000 to 1300 Then I run the optimization and I end without an Eve encounter, even after several runs. Nothing is up against a bound. I'm stumped. How do I get v1.5.8?

@Three_Pounds Wow, thanks! I knew the transfer was far too aggressive, I just couldn't figure out how to fix it (FWIW, I find the plots to be quite unintuitive to use. I'm sure I'm just not used to them yet). On the setting of the coast parameters, you're effectively telling it to burn right at the time that MFMS suggested, right? For some reason though, I just can't open the file you posted. MA says it's loading but it never finishes. If I try to make your changes by hand to my version, I do not get the same good results that you report. Are you using KSPTOT v1.5.7 on windows?

@Three_Pounds Ok here is the MFMS result, and the MA file while trying to optimize just to get to the Eve distance to zero. The last two nights of messing around at this point with this UT and orbit I've been having lots of trouble. Basically, the optimizer always seems to bump up against what seem like reasonable delta-V bounds. I have to get past this hurdle before I can even get back to the UT issue, and I spent 3 hours with this setup last night just trying to figure out what why even though I should be in the right plane for the departure orbit from MFMS, MA seems to want to add a bunch of normal and radial dV to get the eve distance to 0, and even then, wants a ton of prograde dV. I'm stumped a bit. https://www.dropbox.com/s/zlfdypy5v7m48re/MFMS_drhay53_EveDuna.txt?dl=0 https://www.dropbox.com/s/ufupbbeiqpdvofd/MA_drhay53_EveDuna.mat?dl=0 I feel like I must be missing something stupid. quick edit: I noticed when setting the initial state that mousing over the True Anomaly box gives a popup saying it's the Argument of Periapse. Argument of Periapse does seem to work fine when eccentricity isn't 0, so I don't necessarily think the underlying setting of values is bugged. I would think that would have caused so many issues that it would be caught very fast. Basically, from this starting MA file, I have to open up the delta-v constraints on normal and radial pretty wide just to get a "slamming into Eve" encounter as in the tutorial. And I'm just not sure why; I believe I've set the initial orbit into the right plane already, from the MFMS results.

yes, that's the plan, but I have a toddler and I can't get things together until nap time

I've cleared and restarted the MA 3 times over the last 2 nights trying to get it right. It's always the same thing on the UT issue (I'll double-check the timescale of the offset). I don't think I'm missing anything. Basically, the optimizer's minimization target is the distance from Eve, so there's nothing suboptimal about a high-dV solution as far as it's concerned. But I'm following the directions in the tutorial basically to the 't', as far as I can tell. On setting the parameters of the orbit, the argument of periapse part we addressed above; the starting Kerbin orbit should be a circular orbit in the plane of the hyperbolic transfer, but this means argument of periapse is meaningless, right? Just making sure we're on the same page. Wait, isn't true anomaly also undefined for a circular orbit? The coast event is optimizing the true anomaly, which is undefined in a circular orbit right? Now I'm a little confused. Obviously MA selects a time to leave from the coast event, but it seems like a coast to UT might be better to optimize?

I assume you mean the true anomaly of the coast to burn? I still have major problems getting things to converge on the right time of arrival at Eve. Basically following the tutorial steps, I end up with a high-dV burn before adding constraints, and then once constraints are added it's ~months off on the intended UT arrival.

I was attempting to set the initial state orbit to the hyperbolic trajectory plane from MFMS, like in the tutorials, but that's a good point. I'll have to check that. Im just getting started and trying to plan a mission that's a flyby of eve to get to duna, just to see how everything works. But I'm having trouble even getting to eve at the right time. Basically the optimizes initial burn gets there way too fast, and once I try to constrain UT, it has no idea how to get there. I'm trying to follow along the solar systems edge tutorial but for my own mission, and the tutorial says that the constraint solving for the eve part should just finish quickly. But I've messed with it for hours and the UT thing seems to be the culprit. Perhaps a tighter upper limit on prograde burn is the answer? btw in the tutorial I think it says to set the argument of periapse but I think that's a circular orbit too, so that's why I thought perhaps there was a bug. Just didn't know enough about what that angle is to catch that it's meaningless in a circular orbit. Now that you mention it, the name is pretty self-explanatory

Is it possible that setting Argument of Periapse in the mission architect is bugged? When I try to set it manually, it still says 0.0 on the Initial Spacecraft State, and it sets the True Anomaly to the value entered. Further attempts to enter an Argument of Periapse change the True Anomaly to a different value and also mess with the eccentricity, but don't change the actual Arg. of Periapse entry.

To deal with the ascent guidance bugs and get the fixes, I installed the latest Dev version, #741. Rover autopilot does not seem to be setting the heading to navigate to waypoints anymore. Heading control just stays at whatever value you have it set at. Is this a known issue, or do I need to submit logs and an issue somewhere? And if an issue is needed, where is the appropriate place to log an issue on the dev version? edit: Perhaps it is in this PR? This seems to be where the "follow" button was renamed "drive", and they seem to be mucking about with how waypoints are selected. https://github.com/MuMech/MechJeb2/commit/65eafbe720bfa20150ebb71594ac18fbd7d73fde

I used to run the dev builds but I stopped a few months ago for some reason. Thanks for sorting these out! That is me on github too.

Edit: the adapter in question was size 1.4 on the top and 1.5 on the bottom. I played around with some stock size 1-2 adapters and the aerodynamics hit is huge there too. So basically, even though visually the 1.4-1.5 adapter looks like it should be pretty aerodynamic, it's taking a huge hit. I have a problem that I'm quite sure is related to the universal adapter from Hangar. Basically, just about any craft with the adapter on it drastically overuses delta-v in getting to orbit, which leads me to believe that something is off with the aerodynamics of the part. I have noticed this on many different crafts of different designs, with varying top and bottom node sizes on the adapter. Using MechJeb's ascent guidance, for instance, just now I launched a craft with 3800+ atmospheric delta-v. Normally, my minimum is 3400 to ensure a 100km orbit. This craft ran out of delta-v before getting out of the atmosphere. I removed the universal adapter, and reached orbit with 774 delta-v to spare. The rest of the craft was identical. Is there a way for me to further help diagnose that this is an aerodynamics issue with this part (which I'm fairly sure that it is)?

Is there any easy way to stop the virtual "upgrade" parts from showing up due to filter extensions?