Dunbaratu

This thread should probably be kept clear of KOS syntax problems so it's just about the challenge. But, that being said, check to see if the length of the string goes past the right edge of the terminal window. It looks long enough that it might if you start it at column 8. That's a known problem with PRINT AT. Regular PRINT is able to wrap text at the edge of the screen, but PRINT AT isn't, and it causes KOS to overflow an array. It's supposedly fixed already in github, but not in the released version.

Turns out it only works with nodes (it detects encounters on the "brown" path that comes out of a maneuver node). If you haven't set a node because you want the encounter you're already headed to as-is on you current "blue" orbital path, you can't get it. I suppose I could pointlessly set a manuever node right where I am, with a delta-V of zero, just to make a "brown path" that's identical to my "blue path" in order to check for encounter but that seems a it silly.

It's still got lots of bugs but it is usable provided you keep abreast of what those bugs are. Doing "what would make sense to a programmer" often doesn't work. I recommend keeping up to date on the issues list on the github page for it to avoid falling into pitfalls.

I have the same question. The way it's phrased I *suspect* is not what Thrfoot meant. The way it's phrased it technically means you can't run two programs in parallel on two different SCS units either. I suspect the *intended* meaning is that the USER isn't allowed to manually type "run programname" from the terminal window until another has finished, but that a PROGRAM is allowed to run another program before it itself is finished. For now I'm going to write my code as if calling a subprogram is allowed and hope that's what thrfoot meant. If it's not and I submit an attempt before it gets clarified, I'd like to reserve the right to re-submit an attempt with all the subprograms rolled into one.

It does seem strange that you can only get the encounter that you MIGHT end up at if you executed a node correctly, but can't get the encounter that you're already on the guaranteed path to if you did nothing from here on out. It seems like an unnecessary extra step to set an encounter node just to get the encounter name when I don't need the encounter node for the maneuver itself, which I can execute just fine outside of the encounter system. What I'm trying to do is this: Step 1. Wait until correct point to start Hohmann transfer (I do the vector math to work this out myself). Step 2. Start thrusting prograde. Step 3. Hold the throttle there until I've got an encounter with the Mun. It looks like I either have to change it to use an manuever node unnecessarily, or I'll just have to wait until my apoapsis is the right height for me to assume I've gotten an encounter, although if I've taken too long to make the burn that assumption may be wrong.

Does anyone know how the built-in variable "encounter" is supposed to work? I thought it printed the string name of the next upcoming body encounter but it doesn't. Here's a screenshot of what I mean. It's clear from the screenshot that I've got an encounter with the Mun coming up, but "print encounter" still shows "None". (EDIT: you can't read the text in the screenshot's scaled-down image but you can rightclick it and "view image" to see it at full resolution to read the text.)

The parachute is irrelevant to the calculation of whether or not the debris should be removed. The craft dipping into the atmosphere WILL decay and fall in at some point. The parachute just means it will happen in fewer orbits.

One of the weaknesses with the user interface is that it's not typical in any GUI system to just click on a bare text label word to perform an action. The lack of a widget of some sort - a button or toggle or whatever, makes it unclear to new players that the mode even IS manually switchable. Click on the title to change it isn't that intuitive and people generally don't know that exists until someone shows it to them.

It looks like the questions are missing and it's only the answers. That makes some of the answers hard to interpret. Just seeing the word "Correct!" doesn't mean much without seeing the question.

Up-arrow technically doesn't bring up the previous command. It brings up the previous LINE. There's a difference between the two when it's a multi-line command. I've seen behavior like that when the error was this: oops this line has no period lock throttle to 0.5. (press up-arrow here) lock throttle to 0.5. The first one fails because "lock throttle to 0.5" was really part of the poor syntax command: "oops this line has no period\nlock throttle to 0.5.". But when up-arrowing only the last half of the command showed up and was run.

I like the idea, but I have a few questions about the rules: 1 - Does the Mun count as "any body", for the sake of scoring or does it count as still being a child of the SOI of Kerbin (becauase the Mun's SOI is a pocket inside Kerbin's SOI maybe it still counts as being inside Kerbin's SOI, depending on how you wanted to look at it, and what you meant by the phrasing of it. 2 - You didn't explicitly mention Time Warp or Physics Warp in your list of exceptions that you are allowed to control manually. Are you allowed to time warp manually or do you have to have the KOS module do it? I'd prefer it to be manual. In a sense I don't even like the fact that KOS script can adjust time warp, because that's sort of breaking the fourth wall a bit. The Kerbal software engineers who wrote the code shouldn't even know there is such a thing as time warp. From their point of view it doesn't exist. Just like the camera angle. 3 - Lots of people have been sharing code back and forth with each other. That may make it difficult to really track down who gets the credit for a successful mission, but oh well, that really can't be helped. Let's start the challenge.

I can confirm that remotetech has nothing to do with it, as I get the problem with ONLY KOS and no other mods installed. And yeah it's just because the quicksave was made before the problem. Quciksaves and persistence files are the same exact thing in the same exact format. The persistence file is just a save that happens automatically at regular intervals and when performing certain actions (like switching to the space center). I wonder if the mod is perhaps trying to "catch up" in some way when it gets reloaded from rails to full-simulation mode. Imagine if it's trying to go "oh crap I've missed like 3,000 command cycles according to the mission clock, I'd better hurry up and execute them." (i.e. maybe it's trying to update all the active LOCKs for all the missed time?) That's pure speculation. I haven't peeked at the C# code in ages. But at any rate the more people who can say they have the problem the more likely it will get attention and be looked at. Up till now I thought it was just me. And it's definitely not new with 0.92. I first noticed it back in 0.7 and for all I know it was present before then. (I wouldn't know because I hadn't been ever trying to do the things that seem to trigger it until then.)

Is anyone else getting the this problem to frequently recur like I am? I had a script program running on an SCS module on a craft. It doesn't seem to matter what the program was - pretty much any program has the following problem. If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", whether it's because I select it from the tracking center or because I fly another craft within 2.5 km of it, will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS framerate, and furthermore it usually triggers the parts disappearing bug (where half the ship is gone but the camera still rotates around where the center of mass WOULD be if the full craft was present - so SOME part of KSP still thinks the rest of the parts are there but you can't manipulate them.) The only way to recover from this is to have had a quicksave you can go back to. The craft is permanently broken in the persistence file at this point. This seems to happen with great frequency and I don't know why. I suspect it must be something the KOS mod is doing upon loading the vessel into the full physics engine. But it only happens if a program had been run. So what's different about a SCS part without having run a program and one that had run a program? The only think I can think of is that if a program had been run, then the mod is probably going to try to remember the state of things - the global variables that have been SET or LOCK'ed. Perhaps its the restoration of those things that makes this problem occur. I have found that if I turn the SCS module off (via the "toggle power" button) before going on rails, and then power it back on again after coming off from rails, then it doesn't happen. It has to have been turned on when it went onto rails. Can other people confirm or deny whether they get the same thing happening or is it just me?

The mod can only manipulate the controls that exist in the normal game. I don't think this could be possible unless KSP itself provides a way to do that.

The problem with those sorts of suggestions is that the G forces involved would ruin most payloads. You have to get up to orbital velocity in just a few kilometers. The amount of acceleration that takes is enormous. Even if you have the technology to make the rail gun that can do that, you then have the problem of making the payload, be it people or computerized probes, survive it.

And the existence of globals, while it does provide a way for a program to give information back to the caller, isn't nearly as nice and clean and intuitive as having actual return values. This: lock steering to run myUpdateSteerFunc. is way cleaner than: set resultOfSteerFunc to R(0,0,0). // default starting point. lock steering to resultOfSteerfunc. until (something) { run steerFunc. // updates resultOfSteerFunc. }. Granted, running the subprogram continually in the background (via the lock statement) might be an expensive operation, but it doesn't have to be if it was implemented differently. The KOS computer should parse the program once and store it's pre-parsed version to execute, and then not re-parse it unless the timestamp on the file has been updated since it was last parsed.

That's exactly what I do. My tfXYZtoENU was written that way with all variables starting with "tf". But that's insufficient if two different people wrote two different subprograms to be later combined together, and one of them took advantage of the persistence of global variables between calls. One of the things local variables do, besides preventing name clashes, is force people to treat the variables as ephemeral and lasting only as long as one pass through the function, unless *explicitly* stated otherwise. The naming convention doesn't fix the problem because the "L" variable you use might be an "L" variable another subprogram uses, and it gets messed up when you change it.

And I don't want to end up in a situation where to play the game I'm required to perform one of those asinine dance-dance-revolution style simon-says sequences where the computer scrolls pictures across the screen and you have to hit the buttons at the rignt time as the icon scrolls by. And I don't want to have an action sequence in which I have to fight my way through a horde of zombies to get to the launchpad to get into space and escape the undead apocalypse. And the likelyhood of those things ever being implemented in KSP is no less likely that what you're saying you're afraid of having happen. It's not even a remote possibility so it's an odd thing to mention as if it was.

Perhaps the suggestion should be changed to "the altitude at which this happens is too low". Because a piece of debris that's dipping into the atmosphere *at all* would eventually decay and fall in if you were willing to perform the tedious task of having to watch it the whole time so it doesn't go on-rails. It might take more than one orbit to eventually decay that far but it would eventually do it, as it slows down each time it dips into the atmosphere.

In fact, a limitation of the language is that ALL variables are global. Which can be a bit of a problem when trying to write routines to share with other people. You have to warn them "these are the variable names I used. I hope they don't clash with any you used."

Boredom isn't the only problem that a low TWR can cause. It *does* in fact matter when you have to make a burn to get captured in orbit around your target planet. If it takes you 30 minutes to get the needed delta-V to get captured, but your flyby will zoom past in only 20 minutes, you can't get captured.

Put the navball in "surface" mode and watch the green "x" : the retrograde marker. To be falling vertically with respect to the ground you have to have the green 'x' at the very center of the sky. So when you get near the bottom and want to kill your relative horzontal speed, use the navball to steer by and try not to look too much at the 3-D view on the screen - just keep your eyes on the ball. The goal is to get it going vertical a little bit above the ground. And you do that by "chasing" the marker while adjusting your throttle to make sure you never stop falling, but you fall slowly. To "push" the marker, put your aiming crosshairs on the other side of it. You'll "push" the retrograde marker away from your crosshairs. Like this: X = retrograde marker . = where you want to move the retro marker to + = your current crosshairs. + X \ \| ~ . "push" the "X" with your crosshairs, toward the center.

You are contradicting yourself when you claim you have a problem with the idea of not being rewarded for making a space station and also claiming you prefer things to work the way they do for science (where you don't get rewarded for making a space station). It is *already* true with the way science works *now* that not everything you could possibly want to do will give you points. And you state you *like* the way it works now, but don't want missions to work in a way that, when you describe it and give specific examples, is exactly what science does now (which you did say you're okay with). You're just not making sense. Fair point, but I still have no idea what it is you don't want because you contradict your own statements. Some of the time you say you don't want to be compelled to do things you normally wouldn't but then say the way science works now (which does precisely that) is fine.

So you're contemplating something like crossing KSP with Artemis Bridge Simulator?

Same here. I thought it was a way to find new ways to get science, not just change the text of how it's reported.