Dunbaratu

I'm not the only one interpreting it as a minus sign. the game ITSELF is doing that. When you select a target it chooses to arbitrarily call the inclination either positive or negative and I am trying to determine what it's using to decide that. Even if my LAN and my target's LAN are at the same spot, if our inclinations differ they will sometimes be called positive and sometimes negative. If inclinations are not signed, then what is the game saying when it says my inclination is "-2.1 degrees"?

That is not true, because the reference direction does not rotate with the planet. If the reference direction were, hypothetically at 0 degrees longitude at some moment in time, it would be 180 degrees longitude exactly half a day later as the planet rotates and the reference direction does not.

A while back people were posting about wanting to get the normal and anti-normal directions for maneuvers and steering. Just today I was trying to work out how to obtain inclination angle and as a stepping stone to that I also got the normal and anti-normal calculations based on the limited information available from KOS. I added a thing on the wiki for it here: http://kos.wikia.com/wiki/Tutorial_-_getting_normal_vector Shorthand explanation: A while ago I worked out how to transform any of KOS's Directions that get expressed as Euler rotations into unit vectors in XYZ terms instead and put an example of that on the wiki. It just occurred to me today that since this means I can get the UP direction as a vector, and I can get the velocity as a vector, that this gives me two vectors in different directions that are both in the plane of the orbit. that means their cross-product is a vector normal to the plane of the orbit. If you are trying to make an inclination-changing burn, you can continue running the code to recalculate the normal vector in a loop to keep changing the steering as the inclination changes.

Here's why the sign matters: Two satellites which both have an inclination of +5 relative to the SOI body, and which cross the equator above the same point on the planet have zero inclination relative to each other. Two objects, one of which has an inclination of -5 and the other of which has an inclination of +5, which also cross the equator at the same point on the planet have an inclination difference of 10 relative to each other.

I'm trying to do some stuff with the KOS mod about orbital inclinations and I figured out how to calculate the inclination from the current velocity vector, but I have no idea what KSP uses to decide which tilt is as positive angle and which is a negative angle. The inclination is simply this: arccos( magnitude_of_y_component_of_velocity / magnitude_of_entire_velocity_vector ). (since "Y" is always the axis of the SOI body's north pole direction.) But the problem is I can't tell the difference between, say, inclination of +5 degrees or -5 degrees. In other words, what does KSP use as the "reference direction" in this diagram from wikipedia: And anything I can think of to use as a reference point is something that would keep changing: It can't be based on which side of the orbit has the periopsis and which has the apoapsis because if it was then objects with matching inclinations but differently shaped orbits could have opposite inclination signs from each other if it worked like that. It can't be based on the longitude lines of the body because the planet rotates once a day (it's day) underneath you and what had been an ascending node at a chosen longitude might eventually become a descending node at that longitude about half a day later as the planet turns on its axis. It can't be based on which side of the planet its orbit around its parent body comes out, for the same reason - it rotates around once a year (it's year) as the reference flips around to the opposite half a year later. For this reason in the real world astronomers use a reference point external to the solar system. The reference direction they use is to point at the constellation Ares. If your orbit goes above the equator when on the Ares-facing side of the planet, it's a positive inclination. If your orbit goes below the equator when on the Ares-facing side of the planet, it's a negative inclination. But how does that work in KSP? There's nothing external to the solar system. What is the reference direction KSP uses to decid whether an inclination is positive or negative?

According to a comment on the github issues page there might be a workaround for this (although I haven't tested it myself yet). If you explicitly use velocity:orbit instead of velocity it apparently doesn't have the problem even though they're meant to be synonymous. So this works: set vel to velocity:orbit. print vel:x. Where this didn't: set vel to velocity. print vel:x. You will need the temporary in-between variable "vel" and can't just do "velocity:orbit:x" because the parser doesn't like multiple colons in the same term. Like I said I haven't tried this myself yet. I'm just parroting what someone said in a github issue. I hope it works.

But in this case there's also the secondary problem that trying to use the :x, :y, and :z operators on the velocity vector is bugged. So even if you know the coordinate system it still won't mean the code will run right.

There is a bug on github about something being broken with the velocity vector, and unfortunately it's broken as far back as 0.7 as well. The thing that's broken about it is this: you can print the velocity vector and it shows all three parts just fine like so: V(123,456,789). But if you try to obtain a single component of it like so: print velocity:x It says: NULL. So something is wrong with KOS and the XYZ parts of velocity. I don't know why.

Narrowing it down to a repeatable circumstance to trigger the problem is a prerequisite before that would be helpful. That's why I'm trying to gather data from others on the forum who had the same problem.

I would strongly suspect it's actually the other way around. The terminal not responding is probably the highest level side-effect of the bug, if you will, not the lowest level causal effect of it. Anything that makes KOS stop running properly will make the terminal fail like this. The reason the terminal fail is a commonality of so many bugs isn't because it's causing the bugs, but because its failure is a common effect of anything that breaks the execution of the SCS's CPU.

Screenshot of the ship disappearing bug, with debug log. Here's a screenshot of the original vessel: And here it is after the bug "ate" most of it: Note the debug log showing the KOS exception in red. "masterTorch", do you get the same KOS exception when the bug happens to you? (You have to do a "view image" and explode it to full size to be able to read the red text in the debug log on the screenshot). I also note that when I rotate the camera the interface is still behaving as if the center of the ship is in the right place for where it would be if all the parts were there. In other words, see how the disk that's showing is offcentered? If that was all there was to the ship it would be centered on the screen because the camera always aims at the center of mass. That makes me think that KSP sort of 'halfway" thinks the parts are still all there but you can't click them or do anything with them or see them.

Maybe not exactly like the original post suggested, but I do like the idea that in career mode the Tracking Center technology starts off pretty crude, and gets improved by missions you perform. Historically, for the first few Soviet space shots, they had to rely on the brand new tracking station the British built at Jodril Bank, as it was the first of its kind in the world, to prove the shot worked. They didn't "officially" use them, but they "leaked" information about the shots and knew the British would want to track the occasion for their own purposes. Then they watched for their reports in the newspapers as proof. The space race didn't just mean that the vehicles had to be built from scratch, but also that the complex network of how they're tracked had to be built from scratch too.

Nah, not Kerbal enough. For the first Spacewalk of career mode, no EVA pack AND no tether! Just festoon the craft with handhold ladders and warn the player to NEVER hit the "F" key. Then make it so only kerbalnauts with high courage and high stupidity are willing to go on the mission.

Technically there's no reason it can't work to have liquid-filled tires. In most ways pneumatic and hydraulic physics behave similarly, where a gas behaves like a very runny liquid. But I can't see an advantage to it.

I can't comment on the other problems, as I decided to just use 0.7 for now until things are more stable again. But THIS problem I've seen before a LOT, and not just in 0.8x. Normally I prefer to play KSP with permadeath - meaning I don't manipulate the save game folder and I just accept it if I die and crash. But ever since using KOS I have had to abandon that and use save-scumming by backing up savegame folders behind the scenes so I'm able to revert when something goes haywire. This is because a lot of the time the disaster isn't my fault but a bug. This "half the ship disappears" problem is one I get a lot. I hadn't noticed before that it was always disconnecting RIGHT at the spot where the KOS SCS part is attached. But you're right, it is always right at that spot. That might be relevant? I've wanted to make a bug report on it in github but I just can't get a consistent set of circumstances that trigger it. I figure until I have that there's no sense in reporting it. (Programmers HATE it when bug reports don't tell them how to make the problem occur. You can't discover the cause of the problem that way, and even if you can make a good guess about it and try to fix it, to prove it was fixed requires being able to see a difference between the "before" behavior and the "after" behavior. And that means being able to have a test to run that had previously made the problem occur.) Maybe since we've both seen this happen we can help trace down the exact circumstances that cause it. For me, the following have always been necessary but not sufficient conditions to make the truncating spaceship problem happen: 1 - Prior to the spaceship truncation, some other error with KOS caused the terminal to stop responding to typing. Sometimes just to the point where toggling the SCS power will fix it, and sometimes even worse where all of KSP freezes up and it has to be killed externally (from Task Manager, or kill -9 for unix people). 2 - You make the vessel containing the KOS piece that had the error have to be reloaded from rails back into the full physics engine, either by traveling within 2.2 km of it with another vessel, or by switching to it in the Tracking Station. Unfortunately although I know those two things seem to be required for it to happen, they don't seem to be sufficient to make it happen every time.

I have a suspicion this may be related to when KOS was changed to use doubles instead of floats everywhere. I don't know for certain if this is true but it seems likely. At any rate I made an issue about it on the Github and we'll see what Kevin says about it. The problem (maybe?) is that ETA:Apoapsis is returning a native value from the KSP API library directly to the user, as-is, without casting it. Back when all the variables in KOS were single-precision floats this was fine. But now that the system assumes all variables are doubles, this effectively gives you a single-precsion float stored in a variable and the rest of the system assumes that can't happen.

If LOG is used to print values to a file on archive, then a quick diff can use used on the file to compare it to what it said last time. This doesn't cover all the things that need to be tested but it can cover quite a few. For example, if there had been a test script that contained a simple bit that runs an until loop 3 times and prints "1" then "2" then "3" to a log, then the fact that curly braces got broken would have caused that output to be different than it was before (it would fail to print the 1, 2, and 3). If you have a simple diff check on the output from the expected output it would have flagged a problem that would have made it clear that the new version had broken something. Similarly you could have a bit of script that just prints the results of every math function, prints the meaning of every special variable and so on. What may make sense is to not only have a fixed known test script to run, but also have a fixed known save game to run it in, on a fixed known vessel at a fixed known location and a fixed known time. (So the test would involve loading that vessel and running the test script on it as soon as it loads. There would be some minor variance in the output LOGs because it would be impossible to run it at precisely the same instant of time to get the exact same velocity, prograde directions and so on, but as long as the values were checked within a degree of allowed error it could still detect if something really odd was different.) Actually now that universal time is going to be supported and not just mission time, it may be possible to make the test script wait for a known instant of time to run in (some instant a minute or so after the point when the saved game is), to help ensure less variation on variables like velocity vector and prograde directions and altitudes and so on.

I wasn't referring to the bit about parameters. I was referring to your question about not knowing if variables have always been global.

That's been that way all along.

There's some stuff Bizz added to the wiki about how you can go about making any other part in the game into a KOS computer by using another mod that lets you alter the configs of parts. I'm not using it because I'd rather design craft that work "out of the box" and can be shared, but it does look like a good solution if you don't have that as one of your goals.

It's using the old Commodor 64 font, which someone on the internet has translated into TrueType. I can confirm that it is hard to tell "(" and "{" apart in the font because I tried using the same c64 font in my external text editor and had the same problem as in the game's editor. At point sizes of 8,9,and 10 it's hard to tell. It has to get up to about 12 before you can see it well.

Just a warning. 0.8 is unusable at the moment. The parsing of curly braces doesn't work right anymore if they span more than one line, making any code of significant size not work.

Please read the preceding posts in the forum that came between your last post and this one. They describe how version 0.8 is broken in this regard.

It should be possible to work it out using this logic: Your path follows a sine wave when projected onto the planet surface, where the equator is its center line. You can ignore all the components of the velocity vector other than the Y component, because Y is always the SOI body's northward direction (NOTE 3-D north, not surface north. In other words if you're near the pole it's pointing UP, not at the north pole.). So you can basically transform it into a one-dimensional sine wave pattern (like a weight on a spring oscillating up and down) that way. Your latitude combined with your altitude and the body's radius can give your Y position and your Y component of velocity is your Y velocity. So basically you have a snapshot of "I am this far off the center line, and I am moving at this speed up (or this speed down)." to work out the parameters of your sine wave oscillation, including where it peaks (which tells you your inclination.) Yeah the problem is you have less data about the target than you do about yourself. You can't get its velocity.

Inclination from SOI body, or inclination from target vessel? If it's from the SOI body I suspect it's possible to work it out based on your current latitude and your orbital velocity vector. If you want it based on the target vessel I think that might not be possible with the currently available data.