Dunbaratu

You'd probably need a full compile suite to take the source code and make it into a DLL. I could compile a DLL and try to give it to you but it's literally changing about 10 times per night as we fiddle with the final debug tests. When this problem appeared before it was always only off by a few meters, in a way that *didn't* scale with magnitide. It was always only a few meters even when talking about distances to the moon, which is why it's not detectable when doing orbital calculations. The problem (in the past which I thought was fixed, darn it), really only was noticed over very short distances because that's where being a few meters off is relevant.

Okay, thanks! The key problem is probably that it should have had a name change when it was resurrected under new management (i.e. like when KMP became DMP). We've also been plagued by the fact the Google searches keep finding the old dead thread and not the new one when someone looks for "KOS KSP" or "KOS Kerbal".

No need to apologise. It's good. I just forgot to check the recent update logs.

There seems to be a problem with duplicate naming of mods confusing the data mining. kOS, for example, was once maintained by Kevin Laity, who became utterly unreachable and out of contact (nobody has any idea what happened to him - e-mail, google+, twitter, none of these methods to reach him worked). Eventually the fact that it was licensed with GPL3 was taken advantage of, and it was taken over by erendrake after enough months of zero activity and inability to contact the author to determine his wishes. It's been under very active development, with several new releases... however... it was done by starting a brand new thread. So there are now two threads both saying they are for kOS. The data shown here seems to be only using the older defunct thread and not the newer one. So it's advertising to the world the false fact that the kOS mod is dead and out of date when it isn't. It would have been better to have just picked a different name for the resurrected mod, but that wasn't how it was done. Can something be done to the data mining algorithm to handle this case?

I've just had a look at the github and it looks as if some new fields have had the guiActive=true parameter added to them since the last time I tried this when I made that video. When I made the video, those fields I needed were still hidden. Now it looks like they're not anymore. Thank you for the change. I'll have to get the update and try again, making a smarter version of the script now that it can read the position.

This is a problem I ran into when making that video. I couldn't use kOS to query the current position of an Infernal Robotics slider because the KSPField that infernal robotics uses to represent the part's current position is a hidden field not shown on the right click menu. and kOS *deliberately* does not give itself permission to expose a hidden field to the script programs. When we started working on the system for kOS to be able to query and manipulate the values of other modules, we were very conscious of the fact that we could make a lot of other mod writers very mad at us if we started letting users fiddle all willy-nilly with any KSPFields they felt like at any time in any way. This is because there's a lot of mods out there, and Infernal Robotics is one of them, for which a lot of things which are really conceptually internal data for the mod's private use, which the user shouldn't see or change, are still listed as KSPFields anyway, for reasons other than letting the user see or fiddle with them. One possible reason for doing this includes wanting the value to be changeable via a Part.cfg file, but not necessarily changeable in flight by the pilot. Another possible reason for doing this is because it makes it easy to save the value to the persistence file. Because KSP requires all such fields to be declared as public, we can't assume that just because it's public that this means it's okay to let users use it. There's a large difference between "I don't mind other mod programmers messing with this" versus "I don't mind the user in-game messing with this". It's not safe to assume one from the other. Therefore, even though there *are* KSPFields in Infernal Robotics that kOS *could* very easily enable kOS scripts to use, that would let a kOS script get the current position of the moving hinge or slider, we're deliberately not exposing them to the scripts because we don't know if we have the blessing of the authors of IR to do so. (hint, hint). At the moment, the rules we established when we don't have explicit blessing are as follows: 1. Is the KSPField currently visible and showing on the right click menu? If it isn't, then kOS will act as if the field doesn't even exist. Not only will kOS scripts be disallowed from altering the value, they cannot even read it either. 2. Is the KSPField visible on the right click panel but has no gui tweakable control on it? Then the kOS script can read the value but not change it. 3. Is the KSPField visible on the right click panel AND it also has a gui tweakable control on it active in the current context? (i.e. during flight versus in the VAB). Then the kOS script can both read and write the value, but even then it doesn't have full reign to write anything it feels like. It still has to abide by the restrictions in the GUI control. (i.e obeying the min/max/increment values of the slider for a floating point value.) Our basic philosophy was "Allow a kOS script to do everything the player can do on those right click menus as a manual pilot, *and no more than that*." It's the "and no more than that" that's causing us to deliberately not expose the current IR part's position to the kOS user.

If what you're reporting is true, it certainly does look like a bug I need to look into, as the vecdraw stuff was mostly my fault. I don't see the effects you're seeing when I try, but I will try to reproduce the effect when I can. It might require that I get an entire copy of your saved game and craft file to try to mimic the situation as precisely as I can. But, we're in a race against time to try to get out v0.15 RSN because of an upcoming thing that might interfere with @erendrake's free time. There are a lot of nice changes in 0.15 that are a shame they're not out there yet to be used by all the script writers. I promise I'll take a look at this bug in more detail once v0.15 is out, but at the moment getting v0.15 takes first priority.

There were some problems with this but I'd fixed it in a code commit supposedly merged in on Sept 18. Are you on version 0.14.2?

It is impossible to tell what the complaint is without seeing the script code you're talking about. What were the vectors that you were drawing?

Are you allowing any time to pass between your two measurements of latitude? In a real computer, it's physically impossible to have a program instruction finish in literally zero amount of time. Between when the instruction began and when it ended, time had to pass or else the state of the universe (which contains the bits in memory) cannot have changed. But this is a place where the kOS simulated computer is very different from reality. The Unity software that Kerbal Space Program uses simulates the universe by updating things in quantum time. During the tiny slices of time the simulated universe is split into, nothing changes, not your position, not your velocity, and not even the clock. The kOS program runs many instructions between these simulated jumps in time. In order to do something where time has to pass and you have to take a new reading that MUST be at a different time, try doing this in between your 'x' latitude reading and your 'y' latitude reading: set thisTime to TIME:SECONDS. // record the universe's current time-stamp. set x to latitude. wait until time:seconds > thisTime // wait until an update in which the time stamp moved. set y to latitude. Now you will have an x and a y that were taken at different times in the simulation. Note, currently kOS runs once every Update(), not once every FixedUpdate(). In simple terms this means it's tied to your animation framerate instead of being tied to the world's physics. People with faster framerates may end up running more than one Update() in a row in which the universe has not moved yet. In the past I used to say that doing WAIT 0.001 is sufficient to guarantee that the universe has moved. I was wrong. To really be sure you have to use the timestamp example shown above, just in case you have a fast enough frame rate to do two Updates() back to back before the world of physics has moved. IMO, this needs to be addressed in a future update. perhaps we need a simple WAIT UNTIL PHYSICS for when you need to guarantee that a new physics tic has occurred.

No. See: https://github.com/KSP-KOS/KOS/issues/202

It think you're running into this problem: https://github.com/KSP-KOS/KOS/issues/252 The fix will be out with 0.15, which should be ready "any day now".

I can remember asking for that ages ago when I was writing kOS scripts but wasn't helping develop it. I guess it never was implemented. One of the arguments against providing it was that it's getting "magic" data from the simulation, but I would argue that this isn't a fair argument for not including it because the fact that that information is even necessary in the first place is entirely due to an artifact of the simulation. One of the ways the simulation differs from reality is that the simulation will let you escape the gravity well at far less than escape velocity, because you'll escape by merely being higher than SOI radius. All the good math skills in the world won't help you figure out that your vessel will escape even though your orbit is still elliptical and not hyperbolic unless you have that SOI radius number from the simulation to know the point at which the simulation breaks from reality. So, yeah it should exist => https://github.com/KSP-KOS/KOS/issues/342

I assume you want it to mean the same thing as (-1)*TheVector ? Seems reasonable to me. Added to the issues list as => https://github.com/KSP-KOS/KOS/issues/341

They are not inaccessable. The math for doing so, however, is quite wordy, and with the 10000b limit that's a problem. I agree that the limit is too small right now. I've never been a fan of it. It was inherited from Nivekk's old code and I always thought it was a bit small. The ML compiler will help a little bit, in that you won't get penalized for proper commenting and whitespace and long names, but it can't entirely make the 10000b limit reasonable. It's still a problem and I'd like to see it fixed by offering several scaled varieties of the CPU part - one that's large and heavy and small in storage early in the tech tree, and ones that are smaller in diameter but better at storage later in the parts tree. In the meantime, if you don't like the limit you can always change it. It's in the part.cfg file for the SCS comptronix parts.

We just bit the bullet and decided to bundle with ModuleManager. There just didn't seem to be any other good way.

Background: As part of kOS, I've made a very tiny PartModule called KOSNameTag, the only purpose of which is to let the user assign any arbitrary string name they feel like to a part. All it does is add this nametag as a KSPField you can see in the RMB context menu for the part, and also add a KSPEvent button you can click on to open a little textfield widget to alter the name. (And kOS has a new function that will let you get all parts with nametag "your tag name here", so you can write a script to retrieve data about that specific one part in flight). I didn't want to have to add this PartModule to EVERY single part in the game, ModuleManager style, but rather I wanted to give people the ability to click a button in the kOS window (that will come from the ApplicationLauncher toolbar), that says "add nametag to part" and then they can click a part and it causes that one part to get an instance of the KOSNameTag PartModule attached to it. The Problem: I got everything I just described above working perfectly. As long as I do it all within the same Scene. But if I add the new KOSNameTag module to the part inside the VAB, and then launch the ship, the act of going to the launchpad causes the Partmodule to get removed from the ship. (On the other hand if I do add a KOSNameTag permanently to every part of that type, by editing the Part.cfg file, then it does work. So it's not that the *field* is missing or failing to persist, it's that the entire PartModule is being scraped off by the act of launching.) Frustratingly, when I look at the .craft file being created by the VAB editor, it actually *DOES* contain the KOSNameTag PartModule. So it *is* being saved from the editor, but then getting removed when launching. I'm suspecting that when launching the ship, KSP must be going back to the default definition of that part and instancing a new one from there, and then only populating those fields from the .craft file that refer to PartModules that exist in the default definition of the part, rather than instancing the PartModules that are actually mentioned in the .craft file. Is there a solution to this that doesn't involve having to add KOSNameTag to each and every part in the game, ModuleManager style?

Bug confirmed. Sun:Velocity:Orbit causes null reference exception. Another technique that may work is to get Body2's position relative to Body1 (i.e. Duna:position - Kerbin:position), and then get the relative velocity between them (Duna:velocity:orbit - Kerbin:velocity:orbit). And from that work out if Body1 is traveling mostly toward Body2(VDOT between position and vel is positive) or away from Body2 (VDOT between position and vel is negative). Also take into account whether Body1 is the one in a lower orbit or if Body2 is the one in the lower orbit. From those you should be able to work out whether Body1 is behind or ahead of Body2. If the lower orbit body is behind the higher orbit body, it should be closing the distance. If the lower orbit body is ahead of the higher orbit body, it should be widening the distance.

I may have time to look at this later tonight. I suspect it's got something to do with the Sun being a minimal CelestialBody that's missing a few things that other bodies have.

We'll probably cave in and fix this at some point. I've wanted to leave it wonky so that people write their own controller from the raw components, but as it's the first thing people see, it's a big problem for the mod's reputation. I don't like people thinking "these idiots know nothing about the project they're working on", when the truth is "they know how it could be fixed but fear that fixing it will deny users of the sense of accomplishment of writing their own." It's meant as a crutch to get people started, not a final perfect solution. But yeah, the resonating oscillations that keep getting bigger over time are a big problem case. I've seen it myself on one of my designs. It seems to be worst when there's a lot of flexibility and bendy-ness to the craft, between the command core and the bulk of the fuel mass, such that there's a bit of a delay between when the command core stops rotating and when the rest of the craft stops rotating. That seems to cause the oscillation cases where over time it swings wilder and wilder until it's uncontrollable. I have Deadly Re-Entry installed and it checks the G forces for pilot survivability. I've had pilots die from experiencing 15 G oscillations during LOCK STEERING during ascent because the rocket was doing the banana dance. I'd still prefer it to be less than perfect and have a bit of wobble, but it should at least be fixed to the point where the deadly resonance feedback gets dampened.

There was an old episode of QI in which Rich Hall was deducted points for saying the Earth has one moon, and he famously raised a stink about it and made reference to it again and again in later episodes (to the point where the show's makers, predicting he'd do it again, made the phrase "Which moon are you talking about?" into another forfeiture). And Rich was right to be annoyed by it because QI was wrong. They claimed the Earth has 2 moons because they counted Cruithne as a moon. ( http://en.wikipedia.org/wiki/3753_Cruithne ). Cruithne is emphatically NOT a moon of Earth. To be a moon of a body and object needs at minimum the following two conditions: (A) It is a satellite of the body, and ( It is not man-made. Questions of whether there's a minimum size or not never really enter into it in this case because Cruithne fails (A). It's NOT a satellite of Earth because to be a satellite it needs these to be true: (A) It goes around the body in a body-centric frame of reference, and ( The gravitational pull between it and the body it goes around, due to their masses, must be the cause of (A). Cruithne fails (. It only "goes around" Earth in an Earth-centric frame of reference because of they way they are both affected by the SUN's gravity on them, Cruithne doesn't go around Earth due to the EARTH's gravity pulling on it. Earth's gravitational pull on it is too weak to account for its motion "around" Earth. Therefore it's not a satellite of Earth, therefore not a Moon of Earth. Therefore Rich Hall needs to be given his 10 points back. Sorry to derail, but that always annoyed me about QI. They take points away on the premise that someone "fell for" a common "incorrect" naive claim, when often it's the shallow research of the QI team that's being naive, as in the case of calling Cruithne a moon.

Yeah, you'd think. Velocity is relative to whatever the CURRENT SOI of the SHIP is. If your ship is around a body, that body's velocity is zero. To do anything meaningful with bodies, it's always a good idea to get things relative to other things, so it works no matter where the current ship is. Subtracting a vector from another vector is a way to eliminate the "where is the real origin?" from the picture.

It's doable now, but the problem is that there isn't a good way to SET TARGET TO the docking port, just the vessel in general. So as long as your target docking port is aligned with the vessel's center of mass, you can sort of do it. But if it's offcenter it's a bit harder. The big problem you'll encounter is that if you have the docking port in a variable, the position it returns to you is currently unusable because of this: https://github.com/KSP-KOS/KOS/issues/277 I did have some success with a docking script, but it has to assume the target's docking port is aligned to its center of mass for now. Do you mean "X = cond ? val1 : val2" ? Not currently. It would be possible, though, if there's enough interest in it.

No. There should be. It's sort of tied into how we'll eventually do functions though, and the relationship between an "exit" and a "return" should probably be established, and of course does "exit" just quit the current RUN SCRIPTNAME or does it kill all the way to the interactive prompt? Yes .... but see here: https://github.com/KSP-KOS/KOS/issues/277 IMO all objects should be able to print their KOS type. They curently can't because they aren't all wrapped inside a suffix-able type. Hmm... changing that would be a really good idea for the future.

A normal vector of Kerbin's orbit plane: set posKerbinFromSun to (kerbin:position - sun:position). set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit). set normKerbinOrbit to VCRS( velKerbinFromSun, posKerbinFromSun ). A cross product of the position vectors kerbin-to-sun and kerbin-to-duna: set posDunaFromKerbin to (duna:position - kerbin:position). set crossSunKerbinDuna to VCRS( (-1)*posKerbinFromSun, posDunaFromKerbin ). If Duna is ahead of Kerbin, the direction of the two cross products should be mostly the same. If Duna is behind Kerbin, the direction of the two cross products should be mostly opposed. set crossesAngle to VANG(normKerbinOrbit,crossSunKerbinDuna). if cos(crossesAngle) > 0 { print "test: Duna is ahead of Kerbin". } else { print "test: Duna is behind Kerbin". }. I am doing this by picturing the vectors in my head and not testing it, so I might have the signs flipped. Give it a try. It should either be 100% right or 100% backward.