Dunbaratu

It's one of the main reasons I gave up on my attempt to build a kOS orbital missile platform. (The other was the bug, now finally squashed, where half the ship gets deleted when coming back off of rails. That bug made anything in which I intended to run software on the base platform and also on the missile rather impossible to implement. I'd shoot the missile off, have the camera follow it, and then switch focus back to the missle platform and the platform would be mostly missing.)

I have had problems in the past where a decoupled SCS part was still able to activate stages on the detached parent ship. When I typed "stage" on the bit that was decoupled, the next stage of the ship it was no longer attached to was activated. I'm not sure this is kOS's fault however, because KSP itself has a lot of buggy broken behavior when it comes to staging lists with docking and undocking, so it may be KSP's fault that the staging list included parts from the detached craft.

I know that. But your question had nothing to do with asking how to control them. You were asking how to detect that engines have cut out, which would be a valid thing to ask about solid boosters. You can't affect when they'll cut out but you might want to try to detect when it has happened. So that's why I thought it necessary to point out that I was only offering a solution for liquid fuel engines. Your question could very easily have applied to SRBs, but my answer didn't so I thought I should mention that. I also made an asparagus stage trigger that worked by remembering the RATE at which fuel is being consumed, so it could detect when some but not all the engines stopped firing. (i.e. if it used to be dropping at 90 units per sec and now it's dropping at 60 units per sec, and I haven't changed the throttle setting, that probably means 1/3 of the engines have just stopped and it's time to drop a stage.) The problem is that it's normal for there to be small fluctuations in measurements because the amount of time it takes to execute a kOS statement is not fixed, so I had to add some tolerance for normal small changes. (In principle the time to execute a kOS statement is fixed in the kOS mod's code, but in practice it's not quite 100% the same each time, probably because KSP itself has some slight fluctuation in the time it takes between calling the hooks into kOS.)

Despite what I said about avoiding the terms X,Y, and Z, if Vectors were used I'd prefer to keep the terms X Y and Z. The terms Fore/starboard/top would be used if we weren't using Vectors at all. I do sort of see a problem in that vectors are handy thing to have and yet the terminology could confuse people…. I'm now waffling on what's the better thing to do. The thing I fear is someone combining operations between the games' other vectors and the 'docking vectors' and thinking they're the same X Y and Z axes. But the other thing is that being able to treat docking operations with vectors would open up a lot of useful things like using dot and cross products to help you calculate docking moves. These two goals are in direct contradiction…. Hmmm… I'm sure you've seen the stuff I put on the wiki ages ago about rotating frames of reference between native XYZ and north/east/up coordinates. What I'm now wondering is whether or not what kOS needs is a few frame-of-reference translation functions that users can call, like so: set vel to velocity:orbit. set relVel to coordSpaceToShip( vel ). print "I am drifting at " + relVel:y + " m/s toward my roof.". print "I am drifting at " + relVel:x + " m/s toward my right.". print "I am drifting at " + relVel:z + " m/s forward.". i.e. coordSpaceToShip() : input a vector in KSP's XYZ system. outputs a vector in ship-relative system. coordShipToSpace() goes the other way. coordSpaceToGeo() : inputs a vector in KSP's XYZ system. Outputs a vector in the current east/north/up. coordGeoToSpace() goes the other way. The thing is, by adding these functions to the language, you'd make it explicitly clear to users that the XYZ of vectors can be in different frames of reference, and get them used to the idea that the X of one vector might not be the same as the X of another vector. Maybe if these functions existed then having different meanings of X Y and Z wouldn't be as confusing as I had first thought. There's a part of me that feels a bit prideful that I worked out how to deal with XYZ's in KOS and do stuff like those transformations on my own with just trial and error and investigation at the terminal to work out what the coordinate grid is actually like, but I also recognize that having to do that was just silly and shouldn't have been necessary. Maybe providing these as built-ins would be a good idea. (On that subject, also the ability to convert between Direction and Vector, another thing I made a small program using transformation matrices for, would be nice. Obviously when going from Direction to Vector you have no magnitude for the vector, so you just make it a unit vector, and when going from vector to Direction you have no roll information so you have to just pick an arbitrary roll.)

I like the terms because they make it 100% crystal clear that what you are dealing with is a frame of reference that rotates with the ship. It's clear that "fore" can't be anything other than the direction the nose is pointed. As for the other confusion over xyz changing its frame of reference willy-nilly because of how KSP solved the space kraken problem, I agree that that could be cleared up (although it *definately* would introduce backward compatibility problems, it's better to do that earlier rather than later). It would be useful if kOS always returned values in the fixed-planet reference system instead of sometimes using the rotating-planet reference system. (That would mean normalizing the X and Z axes to always be the same longitude lines.) But that would require quite an overhaul in the code, as you'd have to remember to always run all user-supplied coordinates through the transformation before sending them to the KSP API functions.) And on that subject, another point of real confusion is how the *ORIGIN* of the XYZ system keeps changing depending on what value you're retrieving, not just on where you are. For example, the POSITION of a body is its position relative to your ship, while the VELOCITY of it is its velocity relative to your current SOI body. The fact that position and velocity are measured in frames of reference that don't have the same origin point is really messy and utterly non-intuitive. (thankfully they do have the same rotation other wise it would be even more messy).

I don't know how to answer that for solid fuel boosters, but for liquid engines it's just a mater of running a loop that remembers how much total liquid fuel there was in the previous iteration of the loop, compares it to how much total liquid fuel there is now, and assumes that if the value is dropping that must mean the engines are firing. If the value is remaining constant then that means the engines aren't consuming any fuel - i.e. they've cut out.

I'm against the idea of using the nomenclature "x,y,z" for direct RCS translation control (i.e. the HNIJKL keys). This is because there's already a frame of reference in the game using x,y,z axes that are oriented with the orbital body not the vessel. (where Y is north, and the XZ plane is the equator), and axes in this direction are what is used every time you get a vector's XYZ parts in kOS. Calling the vessel's orientation by the same naming convention would really be confusing because the X,y,z you're talking about when steering the vessel would be different from when doing everything else in kOS. How about making it clear that it's relative to the vessel by calling the 6 directions something like Fore, Aft, Port, Starboard, Top, and Bottom? (or left and right if you prefer that to port and starboard). You could have the 3 axes being called Fore, Starboard, Top. (That's a left-handed system akin to the rest of Unity. If you want a right-handed system then change Starbaord to Port.) (I sugested "top" rather than "up" because there's already an "up" direction that means something else in kOS).

It's trivial: Remember the latitude/longitude location where the rover first contacted the ground. Measure distance travelled from that. Any curving that was done along the way is wasteful as it only measures the straight-line distance from the current location to the landing point. A player would then want to curve only as much as is needed to skirt around bad terrain.

Agreed. Most of what made kOS hard to pick up in the early days was not the weirdness of the language, but the buggy implementation of it and the many places where the documentation differed from the reality. If it had worked exactly as advertised it would have been easier to deal with. Keeping an active list in your head of all the stuff that doesn't work and all the workarounds for it was what made it hard. The fact that the language looked weird wasn't hard except insomuch as it made it difficult to tell the difference between "this is a bug" and "this is me not understanding the language". When there were lots and lots of bugs, the inability to tell that difference was a problem. For example, the fact that all variables are global in scope and work across all subprograms was originally a bug and NOT what Nivekk intended. But by the time it was noticed too many people had depended on it (because there was no way for them to tell that it wasn't intentional. kOSscript was a weird language so if it's doing something buggy you might interpret that as what it was meant to do, which is what happened in this case). So what had been a bug became an accepted language feature and was kept.

There really should be two different types of 'early quit', analogous to "exit" and "return" in most languages. "exit" = end the whole process. "return" = just quit the current routine. (which in the case of kOS means the current script file program). They'd behave identically when just running one program, but differ when program calls are nested in other program calls.

Is it an editable file on the github (meaning people can try to edit it and those edits would reach you in the form of pull requests for you to accept or reject)? Fixing up documentation is one of the places where community help can really help a lot because it's far easier to tell that the documentation has a problem if you're in the process of actually trying to learn from it than if you're the person who wrote it and already knows what it was supposed to mean. I think the documentation being an editable github thing might be a good compromise between no user input to the documentation versus documenting by Community Wiki (Which has the problem that people can make up stuff that's wrong and not realize it's wrong because the actual author isn't involved to approve changes). Anyway, thank you for putting documentation out. Question 1 - about the Direction documentation: I'm going through it and I noticed that you mentioned VECTOR as one of the fields of the Direction structure. What is that? Does it return a unit vector in the direction of the Direction? Question 2 - about the List documentation: Is there some way to obtain random access to a single element from a list at its Nth position for any arbitrary N, rather than having to iterate over it sequentially in a FOR loop to get to it? Basically, is there an index operator like: print "The thing at index 3 is " + things[3]. or print "The thing at index 3 is " + things:atindex(3). or print "The thing at index 3 is " + ListElement( things, 3 ). If there is an operator like that, the documentation doesn't seem to mention it. (And if there isn't, it would be a really good idea to add it.) Maybe its the thing called "ITERATOR" that does it, but if so it's not mentioned how to use it anywhere on the page.

There is no surface prograde Direction (i.e. Euler Rotation tuple) but there *IS* a surface velocity Vector which when you think about it contains almost all the same information. (It's missing "roll" information, but adds magnitude information.) And you can lock steering to a Vector just as easily as locking it to a Direction. For example, for retro-firing you can keep yourself pointed at surface retrograde by simply doing this: lock steering to (-1) * velocity:surface. and that *should* be almost identical to: lock steering to retrograde:surface. (If there was such a thing as retrograde:surface). The only difference, really, might be your roll angle. Both will point you at the same spot on the navball. For a simple crude lander script, that should be enough, provided you don't try to kill your speed all the way to zero. As long as you try to keep descending at 5-6 m/s or so, then just locking to negative surface velocity should steer you fine. (It starts to break down if you want to hover, since as your vertical velocity starts to get near zero, the surface vector direction will get very 'sideways' and 'swingy' and staying locked to it when it does that would be suicidal. When I wanted to make a hover and seek-for-better-terrain algorithm, I had to do something more complex than just locking to retrograde. But as long as you're not trying to do that, locking to retrograde is fine.)

I'd like to register my approval of this idea for power off. (But not for going on/off rails, as I think that restoring code state for that makes more sense as on/off rails is a sort of breaking 4th-wall simulation artifact.) Shouldn't the hook be called POWERRESUME rather than POWERLOSS? Presumably it would run the code when the power comes back on again, not when it gets lost. I assume the <FILENAME> has to be local to the SCS unit for powering up, as I assume the SCS unit would forget the state of "switch to ...." when powered off. But would that be true of all hooks?

I wonder if it would be possible to start with a sort of crude dummy placeholder for the art and mesh - like just a plain one color rectangular prism with a color dot on one end to help see which end is the "business end" of it - to get started on the code until a better set of artwork can be created by someone later.

Ideally it would just return the distance to the terrain in whatever direction the sensor is mounted in, whatever that may happen to be. If you mount the sensor pointing out the bottom of the craft, then it tells you the distance in the direction the bottom of your craft is pointing. If you mount the sensor pointing out the side, then it tells you the distance in that direction. That way you could mount several sensors like in the image you posted, slightly angled off from each other by a few degrees, using the "SHIFT" key when building the craft to mount them aimed in slightly different rotations from each other. Actually it if measured in whatever direction it's pointed at the moment, I could get a lot done with just one sensor mounted on the craft. I could just rotate the craft a bit to get different measurements.

If you want to do everything in kOS and avoid having mechjeb do part of the work for you, you can make a rover remain locked to a particular speed very easily with just one kOS lock expression: Assuming the following settings: set seekSpeed to 9.0. // 9 meters per second in this example. set gent to 2.0. // tweak this to decide how "gentle" to make the adjustments. larger for more gentle, smaller for quicker reaction. This one liner will keep you locked to seekSpeed: lock wheelthrottle to ( seekSpeed - velocity:surface:mag ) / gent. It makes the wheelthrottle become zero when coasting exactly at the desired speed, and makes it larger in the forward direction the farther below the desired speed you are, and larger in the reverse direction the farther above the desired speed you are. It's crude and simple but for the most part good enough. As far as the slope seeking algorithm. the hard thing about doing it in this technique is that you can end up going perpendicular to the slope of the terrain and therefore get a false "flat" reading. I've had this problem trying to land before using almost the same sort of algorithm. It's almost like I need to scan over the area first taking sample readings before coming back in a second pass to land.

I actually don't think we are in agreement. I'm saying that it's unreasonable to try to fix the problem in a mod when the problem is caused by the main stock game, at a very deep level of that main stock game. It would be on par with trying to make a 64-bit version of KSP for Windows, by adding a mod.

What I'd like to see is some form of science points that can't be gotten easier by legged landers than by rovers. At the moment everything I could think of doing with a rover is cheaper and easier to do with multiple small landers that just stay where you put them. There should be some sort of science part that accumulates science points slowly as you drive the rover - like "this Mun crater has 80 'driving science' points available, at a rate of 4 per kilometer. You've driven 10 km in this crater, so you've mined 40 of those points so far on this vessel." (That's the general idea - of course the exact rate of points and number of points would need to be adjusted for proper game balance, but a system along those lines would be great).

Unfortunately unfolding parts are on the do not suggest list, sort of. (By which I mean that robotics/mechanics, such a broad term as to be meaningless, is usually interpreted in a way that includes any time someone asks for the ability for parts that hinge in any way.)

I've been playing KSP so long that when I saw "Eve Online" the first thing that came to mind was a team of people using KMP to cooperatively build a station around a big purple planet.

Boot is slightly different from reloading. A SCS unit that loses power and then regains power (i.e. solar panels go into shadow a long time and then come back into the sun later) does actually reboot, but an SCS unit was "on rails" and then becomes loaded into the physics engine again does not go through the "boot". Instead the mod attempts to put the unit right back where it was, in the same state - a bit like a computer going into sleep mode and then being re-awakened and it continues running programs where it left off. Back in version 0.9x that feature was still rather broken and untested (partly because the variable save/load bug made it moot anyway) but I saw that the attempt to do that was in the code. I don't know if 0.10 and up have messed with it much or not. I haven't tested it yet. But the point I wanted to bring up is that if a 'run on bootup' feature was implemented it would probably not quite cover both those two cases you mention, for that reason.

1. There is nothing bad about the 'new' keyword. 2. That syntax is so unlike kOS that it would really require quite a change to the parser in ways a lot more drastic than just adding the 'new' keyword. I doubt it will look anything like that shorthand statement.

Blaming the rounding for the problem is gettting it backward, I think. Imagine this: You are rolled 80 degrees from the horizon according to the navball (so pulling "up" with the "S" key turns you is nearly east, and your the "W" "down" key turns you nearly west.) When you "print facing:roll" you get a value of 0.0001. When you "print facing" you get a value of R(102.812,50.012,0). We don't care about the printing display being 0.0001 off from the value of the variable. We care about the value of the variable being 79.9999 off from what we'd expect in the first place, before the rounding happens. If you do try to address this, please take care to make sure you test it using a craft that is NOT in an equatorial orbit. Make sure it's in a highly inclined orbit and you test the result at different latitudes throughout the orbit. This is because the equator is the XZ plane of the coordinate grid, such that errors involving flipping of axes, or using the wrong axis can easily go unnoticed near the equator where the errors from those sorts of mistakes often don't manifest. I've made lots of errors about this in some of my earlier code because of that.

I don't think it's a difficult thing to separate at all: Is it accomplished entirely by making calls into KSP's current API? Then it's a thing a mod can do without KSP itself changing. Did it require doing something besides just making calls into KSP's current API? Then it's a thing a mod can't do without KSP itself changing. (Note changing something about the API itself counts as KSP changing, which is why I was careful to use the word "current" the way I did.)

True. Even on unmanned flights where there is no crew and the computer program runs the craft, it's usually configured to do something like "when your onboard clock says ....... then perform this maneuver", and the calculation for when that "...." is supposed to be was made by computers here on the ground and beamed to the craft. I'm considering building a building-shaped "vessel" out of metal plates and girders for walls and "launching" it a short distance over to the KSP buildings and landing it there and leaving it there for all time. The building would have some SCS parts in it. The idea is that it would represent the home "mainframe" computer on the ground at mission control - so that the archive back home actually has a CPU that can execute things at home and send the results to the vessels. ("sending" values to the vessels via outputting self-modifying code "log" files that consist of nothing more than 'set' commands, that the vessels can copy and run.)