Dunbaratu

I saw that 0.9 was released and I was all excited to try it out, but the file on spaceport is broken. It's only 44 bytes long so I'm pretty sure that's not going to work.

I'd rather see it work this way for 'hardcore' play: The decision to revert a flight has to be made before you BEGIN the flight. In other words yes you can use "Revert flight" as a test simulation, but only having chosen ahead of time to make this flight not count. You start off by picking "launchpad" and it asks "is this a real flight or simulation?" If you pick real flight then you have to leave the ship in the persistence file even if it crashes - you can't revert flight. If you pick simulation flight, then its the opposite - you CAN pick "revert flight", but then CANNOT keep the ship there and can't get any permanent changes from it (no science points). So you can't start off something as "simulation" and then change your mind and call it real later the one time in five that it happened to work. That being said, before this can even be considered, EVERY one of the "can't select tracking center from menu" bugs needs to be fixed, or else it's unfairly going to punish players for game bugs. At the moment there's cases where reverting a flight is the only means by which you can get unstuck from the flight because it won't let you go back to "space center" due to some limitation that's utterly untrue. (for example, saying you're flying across terrain when.. you're not. Or having a part fall through the ground polygons and be falling INSIDE the Mun, and not letting you switch focus away from it or go back to space center until it stops moving - which it won't because it's going to fall "inside" the Mun forever yo-yo-ing.) As long as there continue to exist bugs that prevent the "space center" option from being pickable when it should be, it's not fair to remove the "revert flight" option as that's sometimes the only way to get unstuck from the bug.

But at the moment you can't even query the terrain under you except at that single datapoint of RIGHT under you. You can't see what the height is even just a few meters to the north, south, east, or west of directly below you. Presumably if you have a radar altimeter it should be possible to use it to get data about a small arc under you rather than just a straight line under you. Mapsat covers a swath of terrain when it passes over it, not just a single line of terrain. So what you said applies to one half of the uses I was talking about (seeing height of a projected landing spot far away), but not for the other half (ability to read the slope of the ground under you by being able to see the ground through more than just a single data point). Even without mapsat you should at least be able to see the ground heights within a small arc under you.

If you have a spare action group you're not using on the craft you can use that as the end trigger condition instead. The syntax looks like this: assume you are using action group "7" in this example: WAIT UNTIL AG7. That line will make the program pause until you hit ALT-7. (One odd thing about using action groups this way, is that you can't hit the key while the terminal window is focused. You have to click outside the terminal window first (making it turn a "faint" color) before hitting ALT-7 or else it won't pass through to the stock KSP keyboard handler.)

Is that the entire end of the program? (As in, the program finishes after executing "stage." and you're back at the interactive prompt). If so, then that might be the problem. When a program exits and you're kicked back to the prompt, I've seen it sometimes return the throttle back to the state it was in before the program started (i.e. off.). To test if this is the problem, add a simple "wait 1." at the end. If this was the problem, then you'll see the engine throttle up for 1 second then shut off again. (because the throttle lock was only staying on during the duration of the program, and without the wait there it was ending the program before the throttle had a chance to react.)

1. Antennae have no effect on targeting vessels. They only affect your range to home base for the sake of getting to your archive files. 2. At the moment the ability to target planets isn't implemented. 3. I don't know about targeting docking ports. It would be a good idea, but I think it's a ways off because we still don't even have access to the ability to control translation via RCS, which is sort of a prerequisite for docking maneuvers.

Actually, I'd find the ability to query the terrain height somewhere other than where you currently are, via a LATLONG, to be extremely handy for other reasons. It would let you work out slope of terrain by comparing several sample datapoints around you. It would let you work out the altitude of your projected landing site (rather than just underneath where you are now when you're not there yet).

I have a script running in 0.85 on KSP 0.22 that most definitely gives a different result for alt:radar than for altitude. Can you show us the code?

I assume this was meant to originally be formatted like so, but you had to join the lines to avoid the other bug? when eta:apoapsis < (DV/(2*acc) + 30) then { set warp to 1. when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.} } Is there a reason it doesn't work to have those as two separate conditions at the same level without nesting? when eta:apoapsis < (DV/(2*acc) + 30) then { set warp to 1. } when eta:apoapsis < (DV/(2*acc) + 15) then { set warp to 0. } It should work provided that you know the first condition will always happen prior to the second condition.

Presumably in an asparagus staging that's exactly the moment when you want to detach the dead weight, so it's only going to be incorrect for the few brief moments before you activate the next stage. Well, in the meantime until such a feature exists, here's an idea that might help: The real problem that you need a way to detect when an engine has become starved of fuel so you know when to activate the stage. If you knew that then you wouldn't need to deal with calculating the max thrust with starved engines because you'd be getting rid of the starved engines as soon as they got starved. Here's an idea that might work - detect and record the rate of mass change as you burn. In a loop, keep track of the difference in mass between consecutive iterations, and the delta of missiontime it took to perform the iterations.. As long as the only reason you're losing mass is that you're burning fuel (you haven't activated any stages to drop off parts), and as long as the same number of engines are burning fuel, then the throttle setting divided by the mass loss rate should remain constant or close to constant (i.e. the mass loss at throttle 1.0 will be twice what it was at throttle 0.5, so the expression (throttle/massloss) should remain constant regardless of the throttle setting as long as the throttle is nonzero.) So it might be possible to use that to detect when an engine has stopped burning fuel. The rate of mass loss should be expected to fluctuates a little bit (due to slight variances in how long it takes to execute KOSscript commands. The time between when you measured missiontime and when you measured mass in the next command will never be exactly the same). But even though it's normal for it to fluctuate a little bit it wouldn't be normal for it to suddenly drop a LOT in one instant. That's the trigger you look for. If the rate of mass loss suddenly changes by more than a fuzzy small tolerance, then assume this is because fewer engines are burning than previously were, so it's time to decouple a stage. That doesn't help your other issues with jet engines, but it might help make asparagus staging work for vanilla rocket engines.

There's a really annoying bug in KSP that causes vessels to receive bogus rotational forces from nowhere if there's even the slightest amount of overlap between parts. I consider this a bug due to the fact that the "overlap" is often the result of KSP itself rather than an intentional part of the design. If you try making a strut reinforcement along the outer edge of two parts, the strut becomes a "clipped" object inside the part rather than running along the outer edge. If you attach a fuel cylinder radially to the outside of another it's often slightly clipped into the first part and you can't do anything to change this. On the one hand, using time warp to stop rotation is a cheat, but on the other hand when the game applies phantom bogus forces to the vessel that aren't really there and can't be stopped, the game is sort of cheating against you in the first place. It's not cheating if the game cheated first and your "cheat" is just a case of trying to find a workaround to get around the game's cheating. I feel the same way about using the debug console to escape from stuck situations in Bethesda games which are notorious for having bugs that prevent finishing the game.

I assume there's a reason that (maxthrust * current throttle setting) doesn't give you your current thrust? I've been using this pretty reliably but never in a context with asparagus staging. Is there something about asparagus staging that breaks using that as a calculation? I've been working out the math for how to get the location of the Pe, Ap, and intercept with planet surface, and it is doable right now, but only by being *extremely* roundabout with how you arrive at the calculations. It would help to have that information more "natively". 1. It is possible to transform any of the script language's Euler rotation directions (like "up", for example) into a unit vector in XYZ terms instead. It requires running some matrix math that would make a lot more sense to do natively in C# instead of as lines of KOSscript but it is doable. 2. It is possible to work out your current normal vector (and therefore your angle of inclination from the body's equator) from your velocity vector cross product'ed with the unit vector version of your current Up direction. 3. It is possible to work out your current true anomaly angle (the angle between the periopsis of your elliptical orbit and your current location in the orbit) from comparing your current radius (altitude plus body radius) to the major axis of the ellipse (Ap height plus Pe Heght, plus diameter of body). 4. Because you know your current Up vector, and your current altitude and can look up the radius of the SOI body, you do essentially have your current position, but expressed in polar coordinates instead of in Cartesian coordinates. 5. Putting it all together should fix the exact picture of your current orbital ellipse, including where Ap and Pe are, where your impact with the Planet is, and so on. I have page after page of scribbled equation notes doing all that, BUT, it really feels like this is unnecessary work because I'm pretty sure the underlying API must have more information about your current predicted orbital ellipse than KOSscript is currently exposing to the user. As part of my attempt to make the landing script better, I'm trying to work out all that math with one goal in mind: Find the LATLONG of my current predicted impact point on the planet. If I have that, then I can use it as the beginnings of making an "aimed" landing.

Do you have any thoughts on how KOS will be integrated into the tech tree for career mode? (Right now you have to be playing a sandbox game to have access to the SCS module.)

A warning about the new comm antenna from the KSP 0.22 update. I just discovered the hard way that the new 0.22 antenna, called the Comms DTS-M1, is not yet implemented in KOS's code. If you add them to your vessel expecting to be able to reach the archive with them, it won't work. I assume this will be addressed eventually, but for now it's a good idea to avoid them.

0.85 broke multi-line parenthesized expressions. Now you can't open a parenthesis on one line and then close it on a later line. The closer has to be on the same line as the opener now. For example: set x to ( ( 100 - 50 ) / ( 30 - 10 ) * 1.01 ). That gives a syntax error now. It didn't before. If I join it all together onto one line like this: set x to ( ( 100 - 50 ) / ( 30 - 10 ) * 1.01 ). Then it works. But it makes it a lot harder now to make long complex math expressions that look readable. Now they have to be strung together all on one line.

Perhaps the some kind of advanced science part that can perform the full experiment without a return would have a large electricity drain and have a lot of mass. That would give people an incentive to make space stations and remote bases, as they'd be the only way to perform such experiments without a return.

How about, along similar lines, if it runs when you toggle power off and on on the unit?

I'd much prefer it if it only works the lastmost time you did it (in other words if you haven't transmitted you can wipe it and try again.) This is because performing an experiment is the only way to detect if you are in a unique new biome worth new points. It would suck to think you are in a new biome, perform the experiment, and find out the game considers it the same as a previous biome and you've wasted your one shot.

Re-read what I posted. If the manuever you're looking for is an inclination change it should be able to calculate that correctly rather than relying on you having to guess it in an analog way without being able to see the numbers. How far do you pull retrograde to get exactly 5 degrees off, for example? It's unknown because you can't see the numbers.

False. The maneuver nodes do not adjust for you if you miss the right moment in time to burn. And while it's possible to get the effect as if it was an instantaneous burn with a prograde or retrograde burn by starting your burn time prior to the time mark so the time mark is in the middle of your burn duration rather than the start of it, this same sort of thing is NOT done properly for normal and antinormal burns because the direction you are given is the direction at the start of burn rather than the direction halfway through the burn. For normal and antinormal direction, if the game wants to let you do it by a single straight-direction burn, it should be giving you the direction that's halfway between the start and finish directions rather than the direction at the start of the burn. If you set up a node that will change inclination by 20 degrees, then the direction of burn should start off being 10 degrees off from normal in the retrograde direction. That makes the 20 degrees of normal change straddle the 90 degree mark in the middle (from 100 degrees at the start of burn to 80 degrees at the end of it) rather than putting the 90 degree mark at the start (from 90 degrees to 70 degrees during the burn). This suggestion would mean that your orbit gets smaller at first, then halfway through starts getting bigger again until it ends roughly the same size as it started. The way it works right now, normal and antinormal manuever nodes always have the side effect of making your orbit bigger because while they start off being perpendicular to your plane, they don't stay that way as the prograde direction tilts toward the aiming vector.

Okay then I withdraw my comment about prograde burns. I do not, however, withdraw my comment about normal and antinormal burns. They are definitely wrong they way they work now. The way they work now it's impossible to change your inclination with them without also changing your apoapsis because they are only in the correct direction at the start of the burn, not after that. It is also impossible to perform an inclination change of >= 90 degrees with them because they don't rotate with the plane.

Maneuver nodes should rotate the blue marker over time to reflect the new direction. For example, a prograde maneuver should turn to stay prograde during the burn as you curve through the orbit. A normal or antinormal maneuver marker should rotate as the plane rotates. As it stands, I never use maneuver nodes anymore to do anything other than predict the right time to do a transfer burn by seeing ahead of time what it would do. I get better results flying manually because I can rotate during the burn.

hHuh? But to close it you have to transmit the data instead of doing a recovery on it. Closimg the pod precludes doing recovery. The reason I'm landing with the pod open is because that's the only way to get the game not to wipe the data prior to landing. How about a "data store" part that represents clunky 1960's computer technology to store electronic data gathered? With it you can re-use an instrument and keep multiple readings. Without it you only get the one. I imagine that this makes more sense to do with the planned but unimplemented money aspect of the game that will come eventually, rather than with science points. Make death expensive, or make it cause the people holding the purse strings to get more stingy with your budget, or make it start costing more money to recruit kerbalnauts the more of them you leave stranded. (Or better yet, the more kerbals that have died the stupider the new recruits get (the ones with low stupidity values don't volunteer anymore).)

I agree with the fact that the current transmission system renders recovery irrelevant, since you can just asymptotically approach the same science value by spamming the transmitter until you decide the last few science points aren't worth it. BUT, I'd rather see as a fix to this the requirement that certain types of experiment utterly require return and recovery to matter. If you're just sending data read from instruments then returning does not render a better value than electronic data does. It's the same. But if you're doing a sample return, or a materials study or a goo report, then these should require getting the physical material back for extended study back at home (i.e. make them worth nothing in transmission). That gives you a good reason to do multiple different types of mission to mine all the types of science.

Software version numbers just arbitrarily mean whatever the developers want them to mean. There's no such thing as the international standards body to decide how major a change has to be for it to affect the major version number instead of the minor version number, for example. It's whatever the software company decided to use as its own personal heuristic. Whether a thing is a minor bug fix or a major new feature really is too subjective to pretend there is any such thing as a standard rule for what a version number increment means. But one thing it FOR SURE does not mean is it is not a percentage of progress toward a goal. 0.22 does not mean 22 % done. It just means "there's been 22 versions so far that we considered major enough to bump the number up.". Extrapolating how long it will take to finish as if 0.22 meant "22% done" is ridiculous.