T.C.

I read license agreements. The license agreement for Kerbal Space Program has changed since I last downloaded the program. The new license agreement is unacceptable. It is ridiculously one-sided in favor of the company. It is an insult to the customers. I know most of you don't bother to read license agreements. Please read this one. Then tell Squad what you think about it. Companies deserve to be called out when they do things like this. -TC

I found a solution. I downloaded the KOS source code, commented-out the lines which enforce the requirement, and re-compiled KOS.dll. If there was an easier way, please let me know. Otherwise, I'm satisfied with this solution.

I want to use KOS in career mode with no restrictions. I've modified the part .cfg files to make all KOS parts available from the start. However, I find that I still cannot use KOS fully because I am unable to change the name tags of parts. When I try to change a name tag, I get a message saying "The VAB requires an upgrade to assign name tags". How can I remove the VAB upgrade requirement?

Does this new forum allow us to customize its presentation by using URL parameters? I'm particularly interested in finding parameters to suppress all the clutter that is wasting space. -TC

Real question here: How does declining contracts benefit the player in any way? I think I'm unfamiliar with the game mechanic being discussed in this thread. Is everyone suggesting that if I decline a contract, I will get a fresh new offer faster than I would have if I had ignored the contract? -TC

According to the announcement for KSP 1.0.5, "The water buoyancy has been completely reworked." This leads me to ask: Does KSP also simulate air buoyancy? -TC

Among the forum rules is this section: I feel this does not belong among the rules because it is not actionable. How should a forum user's decision to post be influenced by the rule that posting may be "frowned upon"? How should a moderator's management of the post be influenced by the rule that the posting may have been "frowned upon?". The declaration of official rules is no place for so much ambiguity. Also, the rule that necromoaning posts are subject to removal is either oddly exclusive or redundant. Nowhere else among the rules is removal of posts mentioned. Does that mean necromoaning posts alone are subject to removal? Alternatively, if all posts which violate Rule 2.3a are subject to removal, why redundantly state that removal under Rule 2.3a applies to necromoaning posts? -TC

FancyMouse, Thank you for the reply. You clearly know what you're talking about, but your post contained a technical mistake which my OCD requires me to correct: It is not true that for any collection of forces on a rigid body there is an equivalent single force. Specifically, if the collection of forces results in a pure torque, there is no equivalent. Also, you said "exerted to a certain point". Technically, a resultant force can be exerted anywhere along a line. That is why in Question 2 I said "a resultant force identifies a line of application, not a point. How is the point defined?" I think I know the answer now. The center of lift is the point on the resultant force line which remains on the resultant force line after an incremental change in the angle of attack. This comes from the definition of the aerodynamic center, which Gaarst assures me is the same as the center of lift, and can also be inferred from your suggestion that the center of lift is similar to the center of mass. Thank you. I'm satisfied with my understanding of the definition of center of lift now, and will ask no more questions about that. Your second paragraph opens a whole new can of worms, however. You seem to be making a distinction between lift and drag which I don't think exists in the real world, but may exist in KSP's model of it. Are you implying that in KSP, "Center of Lift" considers only modeled Bernoulli effects, and no other aerodynamic forces? That would explain a lot, actually. -TC - - - Updated - - - Gaarst, Thank you for the concise answers. It was a big help just to hear that center of lift is equivalent to aerodynamic center. (To all: I recommend that someone add that to the wiki to help future novices up the learning curve.) On the question of whether lift depends on orientation: I've been experimenting in the hangar, and I think maybe it doesn't. Rather, I think lift does depend on orientation during flight, but the center of lift calculation doesn't seem to take orientation into account, except for some broad assumptions about whether your airfoil is up or down. The bottom line is that the center of lift just seems wrong unless all lift-inducing parts are oriented the way KSP expects. Also, FancyMouse raised the possibility that center of lift doesn't refer to lift per se, but just a specially modelled type of lift. In other words, even though the KSP physics simulator would let you get your lift from a barn door attached to the fuselage with an angle of incidence, it might not consider that lift in the center of lift calculation. If true, that makes the center of lift in KSP a much more limited thing than I thought it was, and renders Questions 4 & 5 moot. (Also, who knows -- maybe the specially modeled lift that goes into the center of lift calculation doesn't depend on orientation even in flight, which would make the center of lift calculation correct for the limited thing it is trying to do.) -TC

I'm trying to understand center of lift, and I have several questions: 1) First, is center of lift an established scientific concept, or is it something invented for this game? Is it supposed to be the same as (or approximate) the aerodynamic center? 2) On the KSP wiki, center of lift is described as "...the point where the sum total of all lift generated by parts -- principally by wings, control surfaces, and aerodynamic fuselage parts -- balances out...". What does "balance out" mean in this context? Does it have something to do with a resultant force? If so, a resultant force identifies a line of application, not a point. How is the point defined? 3) Does the lift of a part depend on the craft's orientation? For example, does a wing provide a different lift when the nose is pointing prograde than it does when the nose is pointing radially? And if so, then how is KSP able to show you the center of lift while designing a plane in the hangar? Does it make an assumption about your craft's orientation relative to its velocity through the air? For instance, does it assume your craft will be moving in the direction defined as forward by the root part, and calculate the center of lift accordingly? 4) What is the difference between lift and drag? The wiki says "Lift is contrasted with drag, the force directly opposing an object's motion through the air." By this definition, lift vectors must always be perpendicular to the direction of motion, because any component of aerodynamic force parallel to the axis of motion is regarded as drag, right? But then why does the blue arrow in KSP's center of lift display sometimes tilt fore or aft? (When I trim a wing, for instance.) 5) Why make a distinction between lift and drag anyway? If I understand correctly, players use center of lift to understand the torque that will be caused by lift-inducing parts. But drag-inducing parts also cause torque when they aren't in-line with the center of mass, so wouldn't the center of lift + drag convey a more complete understanding of the torque than the center of lift alone? -TC -- CONCLUSIONS -- After receiving several replies, I think I understand center of lift now. I know future players may come here seeking answers, so I will summarize my conclusions in an edit. (Keep in mind that these conclusions still involve a fair amount of speculation on my part.) Conceptually, center of lift is the same as aerodynamic center. For a craft moving at a certain orientation and airspeed, find the resultant force of all aerodynamic forces. That defines a line. Then find the point on that line which remains unchanged after incremental perturbations in the craft's orientation. That point is the aerodynamic center and the center of lift. When KSP shows the center of lift in the hangar, it is showing an approximation which is inaccurate in two significant ways: 1) KSP's center of lift does not consider all aerodynamic forces; it considers only a special category of force which roughly corresponds to Bernoulli effects. As a result, the center of lift shown on the screen can be significantly off. For instance, the drag of parts on a front-loaded rocket should result in a center of lift in front of the center of mass, but you won't see that in KSP's center of lift display. Also, increasing the incidence of a wing increases lift both in real life and in KSP flight, but you won't see that increase reflected in the center of lift display. 2) KSP's center of lift does not take into account the orientation of lift-inducing parts relative to movement through the air. Thus, if you attach a lift-inducing part at anything other than the default orientation, you'll get an inaccurate center of lift. This particularly affects any craft with wings attached at an angle of incidence or trimmed control surfaces The bottom line is that the center of lift display can be inaccurate for all but the simplest of designs. Whether the inaccuracy is significant enough to matter, I don't know -- I just know theory at this point. I believe KSP's center of lift is inaccurate in the ways described above because it is extremely difficult to calculate center of lift properly, and this approximation is the best Squad could do at the time. (No implied criticism here -- Squad's accomplishments are still A+ in my book.) During my research, I came across a comment from someone at Squad which said that to do lift properly, they would need to add a wind tunnel to the space center. So, it seems that the developers have already thought about this with an eye toward making it better. I mention this because I saw comments which suggest that what I'm calling inaccuracies are actually intentional differences which make a valuable distinction between "lift" and "drag". I believe that is not the case. There is no need to make any such distinction, and a center of lift calculation without the inaccuracies described above would in all ways be better than the one we have now. We need to be careful not to let our understanding of drag and lift be defined by KSP's modeling of those concepts. Drag is any aerodynamic force acting parallel to the direction of motion, and lift is any aerodynamic force acting perpendicular to the direction of motion. KSP uses those terms slightly differently. It tends to use drag and lift to refer to different aerodynamic modeling techniques, where drag corresponds roughly to air resistance and lift corresponds roughly to Bernoulli effects. KSP's terminology isn't really kosher, so be aware that when KSP says "drag", it may be talking about a force that includes a component of lift, and when it says "lift" it may be talking about a force that includes a component of drag. -TC

I have been experiencing what I first thought were exploding solar panels. However, I now think it is not the solar panels which are exploding, but the octagonal struts they are connected to. To elaborate, there have been several instances where I start a maneuver, hear an explosion, inspect the craft, and find one or more solar panels missing. In every case, the panels have been attached to octagonal struts, which also go missing. Once or twice, I've spotted the panels, unharmed, receding into the distance. This is why I now think the octagonal struts are exploding, and not the panels. On one craft, I attached four octagonal struts radially to a hitchhiker storage container, and another four radially to a mobile processing lab, then attached solar panels to all eight of the struts. The four struts attached to the hitchhiker storage container all exploded at one point or another during the mission. The four attached to the lab all survived. Therefore, I think the problem has something to do with the part the octagonal strut is connected to. I am not satisfied with the way some attachments look. For instance, when I attach a part radially to the hitchhiker storage container or the mobile processing lab, the attached part seems to be embedded partially beneath the surface. That's why I use octagonal struts to attach my solar panels -- I prefer to have my panels raised above the surface of the craft, rather than embedded within it. I use Editor Extensions and the offset tool to make everything look as clean as possible. I has occurred to me that, while my placement may look clean, it may actually violate KSP's laws of physics, and that's why the struts are exploding. But even if that is the explanation, I'm not sure what to do about it. -TC

I'd like to request further elaboration. From the preceding posts, the answers to these questions are not clear: 1. Is "right-click" the only way to get context menus, or are there other ways to do it? (other ways that are, perhaps, more accessible to one-button mouse users?) 2. Is ctrl-click on a Mac expected to open context menus in KSP (albeit with the undesired byproduct of reducing the throttle)? Or is it not expected to work at all? I tried it, and it didn't seem to work at all. 3. ToneStack solved the problem by changing right-click to two-finger-click. I assume that only works for touch pad users. Is there also a good solution for mouse users? I have a two-button mouse, but I'm playing the game with my nephew, who is using a one-button mouse -- he's the one who needs help. He somehow built a plane with inverted control surfaces, and we need the part context menu to fix that. I'd be grateful if someone could post a solution easy enough for a nine-year-old. -TC

Beabop, Thank you for the excellent explanation. For those that missed it, I had speculated that there should be an optimal potential difference (grid voltage) in an ion engine. That seemed reasonable to me, because I assumed it would always be desirable to maximize Isp. And if you're keeping the voltage tuned for optimal Isp, then it may be technically correct, but nevertheless seems odd to say that you're adjusting the electrical level to throttle the engine. Thus, my initial question. In reply, Beabop confirmed that Isp depends on the grid voltage, but also explained that ion engines intentionally trade off Isp for thrust. Therefore, there are two aspects to engine performance -- thrust and Isp -- and it makes sense that there must be two inputs -- feed rate and voltage -- to control the performance. It no longer seems odd to say that the electrical level can be adjusted to throttle the engine. -TC

Yes, I'm sure you're right. When I asked the question, I had my electrical concepts mixed up. In retrospect, it makes sense that what should remain constant is the potential difference which accelerates the ions; the current required to sustain that difference should, of course, vary with the feed rate. I withdraw the question. -TC

In the description of Dawn's ion engines here, NASA says "The thrusters work by using an electrical charge to accelerate ions from xenon fuel to a speed 10 times that of chemical engines. The electrical level and xenon fuel feed can be adjusted to throttle each engine up or down." I can understand why the fuel feed changes for throttling, but why does the electrical charge change? Shouldn't the optimal charge remain constant regardless of fuel feed and throttle setting? -TC

The talk page is best, I think. I will not undertake to change the Wikipedia article(s) myself until I am more confident of my knowledge, but I welcome any changes you choose to make as a result of this discussion. -TC

You pretty much settled everything when you said "the mass (or gravitational parameter) of the central body... is a quantity so important in orbital dynamics that I guess it's generally assumed to be known" When you're learning something new, the hard part isn't getting the solid facts down, it is getting your mind around the squishy context. Conceptually grouping mass among the physical constants, and not among the orbital parameters, is the kind of thing that a novice like me wouldn't necessarily do instinctively. It takes a discussion like this to get a feel for that kind of thing. And this discussion has done its job well; I consider my question resolved. You've all helped me a lot. Thanks to everyone who posted. Feel free to go off-topic as much as you'd like now. -TC

Yes, that helps! Just to be clear, you're saying that "the orbital elements are sufficient for orbital predictions in two-body and restricted three-body systems" because "you can obtain the mass of the parent body (at the very least)". This corresponds with my hypothesis that there is an implicit assumption that additional information beyond the orbital elements is known (in this case, the mass of the parent body). Thank you. ZetaX, you've thrown me for a loop. Your claim that the orbital elements themselves contain all information required for orbital predictions seems to contradict other replies I've received here. I don't see how acceleration can be computed from the orbital elements without additional information. I will ponder what you've said. -TC

And is it accurate because the orbital elements themselves contain all information required for orbital predictions, or because any information they lack is, by convention, assumed to be known? -TC

I am grateful for your reply, but please forgive me; I am unable to understand your reply as an answer to my question. Can you elaborate? Do you believe the Wikipedia claim that "once the orbital elements are known for a body, its position can be calculated forward and backwards indefinitely in time" is accurate or inaccurate? -TC

Thank you all for the replies, but I think this thread is getting somewhat off-track. I'm not asking what additional information is required to do orbital predictions (e.g. mass, force, acceleration, etc.). I'm asking why Wikipedia claims that the orbital elements alone are sufficient for orbital predictions. Is it a mistake, or is it because everyone with experience in orbital mechanics just takes it for granted that any required additional information is always available, and therefore doesn't need to be mentioned? -TC

Thank you for the replies. I believe I have learned the following: The six Keplerian elements alone are not sufficient for orbital predictions. Additional information is required. I mistakenly believed the additional information is a force, but as peadar1987 explained, it simplifies to acceleration. In any case, this additional information is not represented among the orbital elements. However, as peadar1987, KSK, and Meithan explained, the additional information can be inferred from the mass of the central body. Unfortunately, I am still not clear whether there is an implicit assumption that the additional information is always known. In other words, is the Wikipedia article correct when it says that "once the orbital elements are known for a body, its position can be calculated forward and backwards indefinitely in time" because we implicitly know the additional information required (e.g. the mass of the central body)? Or, is the Wikipedia article incorrect because there is no implicit assumption that the additional information is known, and without the additional information, the six orbital elements are insufficient for orbital predictions? -TC

I'm trying to understand orbital mechanics, and I've become confused by something I read on Wikipedia. This section says that "In principle once the orbital elements are known for a body, its position can be calculated forward and backwards indefinitely in time". (The article adds appropriate disclaimers for perturbations). I am confused by this because it seems to me that to do orbital predictions, one must know the force of attraction between the bodies, yet the force of attraction doesn't seem to be represented anywhere among the six traditional Keplerian elements. Am I mistaken? Is the gravitational force represented among the Keplerian elements in a way I don't understand? Alternatively, is there some unspoken assumption that, whenever one knows the six Keplerian elements, one also knows the masses (or gravitational parameters) of the bodies, effectively making the force an implied seventh orbital parameter? Or is it possible that the Wikipedia article is wrong, and knowing the orbital elements is not sufficient to calculate the position of an orbiting body forward and backward in time? Note that I asked essentially the same question on the "Orbital elements" discussion page. -TC

While Kerbal Space Program is starting, I briefly see a chimpanzee in a helmet, then I see three Kerbals in space suits for the remainder of the startup. If you're talking about replacing these images, then I'm agreeable; replace them with something pretty. Whatever. Once the program starts, I get the menu screen, featuring an image of a Kerbal on Mun. I consider this screen to be completely unnecessary and annoying. I would much prefer that the application automatically launch into the game I was most recently playing. The menu screen just adds a few unnecessary mouse clicks and extends the time required to get into the game. All the options managed there could easily be managed elsewhere. So, if you are asking whether Squad should update the menu screen, my answer is Yes -- they should remove it completely. -TC

As a new player, I can affirm that ambiguous and inconsistent size names cause confusion. I prefer the 1.25m / 2.5m / 3.75m / etc. naming scheme which I have seen in mods. It is unambiguous, versatile, and descriptive. None of the other schemes share all those characteristics. The problem with using the manufacturer name to describe size is that there is not a 1:1 correlation between manufacturer and size (nor is there any reason why there should be), so that naming scheme potentially leads to ambiguous or convoluted references. (e.g. "the Probodobodyne-sized Rockomax engine", "Steadler's Rockomax-sized command module", "the Rockomax-sized Kerbodyne liquid fuel booster", etc.) -TC