rmaine

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.

I used to do that trick of grabbing with a Klaw and reentering. Doable, but a bit tricky. Then someone pointed out to me that once you grab with the Klaw, you can transfer crew through it. Doesn't look like the Klaw ought to be climable through, but it is. So send up a rescue capsule like you would for other rescue missions, but add a Klaw to it. Grab, transfer crew, release Klaw, and you are home free.

I make it a policy to never buy anything in early access. Too often the game ends up disappointing or even just never getting to a full release at all. (One game that was suggested to me literally a few years ago is still in early access - and they are asking for votes for game of the year - I'm not quite sure how that makes sense when the game isn't actually released). But I'll make an exception for KSP. Even if it turns out to be a complete bomb, I've gotten enough out of KSP already that the total will still seem like a pretty good deal. And that's even including the fact that I bought KSP 1 on both steam and gog.

Ah. That's a bug in my eyesight (combined with some version number indication that I'm not sure I understand). What I was reading as 1.1.3.1 appears to instead be 1:1.3.1 (colon instead of a dot between the first 2 digits). No, I don't understand what that's supposed to indicate. Whatever. :-)

Well, that will be it, then. Scanning back through this thread, I see that the height setting was added with 1.1.3.1 in March 2021. Wonder if the reason CKAN isn't offering you later ones might be if you aren't on the latest version of KSP. Oh, or alternatively, perhaps its because you are, come to think of it. Glancing at the versions tab, I see that Bon Voyage is listed as compatible only with exact versions rather than ranges, and in particular, the latest Bon Voyage version says KSP 1.12.1, without mentioning 1.12.3. I happen to have my CKAN set to accept 1.12.*. BTW, you can tell CKAN to install a specific version regardless of claimed compatibility. Just go to the versions tab for the mod in question. Of course, that doesn't guarantee that the version is compatible, but it does do the install via CKAN instead of manually.

What are the odds that you are on an old version of Bon Voyage? For me, that window with "Automatic dewarp" et al has a "height offset" right below the "toolbar button" part. I seem to recall that got added sometime relatively recently. I suppose another possibility might be the bottom of that window being clipped for UI scale or other reasons.

Community fixes already has a section in the settings window (the one from the pause menu - not the one from the main menu). That would seem like the obvious place, I'd think.

Yeah. I've tended to have CKAN's auto-update turned off for various reasons related to not trying to fix it when it didn't appear broken for me. In fact, in the process of checking to tell you what the current version was, I noticed mine was out of date, though only by one release. Thought I'd better update mine before I suggested that to you. :-) Glad all is good now.

The screenshot doesn't tell me whether or not you did a refresh. It does, however, tell me that you are using an old version of CKAN. CKAN 1.24 is from... let's see... 2018. I don't know whether or not that's related to your problem, but it certainly could be. There's an option in CKAN for updating itself, though I don't know for sure whether or not that will work from that old a version. At any rate, try the refresh first if you haven't.

Installed fine for me using CKAN. Have you done a "refresh" in CKAN? That has it recheck for the latest versions of things. IIRC the refresh is also when it looks to see if you have something manually installed. Using the latest version of CKAN (1.31)? Oh, and I do see a "not indexed" listing for Harmony, but that's for Harmony 1; Harmony 2 says it is incompatible with Harmony 1 (makes sense that you couldn't have both installed) and that Harmony 1 isn't indexed anyway. You should be using Harmony 2 - specifically 2.2.1. I assume you are on KSP 1.12.3? Generally a little skimpy on version number details in your question, so I'm having to make some guesses.