dewin

So I decided to take a stab at this myself. It turns out that ... it's not really possible with currently released kOS builds (but the latest Github version has proper support for addons, and I've got a basic "Hello World!" (actually "PRINT addons:krpc:available.") example working)). With that in mind I have no idea how to properly connect the two addons as far as sending messages back and forth goes. Namely, I don't see any sort of mechanism that would allow a list of variable types. (i.e. the message to request planning for a lambert transfer would have -- at minimum -- two vectors, some ranges of times, etc.). What might be feasible -- though clunky -- is something like (from the kRPC side): Message.argumentTypes() returns a list of what types are encoded in the message. Message.getVessel(2) retrieves the 2nd argument if it's a vessel. etc. I'm super-new to this though (I have a tiny PR for KER, but have no other real C# experience), so I have no idea and I suspect there's a far better solution.

I'm looking to move from kOS to kRPC for my orbital maneuver library. One quick question though before the rest of my post: can kRPC control ships without a Remotetech connection? I do Python professionally anyways, so the learning curve isn't particularly high in my case (and a lot of the harder mathy stuff I've already worked out in kOS That said, oddly enough kOS has kind of grown on me. I'd love a bridgebetween the two mods... like a way for kOS to send a message to kRPC and get a response back -- or the reverse. The use cases I'm thinking are: - Mission controlled from kOS, messages to kRPC to request complicated calculations and await a response (like maneuver planning, particularly Lambert solving for transfers -- my kOS code took 15 minutes(!) to do what Alexmoon's transfer planner does in seconds). I've actually seen this done in another kOS script using a much less elegant method: write request to a file, wait for a Java app to read that file and write a response, and check every quarter-second or so for the response file. But that's messy, and doesn't work on a RT save with no connection. - Mission controlled from kRPC, messages sent to kOS to handle real-time control needs (like executing a maneuver node as precisely as possible without the latency of the protocol). Technically this could be done by telnetting to kOS, though that is also messy and again fails on a RT save with no connection. Are there any thoughts of adding something like this in the future?

There's also the installed.ckan file which I believe tracks the same info. You can even install installed.ckan on another client/to another install folder to bring the entire package of mods over. There's currently a discussion on Github about writing a tiny KSP plugin that would grab this (and other) data and write it into the output log when KSP starts, so it'd be embedded in logs that plugin authors are usually asking for anyways.

What I'd like to see in a perfect world is some form of exception support (even if it's a single exception structure and is caught unconditionally, with members to examine to see what happened) to catch these cases and more (like my maneuver planning functions attempting to do the impossible). Then config:safe would raise immediately when on and -- ideally -- whenever NaN or similar is sent to anything outside kOS if off. I.e. don't let us crash KSP by setting throttle to infinity, crash our script/raise an exception instead. Thus, config:safe would determine whether NaN triggers a crash when first encountered or is deferred until we try to do anything with it in KSP.

You're probably referring to the 3km omni-antenna that's built into probe cores. In Career/Science mode, there's a specific tech tree node that unlocks that -- until then, you need other antennas. And 3km isn't particularly far. You can always set an antenna/dish to be active by default though, and there's even one designed specifically for that purpose.

I've successfully used R and V as variable names without issue. This is a good thing, since they're the conventional mathematical terms for position and velocity vectors. I have no idea what would happen if you assigned a delegate to them though. @MAFman: This appears to still be the case in your current version. Also: It's not necessary to use all the intermediate variables here; you can save some space (and IPU) by just constructing the LIST() all-in-one-go. (You could also save some typing by assigning ship:geoposition to a variable). FUNCTION POPULATE { RETURN LIST( LATLNG(SHIP:GEOPOSITION:LAT + off_90, SHIP:GEOPOSITION:LNG), // North // [...] LATLNG(SHIP:GEOPOSITION:LAT + off_675, SHIP:GEOPOSITION:LNG - off_225) ). } (It's perfectly legal to have a statement take multiple lines)

I discovered that I apparently owned Contraption Maker courtesy of a Humble Bundle or Humble Monthly about 12 hours after my original post, and it does seem to scratch the same itch.

I have no idea if anything knows how to handle a hybrid drive in terms of fragmentation. That said: 1. Hybrid drives work by trying to copy the most frequently accessed sectors from the spinning rust to the SSD portion. Most of this disk access is reads, not writes, so the occasional flurry of writes from defragmenting most likely won't significantly affect longevity. It's entirely possible that the access pattern from defragmenting won't even trigger writes to the SSD portion at all. 2. At modern HDD sizes and speeds using modern filesystems, fragmentation rarely makes a noticeable impact on performance. You won't lose much by turning it off entirely; and you can always do it manually once every few months. 3. There is a very small improvement to be made defragmenting a SSD. While random access isn't a concern with an SSD, there is a tiny bit of increased overhead when your OS has to say "Give me block 12. Now give me block 42. Now give me block 29" instead of "Give me 3 blocks starting at block 14". Again, this is unlikely to be anything you'll ever notice unless you're trying to push for a couple less milliseconds on a benchmark.

I like CKAN in principle, though I feel it does have a lot of flaws in implementation. The original intent was to be like various Linux package managers (namely apt), but it falls short in many ways. I've often wondered if a cross platform port of apt/dpkg would be a better tool for the job. A few major things that I think would help CKAN for everyone are: - The ability for it to have changelog/important information as part of the install/upgrade process. This can allow its use for cases like "90% of this mod is just copying files from X to Y, but you absolutely must do these other steps or nothing will work." - A prominently displayed bit on who the "official" maintainer is for metadata. Installation issues should be reported to that maintainer, which might be the mod author but not necessarily. - A way for users to submit unofficial updates, but warn about them. ("This version of SuperPluginMod is not officially supported by its author. Install anyways?") - Explicit support for beta/alpha/dev mods, with user selectable release preferences for each mod or their entire install as a whole. - More mod authors or communities to maintain their own CKAN repositories. This allows users to still gain all of CKAN's benefits while still allowing mod authors to maintain control. I know that @sarbian does this with MJ dev builds, and there are a few others. If the overwhelming issue with CKAN is its management, there's always the option of forking the existing repository and adopting a more strict policy about updates to the fork's metadata.

I loved The Incredible Machine and The Even More Incredible Machine growing up. Sadly, though, the series hasn't aged well -- at least for me. Who knew that dropping a tennis ball on a hamster cage would produce a perpetual motion machine?

Good job going with a Latitude rather than an Inspiron. Latitudes are their business line and usually are engineered to actually last 3+ years rather than being something you upgrade yearly for the newest shiniest thing. Which model of Latitude is it and what are the other specs? (You can email the cart to yourself and then PM me or post a link if you want). I routinely order these at work and my first step is usually to toss* the HDD (keep it for warranty purposes) and throw in a Samsung Evo SSD -- it's cheaper than ordering it configured that way and super easy to do (though entails reinstalling Windows). You can do similar with the memory -- order it with bare minimum and upgrade it yourself if you're shooting for 16gb or more.

Directly, no, but you can always look at the actions that said keystroke or botton does. I've done WAIT UNTIL ship:control:pilotyaw<>0. before to pause until I hit W. You probably don't want to use pilot controls in your case; other options include waiting for SAS or an action group toggle to no longer equal its previous value. For Joystick problems, you might want the advanced fly by wire (I think) mod.

Pick one: a) Speed != Velocity b) Ludicrous Speed (though I guess this is past light speed) c) RAMMING SPEEEED

Redstone circuits? And various other logic that some of Minecraft mods add. But if you're going to do that, you should grab Infinifactory.edu, which doesn't actually exist but ought to.

(TL;DR: Orbital mechanics is fun.) So I recently finally decided to install kOS. I'm a software developer by trade -- the only reason I put off kOS so long is I'd rather write in a real language (Python preferably). But then I started having mod ideas that require an understanding of astromechanics to pull off correctly... and trying to learn them at the same time as learning C# and restarting KSP a bunch didn't seem like a good idea. For the last month, I've launching KSP pretty much as soon as I got home from work every day. But I haven't set foot in the VAB or SPH, launched any rockets, landed on any planets, or even left Kerbin's SOI. What I have done feels more like rocket science to me than all of my previous hundreds of hours in KSP combined. It began with an unplanned crash refresher course on mathematics. By the way, almost all of the orbital math in KSP (and other cases of restricted 2-body problem) requires only basic algebra. This is good, because I never took calculus, differential equations, or anything else. (I have a computer science background, but no formal education beyond high school knowledge that I've not really used much since then.) Some of the more unusual math concepts I've dealt with are: Complex numbers -- those with both real and imaginary (i = sqrt(-1)) parts. This is mostly for trigonometry functions involving hyperbolas -- in practice, the actual formulas used don't have imaginary numbers at all. Derivatives -- which are basically “What is the slope of this curve at this location”. They look way more complicated than they really are -- it's really “what is the value of y at these two very close values of x, and what's the slope of the resulting line?”. These are used for calculating velocity at a particular point in an orbit. Formulas with no closed-form solution -- which means you can't truly “solve for x”, you can only test various values of x and see what gets you acceptably close to y. A simple example of this is square roots: if you were to try to calculate sqrt(2), you know that it's greater than 1 (1*1=1) but less than 2 (2*2=4), so you might try 1.5 and so on until you converge on the solution. Calculating eccentric anomaly (needed to find true anomaly) from mean anomaly is an example of this. From there, I've spent a bunch of time learning about astromechanics. (And I still am!) kOS has lots of useful functions about getting information on an existing orbit, but those capabilities are nowhere near complete. There's no MechJeb-esque “Plot a maneuver at LAN to raise inclination to 30 degrees” function. Additionally, there's no built-in way to construct an arbitrary orbit (say… the effects of executing a possible maneuver). So some of my goals are now: Implementing all sorts of maneuver planning capabilities within kOS Making it possible to select the most efficient plan to arrive at a given result. For instance, bi-elliptic transfers are sometimes more efficient than Hohmann ones, and ascending/descending nodes are not always the best place to perform an inclination change. Writing down everything I've learned, formulas and all, in a guide that is more approachable and doesn't require having to memorize all of the symbols involved. At some point, actually playing the game again Some interesting things that I've learned along the way: Sometimes “North” or “South” (as related to the poles) are the best place to do inclination changes, against all logic. North and South are always 90 degrees true anomaly away from LAN and LDN. “Radial out” and “up” are not the same direction unless your vertical velocity is zero: at periapsis, apoapsis, or a circular orbit. It's possible to turn a set of the six Keplerian elements into a pair of position and velocity vectors. It's also possible to go the other way. This is handy for orbit prediction. Sometimes running an entire orbit while graphing data makes formulas blatantly obvious. You can calculate latitude for any position in an orbit with the following formula: sin(λ) = sin(ω+Ω) * sin(i) or: sin(latitude) = sin(argument_of_periapsis + true_anomaly) * sin(inclination) I actually derived this formula myself by gathering a bunch of data and graphing it out (as opposed to finding it on the internet), so I’m pretty proud of this one. For anyone else who might find themselves tempted to dive down the rabbit rocket hole, I thought I’d collect some of the resources I’ve found useful: Wikipedia article on Orbital elements - basic starting-off point for everything The Wikipedia articles for mean, eccentric, and true anomaly. Various other Wikipedia articles “How to programmatically calculate orbital elements using position/velocity vectors?” post on StackExchange, including -- to a lesser extent -- some of the links off of that page. “Equations for Elliptical, Parabolic, Hyperbolic Orbits” full of various formulas for the various types of orbital trajectories. “Basics of Spaceflight: Orbital Mechanics” -- Linked off the kOS subreddit, but I ended up finding it independently first. AOE 4134, supplemental page for a an Astromechanics course taught at Virginia Tech (thanks, Google!). Very information-dense.

The UT advance happening at the start would explain the behavior during timewarp, where error values are multiplied by very close to the warp multiplier and none of the other forces are in effect. I'm going to theorize on that being the case and go with it. (Now if I could just figure out the correct Y value for a given orbit and time without : position I'll be set. My existing approach is... not correct).

This is what I initially suspected as well, but it doesn't explain the magnification of error on timewarp. And, judging by my log of velocity magnitudes up above, the obt velocity is extremely close to the NEXT update's vessel velocity. This is what leads me to believe that kOS updates before the ship properties do. GetVelocityAtUT should require exactly one pass through a newton solver -- in calculating the eccentric anomaly (needed to calculate true anomaly). I'm actually implementing the same thing in kOS using a custom lexicon to be able to do things like... predict the outcome of a series of maneuvers prior to actually creating maneuver nodes (by creating my structure from an obt, shifting it to a maneuver time, altering the velocity, and creating a new structure from the position and velocity vectors.) In my own testing, eccentric anomaly can be determined to a precision of 1E-15 in 57 iterations worst-case (average was 55 iterations). There's some tricks that can reduce this: I have a Python script that precomputes a table of results for anomalies 0<M<=180 and dumps the results to a .ks file. (Parsing the file locks up KSP for about 5 minutes but the compiled version is instant so it is a one-time deal). The kOS-side solver uses the table to determine its starting values. (Anomalies for M>180 are 360-f(360-M))

That's not what I meant; the comparison here is happening in a single update tick. What I think is happening is something like: 1. KSP updates orbital position. 2. KOS does its update tick. 3. KSP updates physics position. hence the desync between obt and ship. (Note that the every line of the ON TIME loop corresponds to a single KOS update).

I'm working on a library (lib_orbit.ks and family here) to handle a bunch of orbital match. It currently can convert either an Orbit/Orbitable or a set of position and velocity vectors into a rather lengthy Lexicon of orbital parameters (I'd love proper classes or a way to construct my own Orbits!... someday), intended uses being to predict a series of maneuvers without needing to create nodes and so forth. I've noticed a surprisingly large amount of what I assume is floating point error in a few cases -- basically small* differences in what the game reports vs. what my calculations show. (This is especially prevalent in cases like ... attempting to calculate position from an orbit rather than using obt:position-obt:body:position). I know that sometimes the order of operations or whatnot can be changed to reduce floating-point error, so I'd be interested in seeing if that's the case for me or not. But more interestingly, I've noticed a discrepancy between some parameters of obt and corresponding parameters of ship: print obt:velocity:orbit - ship:velocity:orbit. V(-0.00268574888173134, -0.00161378149967106, -0.00374235661232092) print obt:velocity:orbit - orbitat(ship, time:seconds):velocity:orbit. V(0, 0, 0) print obt:position - ship:position. V(2.98667690483853, 4.64475975453388, 13.1080628449563) The magnitude of these errors increases at higher factors of timewarp, which leads me to believe it's not just floating point error due to something being calculated two different ways. What exactly is going on here? I suspect that kOS's update tick is happening in between one of those values changing and the other. So, for giggles, I ran: on time { print "o: " + obt:velocity:orbit:mag + "; v: " + ship:velocity:orbit:mag. preserve. } o: 671.817348836739; v: 671.820151951602 o: 671.814845544989; v: 671.817648632772 o: 671.811414942815; v: 671.81421800491 o: 671.808185942693; v: 671.81098897715 [...] (Again, differences magnified under timewarp). So, if I want the most accurate calculations, should I be going off the values of obt or ship? The former seems to be slightly ahead of the latter.

This is mentioned earlier in the thread as something the developers want to do as well. Particularly when -- as it stands now -- processors have infinite RAM (so you can run huge amounts of library code as long as you're in range of the archive, once it's loaded and running it's not necessary to maintain comms).

Most of the rocket engines do have their unique role to fill, this is true -- though a handful of them are mostly a case of "This is your best option for X until you unlock Y". But doing that with computers wouldn't make sense. What would be the advantage of using a 1950s computer over a modern smartphone today? Technology is rendered obsolete over time with various breakthroughs, so it makes sense that it should be that way in KSP as well.

Technology advances. Your smartphone is both significantly lighter and has significantly more storage capacity than this. (I'm still just dabbling at KOS, I assume KAL9000 doesn't unlock towards much later in the tech tree.)

@FélixBachiller Uploaded some of my kOS scripts; see https://gist.github.com/dewiniaid/1e57f68c903b38c03aedb552dabe4f95 and https://github.com/dewiniaid/ksp-kos-scripts. (Particularly lib_basis.ks). To avoid derailing this thread though, we should take any further discussion to PMs, the kOS thread, or... poke me on IRC.

I'm not at home to pull up my .ks files (which I'll put on github eventually), but if I recall correctly (mind you, I'm not a math expert): - Your prograde vector is your velocity vector. - Your normal vector is the cross product of your velocity and position vectors. Since kOS positions are relative to the ship's reference frame, use -body:position instead. - Your radial vector is the result of rotating your prograde vector 90 degrees around the normal vector. If I understand my recent crash course in math correctly, it's also the cross product of prograde and normal:normalized. - The angle between radial and position vectors is the same as the angle between prograde and horizon. - From this, you can convert vectors from an XYZ basis to terms of prograde/normal/radial for, e.g, plotting maneuver nodes. An inclination change at LAN/LDN or anywhere on an equatorial orbit can be calculated by rotating your velocity X degrees around position, subtracting your current velocity, and converting basis.

Heh! Coincidentally, I've been working on a bunch of orbital math myself using kOS -- there's a long series of steps on how to convert from position and velocity to the 6 Keplerian elements -- and some of my earlier work essentially finds the flight path angle indirectly (when realizing that the radial vector is not just a line from the planet out passing through your ship, but is instead perpendicular to prograde). KSP uses a left-handed coordinate system though, so your +z is -y and I'm not sure which part of the xz equatorial plane is the vernal equinox vector. (Though +x is probably correct).