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