Dunbaratu

Woohooo! I just happen to be at a point where I'm retiring a career game and starting a fresh one so I'll be able to give this a test run today.

This are all handy. In the past they required some messy bits of code to get the numbers indirectly (i.e. taking the cross product of my up vector and my velocity vector to obtain a vector normal to my orbit plane, and then dot-producting that normal vector with a Y-axis unit vector (which is always in the direction of a ray pointing up out of the north pole) to work out my inclination angle. That's a lot of lines of code (especially since vector operations like cross product had to be done manually) just to obtain one number that is now just one variable expression.). But keeping things hard for bragging sake is just pointless so I'm very glad you've been adding these things. When I go back to revamping the Duna mission I suspect the addition of these things will allow me to make much shorter programs. I especially like being able to see the encounter without a maneuver node. Having to make dummy null maneuver nodes (maneuver nodes with zero delta V) just to get kOS to report the encounter I'm currently heading for always felt a bit silly to me. I'm very happy that these changes are there, and that you picked up this mod and ran with it.

I thought it was slow because it's parsing syntax from ascii files on the HDD. That's very different from merely reading the bytes of a binary dump of data, and puts the task back into the realm of being CPU bound instead of I/O bound.

Is that valid syntax? I've never seen a kOS "until" loop with no boolean condition expression like that. Is it basically a "loop forever"? (the same as "until false")? The only thing I can think of is that if the file copy operation would cause your local volume to exceed the 10,000 byte limit then the copy will be denied (but it won't tell you that that's why it failed. It will just say it failed.).

0.46676 radians = 26.74368 degrees. All the angles in kOS are given in degrees. I do think that radians would be mathematically better for all of the usual math reasons, but also for a purely computer engineering reason: in floating point representations, the closer to zero a number is the less error it has so ranging between 0 and 2*pi is going to give you more accurate representations than ranging between 0 and 360.

A Minor "bug" report for Random Mission Pack (from devbeta5): I don't know if this is a bug or intentional, but the random variation for Periapsis and Apoapsis with mission number 2 "Early Manned Missions Orbits" often gives me values that require me to set up a degrading orbit that is inside Kerbin's atmosphere and therefore can only look like that for a brief bit. (I'm looking at one now that says I have to have a periapsis minimum of 55,432 and an apoapsis maximum of 65,432.) Because these numbers are not above the atmosphere this describes an orbit that can only look like that for a brief while before it deteriorates. That actually makes it harder to achieve the goal than a higher orbit would be. Can the numbers be tweaked on the next release to make sure they don't include numbers below 70,000? At the moment when I get a goal like that I just reject it and ask for a different random mission to replace it. Sometimes it takes about 10 retries before I get one that is above the atmosphere.

Any chance of resurrecting the challenge, using this new continuation of the mod: http://forum.kerbalspaceprogram.com/threads/68089-0-23-kOS-Scriptable-Autopilot-System-v0-10/

What's weird to me is that I don't understand what the technical reason is that it would be easier to make a 64 bit version stable on Linux than on Windows. Unity says "it isn't stable on Windows" but that's just a restatement of the problem rather than an explanation of what causes it. Could it just be the large number of Linux distros out there that don't turn on 32 bit support libraries by default (making you have to go download and install them separately), and try to run the entire system cleanly fully in 64-bit? In other words it's because of a difference in how necessary 64-bit is for smooth installation - that it came to Linux first because of how many Linux admins (including owners of personal home systems) there are in the customer base that are trying to run a purely 64-bit system from top to bottom. For them, having Unity work on 64-bit would be a requirement rather than just a nicety. So getting Unity to be 64-bit on Linux may be a goal with a higher incentive than getting it to be 64-bit on Windows, and that higher incentive is the reason it's further along on Linux than Windows.

Has lateral RCS control (i.e. the HNIJKL keys) been added to kOS yet? That's probably also needed. Without that it is *technically* possible to accomplish translations by giving the craft a very low TWR (technically TMR) main engine and having the craft spin to point in the direction of the desired translation and give a very small bit of throttle, but this is a bit of a pain and also probably requires a craft with overpowered torque so it can spin abusrdly quickly. (i.e. "I'm about half a meter off to the right, aim left, thrust at 0.001 for 0.1 seconds, spin 180 degrees and thrust again to stop, then spin back to face the docking port again and drift in.") I'm holding off on trying to implement docking until there's some sort of HNJLKL equivalent, but I must admit that the temptation to try doing it the way I described above has been eating away at me. I just don't want to bother if it turns out that it becomes moot by the time I implement it because translation gets implemented.

Basicaly "Aliasing" is a term for the sorts of weird artifact behaviors you get from digitizing something analog, and anti-aliasing is any sort of technique designed to try to combat aliasing. Aliasing often happens in the time-dimension when taking discrete samples of a repeating analog thing and the sample rate isn't fast enough to give you enough "in between" positions to see the repetition properly. (i.e. if you use a film camera that captures video at 24 frames a second you can't get a proper animation of a wheel spinning at anything faster than half that (12 revs per second). It will start looking like it's standing still, or going backward. And that's assuming the wheel has some obvious visual feature you can use to see how far it's rotated (i.e. a line painted marking a radius from edge to center.) If the wheel has symmetry that repeats several times through its rotation (i.e. spokes every 30 degrees so you can't see the difference between it rotated at 0, 30, 60, 90, etc degrees and they all look the same) then the problem happens even at much slower wheel speeds. This sort of effect you see in old westerns, where the wagon wheels rotate backward in the film, is a kind of aliasing.) In pixelized graphics, one type of aliasing that occurs is to have jagged stair-step diagonal lines when the analog thing being simulated was meant to be a straight line. This happens in font renderers as well as in 3d graphics renderers. In that specific context, anti-aliasing refers to making the pixels along the edge of the line a shade partway between the color on one side and the color on the other side of the line rather than just making them fully one or the other color. The human vision processing system is used to dealing with less than perfect resolution from its retinas, and having to "cook" the data quite a bit before your conscious brain sees it. When it sees an area of one color next to an area of another color, and the sensors right on the edge between them are registering colors partway between those two colors, it will pick this up and interpret it thusly: "my retina isn't high-res enough to resolve exactly where this edge is, and so I'm getting a bit of a fuzzy result here. If the color I'm getting from this pixel on my retina is closer to the color of the area on the left than the color of the area on the right, then that's telling me that the real location of the edge is closer to the right side of this single data pixel than the left side of it." The purpose of computer graphics anti-aliasing is to trigger this behavior that the human brain is already hardwired to perform. The brain is already used to interpolating between the "pixels" of its retina. By feeding it information simliar to what it's own retina would feed it if it wasn't high-res enough to resolve the pixels of the screen, it makes your brain "see" the smooth edges just like it would when viewing an object that's naturally coming out "pixelated" on its own retinas (due to fog, or poor focus, or the object being too distant, etc). And yes, your retinas really do have pixels and really do have to register images in a "digitized" way - unable to see the data points between 'pixels'. It's just that your natural "pixels" aren't arranged in a nice regular Cartesian grid like they are on a computer screen. It's more like a random shotgun scatter pattern.

I'm looking for a brainstorming list: What sorts of mission goals for kOS do people think make sense as milestones for kOS users to try to "hit" in a missions-based career using the mission control mod.? One example is "make a successful hover script and run it on Kerbin". (For example, the mission goal could require remaining within a very narrow altitude tolerance window a hundred meters up from the launchpad for 1 minute.) What I'm looking for is the sorts of mission goals that indicate important milestones in getting kosscript software to work, and (hopefully) things that would be hard to do if flown manually (like the hover example). Other ideas I've had but I don't know if they're implementable using the Mission Control mod as-is: - Successfully bomb an object on the ground from above. - - (more advanced version) do it while moving horizontally at at least 50 m/s (so it's not just a straight line vertical drop and you have to calculate the arc of the shot). - Land atop an existing base craft on the ground, merging with it using a docking ring mounted on its top. Also, good "easier" missions for earlier in the "plot" would be good too.

No but what kOS does do is have code that attempts to save the state of execution at the moment the craft goes on-rails, and then start it up from that exact moment and continue from where it left off when the craft comes back off-rails. But up until now that was never working right because it broke when trying to load the variable state in that well known bug. I never got as far as testing the execution continuation because the inability to keep the variable state made it irrelevant. (Yes, I know the problem could be avoided by only using small numbers and no strings, but the algorithm required remembering some strings and some big numbers so that wasn't practical.)

I wrote a long post here but there was no point. I realized it was just a repeat of what I already said that you've already decided isn't relevant, even though it is. I won't be trolled into arguing in circles like that.

Has work been done getting rid of the old problem of deleting vessel parts when going on/off rails while a program is running? I had been working on a missile platform in space ages ago but put it aside because that problem made it untenable. (The idea was to use it as a means of playing with multiple computers on a vessel sending information back and forth to each other (i.e. the platform sends parameters to the missile's computer to tell it which thing to target and then fires it), but the design required that the missile platform's computer still be running active code up to the point where it got 2.5 km away from the missile, and that meant when I switched back it it it was half deleted.)

It is probably a very similar effect though as this is a common problem with KSP mods in general (not just kOS). It has more to do with the behavior of how KSP runs mods than anything else. KSP is not very forgiving of having mods that error out when parsing the persistence file. Whenever a mod throws an untrapped exception when trying to parse its portion of the persistence file what KSP does to try to get its parsing algorithm "synced" up again and back to a known normal state is to jump to the end of the vessel definition (skipping past the rest of the parts on the vessel). It's sort of like how when parsing C code, most parsers will skip to the next semicolon to get synced up again if the state of the parse is too confused. (Therefore if one line of code contains two errors sometimes the second one won't get noticed until the first one is fixed.) In the case of KSP, the sync point in the parse is the ending curly brace of the vessel section.

A new type of science data that consists of point-source things in the midst of biomes rather than just wide-area biomes, and a new part to help detect them. For example, detecting specific locations where geothermal activity is under the surface, or detecting specific locations where a rare mineral is there. The idea is that this gives a reason to bother roving and exploring.

A computer should be able to copy data from a thermometer or gravioli detector easier than a Kerbal can. Currently it can't. Copying data from the instrument to a computer core shouldn't require a manned mission.

There's a separate development thread? Maybe my previous post should have gone there instead.

In a real world computer, the computer has to be manufactured with a fixed number of CPUs and software running on it can't arbitrarily manufacture more of them on the fly. It also can't execute any arbitrary expression in fixed time. You cannot execute an expression consisting of 10 math operators and one consisting of 2 math operators in the same fixed time as each other. These differences make trying to use terminology humans developed for real world computers break when you try to apply them to kOS. The differences are large enough to warrant using new terms for them. And to get this on topic about the kOS mod, I suspect this is part of why kOS bogs down KSP and makes it stutter. kOS is pretending that its simulated computer executes things in constant time that on the underlying computer take vastly differing amounts of time. When the next batch of 5 operations that it wants to finish in the next timeslice actually take longer than the timeslice KSP expects a mod to finish its callback hook in, KSP has to pause simulation waiting for the mod to finish. So thus the simulation's clock will claim kOS is constant time when in reality it's not. If the algorithm was changed to not always execute the same number of fixed instructions per callback and instead watch how long they're taking, and stop when it's running out of time for this particular slice (thus executing a varying number of instructions per slice), that might help.

It is. "Velocity" *is* Orbit:Velocity. But "PROGRADE" is not. Prograde is a Euler Rotation and not a vector. That means it contains information about the direction a ray is pointing but not information about how long that ray is (which is why it's not a vector and why MAG won't work on it.) The tuple of 3 numbers in a Euler Rotation (which kOS calls a "Direction") instead of being x,y,z coordinates are actually rotation angles in degrees. The exact type of rotation is badly documented and it takes a lot of trial and error to work it out (which is why they're a pain to work with. You don't know the order in which the rotations occur (which changes everything) and you don't know whether they are intrinsic or extrinsic rotations (which also changes everything and affects the issue of gimbal lock).)

In fact making them rare makes them LESS fun. Because it then becomes unreasonable to expect players to have experience with it, so that when it does happen players feel as if the game betrayed them unfairly. Also, think of the tech support nightmare. The game *already* has a few bugs that cause things that should never happen to happen, like space stations exploding the moment you load them from the tracking center because collision detection "turns on" before all the variables got fully populated yet. Now imagine the flood of people reporting "my rocket blew up for no reason" as a bug, and then tech support having to try to sift through which of the complaints are intentionally unreliable behavior and which are bugs? Deliberately creating random failures would mask the behavior of real bugs.

I too find this annoying but I think the first blame lays with theoretical physicists' love of using oversimplified explanations and terms for situations in which a correct explanation requires a bit more verbosity. The claim that observation *causes* the experiment to give different results comes right out of that tendency for oversimplification. It's not that the observer's mind causes the change to the results, but that there is no physical mechanism to detect something without changing it. Take vision for example. For an object to be visible it has to reflect light and the act of reflecting that light that alters the material of the object. It's not the fact that you put an eyeball attached to a human brain in front of that ray of reflected light that caused the change to the object. The change already happened *prior* to the observation. The change happened at the moment the light got reflected off of it. What the observer effect is really saying is that all the physical means by which any phenomena may be detected are things that must cause a change to the thing being detected. But the way it's always *phrased* is to act as if it's the act of observing (meaning a conscious mind is doing it) that causes the change. And that's horse****. If you measure a phenomenon with a machine and then throw away the results without looking at them then you never observed the phenomenon, and yet the "observer" effect was still happening because it had to in order for the non-thinking non-observing machine to be able to take that measurement. To say otherwise is to violate space-time - because the act of observation occurs AFTER the thing it's measuring. It's not that the act of observing a phenomenon changes it. It's that whatever it was that caused the phenomenon to become observe-able changed it. Whether you choose to make use of that observability or not.

Now that the kOS Mod has been resurrected I've been trying to work out how to make some mission configs for it using this mod - things like "gain X science points for a successful Hover that remains within +/- 5 meters of the target altitude on Kerbin." or "gain X science points for a successful landing on the runway" and so on. The point being that these would be tests of the ability of the player to write bits of kOS script that accomplish hard tasks. But to do this properly I'd need some sort of MissionGoal check along the lines of "no player piloting inputs occurred during this time". I think just checking for the use of the yoke (WASDQE) and throttle (Shift/Ctrl) is probably enough but the hard part would be ensuring that it still allowed those controls to be used if they're used by kOS code, and still allowing the keyboard to have those keys pressed as long as they're being pressed in a terminal window and not controlling the craft. Is a thing like that reasonably doable?

The problem is that the air won't fall in a nice neat little cylindrical slice because the edges of that cylindrical slice are in contact with the non-falling air outside the cylinder. You'd get a lot of messy swirling currents both in and out of the cylinder from that contact.

It's incorrect to use the term "challenge" to refer to a failure you have no control over and isn't your fault when it happens. The main reason random reliability failures for parts is a bad idea in KSP is because the design and manufacture of those parts is entirely out of the player's hands. UNLIKE in a real space program. If the manufacturing process is creating parts that fail, there are people who's job it is to fix that. In the real world if a manufactured part fails, there are human beings ultimately responsible somewhere in the chain. In KSP that is not true.