rmaine

I'm pretty consistently these days getting failures in return from a moon, generally in pretty benign cases. I used to do this fine all the time. Mostly just because it is boring to do it by hand - easy, but repetitive. Recently came back to KSP after being off for a while, and I'm getting this with the recent McJeb2 dev versions. Attached log file (assuming I managed to do that right) is a case from a nearly circular low-inclination mun orbit at 30 km altitude. Log file says "DeltaVToChangeApsis() no feasible solution found". https://www.dropbox.com/s/ryxn6jui09rlm8e/Player.log?dl=0

Exactly. I fiddled with it a little just to see what it was like. Even submitted 2 entirely trivial reports (one was just a typo and the other wasn't much either). Not ready for me to actually play yet, but I'm fine with that and it isn't unexpected for an EA release. I'll likely play more KSP 1 for a while, glancing at the KSP 2 updates as they come.

Many parts don't have additional information. I did submit a related report in that the part descriptions on some parts are truncated. If it's a part that has extra information, then shift shows the additional information and the resulting wider window shows the full part description. But if the part doesn't have extra information, I don't see a way to see the complete part description. First part I ran into this on was the FL100 tank.

I've got a GTX 2080. It was a top-of-the line card when I got it, but I guess that was a while ago. Game seems to run fine in the little time I've spent with it. However, the fan noise from my graphics card tells me it's getting hotter than I like. For me, that's a much bigger issue than frame rate. I'm turning down the settings quite a bit to keep from frying the poor card. Granted, that would give me an excuse to buy a new card, but I don't think right now is the best time for that. :-)

Yes. I ran into that some time ago. Never bothered to report it, as I figured there were plenty of higher priority things to be worked on. Just got me in the habit of turning off autostage before docking. Well, that and I was already in the habit of doing a quicksave before docking, as there are so many things that can go wrong.

Like so any others,I'm excited about colonies. I've spent lot of my KSP 1 time playing with various life support mods to give some purpose to bases; glad to have something in the core game in KSP2. Oh, and hoping that implies physics that won't require mods and hacks to keep bases from self-destructing on scene change.

Might be neat to watch you streaming, but I'll be busy learning it myself. :-)

In spite of having flown in a few real-life helicopters, I'm still not entirely convinced they can actually work. They just seem so implausible. :-)

I notice several people seem to be taking the above comment seriously. Apparently someone's humor detector has failed; I grant the possibility that it is mine. :-)

A little hard to follow your analogy, but I think I got it. It is still wrong. I'm not sure how to explain this to you, but I assure you I *DO* know the physics. Spent my career at NASA as an expert in flight dynamics. But pulling the "I'm an expert" line isn't good, so I'll try otherwise. The only reason your pen tips is that the forces are *NOT* acting along the centerline through the center of mass. By adding a moving tilted surface, you are actually making the situation much more complicated rather than simpler, so it doesn't help much as an analogy. No, attaching something to a rotating, accelerating surface is not anything close to the same as attaching it to the ground. It is far easier to look at the actual situation instead of trying to imagine analogies that introduce more complicated dynamics than the original. As MechBFP and Ashandalar alluded to, you need to realize that there are 3 "degrees of freedom" (to use a technical term, I'm afraid) here. I real flight, there are 6, but as these diagrams are all in a flat plane, only 3 of them are at issue. Two of them are the motion of the center of mass in the vertical and horizontal directions. Those are the two that gravity turns are about. Force components through the center of mass are what affect those. Those forces include both gravity and the component of thrust along the centerline. In the case at hand, all the thrust is along the centerline. The third is the direction that the vehicle is pointing. It is absolutely essential to understand that this has nothing at all to do with the direction of motion of the vehicle. You can turn around and fly backwards and that doesn't change the velocity of the center of mass. Conversely, changing the velocity of the center of mass doesn't cause the craft to rotate. Repeat after me, these are completely independent. The wiki diagram you looked at is causing confusion because it is only about the velocity of the center of mass and yes, it talks about rotation of the velocity vector, but that has nothing to do with the rotation of the vehicle. The only part of a force that causes vehicle rotation is the component of the force that is not directed through the center of mass. If you gimbal the engine so that it is not thrusting down the centerline, you'll get such a component. Just like things don't move if nothing pushes them (gravity counts as a source of pushing here), things don't rotate unless something twists them (that torque word mentioned above). It's actually easiest if you don't try to separate the thrust into vertical and horizontal components. The cleaner separation here is the component through the center of gravity and the component perpendicular to that. But if you really insist on looking at the component of the thrust that is upwards, ok, we can do it that way. Yes, that component of the thrust gives some twisting force (torque) that would tend to push the nose down. But you don't get to just stop there. If you are looking at the upwards component of the thrust, you have to *ALSO* look at the horizontal component; it has both except when the rocket is vertical. That horizontal component is aimed below the center of gravity and thus gives twisting force tending to push the nose up. Turns out that, assuming the total thrust is aligned along the centerline, that nose up twist exactly counterbalances the nose down twist. This is really the harder way to do the analysis - awkward choice of axis system (and it gets really awkward when you are doing real dynamics instead of sticking to a flat plane and adding in aerodynamic forces - which is why nobody does it that way). But if you want to stick with vertical and horizontal directions, you do have to include them both. When you earlier talked about the engine thrusting upwards, it hadn't even occurred to me that this was because you were ignoring its horizontal part; can't do that.

Again, no. The engine is *NOT* pushing the aft end up. Nothing is pushing the aft end up. As you say, the engine is pushing along the longitudinal axis. That axis goes right through the center of mass. This does *NOT* cause any rotation; it just doesn't.

Yes.

Sorry, but just no! Actual NASA engineer (well, retired) speaking here. True that air isn't required for a gravity turn. But *SOMETHING* has to create some torque or the vehicle won't rotate. Air is a convenient way to do it automatically, assuming the vehicle is aerodynamically stable. (It's not drag as one post above describes it, but that's a separate quibble). If not in an atmosphere, the rotation would be either from engine gimballing or RCS jets (or for KSP, gyros, though that's not going to cut the mustard for most real rockets). And most emphatically no, the engine nozzle does not magically produce an upward force. It produces a force along the vehicle centerline (or however else the engine is aligned, but that's most commonly the centerline). Engine gimballing can change that, but that requires active control and almost certainly would not be just an upward force; pretty hard to get into an orbit if the force from the engine was somehow always upward. Oh, there are some relatively minor aerodynamic effects making the thrust not quite along the centerline when the vehicle has a non-zero angle of attack (or sideslip), but those can be neglected for current purposes. There are also scientists (and engineers) who know their stuff, but struggle to convey it to other scientists and engineers. Back before I retired, I often made the point that it didn't matter what great technical insights you had, they weren't worth much if you couldn't express them well enough for other people to understand. This was a lesson I didn't learn myself until well after I left school. My eventual appreciation for that is probably a significant contributing factor to why I ended up as editor of an international programming language standard.

Cute tutorial, even if the grammar cop in me cringes at the use of "as quick as possible" instead of "as quickly as possible". At least it doesn't misuse "crafts" as a plural of "craft". in the context of spacecraft :-)

I'm not sure where to find this specifics tab you refer to. Possibly somewhere related to KAC since you mention KAC? I'm not using KAC at all these days, and the descriptiom of this mod (Alarm Enhancements) specificaly mentions that its purpose is "adds some functionality which the Stock Alarm Clock lacks but was present in KAC" so I don't see that I should need or be looking at KAC. I don't see any tab or setting like that in the stock alarm clock. Where I'm looking is Settings/Difficulty Options/Alarm Enhancements, which has an option named "Maneuver Alarm Margin", which defaults to 60 seconds. (I tried tweaking it to 65 seconds just to see if it needed a tweak to make it get noticed). The mouse-over description of it says "Don't set auto alarm if within this many seconds of the event." That sure sounds exactly like what I was wanting and 0 seconds ahead is less than 60 or 65 seconds ahead.

Either the maneuver alarm margin doesn't work or I don't understand it. I admit the possibility of the latter. It's fairly common for me to create a maneuver (using McJeb) to happen right now (in McJeb maneuver planner terminology "after a fixed time of 0 seconds"). As soon as I create the maneuver, this mod pops up an alarm warning me about it. Every time. Sort of annoying as the alarm pops up right in the way of telling McJeb to execute the maneuver. Yes, its pretty minor as annoyances go, but I thought that's exactly the sort of thing the alarm margin was for. Since I'm right in the middle of creating the alarm, I already have a pretty good idea that it's comming up... and indeed here.

Thanks a lot for your work.

Decided to hit hard on the suggestion of corruption/whatever. I haven't much played games on my iMac for years. The Mac being a pain in the...um... let's say donkey for games is a large part of why I got a Windows box initially as a dedicated game machine, though I've been moving other of my stuff to it over the years. Actually typing this on my iMac. Installed KSP on this Mac using steam. I don't think KSP has ever been installed on this particular Mac, so that's a very fresh install. Had to paw around to remind myself where steam installs stuff on the Mac. Found it. Tried installing CKAN. "Bad word" Apple gatekeeper or whatever it's called. Found where to tell it to allow CKAN to run in spite of not being "blessed" by Apple. (Apple trying to force me to buy into their closed ecosystem is a big reason I'm moving out of it instead). CKAN still won't come up? Oh. Says it needs mono. I start to grab mono, but decide to just do without CKAN for this. Only 3 mods to install anyway, and I'm not worried about keeping them up to date as it's just for this test. Manually installed harmony 2, module manager, and this mod. Took a look at the partDataBase.cfg file. Looks good. Launch ksp. Look at the chute in the VAB. Looks bad. Quit ksp. Relook at the partDataBase.cfg file. Now it looks bad. I'd say that doing all this on a different computer, even with a completely different OS, pretty much puts the nail in any suggestion that it is corruption or something like that on my end.

Yes, I know to delete the ksp dir in steam when doing a clean install. Did that. And yes, that's what my config looks like in my stock game, and even after I install this mod (and its 2 dependencies) from CKAN. No other mods at all. It's after launching KSP that the config file changes as shown.

Ok. More data. Completely deleted my steam install. Reinstalled (without any DLC). The parachuteSIngle block looks like yours above. Copied that install to my C:\Games dir so as to not corrupt anything in my steam dir. CKAN installed latest version of this mod and dependencies. Launch game, letting the mod do its png optimization. Looks bad. Quit game. Check the partDataBase.cfg file. It has changed. Now looks like the (presumably bad) one I show above. make another copy of the game from my steam dir. CKAN install, etc. This time tell the mod not to do it's png optimization. It still changed that block of the partDataBase.cfg file. For the moment, I'm going to leave my steam dir with no DLC in case more digging is useful. Though when I play for real, I really like the Making History DLC (and the Missing History mod).

Hmm. Yes, this is driving me crazy (I know - probably you as well). I do have the making history DLC and pawing through the player.log file (which I find really hard to discern much from), I saw MK16 referencing Making History. Made me wonder about some interaction there, which I was in the middle of investigating when I read your most recent post. As a quick check, I tried moving the GameData\SquadExpansion\MakingHistory dir to my desktop just to get it out of the whole KSP tree. Problem went away. Thought I was on the track, but wasn't sure t hat was a clean way to remove that DLC, so I deleted the DLC from my steam install, made a new copy, installed this mod with CKAN. Darn. Problem still there. Here's the part excerpt you asked about and I see that it sure looks suspiciously different from yours. Think I'll try deleting my whole steam install and reinstalling it without the DLC. Later on that. PART { url = Squad/Parts/Utility/parachuteMk1/parachuteMk1/parachuteSingle DRAG_CUBE { cube = PACKED, 0.1571,0.6559,0.4137, 0.1571,0.6561,0.4137, 0.2765,0.6432,0.3861, 0.2765,0.8647,0.1765, 0.1614,0.6528,0.6308, 0.1614,0.672,0.669, 6.735E-06,0.1034,0.01848, 0.6307,0.3626,0.6124 cube = SEMIDEPLOYED, 7.477,0.2764,0.5794, 7.477,0.2764,0.5794, 0.5275,1.225,4.172, 0.5275,1.124,14.99, 7.54,0.2754,0.5646, 7.54,0.2744,0.5325, 6.557E-07,8.838,1.147E-05, 0.826,17.83,0.821 cube = DEPLOYED, 7.477,2.653,0.5794, 7.477,2.653,0.5794, 0.5275,11.76,4.172, 0.5275,10.79,14.99, 7.54,2.644,0.5646, 7.54,2.634,0.5325, 6.557E-07,8.838,1.147E-05, 0.826,17.83,0.821 } }

Experimenting with the cfg file, which I'd never really looked at before. Use CKAN to go back to mod version 1.24.1. New game, same steps. Yep, effective diameter is 2.6 again. Quit game. Edit the cfg file. Looks straightforward. Changed ChutePhantomSymmetry to false. New game, same steps. Effective diameter still 2.6. Ok. Maybe my focus on that patch was misleading.

Hmm. Ok. Cleanest way I can do. Fresh unmodded KSP 1.12.5 copied from my steam dir into C:\Games. Use CKAN to install the community fixes 1.24.1; it drags in module manager 4.2.2 and harmony 2 22.1.0. No other mods. Start KSP, leaving everything at defaults (even accepting the default lowish resolution windowed graphics, which isn't normally how I play). New career game also accepting all defaults. Yes, let this mod do it's loading efficiency thing. Enter VAB. Right click on the Mk16 chute. Yep. Effective fully-deployed diameter is 2.6. That already shows the issue, so I don't even bother to build or launch a rocket. Quit game. Tell CKAN to use version 1.23.0 of this mod and ignore CKAN's warning that that mod version isn't supported on this game version. Accept the png cache thing. New career game; yes overwrite the game named "default". Enter VAB. Right click Mk16. Fully deployed effective diameter is 20.7. Quit game.

Aha. Tracked it to the latest release of this mod. I started a new KSP career game today. My very first rocket (MK1 pod, flea, MK16 chute, 3 basic fins) is not looking right. Says to myself "what! Descent on chute is 30+ m/s instead of the expected 7 or 8; does not make for gentle landings." Comparing things to a KSP copy on one of my other systems, I see that the MK16 fully deployed effective diameter is I think it was (not looking at that right now) 2.6 instead of 20.7. Odd. I noticed that the version of this mod CKAN gave me is only 2 days old, and looking at this thread, I see recent discussion relating to chutes. Hmm.... Reverting to the previous version of this mod fixes it. Suppose I could generate some log files if needed, but the general diagnosis seems clear enough to me. [edit] Amused at the forum software's bowdlerization of my use of a common 3-letter acronym for expressing surprise. It replaced that acronym with just "what", which I suppose is accurate, if less emphatic. Better than a previous case I ran into where a fairly common word for "complained" got turned into "poodled", which didn't quite catch the meaning; I've learned to avoid that word, even though that particular usage of it doesn't have the impolite connotation that some other uses of the same word have. :-)

Not sure whether it's related to the issues @TMS reports, but I used to have problems with the auto-staging of side-mounted boosters in gravity turn continued until I discovered the auto-stage option in mechjeb. I never quite figured out when the problem did or did not occur, but turning that option on seemed to make my problems go away.