Dunbaratu

I'm considering making my own subprogram to do what lock steering does, not for the same reasons you have, where you basically see it as a sort of cheating, but because it's going to be easier to control things the way I want them controlled that way. I do most of my steering by vector math and one disadvantage that has is that when you transform a vector into a Euler rotation (which happens behind the scenes in the steering algorithm for 'lock steering'), you lack roll information. From an information theory point of view, both a Euler rotation and a Vector contain the same *amount* of information. The tradeoff is that Vectors have length information but lack roll information, while Euler rotations have roll information but lack length information. So when you 'lock steering' to a vector, you can't control which way the ship is rolled. This is usually okay for rockets which have axial symmetry so you don't care which way it's rolled, but its a big problem for airplanes.

Then that's even MORE reason to implement what I suggested. There is currently no reason for space stations, satellites, or ground rovers because you get the same science points for an instant point of time measurement as you do for a measurement while moving over a long distance. Science points that you get while moving that you cannot obtain from a simple point in time measure gives you reason to build all those things. Right now, a rocket that goes up to 100,000 meters and then falls back down is worth just as much for science as one that goes to 100,000 and stays in orbit there.

That's an awesome demonstration of the capabilities. I like it. It makes me want to design a Voltron that assembles itself....

I'll try that next time. It did seem annoying the first time that the little guy can't transition from "W means climb up" to "W means walk forward" without triggering the "I am a tumbling ragdoll and therefore controls are locked out" mode in between. That "I am a tumbling ragdoll and controls are locked out" mode is really annoying, as it triggers for things that are clearly not collisions or crashes, but then the locked out controls themselves cause the kerbal to crash.

What happened here, in my opinion, is that SQUAD solved a problem the wrong way around. The problem is that a single reading from an instrument doesn't mean much. You want to take seismometer readings from several nearby locations and compare them. You want a thermometer to tell you the temperature gradient as you descend. You want to know how the gravity is changing as you orbit, to detect the pattern of non-uniform planet material density. The solution to this was to make you transmit many times, when what it should have been was to make the science data require travel to be worth full points. i.e. if you turn on the gravioli detector, time warp through several polar orbits, and then send your data, you get full value, but if you just send a single datapoint you don't. In other words, the proper moment to need to move ahead through a span of time is not when waiting for batteries to recharge for a second sending, but when taking the experimental data in the first place.

This came about because I had my own body database in script form before and I'm trying to change my code to use the one in KOS instead. Either kOS should provide BODY information, or it shouldn't. All one or the other. What it should *not* do, is provide half the body information, which is what causes the need for two different parallel places to lookup body information, one provided by kOS and one I made up myself. I'd favor supporting both play styles. Put the data there. Use it if you like, or ignore it if you like. That's identical to what already happens when playing the game manually under human control. You don't have to go pull up the info tab in the map view if you don't want to, but it's there for players that do want to. The problem is that you're asking for everyone to have to play it your way. There is nothing about having the data there that stops you from playing it your way by just not using it. There IS something about insisting that it be removed that DOES prevent others from playing it their way. I also don't agree with the idea that kOS should never incorporate any information from the later days of the space program, because Sandbox mode exists. How would you feel about this idea: In Sandbox mode, the body database has everything fully populated up front, because, hey, it's sandbox mode where the presumption is your space program has hit the top of the tech tree and knows everything already. But in Career mode, the body database masks off some of the data, but detects when it's been measured by you in game and flags something inside kOS to remember that you've already gotten the measurement for it already, and then allows it to become unlocked after that (*). Thus the code would work properly and cleanly, and represent that your space agency has updated the data in the database like they *would*, rather than stubbornly insisting that the database must be frozen and never be added to and any new information needs to be put in a new, second database, which makes for ridiculous code. If this was done, it would be ridiculous, and incorrect, to assume the space agency knows nothing about the mass of a body or its radius and its orbital parameters and position data before sending a probe. Those are learned BY watching the planet from afar - it's mass being deduced from the effect its gravity has on the motion of other things, it's radius being deduced from the angle in the field of vision it takes up at a known distance, and so on. Even the atmosphere IS known to some extent beforehand - just not precisely. (It's not like they were expecting Venus to be barren without air.) So to simulate this you have the data produced by the body atmosphere database be present but imprecise and "wiggly" until after the probe was sent. The above may be too much work to implement, but if it is, then erring on the side of giving too much information is less ridiculous than erring on the side of hiding known information that the space agency already has. (*) If this was done, perhaps the way to detect that the information is already learned is to just hook into the science experiment logs. The game already tracks whether or not you've done a particular experiment before and gotten information back about it, so you look for things like "obtained barometric pressure reading from Eve's surface" in the science logbook to decide whether or not that data is available in BODY:ATM or not. That would satisfy your complaint without adding the annoying insistence that the BODY database must be implemented entirely out in the script language with each user having their own different set of function calls for doing it. See, I like sharing code, and I'd much rather be able to say "here's a neat program I want to show off, and it will run in sandbox mode, or in career mode if you have previously visited Eve and taken a pressure reading from its surface" than have to say "along with this program you must also get my own body database because there is no standard for how to do that so you need my body database too and even if you made your own it probably doesn't have the same interface as mine does so it won't work with my code." Here is what I am 100% convinced would happen if you removed the BODY database from kOS: the user community would replace this lack by sharing their own community-made body database instead of each user making their own, putting things right back where they were before. Why am I convinced this would happen? Because I'd do it. I was on the verge of doing it before when Kevin went AWOL and I waited to see if kOS had a future before deciding to do it, and then erendrake's version clearly was heading toward having a fully populated BODY database so I stopped.

My take is this: When the human player was already given the data by SQUAD then trying to hide that data from kOS just means the human player writes less portable code. The script code will be better designed if that data that a human has learned is available in a cleaner way instead of being ad-hoc cobbled together differently by each player. And even if it's something that wasn't already given by SQUAD like atmosphere is, think of what the code would look like *after* the player learns a thing about a body and uses it on their subsequent missions. If you're disallowing that information from being in BODY then you're having code that looks in two different places for BODY information. kOS script isn't sophisticated enough to let a player subclass the body database and add more to it themselves, so they'd be maintaining a separate independent body database in parallel to the one in the game. Your false dichotomy assumes two viewpoints with people being on a line between them - on the one end people wanting kOS to be easy with broad appeal, and on the other end people wanting kOS to have even less information than the game gives a human being. My viewpoint is primarily about wanting not to have to write sucky code. And that means avoiding having two different parallel body databases - one that kOS built-in and a second one that I make on the side.

That doesn't work. When a Kerbal climbs a ladder up to a platform. the game does not let you climb up onto it and stand on it. It stays stuck on the ladder until you let go of it and fall down the ladder. You can't go up over the top of the ladder onto the platform.

What seems silly is that you had no complaint when the rest of the atmospheric numbers got added. The scale of the falloff rate of the pressure was already there in previous updates and you didn't complain about them. Knowing the scale for the change in pressure as you go up in altitude might as well not have been there if you want to have the pressure itself be unknown. I asked for sea level pressure to be added because the data that was already there had no meaning when it was missing. And wouldn't have been available if pressure wasn't already known. "Here's the rate of change of the thing we've never gotten any numbers for." Furthermore the information you are talking about is already there in game for the human player. On the map screen. Even without kOS. All this does is let you write code thats not hardcoded and instead lets you use the current body as a lookup key to get to the atmosphere data that you clearly already have in the game as a human. If you don't like knowing anything about the atmosphere pressure, asking kOS to pretend the player wasn't already given it by SQUAD is a bit late to be trying to change it.

That is the advantage of using a real parser. Nice work.

Realistically I'd imagine that the power consumption for a storage device would actually be inversely proportional to its storage capacity simply because the smaller drives are older drives that aren't as streamlined. You can get a lot of storage on a modern smartphone and yet keep running it on battery alone for quite a few hours (and most of that battery is being drained by the display and CPU not memory). To store a tiny fraction as much permanent storage used to require a disk drive the size of a washing machine. Camcha, you are operating on the false assumption that the probe is operating without anyone back at home having done any analysis beforehand. If you didn't know the stats of the body beforehand you couldn't even send the mission in the first place. NASA already knew, for example, the mass of Mars, its radius, and the atmospheric density at the ground, prior to sending the Curiosity probe there. If it didn't have that information, then the complex landing procedure of the probe would never have been possible to engineer. A lot of the data provided by the body structure is data that was known before the space race even began. When the Soviets sent probes to Venus, they already knew perfectly well what sorts of high air pressures they were going to have to design the probes for. There's a lot that's learned from afar with telescopes and math and spectroscopy. The stuff in the BODY structure is stuff a space agency has to know before it even begins work on designing the vessel for the mission. If you didn't know the body's radius and mass and atmosphere, you'd have no clue whether or not parachutes would work, how well they'd work, whether you should use them at all, and you'd have no idea how strong the effect of gravity would be so you don't know how powerful the engines have to be, how much fuel consumption to expect, and so on and so forth.

Idea: Mission Control's Mainframe CPU back home. There is a a storage volume back home at KSC called "archive", by why do the only CPUs that can run code off that volume exist out on remote vessels? Wouldn't they know how to build a bulky mainframe computer and house it in a room in a building on the ground long before they learn how to put a computer on a spaceship? What I'm thinking of is this: Add one additional kOS SCS CPU that lives not inside a vessel part, but just lives "in limbo". (Or, it does live in a "part" but that "part" isn't hooked into the rest of the structure for a vessel part. It's just a "part" object that lives inside the kOS Mod's own head and isn't connected to anything.) It's not part of the KSP physics engine. It doesn't get unloaded when a vessel goes out of scope because it's not on a vessel at all. It represents the mainframe back home at KSC. It can run code. It's default Volume is 0, the archive, and it doesn't have a local volume. It just runs natively off the archive. Because it's not on a part it doesn't unload and can continue running no matter where the game is focused. kOS just makes sure that the list of currently active CPUs it needs to execute instructions for when KSP runs its update hook for kOS includes this phantom mainframe CPU as well as the CPUs attached to loaded parts. What the mainframe CPU could do: Presumably the mainframe can obtain data about any named vessel in comms range (where the meaning of "in comms range" would vary depending on whether or not remote tech is being used, just like it does currently for seeing if a remote volume is reachable). Perhaps for realism, attempts to obtain telemetry about a vessel would generate a lightspeed delay in the execution of that command. Then the home mainframe could perform calculations without the limitations of lightspeed delay or small hard drives. For example: // Running on the mainframe: set ves to vessel("some name"). set vesOrb to ves:orbit. // This command takes lightspeed-delayed minutes to finish. run calcTransfer( "Duna", vesOrb ). // mainframe makes complex calculations instead of the vessel doing it. log burnStartTime to sendFile. log burnAim to sendFile. log burnDuration to sendFile. // Now the vessel can "copy sendfile from archive" to get the result. The mainframe could also be responsible for storing its own database of really complex slingshot planetary transport network calculations that it can use to tell the vessel what to do. Or it could run the over-arching "mission script" like I did in the Duna Challenge Mission 2 entry. That always felt a bit "wrong" because in my head I was imagining that that global script was running at home, telling the craft how to initiate each of its smaller script steps, but I knew that's not really what was happening in the mod because the computer was on the vessel and just accessing the mission script from the archive, rather than the mission script *actually* running back home on the archive. It could also be responsible for getting the vessel set up on the launchpad. Imagine an init script stored on the mainframe that you run from the mainframe to copy the code and initial settings onto the vessel's computer before launch. What to do with the mission control mainframe computer is really up to the player of course. I'm just thinking of ways it could be useful. What it could not do: Anything involving current vessel velocity or position or orientation. The current SHIP, is essentially, null for the purposes of running mainframe code. This may be the trickiest change as it would mean having to trap that condition and make sure it doesn't bog up the mod when there is no current ship, and instead gives a pleasant error message about it.

I like this but the forking of kOS has me worried. At the moment I have to choose between whether I want the better underlying infrastructure that this mod would give, or if I want the extra features that erendrake's version has added after the point of code forking.

There seems to be a bug with contract-generated missions when you only get halfway through the first attempt and then fail and crash. If you try again after using the Mission Control's own revert button (not the stock KSP revert button), the mission does not reset its flags properly and even if your second attempt is correct you don't get credit for it. If the mission had two goals, say an orbitgoal and then a landinggoal, and you succeeded at the orbitgoal but failed the landinggoal, then after a revert the one goal you succeeded at the first time, the orbitgoal, is no longer obtainable using your second launch. It becomes impossible for the second craft to hit all the goals and get the credit.

Does anyone know a good resource for solving this messy math problem? Givens: 1. All the shape parameters of your current orbit, which in turn tells you how fast you'd be going at periapsis were it not for the atmosphere. 2. The mass and radius of the body, and all its atmospheric qualities. 3. A desired amount of speed I'd like to lose at periapsis. Find: "What altitude should I dip my periapsis to so that when I dip into the atmosphere I will lose the desired amount of speed, no more, no less." I already know how to calculate the amount of force caused by drag, given the altitude (which determines air density), the craft's drag numbers (usually 0.2), and the current speed. The really hairy part is that all of those things are constantly changing during the aerobraking maneuver and they depend on each other. The drag force is constantly changing as you change altitude, and as you slow down the drag force lessens. Because of the slowing down even the shape itself of the path through the air is not simply straddling the periapsis symmetrically, as you will spend more time in air after periapsis than before it because the slowing down altered your path during the aerobraking. The math has a messy amount of self-affecting feedback loops in it. Presumably I could work out the integral of the deceleration the air causes throughout the breaking maneuver, to get the total change in velocity, but the velocity itself changes the amount of deceleration the air provides, and it's that feedback into the equation that I can't quite figure out how to work out. My math coursework in college went through calculus and just into the very beginnings of differential equations before I stopped (because I decided to pursue compsci instead of physics). I get the strong impression that this messy situation is exactly the sort of thing that differential equations would do. I don't need the math to be calculated on the fly by the vessel's kOS code. Precalcuating something in a lookup table and having the code interpolate from the lookup table is fine. I just need to be careful to always brake enough to be captured, but not so much as to kill the orbit and fall in, and then I can adjust from there to the specific orbit I want after the first pass through the atmosphere.

Could a model halfway between "only occlude the parts directly attached" and "occlude everything in a straight line behind the part" be achieved by having parts occlude a "wedge" behind them that tapers to a point? In other words an object might occlude another object 1 meter behind it, but not, say, 3 meters behind it. Basically this simplified model would make it so that the air "comes back together" a short distance behind the leading object and starts causing drag again. Only a small wedge would be in the lee of the object.

While it's not realistic to magic up a different gravity for testing, it's also true that it's not realistic for the space program to have zero numerical information about things like how the suspension of the wheels of a rover works. Actual space engineers building a rover would be able to calculate "this is how many centimeters the craft will depress the suspension by, given its mass, the gravity of the target body, and the way the suspension was made." But people playing KSP have those numbers hidden from them. Some mods do help a bit, but they don't tell you everything (like the suspension isn't given to you in units where you can calculate the deflection. This makes it impossible to work out where to place that rover's docking port so it will line up correctly - a very common problem KSP players have.

Yes this is annoying. Another possibly related problem is when two or more vessels are close to each other, you are unable to pick which ship you meant to target on the map view. It keeps redirecting your click to the wrong one of them. This might be related because both that complaint and this complaint in this thread seem to be a case of being a bit weird about how it handles "near" clicks. It seems that a mouse click has a certain radius around it and if a thing is in that radius then the click is near enough to be counted as clicked on that thing. The problem is when there's more than one thing within that radius, it doesn't seem to select the one that's closest to the click. It just selects the first thing it finds it its data structure that fits the nearness criteria even when there's aother thing that would be even nearer. Thus when two objects are both within the click-radius of each other, it's nigh impossible to get the game to realize you meant the "second" one it finds. At least that's my guess about what's happening because that's what it looks like from the user's point of view. If that's what's happening then the fix would be to find ALL hits within the click zone and select the one of them with the least distance from the click, rather than just stopping on whichever hit is discovered first.

The stock game really should agree with itself about what the word "day" actually means in the game. It shouldn't require a mod to get the term to mean the same thing everywhere. That's just basic functionality. Either a Kerbin day should be lengthened to an Earth day, OR the game clock should be telling you Kerbin days not Earth days. It's just a matter of consistency - the game should agree with *itself*. I think it would be far less confusing to have to think in Kerbin 6 hour days than to have to switch modes between thinking in earth days and thinking in kerbin days. As non-intuitve as it may be to think of a "day" as 6 hours, it's even more non-intuitive to think that the word "day" means two different things in the same game. There's plenty of precedent for players being used to the idea that a game day is shorter than an Earth day in a video game. It's a very common practice. Heck, a Minecraft day is only 20 minutes and people deal with understanding that just fine.

LOCK has two important differences from SET: 1. The fact that it overrides user control. 2. The other effect is that the value can be a re-executable expression that is re-run each time the value is checked, rather than a flat value. So if you want effect #1 without also having effect #2 there wasn't really a way to do that in the language. What happened with this SET is that it gives you effect #1 without effect #2, but then didn't have a corresponding UNLOCK to release it because it wasn't a LOCK in the first place. (And I did try it with LOCK first. It actually returns an error when you try to use it with LOCK. It only works with SET.)

The problem is that the new manuevers used SET rather than LOCK, but despite being called "set" it still locks the controls, and there's no way to unlock them. I haven't tried the new 'neutralize' that erendrake just made to see if that fixes it.

I was just playing around with typing commands on the terminal and I was trying to use Fore, Starboard, and Top to translate, and the behavior of this seems really weird and off: sas off. rcs off. set f to facing. lock steering to f. rcs on. // getting ready for translation. // At this point it seems right. It rigidly stays in the current orientation like I'd expect, using kOS instead of SAS to do it, and it's not using RCS fuel because it's settled down into the fixed orientation. set ship:control:fore to 1.0. // attempting to translate forward. // Instead of moving in a straight line, it activates the RCS thrust blocks asymmetrically and tries to rotate me. The problem seems to be triggered by trying to use LOCK STEERING. If I try it by unlocking the steering and instead using SAS to lock my orientation, then it behaves as you'd expect. Something about using LOCK STEERING and using FORE for translation at the same time makes kOS try to rotate the craft even when the current orientation is already the one that the steering is locked to. (EDIT: Additionally, another problem seems to be the inability to unlock the translation controls and give them back to my manual control. You know how if you don't UNLOCK STEERING, you can't steer manually? Well after I played with "ship:control:fore" and then set it back to zero again, from then on there was no way to make the H and N keys work again to move the RCS translation manually. They were locked out. Even toggling power on the SCS module didn't give me control back.)

I tried looking at how I'd make a docking program using the new release and the first thing I came up with as a potential snag is this: Is there support yet for selecting a certain part on the other vessel as your target, rather than targeting just its center of mass? I refer of course to the way you can, when manually playing KSP, rightclick a docking port of the other vessel and pick that docking port as your target rather than the center of the vessel as your target. Without that I can still make a docking script provided I'm docking to a port that is lined up with the vessel's center of mass, and I stipulate that the docking script must make sure it gets lined up more than N meters away from the target, where N is the distance from the center of the ship to its docking port. Otherwise the deflection in angle between the center of the target vessel and its docking port becomes too large once you get close to it. If you try to line up by sliding sideways while too close to it, that difference in angle will mess the script up. But if you get lined up while still far away from it so the center of the vessel and it's docking port are in line with each other, then that difference won't be relevant.

Adjust load distance? The KSP API lets you do that?? On a per-ship basis???? (i.e. some ships staying loaded farther away than other ships?) Then why haven't more mods made use of it? I'd love to hear more about how that works and how you use it. If it does what it sounds like it does I might want to go back to trying my orbital missile platform again.

This definitely needs fixing. It's misleading to the script programmer, as it is essentially "lying" about what the datatype of "Velocity" really is. Either have it print both the vectors that are inside it, like so: Orbit: V(...,...,...) Surface: V(...,...,...)" Or have it just print a crpytic "Velocity Object". But making it look like it's a vector when it's not is going to confuse. And actually, that brings to mind an interesting question: Should there be a generic toString() for all structure objects like Velocity, that always does something like what I suggested above? Just make it so that all structure objects always will, when converted to a string, dump their component parts recursively. For any such structure object, have it do this as it's toString: For each component inside me, do: append the name of the component, then a " : ", then append that component's toString. Thus a Velocity prints as: "ORBIT: V(..., ..., ...) SURFACE: V(...,...,...)" while a SENSORS prints as: "ACC: V(..., ..., ...) PRES 99.9999 TEMP 99.999 GRAV V(..., ..., ...)" And so on. It's not pretty and you probably wouldn't want to use these strings for much of anything to display to the user, but the point it it's VERY instructive to the script writer what's really going on, and besides these are cases where you probably shouldn't be writing script code that prints these things direct to the user anyway. (So there's no harm in making the toString more instructive for debugging and learning purposes.)