Dunbaratu

re Question 1: My suggestion: set mythrot to 0.1. lock throttle to mythrot. // From now on when you want to change throttle, do it indirectly by chaning mythrot. When you want to print the throttle, print mythrot instead. re Question 2: Why does your code multiply the mass by 10 when calculating TWR? Why not use 9.802? Without quantifying "the value doesn't really come close" it's hard to say anything more than that.

Why is this report tagged as intended behavior? The overlay is clearly showing cyan arrows on the left side that aren't appearing on the mirrored part on the right side. If that's meant to be correct then clearly we users aren't understanding how the game is supposed to work, in a major way. Can that be explained please rather than just claiming it's correct without any commentary whatsoever on why? Because it certainly doesn't *look* right.

Other Linux users have reported success using this mod: http://forum.kerbalspaceprogram.com/threads/108561-0-90-%28Jan25-15%29-Control-Lock-Input-text-into-text-fields-without-issuing-commands-to-your-vessel?highlight=kos It basically lets you override how the game is delivering your keypress events to different parts of the game, and force them to go to the window you want. The likely reason you're having trouble is that the R and E keys are being consumed by some other mod or some part of the stock game before kOS is allowed to even know they exist.

Linux? I ask because Unity stupidly made some differences between how keycodes are dealt with on different OS ports. These are differences that the actual host OS does not require them to make, but they did anyway. (i.e. Unity's fault, not Linux's fault). This has bit us before in kOS in regards to Linux. I've never ever heard of this one before, of specifically the "R" and "E" keys not working when everything else does work.

I'd recommend that you get an initial guess on the vector at that point, get started aiming toward it, but then recalc it with another reading just a few seconds before you burn, as it may have moved by a few degrees since then (or more accurately, the universe axes may have rotated since then, making the previous X,Y,Z components incorrect under the new rotated universe.)

First you've got to get the LAN vector in the first place, which is where the sticking problem was. LAN is expressed in degrees rotated from the universal reference direction, but that universal reference direction is hidden from a kOS script at the moment (although there's a messy way to derive it if you have an orbiting object to use to reverse engineer what it is).

I had originally said you can use any orbiting object, like the Mun, but now that I think of it, the Mun may be a problem given that it is locked on a perfectly zero-incline equatorial orbit. That means its LAN isn't particularly meaningful. I suspect the floating point math will be most stable if you use an object that has the best of both worlds, being both inclined (unlike the Mun), and locked on rails (unlike your ship). Minmus would fit the bill well I think. One of them. I did a lot of work a few months ago - adding functions and local variables, and a few months before that, adding executable suffixes (previously suffixes were passive members that can't take arguments) - but lately I've slowed down a bit and the next update likely won't have a lot of my own work in it. I'm in danger of leaving it too long so I'm starting to forget the archetecture and get rusty. I've got to pick a project and dive back in again.

In discussing this with devs, one of the others (hvacengi) did have a way you could use to calculate the Reference Direction indirectly. I consider it a stopgap until a new release is out that just returns the value directly, but for now you can do this: Even though your intended orbit itself has no item in orbit yet, plenty of other objects do exist in orbit and you should be able to use one of them to get the value this way: step 1 - Pick any object you like that is orbiting your same SOI body as your intended orbit (i.e. your ship, or maybe the Mun if you're in Kerbin's SOI). step 2 - Get that object's following orbital parameters: Longitude of ascending node (otherLAN) , Argument of Periapsis (otherAOP), True Anomaly (otherTA). step 3 - run this calculation: SET UNI_LONG to otherLAN + otherAOP + otherTA. You now know what the universal longitude of THAT object is right now in it's current position. "Universal Longitude" meaning its angle around its SOI body relative to where the Reference Direction is. From that, if you like, could could derive the Reference Vector. You know what that object's PLANETARY longitude is on its SOI body, and what its UNI_LONG is - the difference between them tells you how far your SOI body is rotated from the universe's Reference Direction. With that, you can convert the orbital LAN to a planetary LONGITUDE. (remember the planet is rotating so this is only temporarily true for an instant). From a planetary Longitude you can get a GEOPOSITION, from which you can get a XYZ position. That is the position of the Ascending node in XYZ space right now, or at least the position of the surface of the planet underneath it, which is good enough for what you need (it will move, so use it fast to come up with your needed info). It's a lot of steps and you shouldn't have to go through that, but it may be a while before there's another kOS release so you might have to do this. I deliberately left the actual code for you to write, because if you're using kOS it's probably because you want to do that sort of thing yourself.

At periapsis, you will have a retrograde direction lined up with the horizon. Presumably what you would like to do is start firing in that direction just a bit before you get there. So try velocityat(ship,eta:periapsis):orbit to get what your orbital velocity WILL be at periapsis, then aim in the negative of that vector to get the retrograde version of it. Warning: Because KSP's coordinate system is slippery and likes to change without warning, be sure to take that prediction reading with velocityAt fairly soon before you do the burn. Don't take the reading from the other side of the moon while eta:periapsis is still like 10 minutes into the future, and lock steering to that. Instead take the reading just a few seconds before you're planning to start your burn - just enough time to get your ship rotated to the right heading before the burn.

The missing piece of information is what is the Reference Direction of the KSP' solar system, expressed in whatever the current game's XYZ axes are rotated to, which varies as you play the game for complex reasons, which is why it's not just always the x axis or always the z axis. The Reference Direction is some arbitrary made-up direction that stays constant (even though if expressed in XYZ coords it won't appear to be constant, because the universe's coords rotation changes every time you ascend/descend to a planet or moon and the game swaps between planet-fixed and planet-rotating modes.) Usually in Astronomy the Reference Direction refers to some distant star that doesn't move much over time relative to our solar system but is findable in a telescope. That's why we're helpless to figure out what it means in KSP - there is no such thing as a distant star on which to base the vector - the universe outside the solar system doesn't exist - that backdrop of stars is just a fake painting. Without that Reference Direction, the Longitude of the Ascending Node is meaningless, and it's THAT that you need to really answer the question. In other cases we've been able to get around this problem because there's an object actually in the orbit so you can get the normal by looking at that object's velocity vector and its position vector. This works great for trying to match orbits for a rendezvous or a dock - but for an orbit that doesn't exist on any object yet, you can't get that information. In digging through the mostly undocumented KSP API over the last hour or so, trying to find anything called a "reference direction" of any sort, I come up with a google hit or two where other modders claim "Planetarium.Right" might be the reference direction of the LAN. If so, then at the moment you're out of luck because kOS doesn't expose that information to scripts. But if the mysteriously named "Planetarium.Right" is the undocumented secret reference direction of the orbital parameters, then kOS should be updated to expose it, as it is necessary information for the rest of the orbital parameters it returns to be complete. I've made an issue for this over on the kOS GITHUB site. But I don't know how long it will be before a release containing it is out: https://github.com/KSP-KOS/KOS/issues/1116 - - - Updated - - - The difficulty the OP is having is that in this case there is no such object to get a position and velocity of, because the orbit is a contract parameter defined ONLY by giving the Keplerian values as described. These are the sorts of colored hypothetical future orbits you see in the game when you accept a contract for a satellite but haven't fulfilled it yet and the map view has a colored orbit with nothing in it to help show you were you need to end up. Those sorts of "orbits" don't contain any current object in them.

A super useful feature would be an ability to do a generic text search on the description text and relationships in the metadata area. This would be to help in the situation where you're thinking "There might be a mod that does such-and-such but I would have no idea what it's called if it exists." Often the mod name doesn't really generate hits on any sort of search term you'd think of.

One of the things that can make RemoteTech tedious is that you can't make self-correcting station-keeping satellites in KSP. No amount of knowledge of autopilot coding, no amount of expertise with C# or kerboscript, will help fix the fact that KSP itself cannot have multiple vessels all being "active" at once, all self-correcting themselves like a realistic set of satellites can do. Again, it's not a player limitation, nor a thing a mod can fix. The base game itself demands that the only part of the universe that can currently operate with the full simulation environment is a small sphere within a near distance of the camera. Everything else is frozen on rails. You can write all the station-keeping code you feel like in something like kOS and it doesn't do a bit of good unless you occasionally interrupt yourself every few days of gametime to re-focus the camera on the satellites so the KSP game engine will actually allow them to get off rails and do adjustments. It would be handy if the main game allowed you to sync a few satellites in orbit to each other and lock them on rails TOGETHER as a locked SET, to simulate the stationkeeping that the game engine's limitations currently makes impossible. It could have tight narrow tolerances and say that before you tie them together into a locked set, you must first put them within very closely the same orbit, just differing by phase angle only - then it could put them all on the "same rail" - remembering their phase angle offsets and locking them all to one satellite (i.e. remember that satellite C is 120 degrees behind B, which is 120 degrees behind A, and then just calculate A's position on rails, and derive B's and C's positions as being locked at 120, and 240 degrees off from wherever A is.)

Just tried it - this fixed it. Does SQUAD have a set of consts or an enum that gives a good mnemonic for the layer numbers or do I just have to call it '15'?

The cooked steering in kOS currently is broken for dealing with the case of a ship that gets all its control authority from engine gimbals and rcs. The fact that RO nerfs the torque wheels messes it up. While it doesn't exclusively use the torque wheels to move, it uses them to do some math to *decide* how to move things and that math comes out wrong. I don't understand the details, but it's a part of the system that hasn't been touched in ages since the early days. We're considering gutting the whole thing and doing it over from scratch rather than trying to debug what's there.

Can you write this up on Github? I think I have seen a similar problem before but it's been hard to reproduce - if you have a set of circumstances that reliably recreates it that would be useful for getting it fixed.

Also, in addition to what the others said above, be aware of this: You'll have a much easier time if you leave the 1000 multiplier out and just store your weight variable as weight in kilonewtons rather than weight in newtons. This is because all the other forces and masses are returned in the *1000 scale already. This is the way the game "thinks" under the hood all the time. To help reduce floating point error it's better to work with smaller magnitude numbers. When the stock panel shows a value like "mass: 0.2 tonnes". that's not just how it displays to the user. That's really how it's doing the math itself too. The PART:MASS for that part will be returned as 0.2, not as 200.

Uhm. Can you elaborate a bit further what you mean by this? Do you want to run a kOS program outside of KSP? In a sense, the kOS mod *is* the emulator, in the sense that the kOS computer doesn't really exist as a hardware device anywhere in the world right now, and only exists in "emulation" inside a computer game. There's a sort of neverending slow refactor of trying to divorce all the things kOS does that don't use Unity from all the things it does that do need Unity, with an eye toward us eventualy being able to run unit tests of small kerboscript "proof" programs as part of the build pipeline, without having to run KSP to do it. But that's a major task that's only being embarked upon half-heartedly in small pieces, because it's not "interesting" enough. If that ever goes further, it would have to include a kOS virtual CPU that lives outside of Unity and runs scripts so long as those scripts never need to call SHIP:, or VESSEL:, or BODY:, etc.

To be pedantic, the way the question was phrased, it just said "first game", not "first computer game" or "first video game". So I'm going to go with tic tac toe. I'm guess the very first game probably was peeka-boo, but it does explicitly say it has to be a game I actually *remember* playing.

The record of the live stream from tonight is now up on Twitch: http://www.twitch.tv/dunbaratu/c/6959259

This may help you: https://github.com/KSP-KOS/KSLib/blob/master/library/lib_navball.ks

It's literally just spitting out exactly what the KSP API says, for this: Vessel.horizontalSrfSpeed I have no clue why that is returning weird numbers that don't make sense.

Clarified timezone info on stream feed announcement. My timezone is listed as UTC-6 on most websites, but they failed to mention it's UTC-5 during daylight savings.

I finally decided to fix a time for my first episode of twitch kOS demos and stop putting it off. (This is what I first talked about here: https://www.reddit.com/r/Kos/comments/39qgjn/any_interest_in_a_regularly_scheduled_kos_live/ ) TIME IS GIVEN IN TIMEZONE UTC-5 (US CDT, UTC-6, +1 for Daylight Savings). Please adjust accordingly for your location. BROADCAST DETAILS: twitch channel to watch: http://www.twitch.tv/dunbaratu/ start time: UTC-5 (US CDT: UTC-6 + 1 for daylight savings): 7PM on Tuesday night, 14 July 2015 duration: between 2 and 3 hours, depending on how fast we go thought it* Be gentle. I've not done twitch much before. Subject: Rescue a stranded orbiting Kerbal with kOS. (Like the career mode mission, but demo'ed in sandbox for debugging reasons.). Sub-steps: Focus on inclination matching and rendezvous prediction. Less focus on the initial ascent and final re-entry. (Those topics are often covered well by others. I may start from already being in orbit.) Format: I am already solving the problem in my own code ahead of time, but intend to re-type it all in and explain as the stream goes on. You can stop me as I do so if you need a thing explained better, or have a better idea. The stream will be a mixture of code typing and crude hand-drawn math formula derivation, and running the code.

Thanks, I'll give that a try. I really wish SQUAD had used an enum or mnemonic constant integers for the layer numbers, to make it clear how they meant for them to be used, so instead of saying "15" you could say "UI_LAYER" or some such. You could then also get a listing of all the layer numbers and what they mean, instead of having to rely on the modder community reverse-engineering what they are.

To add to this: triggers don't actually get turned on until they're mentioned in the code. set x to 1. print "one". wait 1. print "two". wait 1. when x = 1 then { print "x is one". } print "three". wait 1. Will print something like this: one two x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one three x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one x is one The trigger that prints 'x is one' doesn't really become active until the point in the program where it was mentioned.