Dunbaratu

In principle I like the idea of keeping Kerbin orbit debris free, but I'm annoyed that in practical terms it's impossible unless I never build any rockets that need to strut connections between the upper orbital stages. The problem is that if you have struts connecting two parts of a craft that decouple, although the struts do break so the decoupling works, they don't just break off from one of the two halves, they break off from BOTH, leaving a bit of strut debris. Now, if the only place you strut is on the lower stages that fall back down, then that's not a problem. But if you have to strut together upper stages that don't fall back down, for example you're doing an Apollo style mission and your lander and command module need to be separable, then all those little bits of strut debris stick around. I've got hundreds of bits of debris around and all of them are little nubs of struts. (If you have, say, 6-way symmetrical strutting and break them off, you made six separate bits of debris right there.). I don't want to set debris to zero, because I *LIKE* the idea of having to deal with minimizing debris like stages and tanks, but having to deal with the fact that struts become debris, and struts are impossible to do without because the parts wobble too much without them, feels like that's not my fault.

Yeah Alt-L is untrustworthy. I've tested it a few times by hitting Alt-L and then hitting spacebar afterward, and every time I tried it decoupled the next stage anyway, so I just don't use it anymore.

Well, yeah I'm "just used to it" but I'm "just used to it" from a lot MORE than just KSP. KSP is not the only program that works that way. The "back for up, and forward for down" standard is VERY old, and dates back to the very first areoplanes, and makes sense if you think of the control stick as rotating around a ball rather than moving in straight lines. When you push the stick forward, it's not just moving straight forward. It's a lever rotating at the fulcrum, and that rotation is rotating downward. Or to put it another way, imagine a flat board on which you've painted a silhouette of an airplane, and you glue a stick to the board sticking up normal to the plane of the board. If you hold the stick and want to use your grip on the stick to rotate the board, the way you move the stick to rotate the airplane picture on the board matches the way airplane controls work where forward is down and backward is up. This is a standard that's been in common usage a LOT longer than video games. It raises my hackles every time a video game's settings screen describes doing it the correct way as "inverted", when it's not. Back-means-up is normal, BOTH historically, AND by the geometry of what the stick represents. The NEW standard where forward means up and backward means down is an inversion. It's the first thing I fix in any game I'm playing that defaults it to the wrong way around and incorrectly calls the intuitive right way around "inverted". I would agree, however, that everything needs to be mappable so people can play it the way they like. I was just contending that the claim that IJKL are doing things differently than WASD is incorrect if you're used to the controls that have been standard for airplanes for ages.

I agreed with most of what you said but to me this one point seems like a terrible idea. You're trying to make IJKL agree with ROVER behavior even though IJKL are used during space maneuvering, not during rovering, and therefore it's far MORE important to make IJKL agree with WASD while doing space manuevers. In my brain, they do match as they are now: When I think "rotate up" I hit "A", and when I think "pan up" I hit "K". When I think "rotate down" I hit "W" and when I think "pan down" I hit "I". On the other hand, if "A" means "up" when rotating but "backward" when translating, that is really going to screw with my head, especially since I'm using both at the SAME time because I dock using staging mode (i really dislike using docking mode because I want to be able to control rotation and translation at the same time without a mode switch. In staging mode you can think "left hand is for rotating, right hand is for translation, and the two match up 1-to-1." With what you're proposing they wouldn't match anymore.).

For people who want to play more hardcore, but dislike the way that there can be problems you just can't forsee until your first attempt at launching something, why not have an option halfway between "No revert flight exists" and "you can revert all mistakes"? What I picture is this: When you fly the ship, you can explicitly choose at the start whether this is a simulation or a real flight. If it's a simulation flight, then you can do "revert flight" all you want, BUT at the cost of making it so that this flight will never get added to the campaign save because it's not "really" happening. To make flights with lasting effect, like leaving a space station in orbit, you have to fly the flight "for real" and then revert flight doesn't exist. I sort of do a thing a bit like this now by maintaining two different campaigns, one of which is my "simulator" and the other is the real one, but then that has a really annoying hassle of having to go outside the game to move craft designs from one to the other. It seems like a thing the game could support easily internally - when you want to launch a simulation, it could generate a new temporary campaign folder, move the design over into that temporary folder, and run the game in that folder, and then remove the folder after the the flight is exited. For a fun special effect it could even enable a sort of "crude" set of graphics texture rules that make it look a bit more computery (i.e. parts render as wireframes for example) to remind you that you are in simulation.

Engines are heavy. Even if most of the fuel is spent, leaving the engines in orbit and then docking up with them later means you don't have to carry your interplanetary engine with you when you launch from the surface. You can design a craft who's topmost stage (the one that will leave Kerbin's sphere of influence) is missing its engine entirely (so you don't have to lift that weight up there), and then dock it with the engine debris that's already up there and use that as its engine. Of course, this requires planning for it in advance such that your top stages are attached with docking rings instead of exploding separators, so they can be re-attached to something else.

But then that has the opposite problem. Old ideas end up crowding out new ideas. If each page of the thread topics list shows about 20 rows, then once there's been 20 good previous suggestions turned into sticky threads you'll never again see any new suggestion on the front page, and instead have to go to page 2 or 3 to get to the new stuff.

What really makes this issue a pain is the "cannot switch vessels while moving over terrain" check. You hit "[", end up on a bit of moving debris, and then cannot get off the debris - stuck on it forever until you force kill the program.

Uhm, hey I just tested a craft in which the engines being fired in the decoupling stage were sepratron SRBS. They STILL didn't fire. To get the sepratrons to fire I had to put them in their own seperate stage that fires prior to decoupling. I press spacebar, wait a second, and press it again. Others have asserted that the problem is that I was using liquid engines, but the problem is there regardless of the type of engine.

Don't forget the other problem besides air friction and the immense G forces experienced at launch. There's the fact that in ANY orbital maneuver, you can't move your current point on the predicted ellipse path - you can only reshape the rest of the ellipse, but the ellipse MUST still pass through the point you currently occupy as one of the points along its curve. I.e. if you thrust prograde, you raise the OPPOSITE side of the ellipse, not where you are right now, and the path will still come back down again to where you are right now. So basically, if the only point at which you accelerate is at the planet's surface in the launch gun, then your orbital path will come back down again to that altitude again, unless you're planning to leave the earth's sphere of influence entirely from one launch. In other words you can only use this idea to get things out into the solar system away from Earth, NOT to put objects in orbit around earth. If you try to put an object in orbit by just firing it from the surface and having it entirely be ballistic after that, then even if you manage to get it to go up really high its elliptical path will still bring it back down to the surface again unless you have the ability to thrust the craft later on after launch, to circularize the orbit.

The compression of JPEG doesn't work by reducing the number of pixels, but rather it works by storing the information for a group of pixels as a "trend" rather than storing their exact values. Imagine the smooth gradient curve at the edge of an object such that it's bright yellow at pixel 1, then pixel 2 is slightly dimmer yellow, then pixel 3 is slightly dimmer, then pixel 4 is dimmer still, etc all the way over to pixel 15 which is dark. This pattern is the sort of thing you get when an object is curving, and it happens a LOT in photographs. What JPEG does is look for cases where instead of storing individual pixel color values you can instead just store the start and end color of a gradient smooth transition, and how fast the gradient from one to the other is. This can be coded in fewer bytes than, say, showing all 15 pixel values across the 15 pixel gradient. This produces a picture that is VERY similar to the original picture, but not necessarily exactly the same. The quality factor (i.e. 80% quality) determines how close the original values have to "fit" to the value approximation gradient curve in order to be allowed to be replaced by the approximation curve equation.

As I found out from another commenter, there's a difference in this behavior for SRBs versus liquid engines, for no apparent good reason. Not knowing that, I assumed I'd get the same behavior from any engine since all the engines I tried it with failed. The reason I didn't use SRB sepratrons is that they didn't have the power to lift the capsule as an escape mechanism, as I'd found out from earlier tests before I'd attached the rest of the rocket to the capsule, so I stopped trying to use them. So it works ONLY for sepratrons and not if you use the small little 20-thrust engines on a tiny fuel tank to supply them for a few seconds. So I guess I could change my title to "make liquid engines work right when in the same staging step as a decoupling, like SRBs do."

True. But I cannot see ANY logical reason for there to be a difference in how the game works for SRBS versus liquid engines in regards to whether or not you can fire them in the same stage as a separation happens. I presumed I would get the same behavior from sepratrons so I mentioned them as a shorthand way of saying "firing an engine so a part will separate when it detaches." I had no idea it made any difference because it doesn't make any SENSE that it makes a difference.

If you decouple a stage before its fuel is gone, it continues to fire at its previous throttle setting even though it's just debris with no core.

See original post. I was doing the escape tower of the Apollo missions. And to have the thrust to pull a capsule up, sepratrons isn't enough. That was the first thing I tried. After putting 16 of them on STILL didn't pull the capsule off the ground, I gave up on them and went with the tiny liquid engines because the sepratrons didn't have the thrust.

Except that that is NOT what happens when I do it. It detaches without firing.

I'm aware of the mod. But I'll say the same thing to you that I say to anyone who replies like this to a suggestion thread. Suggestions are about the core game, not about mods. And the existence of a mod as a workaround to a problem in the main game should never be a reason to stifle suggestions about making the main game better. After all, a lot of the new improved map view screen is stuff that used to require the Haystack mod. The existence of Haystack shouldn't have meant that the main game's behavior on the map screen should have remained as it was.

Is the real impetus behind this suggestion, however, merely the fact that the time to load the next screen is so long? Would it be that much of a burden to go to space center first then to tracking station if doing so wasn't so slow?

I get the impression that the eventual planned style of gameplay is meant to be permadeath, which sort of flies in the face of having the ability to reload old saves. Saves are needed for now because it's still buggy enough that it's still unfair to enforce permadeath on you when half the time you died because of a clipping bug rather than because of your flying or engineering.

It seems to me that if it's possible to calculate the elliptical path as a time-parameterized equation for on-rails coasting, it should also be possible to calculate what the curved path should look like under a thrust as well. It seems like a calculus problem to just figure out the position vs time equation given two different accelerations - one due to the gravitational primary body, and one due to the craft thrusting in a constant fixed direction (although the thrust is in a constant direction it's not in a constant acceleration because you also have to calculate how the fuel gets burned and reduces the mass as you go). I'm not saying I particularly want to be the one to do the calculus to figure it out, but it does seem like it should be a solvable problem. You know the formula for how the acceleration due to the engine at constant throttle changes over time as the fuel burns ( a = F/m, where m is changing over time by a linear slope downward ), and you know the formula for how gravity pulls depending on current position relative to the primary body, so in principle if you add those two together you should get an equation for the total acceleration from both effects and be able to integrate it twice to get the position equations. Of course this shouldn't be done on the fly, but be done ahead of time by the mathematicians in the dev team, and then the final result could become the new "on rails" equations.

How about a single button in the map view that just says "time jump to next maneuver node"?

This isn't a bad idea but I think one thing that would help would be a timeline view in the map screen (assuming we can time warp from the map screen at some future date, which is a feature we REALLY should have), in which the time of future manuever nodes is marked on the timeline, with "now" on the lefthand side, and the scale of the timeline zooms with the map view zoom. (so when zoomed far out, the timeline shows several years of time, as would be needed for looking at interplanetary intercepts, but when zoomed in tighter it might only show a day or two of time, as would be needed for maneuvers in orbit around a planet or moon.).

Oh I like the idea of a "stupidity" slider. I just have no idea what it does. Same with courage. What do these actually DO? Are they a stub for some planned future expansion where the crew is more detailed? At the moment I think all they do is drive the facial expressions in the little windows in the corner of the screen.

I've suggested this before and I second the suggestion here. It would seem to me that the tracking center is the ideal place for time warp because there you're guaranteed there's NO ships currently loaded into the full-blown physics model, so all the various reasons for limiting time warp (in the atmosphere, too low altitude, etc) don't apply. I've launched a stupid little satellite into solar orbit alongside Kebin on an orbit with a radius of roughly 1 AU (or whatever Kerbin's orbit radius is called), named "Time Warp Focuser". The only purpose of the satellite is to give me a place to switch control to so I can be allowed to perform time warps up to 10000x.

When a stage has both a decoupling AND an engine activation in it, it seems (as far as I can tell) to be using this ordering of events: Search for any decouplers in this stage step. Do them FIRST. Then *After* that, perform any engine activations that may be in the step. The problem with this logic is that while it works when the purpose is to decouple a stage of debris and then fire the next engine up the stack that's still attached to the control capsule, it fails when the purpose is to do it the other way around and fire an engine on the bit of debris you're letting go (i.e. to make a forceful separation of the debris with sepratron boosters.) The problem is that when the engine you're trying to activate is on the bit that's about to become detached debris, the game's insistence on completing all detachments FIRST before doing any engine firings means that it fails to execute the engine activation that's in the same stage step as the decoupling. I *think* that what's happening is that by the time it gets around to executing the engine activation, the piece is now detached and no longer has a path to the command capsule, and therefore the engine is treated as unresponsive debris. This isn't fair since the staging list instructions said to perform the engine activation WITH the decoupling, not a moment after it. It would be better if the check dealt with this scenario, otherwise sepratrons aren't really usable. I tried making an Apollo-style escape tower and it had the problem that when the tower had been unnecessary on that launch and the launch worked fine and it was now time to jettison the tower partway into the flight, I had to jettison it as a two-stage process - first fire its engines in one stage and then a couple of seconds later hit the next stage to jettison it. When I tried to do the sensible thing and make it one stage (or one action group with an ALT-key) the decoupling always happened first and the engine activation never occurred. My proposed change - make it work like this: Make a queue for "engines being activated in this step". BEFORE doing any decoupling, run through and populate the queue, performing the "is it attached?" check THEN at the beginning of executing the staging step. Then execute the decouplings, and then go back and execute the engine activations that are in the queue. That way the "is it attached?" check happens before the decoupling happens, but the actual firing happens right afterward (This approach handles both the fact that the separation must come first for engines attached "above" the separator, but also handles the fact that the check for "is it attached" to see if the instruction to fire the engine can happen must come first before the separation for other types of engine activations.)