VFB1210

For what it's worth, I've been using Rescale! 3.2x with the latest version of Sigma Dimensions, and it seems to work just fine. I can't confirm that it's 100% bug free, but I haven't noticed anything catastrophic.

The thing is that this mod doesn't use Texture Replacer, it uses Texture Replacer Replaced, which is not yet updated.

Yes, god forbid Squad update their game and fix things and add features. How horrible. /s Also, anything that worked with 1.4.1 and 1.4.2 has a very high likelihood of working with 1.4.3 anyway. And it appears that this mod doesn't work with 1.4.anything at the moment, so it's a moot point to post here. Anyway, @StarCrusher96, the mod looks amazing, and I am eagerly looking forward to the next release so I can roll it into my 1.4 install!

I've had this idea rolling around in my head for a bit now. Is it possible for EEX to change the rotation and offset snapping when using the gizmos? I think that would be a fantastic feature that will add a lot more to this amazing mod.

I too am having issues with Scatterer and 64k. Installing Scatterer normally makes Kerbin look like this in map view. When I use the RSS fix config, Kerbin looks normal in map view, but lacks the Scatterer effects in the normal flight screen. Any idea how to fix this?

1. Lovell did have engine gimballing and RCS capabilities when performing that burn. If he had neither of those the situation would have been literally hopeless because there would be no way to orient the craft to make any burns whatsoever. There is in fact video of the burn (I'm trying to find it now.) where you can see the Earth bob in and out of view during the burn. 2. The Vostok 1 capsule didn't blow up-where did you even hear that? And think about it: what combustibles would have even been there to allow it to? Astronauts parachuted out of Vostok capsules because the parachutes on the capsules weren't large enough to slow it down enough for a human-survivable landing. So the astronauts would jump out and parachute to safety while the capsule would slam into the ground. And survive remarkably in tact..

I'm dumb and I've been over complicating everything this whole time. Also, this wikipedia article is a thing. The v in v(dm/dt) is supposed to be the exhaust velocity. Exhaust velocity multiplied by mass flow rate also has its own name: THRUST. So according to the article, we get ΣF + thrust = ma. ΣF is all of the external forces. Gravity. Drag. Lift. So: Gravity + Drag + Lift + Thrust = ma. TDW was literally right THE ENTIRE TIME. My apologies for misleading everyone. Let this be a lesson: don't blindly apply formulas without thinking about them, and don't ever be too proud to look something up.

It should be taken into account whenever you are calculating the net force on the vessel. But the v(dm/dt) term only emerges when you are burning because dm/dt is zero when you aren't.

dm/dt is a scalar value, a regular number, not a vector. It can't be parallel or orthogonal to v.

Quigon-integrating the flow rate leads to a lighter vessel because integration is actually the opposite of differentiation. When you integrate the mass flow rate, you go from knowing how fast you're throwing mass away to finding out how much you've thrown away. And of course, once you've thrown away some of your rocket's mass, it is going to be lighter. And the constant g has to do with the fact that is just a conversion factor, and in this case has nothing to do with the actual strength of the gravitational field. At some point, someone needed to dividentify by an arbitrary value with units [l]/[t]^2, and they said "I'm just going to use g, because everyone agrees that that is 9.80665m/s^2, or 32.174ft/s^2, or whatever it is in whatever units they want to use. They all know what it is, and there will be no confusion when calculating."

To be truthful, even I have a difficult time wrapping my mind around how (dm/dt)v actually plays into the equation, but the math doesn't lie, and the math that derives it is very simple, and makes it plain that it cannot be ignored. (Provided you know Calculus, that is.) But physically, it is pretty unintuitive. (Again, as in my last post, bolded values are vectors. Just for bookkeeping and clarity.) So, to start off, we have commonly taught version of Newton's 2nd law: ΣF = ma. This is read as "The sum of all external forces on an object (ΣF) is equal to the mass of the object multiplied by the rate at which it accelerates." As I said in a previous post, this is not 100% true in every possible situation, but it works in the case of a constant mass. (In fact, as you'll see later, it actually IS this in the case of constant mass. The general case will simplify down to this.) However, to get the whole story, you need the equation ΣF=dp/dt. This is read as "The sum of all external forces on an object is equal to the time derivative of its momentum." Now, I'm sure you know what momentum is, it is mass multiplied by velocity! Or mv. But, what the heck does "time derivative" mean? Well, in calculus, there are three big concepts: limits, derivatives, and integrals. Limits hare extremely useful tools, but they're not relevant here. All you need to know about them for now is that they are used in the construction of the next two tools we gain from calculus: derivatives and integrals. Integrals are also extremely useful, but also very confusing, and not needed here, so we will throw them out for now too. That leaves us with derivatives, which is the relevant topic. A derivative, in short, is the rate of change of something. It can be the same everywhere (as is the case in a linear function), it can change smoothly according to its own function (as with any polynomial that isn't a linear function), or it can even jump around pretty wildly in some weird cases. But, for any function which has a derivative, the derivative will tell you how fast that function is changing at any point you want! (Well, not any point you want, there are some rules. But they're not relevant to us here.) That is what a derivative is, it is a function that tells you how fast another function is changing at any point you need to know. In the case of a time derivative, we are concerned with how our function changes as time changes. You can take a functions derivative with respect to any variable you want, but time is the one we are looking for here. Whenever you see something like dm/dt, that is what it means. You want to know how the top variable (m, in our case) changes as the bottom variable (t) changes. Don't worry about the d's, those are just part of the notation. So, for the sake of brevity, we are going to skip a lot of steps here, stuff like calculating derivatives by hand, and go right to the shortcuts! As it turns out, derivatives of certain types of functions always follow the same rules, and instead of doing everything out the long way, you can use these rules to calculate your derivative much quicker. The rule we are interested in is called The Product Rule. The product rule says that whenever you have a function (which we will call h(t)) that is equal to two other functions multiplied by each other, (e.g. h(t) = f(t)*g(t)) the derivative of h(t) is equal to the derivative of the first function, multiplied by the second function, plus the first function multiplied by the derivative of the second function. (dh/dt = df/dt * g(t) + f(t) * dg/dt) Now that we have our rule, let's see how it applies to what we were talking about: we know that ΣF = dp/dt. And we know that p = mv. And we know how to take the derivative of two things multiplied together, so let's do that! Our result ends up being dp/dt = (dm/dt) * v + m * (dv/dt). Now, it just so happens that dv/dt (the rate of change of velocity as time changes) has its own name: acceleration. It also has its own symbol: a. So we'll plug a in for dv/dt so things get less cluttered. Now we have ΣF = dp/dt = (dm/dt) * v + ma. This is the general form of Newton's 2nd law. But, most of the time when you're using it, the mass of the thing your using it on (such as a billiard ball, to pull an example out of a hat) doesn't change at all. Ever. Period. In this case, dm/dt (the rate of change of mass as time changes) is 0. Everywhere. Always. So, if we plug that in, we get ΣF = dp/dt = 0 * v + ma = ma. In this case, the bit with dm/dt goes away, and the law simplifies down to what you were taught in school. But, in our case, we have rockets that do little else but throw their mass away really fast so they can get to space. (Or the ground 100 feet from the launch pad.) In this case, our mass is always changing, so dm/dt is never zero, and so that part of the equation never goes away, and so we can't pretend it doesn't exist, we have to take it into account. That's the math, and the math doesn't lie. TL;DR: I don't understand it either, but the math says it has to be there, and the math doesn't lie. Also, unfortunately I haven't had much time to play with KSP and experiment with this, as much as it's been gnawing at me. So I have no data to report.

I've seen other people do it, (e.g. F9 flyback booster) but I could never get it to work, and the ship has to be within physics range. So an ore ship to Minmus would probably be out of the qurstion.

If you are flying level at a constant speed, the net force on the plane should be zero, and drag should be equal to thrust. That makes sense. Similarly, thrust will be greater than drag when speeding up, and less than drag when slowing down.

How strange. I'll have to look over the math once again and do a couple of test flights once I get home from work. Also, if I'm not mistaken, the ship:acceleration tag is actually a thing in kOS, so you should be able to use that rather than relying on an accelerometer. Edit: A very preliminary guess without having the chance to look anything over would be that there may be a unit mismatch somewhere, an overlooked conversion factor or something.

What exactly are odd results? I haven't had a chance to play with either of our scripts myself.

^The only issue I see with that is that it would be extremely difficult to calculate lift from wings. Body lift is easy enough, as it is essentially just the component of drag working opposite the direction of gravity. In fact, looking back at the code now, getting vector drag is literally as simple as dropping the :mag tags and multiplying the thrust by the unit vector along ship:up. For some reason I decided it would be more complicated than that and got lazy. ISP is <someValue> //You'll need to specify this yourself unless you want to grab engines from the list() function and pull the ISP from that. (Hint: it's easier to just plug this one in.) mDot is vessel:maxthrustat(1)/(ISP*9.802) //Note that thrust used is sea level thrust. Use corresponding ISP value. function drag { local drag is ship:mass*(ship:acc - ship:grav/9.802) - vessel:maxthrustat(vessel:pres)*ship:up + mDot*ship:velocity. return drag. } function bodyLift { local localUp is -kerbin:position:normalized. //Kerbin:position returns a vector from the ship to the center of Kerbin, constituting the local "down" direction. Opposite of this is the local "up." Key here is that it points in the exact opposite direction of gravity. local bodyLift is vdot(drag(),localUp). //Calculate component of of drag working against gravity-aka body lift. return localUp*bodyLift. //Project onto localUp. } Of course, this wouldn't quite work in a situation where the body is generating significant amounts of lift via the bernoulli effect, but it should be at least somewhat useful.

This is actually an approximation and is only valid when mass is constant. The actual definition is ΣF = dp/dt. In a situation with varying mass such as a rocket, dp/dt = m(dv/dt) + (dm/dt)v. Thus ΣF = (instantaneous mass)(acceleration) + (mass flow rate)(instantaneous velocity) = (engine thrust) + (instantaneous mass)(gravity) + (lift) + (drag). Thus (Lift) + (Drag) = (instantaneous mass)(acceleration) + (mass flow rate)(velocity) - (engine thrust) - (instantaneous mass)(Gravity). One can assume lift to be 0, since rockets are typically fly without wings and with no sideslip angle to generate body lift. Thus (Drag) = (instantaneous mass)(acceleration) + (mass flow rate)(velocity) - (engine thrust) - (instantaneous mass)(Gravity). And Thus (Drag) = (instantaneous mass)(acceleration - gravity) - (engine thrust) + (mass flow rate)(velocity). (Bolded values are vectors, just for my own bookkeeping. Might also be helpful for anyone who needs to calculate vector drag.) Thankfully, since the aero update, mass flow rate through an engine is constant for any given throttle value, so that simplifies things a little bit. Mass flow rate = (Thrust)/(Specific Impulse)(g), where g = 9.802m/s^2 always. The ratio of thrust to specific impulse is constant, so you can just plug in the sea level thrust and ISP numbers to calculate this. Or the vaccum numbers, those will work too. Thus to calculate this, we get something like: ISP = <someValue> //You'll need to specify this yourself unless you want to grab engines from the list() function and pull the ISP from that. (Hint: it's easier to just plug this one in.) mDot is vessel:maxthrustat(1)/(ISP*9.802) //Note that thrust used is sea level thrust. Use corresponding ISP value. function drag { local drag is ship:mass*(ship:acc:mag - ship:grav:mag/9.802) - vessel:maxthrustat(vessel:pres) + mDot*ship:velocity:mag. //Drag calculated is scalar and not vector since drag /should/ always be oriented opposite ship:up. If you need vector drag you can do that yourself. return drag. } And you can call the drag() function as needed. And to answer your question Qigon; yes, thrust is technically a vector, though it is usually convenient to treat it like a scalar since it is (almost) always pointing through the center of mass of the rocket.

Well I'll be damned. Awesome to know!

Well, for one, those functions have nothing in them, and two, they need to be declared in every program you want to use them in. You call them just like you showed, using apnode() and exnode().

^That could be interesting, but I was more or less talking about a variable scope one step above global. Maybe SHARED or UNIVERSAL? I'd probably go with SHARED, and only allow processors to access shared variables when they are within a certain distance of the core they were declared on. Perhaps even allow antennas to increase this distance.

^I'm the same way, I usually have Netflix on while I'm messing around. Usually my setup is KSP on the main monitor in -popupwindow mode, Visual Studio on my portrait screen, and then my phone plugged into my line in with Futurama playing. Oversaturation of media? Pft. Now in a vein actually related to kOS as it is, is it possible to pass variables around multiple scripts running on multiple processors? For instance, if I have a seperate processor that controls only the engine gimbal/throttle etc, could I pass things like throttle and steering information from a different kOS processing unit into that processor to keep guidance scripts clutter-free usable on different rockets, without LOCK STEERING shaking the rocket to pieces whenever SAS is not engaged.

Please don't get me wrong, I absolutely understand that, and I was in no way trying to say that kerboscript is holding the mod back. While I don't posses the programming skills to produce anything like kOS, I do know enough to know that is a massive undertaking, and that even though this mod has matured for a quite a long time already, it needs more time to become more well rounded and full-featured. It's just that programming in kerboscript can sometimes feel...I'm not exactly sure how to describe it; maybe a little juvenile? That sort of gets the sentiment across but sounds much more derogatory than I actually feel about it. And I'd like to reiterate that I understand kerboscript's purpose and appreciate all of the work you've done to make it so accessible. Without that accessibility the mod may not have garnered much support, without much support it probably wouldn't have been picked up by two new authors who have improved the mod so much, and I would be without a mod that I very much enjoy. It's just that part of me feels like something more C#/C++ like wouldn't have been too difficult for a complete noob to get used to. A good example to look at would be the Expression2 system from the Garry's Mod mod WireMod (say that 5 times fast!). Very similar premise to kOS, but is coded in a syntax very much like C++ (though it is distinctly its own--it isn't actually C++). Despite that, new users without programming experience had little or no trouble picking it up. I'm not sure why I'm saying all this though, it's not like I'm entitled enough to think that such a large feature of the mod should be changed because I want it to scratch my "I feel smart." itch a little better. And to be perfectly honest, I would 100% rather keep kOS with all of its current features and kerboscript, rather than ditch kerboscript and lose features until they can be put back in with a new language.

And I have to say, as much as I appreciate this sentiment and commend you for the effort you've gone through to make everything accessible to people new to programming, sometimes I find myself wishing there were an alternative available that used somewhat higher-level syntax. (and I don't mean that in the computational sense, just something like more like "private foo = number;" instead of "LOCAL foo IS number.") Hell, if I were good enough at programming, I'd even start poking around under the hood and seeing what it might take to get a kOS-like mod that used straight C#. (Or, at the very least, something very close to it.) Unfortunately, I lack the knowledge and skills to even be able to determine whether or not that is actually feasible, much less execute it. There are actually a couple of ways you could accomplish this. You could set all or some of those variables as parameters and then pass them as inputs to the program when it is run. For example: //myLaunchProgram.ks PARAMETER inclination PARAMETER periapsis PARAMETER apoapsis ...etc. //programmy stuff and then do: RUN myLaunchProgram(45,100,250). //45 degree inclination, 100km periapsis, 250km apoapsis. Or, if you have a second monitor like I do, you can keep the script open in a text editor on your second panel, (scripts stored in kOS's archive are in Kerbal Space Program/Ships/Script) run your program, watch your rocket explode, tweak some stuff in the text editor, CTRL+S, then reload your rocket and do COPY myLaunchProgram.ks FROM ARCHIVE. RUN myLaunchProgram.ks.

I believe he is referring to something similar to Console.ReadLine() in C#, or cin >> in C++, which is a feature unfortunately lacking in kOS.

You're typing commands into the console, not the program editor. To access the program editor, type "edit <program>." into the console. <program> is the name of the program you want to edit. If a program with the name <program> doesn't exist, a blank program will be created under that name and the program editor will be opened.