Dunbaratu

When all objects are on rails and none are in current "full physics" mode, presumably KSP could work out their position at any arbitrary time T without having to actually calculate all the intervening positions they occupied between now and then. If you have equations that you plug in time T and get out the locations of the objects (which as I understand it is how being on-rails works), then why not have a faster version of "time warp" that just skips ahead to the requested time and doesn't bother calculating the intervening moments? To ensure it cannot be used when any object is currently loaded into the full physics engine, you could put the user interface for it only on the Tracking Center screen. I think you can't get to that screen without putting your current craft on rails first. So the way it would work is this: After performing a burn you see that it claims you'll have a Duna encounter 180 days from now. You could time warp through those 180 days at 10000x speed, but instead you decide to escape out to the tracking center, bring up to time jump interface and type in, say, 178 days, 12 hours, to jump ahead to the point in time about 1.5 days prior to the intercept. Alternatively, if the idea of typing a time is seen as a bad user interface, a slider along a timeline would work as well as a user interface. If there's problems where trying to skip past changes of spheres of influence might make it not work and calculate everything wrongly, you could implement an upper limit on how far you can time jump - you can't time jump past the next predicted SOI change of a craft (i.e. encounter). Obviously the impetus for this is the fact that even at max time warp, you can be waiting a very long time to slowly creep along your orbital path when going to/from the outer planets.

Someone tried making a version for 0.23 that will make it work for KSP 0.23 but it introduced other problems that makes it a pain to use. (I suspect this is because it also contains other github changes people have made that haven't been regression tested and are not in the main code. At any rate it broke the ability to test against a literal string and that would require a lot of editing of my scripts to get them to work with it, so I decided not to pursue it any further until there's a more formal project admin back at the helm again to decide what pull requests are in and what ones are out.). Luckily I knew that KSP updates tend to break mods, and I knew that we had no mod admin right now, and I knew 0.23 was coming soon, so I copied off my entire 0.22 install of KSP before the update came. If I want to play with kOS I go over into my KSP 0.22 copy to do so. But right now, if you're somebody who didn't do that, or you are only just getting into kOS now after the 0.23 update, then you're sort of out of luck. No idea. Buzz got one limited cryptic message about "dealing with personal stuff" but nothing about whether or not he'd like someone else to take over managing the project or if he's planning to come back to it soon. The fact that the version on spaceport doesn't work for 0.23 is sort of forcing the issue. We'll need to pick a new admin and set up a new fork of the project, I fear, since nobody can get a hold of Kevin Laity to ask his opinion on what to do with his project. I'd volunteer except for the fact that all my programming experience has been in UNIX, where hardly anybody uses C# or Mono, so I have zero experience with them. The admin should be someone well versed in the core system being used, and that someone isn't me. I barely consider myself qualified to contribute a one or two line change here or there. It's licensed using GPL, which being one of the open source licenses means that starting a new branch of the code should be no problem, legally. But out of respect for Kevin, I think we should be clear in the naming of the branched project that it's something distinct from Kevin's. I.e. calling it "KOS 2.0" would be a bit rude to Kevin. Perhaps a name like "CommunityKos" or another punning of old-school computer products akin to KOS could be used, like "DR-kOS" (Derived Respectfully kOS).

The launchpad its not the only place a bootloader would run. It would also run whenever an SCS is rebooted. (And if it doesn't then it's implemented wrong). That makes it a lot more useful.

Whenever someone requests the ability to rotate parts like docking clamps, the request is immediately stifled using the utterly ridiculous notion that they've just asked for robotics. No They Haven't. Manually moved things under human control are not robots. The fact that I can turn a doorknob does not make the doorknob a robot. The fact that the fins and flaps on a KSP rocket rotate when you use the WASD keys does not mean they are robots. If there is a reason that manually rotatable parts are not supposed to be suggested then they need to be treated as an entirely separate topic from robotics. Constantly telling people they should have already known that that's what "robotics" means is not reasonable because that's not what the word means. Causing a thing to move by twisting a control knob is not robotics. If there is a reason that rotating parts are not to be suggested then they need to be mentioned separately from robotics, since that's not even remotely close to being the same thing.

Wait... you CAN? Gaargh why is so much basic functionality of this game a secret easter egg?! I've played over 1000 hours and never found that. I agree, that given that previously unknown fact it does rather mitigate the need for my request. It's still a bit annoying that the weird ladder alignment means you have to build a rather weirdly skewed looking craft to make the ladder line up but at least it's possible. (i.e. the fact that the cockpit's idea of "up" on the navball can't line up properly with the rest of the craft if you rotate the capsule to get the ladder to line up is still a bit annoying. )

No it doesn't. With a lab you can put a station in orbit around the Mun with a light small science lander attached to it, and keep landing the lander at different "biomes" (I hate how kSP uses that word, as it's about terrain not biology so it's the wrong term) without having to carry the fuel of the return with you. Exploring 10 different "biomes" with one set of reusable science instruments, storing the results in the lab between landings, and then bringing the lab back home, is less expensive than sending 10 different missions to the moon and back. That way you are only paying the fuel cost of bringing the small lander in and out of the Mun's gravity well, not the cost of doing that with whole missions over and over.

You can only rotate a part by exactly 90 degrees. Therefore when the ladder of the Mk1-2 Command pod is rotated 30 degress off from the ladders embedded in all the other parts in the game, there isn't a thing you can do about it. It's impossible to make it line up. This has been a problem for many versions now and it's getting a bit silly. I refer to this:

One of the reasons I'd find arrays useful is that they'd give a way to make the various LIST commands usable by scripts. Right now they're only usable by humans because the data they spew out appears only in screen text and can't be read by the script. But if arrays existed then you'd also be able to alter the LIST commands to say things like LIST PARTS INTO myArr. (Now myArr is an array containing the strings of the part names.)

Changing the name of the bootloader per vessel is kind of ugly. How about making it based on vessel NAME. If I call my vessel "QWERTY1" then it will bootload the archive program called "QWERTY1.TXT". I;e;. if vessel name is QWERY1, then it will: copy QWERTY1 from 0. run QWERTY1. After it finishes loading the vessel and engaging the physics engine on the lauchpad. I would assume that arrays would be dynamically growable in order to make it noob friendly. Also, if they don't contain all generic kos objects then there's no point in having them. (and, if you make them contain all generic KOS objects and the array itself is also a generic KOS object then you get multidimensional arrays for free without any additional implementation work - a 2D array is an array whose elements are themselves also arrays. Just make sure that the syntax parsing tolerates this without having to perform additional statements. i.e. something like arr:thingAt(i):thingAt(j) or arr(i)(j) needs to work as opposed to needing to resort to getting it in two statements like set row = arr(i). set thing to row(j).) As for array size, one style that has been done in the past is to tolerate any array index by simply growing the array as needed to fit the subscript used. i.e. if you have an array of size zero, and try to store something in arr[10], then it grows the array to size 10 and then stores the thing there, rather than erroring out. This approach is very noob friendly, but it does open up the possibility of accidentally carving off an enormous amount of memory and thus crashing the system if you say something like set arr[altitude] to 0 when you meant to say set arr[0] to altitude.

(when talking about adding arrays) I think it's important to categorize complexities into two very distinct categories: 1 - Complex things that the mod requires a user to use. 2 - Complex things that the mod allows a user to use. Arrays would belong in category 2. That makes it far less confusing than a thing in category 1 would be. Examples of things that are in category 1 right now would be Euler rotation tuples. You can't get anything done without understanding them (and, importantly, finding out the super-secret undocumented fact about the order in which the rotations occur. The same rotation tuple gets different results depending on if you roll, pitch, then yaw, or yaw, roll, then pitch, or pitch, roll, then yaw, etc. And I only found out which way it is because I found a webpage about the Unity engine describing how they do it, and presumed that kOS is using Unity functions so it must be doing it in the same order. That's an example of a complexity that users MUST learn to make sense of the mod, whereas arrays are a complexity the user only adds when they choose to.

I think that if someone wants to make a kos-like mod starting from the existing code and forking it, but change so much about it that it is no loner recognizable as being the same basic language structure, that the proper way to do that would be to pick a brand new name for that project and call it a different mod entirely. Continuing to call it the same thing when it's totally different would lead to unnecessary confusion.

In other words, kosscript. which looks nothing like c++ or c#. There is exactly 1 thing ONLY it shares with C++ and that's the curly braces. That's IT. Nothing else looks anything remotely like C++. To claim it looks like C++ is to reduce C++ down to one single teeny tiny aspect of the language and ignore everything else about it. It's an impossible dream to a certain extent. unless you sacrifice functionality to get simplicity. Programming languages are complex not because programmers go around trying on purpose to make life harder for themselves, but because there's a minimum complexity inherent in their flexibility.

I am mindful of the original intent of Kevin to make this not TOO hard for non-programmers to get started with. So the idea of variables being global by default. while terrible programming practice for "real" programming, does ease the barrier to entry for new people. Since one of the design goals was to make declaring variables optional, and allowing them to just be made by using them, you have to decide how those implicit declarations behave. Thus globals by default, locals only if explicit. Also, I'm trying to suggest the least syntax changes as possible. Making the behavior be identical to what it used to be if you don't change the script code keeps things backward compatible with Kevin's original design. I too think the period is a bad idea. But I'm mindful of the idea that even if we do decide to "steal away" Kevin's project for now I want to be nice to him and leave it in a state that he would accept if he comes back. Basically when it comes to a conflict between "do it the way I'd prefer" versus "do it the way that looks most similar to the rest of the language" I'll side with making it look like the rest of the language. That's also why I suggested a syntax like "SET X to 1 + run myProg." for return values, inserting the word "run" in there just to keep it consistent even though that looks weird to us old-time programmers.

Which of the following script language features would be most useful? Just taking a survey of people's opinions. This is NOT a question about the instrumentation or the I/O for controlling the craft. This is about basic language features the syntax should be made to support and which ones people think are best. Also, this isn't about fixing obvious bugs, like the misreported line numbers on errors, but about new features. Keep in mind that things that would confuse non-programmers need to be considered with great caution. * A way to explicitly declare a variable to be local (so it goes out of scope when the sub-program run ends). * A way to embed quote marks inside literal strings. * A way to give programs return values (so you can use them in expressions such as SET X to 1 + run myProg(y).). * A way to make array variables. (if they can contain any arbitrary object then a 2-D array would be doable as an array of arrays). * ONCPU: A way to make one CPU tell another CPU to execute an arbitrary command on itself (i.e. ONCPU 2 run prog1.) (only if they're on the same vessel). * BOOT.txt: A standard convention that if a volume contains a program called BOOT on it then this program is auto-executed after the CPU is started or restarted. Feel free to add to the list if there's something obvious I missed.

You can't do arrays but you can do vectors of 3 numbers. The intent was to use them for xyz coordinates but technically you could use them as a crude 3x1 array until such a time as the language actually supports arrays.

At minimum even if you edit all the code externally you still have to type at LEAST the spaces in the following commands: copy[space]programname[space]from[space]0. run[space]programname. If those cause stages to execute that's still going to make the mod unusable. I haven't seen this behavior. Something is wrong with the installation.

What there should be to solve this is a sort of basic walkthrough to build a "hello world" sort of program. It would include an example of where the archive is and so on. I wonder what a "hello world" would be for kOS, though. A program that just unconditionally shoots off at a 45 degree angle for a few seconds, cuts the engines and hits the chutes perhaps? Kevin originally had some basic simple scripts but they don't start from the beginning of the process. A good hello world walkthrough should actually start from assembling a simple crude rocket in the VAB, editing the code in an external editor, where to copy the code to in an installation, and so on. With the exception of two keypresses that can't be exclusively trapped by a mod, which are "X" and "Backspace/Del", that's not supposed to happen. If it's happening then something wrong is going on. Do you have other mods installed? Sometimes different mods "argue with each other" over who gets control of the kepresses. There should be a variant of the ground radar that aims in the direction the craft is pointed. But there isn't. It always aims straight down no matter how the craft is oriented. That makes it hard to scan an area because you have to move the craft over it instead of just rotating the radar receiver back and forth. If I knew more about the artwork side of things I'd consider going through the effort to make a radar part that does this. You mount it on the craft and it always reads the way it's pointed (so mount it upside down to scan the ground) and when the part tilts (by tilting the craft) it also changes its aim to match. I just don't know enough about KSP to do it. kOS does not support arrays right now. There's a few things that it's hard to implement because of that. You can't make a generic algorithm that operates on arbitrary amounts of data when you need a different hardcoded variable name for each and every piece of data. You could hardcode a solution for a known small array size with variable names like arr11, arr12, arr13, arr21, arr22, arr23, arr31, arr32, arr33, but you can't write code that lets you, say, pass in any arbitrary M and N for the array sizes.

@MaHuJa: I've been trying the build you made to work with 0.23 KSP and I noticed its version is listed as 0.93 in the terminal window, which makes me think it has more changes than just the ones you did to make it work with KSP 0.23. Did you build it from code on github that also contains other changes from other people too? Because I noticed it won't parse any of my programs because this syntax that used to work in 0.92 no longer works in your build: if someVar = "literal string here" { print "hi". }. You can no longer compare against a literal string. It used to work in 0.92. If this is an intentional new change and is to be expected in future versions of kOS then I'll go though my scripts and change them all, but if it's an accidental change that's the result of someone making a mistake when editing the code, then I'll leave my scripts alone and wait.

After reading your post I tried wiping kOS and re-installing it. Now the SCS part is there and it works. It seems that if you do it in this order: Step 1. Have kOS already installed. Step 2. Upgrade KSP from 0.22 to 0.23 Then the kOS part won't appear. But if you do it in this order: Step 1. Upgrade KSP from 0.22 to 0.23 Step 2. Install kOS after that. Then it works. EDIT: No it doesn't. I spoke too soon. I just tried it and it won't let me click on the terminal window to focus keyboard input onto it. When I try I get this in KSP's debug log: "[Exception]: MissingMethodException: Method not found: 'EditorLogic.Lock'."

For people more familiar with C# than I am, can you confirm what I'm saying here? I think in kOS that when you use a lock expression, the system stores the parsed expression data structure for re-execution later rather than re-parsing the actual raw ascii text of the expression each time. If that's true then there sort of is a bit of precedent for this. Maybe that system could be expanded to the entire program.

I suspect the intent of Progcom was that if you emulate the low level machine you should be able to run compiled code on it. The idea being that you could write in a higher level language and cross-compile it targeting the progcom CPU. But it never really got that far.

Is the challenge only supposed to be for spaceplanes? It's a bit of a pain to get a rocket design into the hangar instead of the the VAB. Secondly, that really doesn't answer all the questions. Vacuum versus Atmosphere measure was just one question.

So we've been waiting on Kevin so as not to steal his project away from him while he's sorting other things out, but it looks as if the 0.23 KSP update may be the thing that forces the issue, since kOS 0.92 doesn't work iwth 0.23 KSP. (It's not just a matter of it not compiling the source code, even the precompiled version on Spaceport doesn't work anymore - I'm playing through a new career and the SCS part doesn't show up in the tech tree in 0.23. MahuJa 's work to make it go in 0.23 is nice but the time may have come to make an official fork and start up a new github page. I would have otherwise preferred to give Kevin more time but the fact that 0.23 requires a recompile sort of makes that nicety impossible.

So, supposedly KSP 0.23 is going to appear real soon now. With Kevin still gone are there any ideas about what to do about the 0.23 update? I'm going to save off a snapshot of my 0.22 game now just in case there's compatibility problems with 0.23 that could take a very long time to fix without the project admin around.

Although you already got one solution it can't hurt to have more tools in your toolbox of solutions, so here's another technique that works to find your radial-in direction without much math: Use a maneuver node to find it, like so: 1 - Make a dummy maneuver node at the point where your periapsis would be if you didn't burn, with a delta-V of -1,0,0. 2 - Add it to the flight plan. 3 - Read the delta-V vector of it. 4 - Remove the node from the flight plan. It served its purpose which was just to tell you which way to burn. 5 - Use the delta-V vector from step 3 as your steering direction. Code would look like this: set dummyNode to NODE( time:seconds+ETA:periapsis, (-1), 0, 0 ). add dummyNode. set radUnitVec to dummyNode:DELTAV. remove dummyNode. // "radUnitVec" is now a unit vector pointing in your radial-in direction. You can steer by it: lock steering to radDir. What this does is that instead of a slowly rotating burn that turns as your velocity vector rotates, it will point you at what the radial in direction *will be* at periapsis rather than which way it is right now, and it has you burn in a straight line that way, as shown below in direction 2: KEY: @@ = where your ship is now. 1 = Direction of radial-in now. 2 = Direction of radial-in later at periapsis. ..... ..@@_____\ 2. ... \ / .. \ | :: __\| :: 1. : **** : ********** Pe______\ ************ : / ************ : ********** : **** :: :: .. ... .... .....