Dunbaratu

I remember seeing them come back to the main hangar bay, but not how they moved from there back to the launching bays. There didn't seem to be an internal mechanism for moving them through the ship back to the bays.

Yes one of the ways in which rotating for "gravity" creates some weird effects is that if you run east you "weigh" more than when you're running west. (if you define "east" to be "in the direction the floor is moving". Actually the same effect happens on Earth (but reversed because we're on the outside of Earth, not the inside - so east makes you lighter and west makes you heavier). It's just that the amount by which it occurs is so minor that you won't notice it. But on a station with a radius far smaller, rotating far faster than Earth does, it would be noticeable. If you live on a rotating space station and have a daily workout routine, then if you want a lighter workout for your morning jog, jog west. For a heavier workout, turn around and jog east instead.

If I recall (and it has been a while now) one of the things that Babylon 5 got right about the physics is that if you are going to have a large rotating cylinder space station like that, you have to put the spaceport dock on the axis of rotation. I seem to recall that they did that - ships would approach the end of the station right on its center axis and drift inside through a giant set of blast doors. They never showed how the ships moved after that, but I imagined that the hangar bay inside was a big space with berths around the edge of it that you drifted out to and then had to match velocities with. As long as the berths are much closer to the axis than the outer floor of the station is, they'd have lighter "gravity" and slower sideways velocity to contend with. A couple of other things they sort of "got right" - ish were that the fighters (okay, yes even HAVING some sort of manned fighter is a bit silly, I'll grant you) were launched from berths in the outer wall of the station, mounted in clamps that aimed them downward facing the "floor", so that when the clamps let go the fighters would be naturally flung outward from the station's rotation. (I note they never tried to explain how the fighters came back and got re-installed in those launch bays after use.) They also had the notion that housing was not all at the same radius - that there were several floors of residential decks and the aliens lived in whichever deck was at the right radius to give them a fake gravity closer to what they were used to on their home planet. (And that one of the problems with the homeless living "downbelow" underneath the main floor is that they had to endure higher G forces because of where they were.)

I have discovered that the problem might be "revert flight". There must be something in KOS that is being "left behind" that the DLL is still trying to run, or perhaps some memory it's still holding onto, when you revert flight, so that in a session debugging your script, if you keep trying to "revert flight" and try again, each successive time you do it makes the lag worse. Something is getting left behind. I can tell because when I remember to always issue a "shutdown." command to the KOS terminal before I revert flight, the lag never accumulates to get worse, whereas when I don't do that and instead just revert flight while the KOS SCS unit is still active and turned on, it always DOES get worse the next run through. So I don't have the lag problem as badly, but I still do think it would be convenient to be able to record the video in separate goes with saving the game between so I don't have to make it one enormous video.

If it worked like that it wouldn't be a problem, but it doesn't work like that. It does NOT report the fuel available to currently active engines, but rather it reports the fuel directly connected to the currently active engines (i.e. there exist no stage decouplers between the tank and the engine.) The relevant difference between those two meanings is due to the existence of the yellow fuel hoses. Fuel that is available to an active engine, but it's only available via a yellow hose, doesn't get reported in stage:liquidfuel or stage:oxidizer. @JohnFX, I can't see your dark screenshot well enough to tell for sure, but it seems from your description that this might be what's happening in your case. if your engines are pushing against plates and have no fuel tanks directly attached but instead are getting all their fuel through yellow hoses, then ship:liquidfuel isn't sophisticated enough to "see" through that hose to report that fuel. It's not a trivial problem to fix because it's fuzzy how much of that fuel is really part of this stage and how much is for another stage, and also if four engines are all siphoning from the same tank you don't want to end up counting the tank's contents 4 times over into the total (adding it once for each engine). But if you make an asparagus staged rocket you can tell that KSP itself gets it a bit wrong, counting the same fuel toward multiple engines in the little green fuel bars on the staging list. But at any rate, an engine who's sole fuel supply is a yellow hose will report as having zero fuel in stage:liquidfuel. I ran into this problem myself as I had an ascent script with the logic to stage whenever stage:liquidfuel hits zero, and it kept skipping right past one of my stages to the next one even though it had fuel. I eventually traced it down to this cause. One workaround is to, instead of building those engines against pusher plates, put them against the smallest fuel tank available in the game that will take the engine. Use those little fuel tanks as the pusher plates, and feed a yellow hose from the center tank out to the side "pusher plate" tanks. For example, lets say you use the small 45 unit fuel tanks as the pusher plates and they get fed by hoses from a center tank with 320 units, and you've got 2 engines thusly mounted. Your total stage:liquidfuel *should* be 410 units, the 320 plus 2 of the 45's. But it will only be reported as 90 units (the two 45's). BUT those 90 units will be the LAST units spent, so you can still use stage:liquidfuel=0 to decide when to stage. You won't be able to tell the difference between having 300 units left versus having 200 units left, but you'll be able to tell the difference between having 90 units versus 80 units. Once you've emptied the center tank and only the "pusher plate" tanks have fuel left, (i.e. there's less than 90 units left in this example) then stage:liquidfuel would start becoming accurate again.

I knew it worked for resources but verticalspeed and altitude aren't resources, which is why I didn't know it worked for that too But the real thing that struck me as wrong and made me comment in the first place was the bit about how it has to be within <> when printing when I knew I had printed it many times before without the <>. Even if it CAN be in <> it certainly doesn't have to be. It will print just fine without the <> so I thought people might be mislead by that comment.

Of course I don't think it is, which you would know if you read my post in which I specifically said autopilots are realistic. What I called unrealistic was the fact that something as complex as the autopilot software, which is just as complex as the entire physical rocket design, contains no ability for the player to make mistakes in putting it together.

I've heard that argument before but if you read what I wrote, I already anticipated it and raised the counterargument to it. I mentioned how in the VAB, you still have to assemble the final craft out of the the parts so the player is involved in some way, and still has the chance to make some mistakes in the design. There's still some player agency involved. Mechjeb is not analogous to the way the VAB gives you perfectly working parts of a craft to assemble. It's more analogous to going into the VAB and finding that there's only one rocket there, and it's been pre-assembled already, and you don't have player agency in deciding how it works, and you don't have the opportunity to put it together wrong (and therefore there's no pride in getting it right). While it's true that most of the ugly details are deliberately glossed over when putting a rocket together in the VAB the fact that there's still some player agency in the final assembly means you can feel a bit of pride and accomplishment in making a good working design because at least you had *something* to do with it. There's no sense of pride in making a good landing or a good docking with mechjeb because it doesn't feel like you had anything to do with it. It feels like somebody else's accomplishment instead of your own. So if you don't enjoy the piloting and want someone else to do it for you, that's fine. Enjoy the game your way. But don't claim it's the same thing as the parts in the VAB. It's not. The VAB leaves more room open for player agency than Mehcjeb's autopilot does. All of which I already mentioned. You can disagree with it but when you pretend I didn't say it you're just arguing against a strawman.

The problem is that it ends up having to be fixed multiple times if you try to fix it too early, as each and every time the terrain is reworked the objects aren't in the right place anymore. So I'd rather they wait until they know the terrain is set in stone before they fix it. Otherwise they're just wasting time fixing the problem many times instead of just doing it once.

I was more referring to the bit about "//has to be within <> when printing". You can print it without the <> and vertical speed isn't a ship expendable resource like the other things with <> are. I thought the <> marks were for expendables like fuel and monoprop and battery charge.

One of two things has to happen, either one of which will be a major problem: Scenario 1 - There isn't air, or if there is the air doesn't have time to push against you with friction long enough to make you match speeds with it. Result: If that's the case then you float down nice and gentle toward the outer floor, but the floor is moving laterally very fast and you hit it like a cymbal strike when you touch it. Scenario 2 - The air has enough time to push against you long enough to make you match velocity with it as you pass down toward the floor. Result: You match motion with the floor's lateral motion, but in so doing you are no longer falling nice and gently and you're falling faster. You got rid of the lateral motion problem by starting to rotate with the ship, and therefore fall.

That is by definition NOT an AI then. It's just a program. AI is still a pipe dream at the moment. Nobody has been able to create one, and every time a game company or anyone else calls their game algorithm an "AI" they are misusing the term.

True, but it's also pretty silly for someone to claim that the reason the replicators can't work is because of a feature that the show never once implied was true about them - that they use E=mc^2 to make matter from energy. That was never stated nor implied anywhere. What *was* implied was that they can somehow rearrange matter, not create it out of nothing.

Really? I've gotten "print verticalspeed" to work. I thought the angle-bracket notation was deprecated in favor of ship:thingy. (i.e. where it used to be <liquidfuel> it's now ship:liquidfuel).

The ethics of spaceflight does account for a large part of what makes manned flight more expensive than unmanned flight. The risk allowed on a robot mission is far larger, for ethical reasons, so you can save mass on safety systems. A robot doesn't have to COME BACK, so you can send one-way missions where doing that with manned flight requires the astronauts to volunteer for suicide. (Not just "there is some risk of death" but "the risk of death is 100%".) Not having to come back saves an enormous amount on fuel mass. Also, the requirements of life support are large. Keeping a human alive while adrift for 6 months is going to take quite a bit of equipment and stores, whereas a robot can just be turned off during the trip. And then there's the extra volume needed for psychology reasons. While it may be possible to keep a human alive in a chair for 6 months with barely enough room to stretch arms and legs out, you're almost guaranteed to end up with an utterly insane human by the time it's over. And even ignoring the ethics of doing that to an astronaut (even a volunteer), an insane human won't be useful for completing the mission goals. So you need a lot more living space than that just to keep the human sane. Probably the closest analogy to the long term spaceflight in cramped space problem we've already seen here on earth is nuclear submarine sailors. But even THEY don't have to spend 100% of that time in their bunks not moving. There are corridors and other rooms. Tiny rooms, but its still quite a bit more space than, say, the Apollo astronauts had and they only were expected to have to live in that space for about a week. Lifting something the size of, say 3 submarine's bunks, 1 submarine's toilet, 1 tiny kitchen/dining/meeting space, and 1 cockpit area, is still quite a hefty payload. We've never sent anything to Mars anywhere near that enormous before. And of course, radiation. That means shielding. And that means even more mass. So basically, yes I think manned spaceflight is a good thing despite the dangers, BUT those very dangers themselves are the things that make manned flight so incredibly expensive and bulky. Therefore I'd rather see effort concentrated MORE on the research into cheaper ways to lift things into orbit. That's the key linchpin that's restricting manned flight right now. As long as getting a single kilogram of mass into orbit is as expensive as it is now, the extra kilograms needed for manned versus unmanned flight will continue to make manned flight very hard to justify. The way to reduce the risks, and also to make it more feasible, is to attack the problem that getting mass into orbit is too expensive. Currently it's way cheaper to have craft that operate using very expensive but very small engines that burn very expensive but very small amounts of fuel than it is to have them use cheap engines that use cheap but bulky fuel, just because those kilograms cost more than rare materials do.

Ewwwwwwww... Yuck.

Another rules question: can people be allowed to use the mods that mod the KOS mod itself? i.e. http://forum.kerbalspaceprogram.com/threads/51211-Sensor-Reporter-for-kOS for example. The way the rules are phrased now, KOS is the only allowed mod. If mods like the Sensor Reporter *do* become allowed, I'd recommend doing it by adding to the rules an explicit whitelist of allowed mods. given by name, rather than simply saying "any mod that contains KOS hooks in it". I say that because I can see a potential problem with opening it up entirely to ANY possible future mod that might be made which happens to have a hook for KOS to call, because then if, say, Mechjeb adds a few KOS calls you could have Mechjeb installed. Such a rule could become a backdoor into allowing someone to pretty much ignore KOS and instead write a Mod that controls the mission from the C# code, and have that mod create a hook to allow a KOS script to trigger the Mod's code and have the Mod's code actually doing the work rather than KOSscript doing it. I guess on a similar note, maybe a rule should be added to require that the mission has to work using only an official release of KOS (but perhaps an older release is allowed), rather than something compiled from a personal private fork of the github code, for the same reason - someone could fork KOS and then write their own C# solutions to things that aren't in the main release for others to use. This is more for the repeatability of the test by others than anything else. Granted, at the moment because Kevin isn't around to merge pull requests back into the main releases this means having to avoid using any of the fixes people have made for things, but the alternative to allow anyone to use any fork of KOS they made would be too hard to control and keep the challenge fair.

I think this challenge, in addition to being fun, has also turned out to be quite USEFUL to the development of KOS itself. After the challenge started there was a sudden uptick in the rate of reported issues on the KOS Github page, and I think that's largely because in response to the challenge people started trying to do more difficult things with KOS and thus discover limitations they hadn't run into before. In a sense, the challenge became a "use case" scenario for testing KOS.

To @Sacred Aardvark and @blizzy78, the term "open source" actually has a group that approves whether or not people can legally call their license an open source license. They trademarked the term specifically to fight the definitional drift that your arguments are both based on. You can read the whole thing here: http://opensource.org/docs/osd But this is the relevant part of it: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. So can you let this rest for once? GNU GPL is AN open sourced license. There are others too. The property I was referring to that GPL has which allows someone to fork the code and make their own mod is *precisely* this property that GPL shares with all the other open source licenses too. I wrote up longer responses, but I went back to delete them because really, this should settle it once and for all. The point is moot. I obviously was NOT referring merely to the ability to view the code when I called it open sourced, and I was using the term the same way the OSI (Open Source Initiative) themselves uses it.

The point is that any pretend legibility improvement of putting a condition in the loop header versus checking explicitly and calling "break" in the body is largely imaginary because in EITHER case you still have to go examine the loop body to see how the loop exits, or indeed IF it exits at all. If the loop header looks unconditional and says "until 0" then you have to search the loop body for the word "break" to see how (or if) it ends, but on the other hand if the loop header looks conditional and mentions a variable or an expression then you STILL have to search the loop body to see the place where that expression or variable's value will get altered. Now, if we had a FOR loop in KOS, THAT would be the one exception I make to that general principle, because unlike an UNTIL or a WHILE, a FOR loop does in fact encapsulate all the information up in the loop header in one place - you show how you'll initialize, what you'll check for, and how you'll increment, all up in the header. So that I do agree is more legible and less error prone. But once you remove init and increment and leave just the check alone, so you still have to look inside the body for the increment and look outside the body for the initialization, then there's zero legibility "win" over just explicitly using break instead.

I've seen that KOS's steering system tends to violently wiggle the craft back and forth as it self-corrects. It's like the old ASAS used to work. It seems the only real solution is to build an extremely rigid craft, strutted all over the place to prevent any flexibility.

Wait... it's not there anymore in recent versions??? Then no WONDER why I haven't been able to find it in LOTS and LOTS of time spent looking. Gaaaaah.

until 0 is only an infinite loop when it contains no code inside that causes break. ANY loop has the potential to be infinite if the condition wasn't set up right. Even if you explicitly say something like "until X > 10" it could still be infinite if X doesn't count up correctly. You still have to examine the body of the loop to see if it's infinite or not. ANY condition that checks for (some variable)=TRUE is poor coding that would be far better served by just using the variable bare without the =TRUE part. This is because TRUE will be a single value (typically 1) where the actual boolean definition says that ALL non-falses (for example, 2, 3, 4, 5, -1, 2, -3, etc) are true. There's a relevant difference. And the idea of using the name of a variable bare as a conditional clause is VERY VERY well established longstanding practice. It's not something I invented out of whole cloth. It's how boolean variables have been used for decades.

Your response is predicated on the idea that the phrase "open source" simply means that you can see the source code and that's all it means. If that was true I'd agree with you. But it doesn't just mean that. While it's true that many licenses allow you to fork the code and use it for your own purposes, and it's the license that allows this, the fact that there are many such licenses with slightly different terms gave rise to the need to make a catch-all term for them, and that catch-all term is open source. It does not merely mean you can look at the source. It's a fuzzy catch-all term that means "that collection of various licenses that share in common the ability to use and modify the source code." (note, USE, not just look at.).

Astronomers are always having to come up with new names for things as they get discovered, and they tend to use various naming schemes to do it, some involving pop culture and some involving tributes to hard sci-fi novels or tributes to famous scientists. How awesome would it be if some day when they do discover yet another solar system with planets that they decide as a tribute, to start naming the planets Kerbin, Eve, Duna, Moho, and so on.