Gaius

No, nothing I said requires the numbers to change depending on the time of day. The system is relative to Kerbin, and rotates with it. But everything I posted is true nonetheless. If your velocity is <x, 0, z> at your current point on the surface, it'll be <-x, 0, -z> if you were 180 longitude degrees away. It's "universal" in that sense. <x, 0, z> is the same direction no matter where you are, which may make it the opposite direction relative to the surface at that point (i.e. if it's motion due east where you are, it'd be due west 180 degrees from where you are -- the same direction from a "universal" point of view, but opposite relative to the surface at that point). I guess "universal" is not the best term to use here. Or it is, kinda, with the understanding that your current sphere of influence defines the "universe". The point being, the numbers don't change depending on where you are within the sphere of influence. At a given moment in time, everyone flying in the direction <x, y, z> will be flying parallel, heading towards the same star.

You would think, but no, that is not the case. Why the offset, I'm not sure...

Because you're not at the right place on the planet, and it's not a spherical coordinate system. There is one particular point on the equator where your velocity would be <0,0,174>. On the opposite side of the planet, your velocity would be <0,0,-174>, and at 90 degrees from those points you'd find <174,0,0> and <-174,0,0>. <0,0,174> always indicates a particular direction in universal space, which is the opposite of the direction you'd be moving while on the opposite side of the planet. The center number will always be zero since it indicates movement along the Y axis, which is identical to the planet's axis since all Kerbol's planets have no axial tilt. At the north pole, <0,1,0> would be moving straight up, whereas at the south pole, that'd be the direction of the ground. In other words, the same direction in universal space, just the opposite direction relative to the surface of the planet at those locations.

No, you put as much antimatter in the container as it can safely contain should the magnetic bottle fail and the antimatter impacts the container walls. If you need more, you use multiple containers, and if the containment on one bottle fails (and it will -- if you don't understand Murphy's Law, you don't become an engineer), you're out a fraction of your fuel supply, but the ship does not explode. An ejection system is pointless. If the containment fails, either the container contains the explosion or it doesn't faster than you can do anything about it. Indeed. It remains an open question whether antimatter really has a better energy density than other sources, once you factor in all the support equipment necessary to use it without blowing your ship to kingdom come. Not arguing with the sci-fi aspects of this. Just that when you say "in reality"... in reality, it remains to be seen if any of this is feasible. But once thing is for sure: in reality, we would NOT be using containers that blow holes through the crust of the planet when the power goes out. Handwave all you want, that much is a fact. We're not kerbals. We may be stupid but we're not that stupid. We're not always perfect at it, but we do always try to ensure systems fail gracefully. No real engineer says "it's not going to fail"... we design around the fact that they will, and test what happens when they do and how to prevent that from being catastrophic.

No particular requirements on the position of an ON statement. It should work any time after the ON statement is executed.

I understand antimatter perfectly. You seem to have missed the point of my post (feel free to reread it). You're completely, utterly insane if you think we'd put that quantity of antimatter in a container in our reality, ready to detonate and tear a hole through the crust of the planet the moment the power goes out. In reality, an antimatter container would never contain as ludicrously large an amount as a cubic centimeter of it (unless it was an extremely rarefied gas). When we build antimatter containers, we count the amount of antimatter in it by the number of atoms. The number of milligrams is a silly unit to use when talking about such tiny fractions of a milligram. Incidentally, I got a good chuckle out of "In reality, if 1 unit of Antimatter from this mod..." If you're talking about this mod, you're not talking about reality. In reality, this mod contains no actual antimatter.

Something like this? ON AG9 RUN ABORTPROG. I haven't tried it, but that ought to run ABORTPROG if you hit 9 (which will also kill the current program -- kOS doesn't multitask afaik). Is ON ABORT ... an option? I'll have to try that...

To quote the first post in the thread:

Yeah... as a general rule, you shouldn't use "=" or the language equivalent to compare floating point numbers unless also accompanied by a "round" function with the level of precision you want specified. 60.0001 != 60, and values will happily move from above to below your target without ever being precisely equal to it. "x == 0.0" is a bit of an exception, but even that can be dodgy depending on the circumstances...

Actually, lossy compression often introduces artifacts on decompression that weren't in the original. You might end up adding more "detail" than you lose that way...

Sorry, clarification: add a CALL that hides/shows the interface, so the program can hide/show the controls (without resorting to actiongroups). Come to think of it, is this necessary for mod authors to do? Can't kOS simply access anything that shows up in right-click menus and give programs the ability to "right click" items, virtually speaking?

Well, no. In our reality, we have plenty of experience containing explosions (heck, that's how an internal combustion engine works). We'd design a tank so that if the power failed, it would destroy the antimatter and probably ruin the tank, but contain the explosion, even if that meant (and it probably would) that over 99% of the mass of our antimatter tank was matter, and the majority of it was shielding for containing the explosion and catching the radiation when the antimatter and an equal amount of matter mutually annihilate. A competent engineer doesn't hope a system doesn't fail, they understand that it absolutely positively certainly will, and designs it to fail gracefully. Then they deliberately break it over and over again to test this until upper management refuses to pay for more explosions. Granted, that's what human engineers do. Kerbals will be kerbals...

Awesome! Suggestion: add a way to hide the usual Infernal Robotics interface. If I have a way to control the groups programatically, I really don't need or want the usual control window cluttering up my screen...

Since the amount of steering needed differs from rocket to rocket, it would be nice if there was some way to control how aggressively it turns inside the program.

Actually, what I've observed is that the first rocket I launch after starting the game doesn't exhibit the problem, but sometime after taffing about in space for a while, doing dockings and such, when I go back and launch another rocket (even the same one that launched fine earlier), the rocket attempts to do a roll maneuver on liftoff, and if it's not a sufficiently agile rocket, can indeed do a massive, energy-wasting loop, sometimes crashing or tearing the rocket apart from the stress. I think it may be related to the "force roll" feature somehow (but it does this even if you ensure that's turned off -- somehow the "offness" of this isn't getting through to the ascent guidance computer).

One consideration: It really ought to work equally well at any time-warp. It always bugged me that ISA MapSat (and the Kethane detectors for that matter) start missing cells at higher time warps. You know where the satellite was the last time you added a cell, and you know where it is now -- it ought to be trivial to fill in all the data in between, rather than just at the current point... ("It ought to be trivial" is what a usually say before I dig into the code and really come to understand the problem... lol)

Yeah... and you might want to update to 0.21.1 while you're at it.

Yes, quite oddly, YouTube did not list it as a recent upload when searching on his username. However, it's linked from his devblog: http://kosdev.blogspot.ca/

Actually, the stock probe cores do have SAS. GameData/Squad/Parts/Command % grep -r 'ModuleSAS' . ./advSasModule/part.cfg: name = ModuleSAS ./asasmodule1-2/part.cfg: name = ModuleSAS ./avionicsNoseCone/part.cfg: name = ModuleSAS ./cupola/part.cfg: name = ModuleSAS ./landerCabinSmall/part.cfg: name = ModuleSAS ./Mark1Cockpit/part.cfg: name = ModuleSAS ./Mark2Cockpit/part.cfg: name = ModuleSAS ./mark3Cockpit/part.cfg: name = ModuleSAS ./Mk1-2Pod/part.cfg: name = ModuleSAS ./mk1pod/part.cfg: name = ModuleSAS ./mk2LanderCabin/part.cfg: name = ModuleSAS ./probeCoreCube/part.cfg: name = ModuleSAS ./probeCoreHex/part.cfg: name = ModuleSAS ./probeCoreOcto/part.cfg: name = ModuleSAS ./probeCoreOcto2/part.cfg: name = ModuleSAS ./probeCoreSphere/part.cfg: name = ModuleSAS ./probeStackLarge/part.cfg: name = ModuleSAS ./probeStackSmall/part.cfg: name = ModuleSAS ./sasModule/part.cfg: name = ModuleSAS That's everything but crewCabin and seatExternalCmd...

There's definitely something funky about the orbits it puts you in. I don't mean their eccentric nature, I mean that an eastward facing launch is somehow putting me into a polar (sub)orbit... the eccentricity I understand, but how is it getting this incredible inclination from an equatorial eastward launch?

I'd be happy with a simple heading, attitude, bank rotation (aka "yaw, pitch, roll"). I guess the technical term for this is Tait-Bryan rotation? Anyhow, that's always seemed intuitive to me.

"It's only a model." *shhh*

This may be too much awesome for one update. Handle with care, folks...

The whole point of ion engines is that they use a dense fuel extremely efficiently. You use them in circumstances where you want to go a long way on a very small fuel tank. Considering the currently balanced versions of the hybrids have an ISP barely better than a nuclear rocket, they're probably consuming too much Xenon...

Good point -- I'm honestly not sure how robust the regex parser in C# is. Being able to use tabs as whitespace is a desirable feature, though.