Dunbaratu

I tried working out that same drag formula and balked at KOS's inability to query the coefficient of drag for the ship. It looks like you're plugging in 0.2 as the coefficient of drag. Where did you get that 0.2 figure from? You mention that it would be higher with a parachute. That's true but even before the parachute is thrown into the mix how did you know it was 0.2 in the first place? Did you obtain that number from outside of KOS? (i.e. writing down the parts' drags as you add them to the ship, or getting it from a mod, or something like that)? Because I can't figure out how to derive it from inside of KOS.

That should be on the GitHub Issues page. But I'd recommend that if you're only going to be able to get one operator of the set: ROUND, TRUNC OR FLOOR (same thing), CEIL MODULO (the "%" operator). implemented (because let's face it, Kevin is busy), then of the set of all those, that TRUNC is in fact the most valuable one to implement first, because with it you can derive the others: CEIL(X) is almost always the same as TRUNC(X + 0.999999999999 ). (As many '9's as you can fit before the float precision rounds it up - the problem being that how large that can be varies depending on how far away from zero X is. The precision is not constant - it gets worse the bigger the number is. That's why I had to say "almost always" rather than "always".) ROUND(X) is almost always the same as TRUNC( X + 0.5 ). (Depending on rounding algorithm). (To get a ROUND(X,digits) function you can multiply by powers of 10 to shift the decimal place, do the TRUNC, and then multiply by the opposite power of 10 to shift the number back.) And MODULO(X,Y) *is* always the same as X - TRUNC(X/Y). (What's leftover after the integer portion of X/Y). If there's only going to be one thing implemented, I'd rather it be TRUNC. It's a lot more universal.

I made the "Sidebar Topics" page for things that are sort of not quite syntax and language features, and also sort of not really containing fully fleshed out examples and tutorials, but are instead for exactly things like this - helpful extra information on the side that a KOS script writer would need to know - like how the XYZ system is laid out, or how the Volumes and Archive work, or how long antenna range is.

It would be even nicer if we didn't HAVE to worry as much about the global namespace. I'm thinking in terms of the stuff needed to write helper library routines and one of the hard problems is that all variables are global in scope and there's no way to declare a variable to be local. (Only the DECLARE PARAMETERS are local, nothing else is.) While this certainly fits with Kevin's goal of making it easy to understand for the layperson it does have the problem that there's a good *reason* languages have a distinction between global and local variables. Local variables let you make subroutines that don't have to "know" the names of all the other variables in the rest of the code they are going to be mixed in with. They can use a variable with a short name like "x" or "i" or "front" or "count" without worrying that they may be clobbering a variable used by the calling program.

I do not agree that both do so. But I've already shown exactly why I don't agree, so there's no point in me repeating the same thing I already said in response to you saying the same thing you already said. Back to kOS.

But you can query the variable "body" to see the string name of your current body. So while this isn't ideal, and I'd rather be able to read the science instruments as well, you *can* at least make a routine that contains all the wiki-able stats about the planets and moons, and looks them up based on the string you pass in. Here's what I've done so far for just Kerbin, Mun, and Minmus. It's clear that the idea can be expanded to all the planets with a bit of time spent wiki-looking and typing. Seeing as how this isn't the interesting part of making an autopilot, but it is needed, I'd like to have this be a thing that people communally edit wiki-style for everyone to use. Once it includes all the stats for all the bodies it will become too big and will eat up most of the disk on a remote probe, but I have an idea that what you'd do with it is keep it at home on your archive and "beam" the stats to the probe like so: //Running on Probe, if it has radio range: switch to archive. run bodyStats(body). switch to 1. // go on with rest of code. To simulate the idea of the home base sending the data to the probe when it asks for it, rather than the probe having to know the stats about everything in the system. The bodystats looks like this so far. Some of these parameters would be pulled out of it if it was for public use because they're just for my lander script: // bodystats: sets up variables for use in programs // that need stats about the orbital body that is the // current SOI. Looks up the body name and fills // the appropriate variables. clearscreen. declare parameter forBody. print "Settings for SOI body: " + forBody. print " ". // Placeholder Defaults in case I didn't code stats for current body. // ------------------------------------------------------------------ set bodySurfaceGrav to 10. // The m/s^2 at the body's surface. set bodyRadius to 500000 . // The radius from center to equator. set bodyMaxElev to 4000. // The peak of the highest mountain. set bodyTVelTenKm to 999999. // Terminal velocity at 10,000 m. // The actual math for term vel is complex. // This data point is for fuzzy heuristics. // Set really high for planets with no atmo. set descendTop to 50000 . // The highest AGL at which descents might start. set descendBot to 100 . // the AGL where a descending craft should hover. set descendTopSpeed to 2000.0 . // Desired speed at top of descent profile. set descendBotSpeed to 4.0 . // Desried speed at bottom of desecnt profile. set bodyLandingSpeed to 4.0. // Desried speed to come down from hover to set craneDropAGL to 10. // AGLto drop skycrane payloads from. // Warning this is measured from craft control // unit, not from craft's bottom. set throttleGentle to 100. // Throttle gentleness. // too low and the throttle is twitchy. // too high and its too slow to react. set c to " ====== deviations for each body ===== ". if forBody = "Kerbin" { set bodySurfaceGrav to 9.802 . set bodyRadius to 600000 . set bodyMaxElev to 6761 . set bodyTVelTenKm to 267 . set descendTop to 70000 . set descendBot to 100. set descendTopSpeed to 1800.0 . set descendBotSpeed to 6.0 . set descendLandingSpeed to 4.0 . }. if forBody = "Mun" { set bodySurfaceGrav to 1.63 . set bodyRadius to 200000 . set bodyMaxElev to 7061 . set descendTop to 20000 . set descendBot to 50 . set descendTopSpeed to 542.0 . set descendBotSpeed to 6.0 . set bodyLandingSpeed to 2.0 . }. if forBody = "Minmus" { set bodySurfaceGrav to 0.491 . set bodyRadius to 60000 . set bodyMaxElev to 5725 . set descendTop to 10000 . set descendBot to 30 . set descendTopSpeed to 274.0 . set descendBotSpeed to 5.0 . set bodyLandingSpeed to 2.0 . }. print " ". print "bodySurfaceGrav = " + bodySurfaceGrav. print "bodyRadius = " + bodyRadius. print "descendTop = " + descendTop. print "descendBot = " + descendBot. print "descendTopSpeed = " + descendTopSpeed. print "descendBotSpeed = " + descendBotSpeed. print "bodyLandingSpeed = " + bodyLandingSpeed. print "throttleGentle = " + throttleGentle. print " ". print "('AGL' means Above Ground Level to distinguish ". print "from sea level altitude.)". print " ". print "You may change these variables with the 'set' ". print "command before running other programs to try ". print "other settings.". print " ". I like this idea and would like to see it publicly developed. But first I'd like to see some better conventions for variable names than I used. I think mine are too wordy given the small size of things in KOS.

You've altered your definition in that last line. I added the boldfacing to show the contradiction. You changed your claim after looking it up. I'll admit I had it wrong if you ALSO admit you had it wrong. Saying not a requisite for allows for the first and second definitions in the Oxford dictionary to exist. What you said earlier does not allow the first definition to exist. What I said didn't allow the second definition to exist. We were both wrong.

Well I would argue that if you start from a thing that isn't perfect, and after working on it for a while you end with a thing that is better but still isn't perfect, that using the term "perfecting" isn't really correct and when people use the word that way they're doing is engaging in hyperbole rather than telling the literal truth. Part of the problem in declaring an autopilot to be perfected is that the same human error that can appear in the making of it can also appear in the judging of it. If the software is judged to be perfect you first have to ask by what criteria it's being judged as perfect, then you have to check if the judgement process itself is perfect, and then whether or not the judgement of the judgement process is perfect, and so on in an infinite regress. Only when it contains no loops. Once there's a loop meant to execute a very large number of times this becomes a mathematical impossibility due to the fact that any program analyzing a loop is no more reliable at concluding and coming to a final answer than the loop itself is. (i.e. if you write a program to detect whether or not another program has an infinite loop, if it does have an infinite loop then the detector program gets stuck in an infinite loop as well when trying to analyze it - so the only answers you can get out are "it does terminate" or "I don't know if it does or not. Give me more time." You can never get the answer out "yes it does have an infinite loop.")

No it can't. In fact there are a number of mathematical PROOFS that it can't. You can only approach the asymptote of reliability without actually getting there. If you drop the word "perfected" I'd be more willing to agree with you. The program can be subjected to lots of test cases, bringing the reliability up. But it cannot actually achieve 100% reliability. That would require an omniscient programmer. The difference in terms of reliability between a craft being piloted by a computer programmer ahead of time versus by a pilot who handles the controls "live" is the property of consistency. The computer programmer pilot doesn't have the luxury of being able to change his mind on the fly about what algorithm to follow. This is both a benefit and a hindrance at the same time. The meat pilot is more likely to make an error through inconsistency, but also more capable of reacting to exception cases. I would never want to fly in a plane that didn't have a pilot in the chair with the capacity to do a manual override.

This issue with inverse trig functions is probably not your fault. There's a bug in the current version that makes it nearly impossible to use inverse trig functions like arcsin, arccos, and so on in mathematical expressions. The entire system uses single-precision floating point numbers, but a tiny error in how the values of the inverse trig functions were being calculated made them return double-precision numbers instead. Once you've used an arcsin in an expression, from then on that expression gets promoted to double-precision and stays that way. If you assign it to a variable, the variable becomes a double. From then on anywhere you use that value it won't ever get demoted back down to single-precision. and the entire rest of the KSP system makes the assumption that all numbers are single-precision. When you stuff double-precision numbers into things it starts going all wrong. The fix for it is already in the development code according to what I see on Github, but it's not in a released version yet.

That's an excellent approach. It can get a bit confusing at times why expressions that work in one context don't work in another.

It's sort of inevitable that they will increase over time. As the language gets more things added to it, the parser complexity grows, to the point where it starts to become harder and harder to maintain a monolithic top-down parser like this. You find that making one change requires making it in 20 different places in order to make the language consistent about the change. Thankfully, from the issues raised on GitHub, I get the impression that the mod author is very aware of this but just doesn't have experience with parser generators and is still feeling the way through the idea. It can be a daunting subject the very first time you write using one, so I don't want to push too hard about making the change. I understand it might take a while for a person doing it for the first time. It's NOT a simple subject and most colleges dedicate an entire semester course to it when they teach it. Also, I can't complain too loudly about it when I'm not taking the time to teach myself Csharp and .NET to do it myself. I can't really fault someone else for not having time to learn a new tool from scratch when I'm not volunteering to do a similar thing from my end either.

But it introduces programmer error instead. Which is basically just pilot error that happened ahead of time. Autopilots are better at having fast reaction times, which gives the quick instant corrections needed for hovering, but its not because of pilot error that autopilots do the job better. It's because the meaty CPU in the pilot's skull has a very slow clock speed and more importantly has a very slow I/O system to receive the data about the state of the craft at any given instant and send commands back to respond to that state. The software running on that slow meaty CPU might be just fine with no errors in it and it still won't be able to do the job very well.

I hope so. My idea rather depends on this being true.

All bodies' positions are tracked relative to their parent body. I.e. the game doesn't track where the Mun is relative to the Sun. It tracks where the Mun is relative to Kerbin, and then in turn it tracks where Kerbin is relative to the Sun.

Thank you. This contains the information I need. Using the Mean Anomoly stat I can derive the initial position. It's a bit annoying that it's expressed in mean anomoly, as that's several steps removed from what I actually need which is angle from the parent body (true anomaly), but I can derive it from that so it gives me what I need.

This was very cool and it inspired me to make this similar thing: Which is sort of the same idea but my goal was instead of mimicking the Curiosity deployment to make some sort of generic lander script that could be used for any future craft I make. I intend to edit and refine it as KOS gives me more features until it's a be-all end-all lander script. Right now it doesn't do parachutes simply because KOS doesn't provide a way to query the parts on the craft and have the program "learn" if there's any parachutes and where they are. That's a feature I'd love to have - the ability to iterate over the craft's parts list and activate parts without them being in action groups. But there's other things KOS script needs dealt with sooner than that so that will have to wait.

That looks great. It's a bit annoying that hinged connectors are on the "do not suggest" list because they are so clearly needed to do missions the way real space programs do them. I like this mod. But ... what's the connection to KOS?

If you click on the embedded video and go to the Youtube site, the description had the link to it. But here it is again: http://kos.wikia.com/wiki/Example_-_Descend_Lander/Skycrane I've read through it again and realized there's some code in there I can delete. It sets a few variables up front that are no longer actually used anymore. They're a holdover from previous versions before KOS supported passing parameters to programs.

Your second post describes writing the first half of the program statically ahead of time and only writing the latter half of it dynamically. Your first post didn't explicitly mention that this is what you had in mind. Your idea works but only if the dynamic program is going to be run just once and then never again. It doesn't work if you want to write the dynamic code in a loop where it changes each time. To do that you can't just keep appending code. You have to delete and re-create the program from the start, and that means writing half the file ahead of time statically and then writing the other half later dynamically isn't a solution.

I thought of that. It doesn't work because it merely moves the problem to a new spot. Now instead of the modifying program being unable to print the quotes to build the statement print "hello"., it is now unable to print the quotes to build the statement set h to "h". and set o to "o" and so on. Besides, if that worked you'd just make one variable to store the dquote instead of a variable for each letter: set cmd to "print " + dquote + "hello" + dquote + "." . log cmd to prog. The real problem is there is NO way to store a quote in a variable in the first place.

They don't make sense because they're mis-labeled. They're CALLED yaw pitch and roll which makes you think they'd be related to the aircraft's view of the horizon, but they're not. They're relative to the native XYZ coordinate system of KSP. For example, what's called "yaw" is actually more like longitude (but not zeroed at the same point so it will always be an offset of longitude). A yaw of zero means "I'd be pointing at the center of the sky straight up if I was at the exact spot on my planet that the X axis comes out of the surface." A yaw of 90 means "This is the direction that would be pointed straight up if I was at the spot on the planet where the Z axis comes out of the surface. If that's not where I'm located then that's not true, for example if I'm actually at the spot the X axis comes out, then a yaw of 90 means I'm pointed due east at the horizon". I spent quite a while working it out by trial and error since KOS hides the real XYZ coordinates it was hard to figure out what the actual coordinate system even is. I put a long winded thing about it on the community wiki.

No, you don't *have* to delete the file after each edit. You *may* delete the file if it's your intent to start over. But that might not be your intent. So I prefer it how it works now. If you WANT to do just one statement each time by deleting the file each time you can do that. But otherwise you can build a larger program to run by appending many lines to the same file. On the subject of the self-modifying code use of the logger: I can think of two practical uses for this. It's not just a silly toy example for the heck of it: Useful Thing 1: Running a variable program name: The self-modifying code gives you the ability to make a hardcoded part of the syntax that wasn't designed to use a variable capable of doing so anyway. For example, normally you can't run a program whose name is stored in a variable. But with self-modifying code you could. // This section of code simulates contacting home base and asking them to transmit the stats about the body I'm orbiting: // OLD WAY YOU HAD TO DO IT: if body = "Kerbin" { copy KerbinStats from archive. run KerbinStats. }. if body = "Mun" { copy MunStats from archive. run MunnStats. }. if body = "Minmus" { copy MinmusStats from archive. run MinmusStats. }. if body = "Duna" { copy DunaStats from archive. run DunaStats. }. // ... etc ... with an entry for all the bodies in the game. // The NEW way with self-modifying code: delete getStats. set cmd to "copy " + body + "Stats from archive.". log cmd to getStats. set cmd to "run " + body + "Stats.". log cmd to getStats. run getStats. Useful thing 2: Giving data or setting communication signal flags for another SCS module on another craft to see: Imagine that two craft are working together to do a thing (docking?), and craft 1 needs to tell craft 2 when it's ready for craft2 to start running its code. Since SCS modules can't talk to each other directly unless they're on the same ship and can see each others hard drives, we use the archive as a stand-in for the idea of radio communication between the two craft. (craft 1 signals the archive, and craft 2 queries the archive. Imagine that this is like them talking to each other directly.) So imagine a signal flag called comFlag with these 3 values: 0 = wait for it.... 1 = Please do your thing. 2 = I acknowledge that I got your signal. There is a file on the archive called "signal" that just has this one line: set comFlag to 0. . The code for craft 1 does this: // At the point this code is ready to tell craft 2 that it's done, it runs this: switch to archive. log "set comFlag to 1." to signal. switch to 1. The code for craft 2 has this polling loop in it: switch to archive. set comFlag to -999. while comFlag < 1 { run signal. }. log "set comFlag to 2." to signal. switch to 1. // Do its thing. Now of course the file never got deleted, just appended to, so it actually looks like this now: set comFlag to 0. set comFlag to 1. set comFlag to 2. But only the result of the lastmost line will "stick", overwriting the earlier ones. At some point when the two programs agree that they're done using the flag file they'll have to delete it so it doesn't keep growing. You might be wondering why I didn't just delete it each time so it only ever has 1 line in it. This is because doing that would only be safe if the two statements "delete singal." and "log ... to signal." could be made into a single atomic operation that can't be interrupted. As long as there is the chance that craft 2 might try to "rum comFlag" just at the very moment that craft1 has just deleted it but hasn't executed the next line to re-write it yet, there's a danger of craft 2's code crashing on the file not found error. Since marking a section for atomic execution is a fairly in-depth programming feature that just doesn't exist in KOSscript and I don't expect it to, I ensure this problem doesn't happen by just making sure I only edit the signal file with one simple statement, which looking at the KOS code I know at least THAT much would be atomic (unlike in a real compiled language where you couldn't even assume a single line of code is atomic, in KOS you can).

Correct. That's why I like the idea of this over using mechjeb. Mechjeb is somebody ELSE's autopilot that just works out of the box. With this I make my own autopilot, and my own mistakes. But that being said, it's still got a ways to go before it's really practical to be able to do that stuff yet. Not quite enough information is exposed to the player writing a KOS script to be able to do all those math operations. But it looks like it's getting there, and it's gotten popular enough that there's now more than just one person helping edit the code for it on the GitHub archive. To give an example of how there's not quite enough information yet: you can't query to find the position of the planets. So there's not any way to calculate when to make your burn if you want to, for example, go to Duna.

Unfortunately you can't use the self-modifying code idea to make a program that contains any literal strings in it, since Kosscript doesn't include a way to protect a quote mark inside a quote string, as far as I know. You can't say something like this: log "print \"hello\". " to progfile. Nor this: set qmark to "\"". set statement to "print " + qmark + "hello" + qmark + "." . log statement to progfile. or anything else that might let you do that. If anyone has any ideas let me know.