Dunbaratu

You might want to deliberately slow down the speed if the computer you run KSP on isn't super fast, to ensure the kOS code doesn't end up choking the simulation to the point where it stutters. We've already seen that it's possible for kOS to starve the main KSP thread of time so that KSP stutter-pauses its simulation. Granted, that was because of a bug that clogged the execution queue with more and more pointless no-op work as a loop iterated. Still the fact that kOS (or any mod) that takes a long time to finish responding to an update call can starve KSP of time like that could mean that someone may want to throttle back their code if their animation starts stuttering. If they've got kOS and a bunch of other mods too it might hit a point where it's too much to finish all the updates all the mods are doing in one physics tick.

Or perhaps a memorial followed by a quick cutscene for a few seconds of a kerbal in a green goo vat of something and a nameplate outside the apparatus saying "Jebadiah Kerman Clone incubating...." To explain away why there's another one a few days later.

True, but the point is that any time the ONLY form of "user input" to tell the program not to continue in a situation where continuing will ruin the saved game is to externally kill the program, that means the program needs a confirmation dialog there.

I am very very happy to find that both project maintainers are willing to merge the two projects into one. To me that is far more important than any new features and I'm willing to wait quite a long time on feature updates if that's what it takes to get the two to become one. I'm willing to be a testing guinea pig for the merged version when a release candidate appears.

No, what the OP expected is to be warned before it's too late and the damage is already done.

Of course that works but it defeats the point of having the logic in a child script, which is to make modules that "just work" when used in the main program with just one call instead of having to putting half their logic in the main program. What's being asked for is the ability to something like this: Main program: run emptyStager. // go on to do other stuff. emptyStager program: when stage:liquidfuel = 0 then { until stage:liquidfuel > 0 { stage. wait 0.5. }. // keep staging until there's some fuel. run emptyStager. // re-run myself to make another "when" hook for the next stage. }. I tried doing this myself like that and ran into the same problem, that hook triggers you set up, like WHEN, are removed when the subprogram ends so you can't isolate any hook logic in subprograms, nor can you use subprograms with recursion to create a recurring hook like I show above. I can understand the logic with removing the ON and WHEN hooks when done with a program, for the same reason you don't want to leave throttle or steering locked when the program ends - because when the program ends you should go back to 100% manual control. BUT, throttle and steering locks go away only when the outermost program ends and you go back to immediate mode, NOT when a subprogram ends. I think ON and WHEN should work the same way, that they only go away on the final outermost program, not with a subprogram (*). (*) But that does mean that we'd also need a way to explicitly end ONs and WHENs so that we can make them go away when we want to. Right now the only way to make them go away is to either trigger them, or end the subprogram. So if that explicit ending feature wasn't also added then we'd run into a problem when running a very long term program (like my Duna mission) that hooks from previous steps can trigger way later after that step is done. I think doing that would require the ability to name the hooks so you could mention which one you meant when you want to remove it later.

Is there a good reason for them to continue being two separate projects? It sounds like if they stay separate then you just have to keep re-doing the merge effort again and again on a regular basis.

The eccentricity isn't the reason. It's because it's not big enough to be forced into a spheriod and because it hasn't swept its orbit clear of other debris. The problem was that astronomers had been living under a fuzzy definition of the difference between a planet and an asteroid and when they decided to nail it down to something concrete they ran into difficulty trying to find a place to draw the dividing line that put Pluto on the "planet" side of that line while also keeping all the asteroids we know about on the "not planet" side of the line. There wasn't a definition of "planet" that kept Pluto as a planet without having to call asteroids planets as well. So they had two choices - pick a definition that reduces the Solar System to only 8 planets, or pick one that increases it to 30-40 planets, most of them tiny. There wasn't a definition they could find that would have kept the count at 9.

Why are you pretending this is in contrast to kOS when it isn't? I've written kOS scripts that can run an entire mission to Duna and back home with the only player input being to tell it "okay start the next step of my script now".

The front page of this thread claims you can download 0.55 from either spaceport or dropbox, and provides both links, however, only the dropbox link is 0.55. The spaceport link is 0.54.

Have they looked into the difficulty of keeping human beings sane under those conditions? I'd think that would be a bigger problem than the life support and shielding and consumables problems. Human psychology doesn't hold up well to being stuck in a small box for 2 years with nowhere to go.

You may have found one exception that most people will never encounter (because who the heck lands a thing with a jumbo tank into the water? By the time you're landing the craft is usually smaller than that.) But that still doesn't change the fact that the majority of parts do float when they shouldn't. A metal girder shouldn't float. Until that problem is fixed there's no point in designing pontoons. All they do is make things float that.... already float anyway.

It all comes down to where you want the wall between "player's space agency does it" and "someone else on Kerbin does it" to exist. Sometimes the work that real-world people did in the space program is abstracted away so far in the KSP game that the player has no say in them - for example the engineering decisions about the dimensions that rockets and fuel tanks have, and the work to make a liquid engine that won't blow itself up. These were not easy at all, but the player doesn't have to worry about them in KSP. The presumption is that other companies handle that and got it all working for you. Whereas, the top-level decision about how to put those parts together, how many stages the rocket should have, and so on are in the player's hands. So SOME of the stuff is in the player's hands and some is abstracted away and assumed to be done by other Kerbal people outside the scope of the game. So the question really just boils down to this and this alone: Given that the task of programming a working computer automation system is still a thing done by people, not by the computers themselves, how much of that task should be in the player's hands and how much of it should be abstracted away and presumed to be done by other people outside the scope of the game? That's really all it comes down to. Nobody is claiming that an autopilot is unrealistic, just that if it works perfectly out of the box regardless of what the player does, then it removes from the player that aspect of the game and puts "making the autopilot" into the realm of "stuff the player assumes some other Kerbals somewhere else on Kerbin did for you." This whole "automation not autopilot" title is a misnomer. It's still an autopilot system - but just one in which the player is assumed to be the programmer at the topmost level of putting it together. Only the primitive steps are abstracted away, not the top level decision of how to assemble them together. Whether or not the piloting has automated help outside the player's control is not a boolean yes/no. It's a continuous sliding scale. Even in the stock game there's a lot of computerized help for the pilot. Setting a maneuver node and getting a prediction out of it about where it will send you if you burn that way, and whether or not your movement will be timed to coincide with a planet's arrival and thus form an encounter is a really hairy mathematical problem that your onboard computer is calculating for you. So it's just a matter of where you want that sliding scale set. It's never going to be 100% player control (it *already* isn't in the stock game), nor is it going to be 100% outside the player's control either (because then why is the player there?). And furthermore, as the mod kOS demonstrates, having an autopilot doesn't have to imply having one that other people made. You could have one that YOU made. So the distinction between "player controlling it live as it happens" and "player controlling it, but doing so ahead of time by making an autopilot" and "player not in control because somebody else's autopilot is doing it." is important. The arguments that real astronauts don't have to fly manually and therefore you should let someone else's software fly for you sort of ignore that rich middle ground between the two of having an autopilot that YOU had a hand in making fly the craft. So you're not flying in real-time manually but you, ultimately, are still the one responsible for how it flies. I'm not sure a thing like kOS is ever going to have wide enough appeal to be in the stock game, because it's very much the sort of thing that a person who's done a small amount of programming can pick up quickly but for someone who hasn't programmed at all before it can be a bit of a steep learning curve. BUT, that being said, there may be room for something a bit further on the slider toward "game provides it for you" than kOS is, but not quite as far over in that direction as, say, making Mechjeb stock would be. If you've ever played the old PS1 game called "Carnage Heart", a thing like that might work. (In the game you programmed your mechs to fight other mechs, and your program was basically a bunch of command tiles you dropped onto a slate to make a visual flowchart.)

I do think that the tech tree items appear in the wrong order. And yes, it is pointless to have landing gear and wings in different parts of the tech tree far apart from each other because neither one can be used *at all* without the other. And there's often something a bit anticlimactic about the tech tree, as so many of the nodes just give you differently sized versions of what you already have. (And weirdly, you apparently have no idea how to make small girders until late in the game, as if the technology to build a nuclear fusion engine is somehow easier than the complex technology behind the metal I-beam.) I don't think the nodes are in the right order. On that I agree.

It's better than passing judgement on something that's already set in stone because it *IS* complete. If you do that, then it's just whining for no good effect. But if you raise those issues BEFORE it's done, then there's a chance the complaints may affect development. While there's still time to change things is exactly the right time TO register complaints like this. I don't agree with much of what Sauron complaints about, but the idea that people should wait until it's a finished product before saying anything is defeating the entire point of having user feedback during the alpha stage.

I'm in the middle of performing tests trying to trigger the problem, using the simplest little vessel I can build, launching it a mere kilometer or so away from KSC, landing it there, and then opening up its SCS terminal and fiddling with setting variables and quitting and reloading the game to see if I can make it break. In so doing I've encountered several cases where even though I had a vector saved, it didn't break and loaded fine, so I'm not sure that's the problem anymore. But I have now noticed two new problems in doing this test: Problem 1: Some variables being changed to zero when re-loading from persistence: In the terminal I do this: set varA to 12.1. set varB to 1230000000000000000. set varC to "string with spaces". set varD to V(1,2,3). Then quit the game. The persistence file now contains this, which seems correct to me: context { variables { vara = 12.1 varb = 1.23E+18 varc = string(*)with(*)spaces vard = V(1,(*)2,(*)3) } context { context-type = kOS.Interpreter.ImmediateMode } } (NOTE: Everywhere you see (*) above that's *ACTUALLY* this: & # 3 2 ; But I haven't been successful at forcing the forum software to stop processing the ampersand directive when want to literally type it out like that.) After reloading that game, the vessel now does this: print varA. 12.1 print varB. 0 print varC. 0 print varD. V(1, 2, 3) So it does seem to be able to parse in the vector correctly after all. I was wrong about that being the cause of it. But, notice what happened to varB and varC. They got overwritten with zero values instead of what they are in the persistence file. Not the same error, but still something is wrong there. Problem 2: UNSET ALL bug Furthermore, a tertiary bug I discovered in doing this was with the UNSET command. After printing the above, I then tried to prep for my next test by clearing everything out, as follows: unset all. print varA. Unrecognized term: 'varA', Type:FINAL. print varB. Unrecognized term: 'varB', Type:FINAL. print varC. Unrecognized term: 'varC', Type:FINAL. print varD. V(1, 2, 3) "unset all" cleared varA, varB, and varC, but not varD. Then I proceeded to re-set varD to the same value as it already had, and then run unset all again: set varD to V(1,2,3). unset all. print varD. Unrecognized term: 'varD', Type:FINAL. That time it worked. I have no idea what's going on there. It failed to UNSET varD after it had been populated by loading it from the persistence, but was able to do so after I populated it by the SET command in that particular run. But that can't be all there is to the problem because if that was it then it should have affected varA, varB, and varC just as much as varD.

I have also encountered the save/load bug again where it crashes partway through loading the vessel from the persistence file and therefore truncates the ship at the spot where the kOS SCS part is located in the file. It's one of the reasons it's taken me longer than expected to update my Duna mission. I thought it was fixed but it's still happening, and I have narrowed it down to this: If your variable context contains a vector, the bug triggers. If your variable context does not contain a vector, it doesn't seem to trigger. Vectors are being saved in the persistence file like this: V ( 1 0 0 , & # 3 2 ; 5 0 , & # 3 2 ; 0 ) (I spaced out all the characters because after about 10 attempts to try different ways to get the forum software to let me literal-protect the ampersands codes so it wouldn't interpret them I gave up. It kept mangling what I wrote even in [ code ] blocks.) 32 is the decimal ASCII code for a space character. So I suspect it's trying to print it out to the file as: somevariable = V(100, 50, 0) and the spaces are being encoded with HTML-style protection, but then it doesn't know how to read those back in when loading the vessel. At least that's my guess.

Having Matrix and trig primitives that we can invoke allows for imagined hardware acceleration. Even in the Apollo days they already had a hardware instruction on the Apollo Guidance Computer to do matrix algebra electronically in one step. So it's pretty realistic to have them as low-level primitives. The thing that should be left in userland is the knowledge of how you need to use those primitives to perform the rotations you're trying to do. It's still just one simple instruction to execute, but you need to know how to set it up, and it's the knowing of that in which the user's intelligence is involved. I'm almost done with converting my Duna mission to kOS 0.11 so you have it as a testbed like you asked. After that I'll tackle docking and see if what's there already is enough to make it work. I suspect it now is if the issues of translation are fixed now.

Whether or not the antennae are extended used to be relevant but its not anymore. The check for whether or not they're extended had to be removed when SQUAD added science points because now when you transmit science the antenna will retract, whether you want it to or not, at the end of the transmission. Since the intent was to someday maybe make it so that you have to have communication with the probe to do anything at all on an unmanned craft (like extend antenna), that inability to stop KSP from retracting the antenna could ruin the whole mission, so the check for extended-ness of antennae was removed.

Many of the things on the wiki are becoming wronger and wronger as kOS evolves. The wiki originally became a place where basic functionality got documented by the users because Kevin's was quite incomplete. erendrake is more proactive about documentation so I don't know if the Wiki will keep being updated a the original reason for it isn't as strong.

Fair enough. I agree with you about "lock steering to" being magic (but in the past there was no choice as no other mechanism existed), but not about the body database being magic.

But where I disagree is the very notion that the numbers are magic, and just how "external" those parties really are. The reason NASA can succeed at putting a probe in orbit around Mars is because NASA already knows what BODY("Mars"):Mass and BODY("Mars"):Radius are. It seems silly to have to re-measure it every time once it's been calculated by scientists back home. Either it's calculated already before even the first probe is sent, or if it does require a probe it's only unknown once, the first time, then after that they'd add it as a constant to look up in all future software. Secondly, it's an utter pain to show off your software to other people if you have to put "spoiler alert" and mask off parts of it. That's why the only sort of keeping data out of the BODY structure that I'd accept as being okay is if it *IS* there in the structure, but masked off until your career mode campaign has measured it (as described in the post I made earlier). (And in the case of sandbox mode it's not masked off). That way I can still say "here's the code" without it containing spoilers because all people will see is a call to BODY():something and they won't know the actual number unless they're playing sandbox or have gotten that far in their career mode game. It allows me to show 100% of my code rather than only 99% of it and having to hide the private database of stuff I learned in my career.

The controls aren't the problem. A PS3 has 512 MB of ram. THAT's the problem.

This is unrealistic, but pretty much every single stock part in the game floats. A metal girder floats. A full fuel tank floats. An engine floats, etc. What makes them appear to "sink" is that when they drop below a certain distance below the surface they get deleted, so the bottom parts of a tall craft never survive splashdown just from the fact that they get pushed under the surface too far before they would have bobbed back up again had they not been deleted. So pretty much anything works as a pontoon provided you build the craft wide and shallow enough that parts aren't driven under the surface by the weight of the parts above them. Totally unrealistic, but it works. I'd rather see parts that sink, and having to build pontoons to counteract that.

The Mun is easier to land on than Minmus. But harder to get BACK from. When you add the delta V needed to lift off again to get back to Kerbin that's where Minmus wins out as being the easier one. Not only does it take less fuel to escape Minmus, there's also the fact that this means you don't need to bring all that extra fuel mass down with you on the landing.