Anquietas314

Nah that's completely fine. I've had a few contracts to deploy satellites in a (prograde) orbit that quite quickly has an encounter with the Mun. You obviously won't have as long to get into the right orbit though in a retrograde one.

Your reputation is the middle resource on the space center view and the (career) resources tab in flight - it's the one with the multicoloured bar and a 5-point star. You increase it by doing contracts successfully, and you can lose it depending on strategies and if you lose Kerbals or fail/cancel contracts.

You might not have enough reputation to get the missions. They're some of the highest paying ones.

You shouldn't need 1800m/s deltaV to reverse your satellite's orbit. I've yet to see a contract that has a low enough orbit for that - instead either do the burn at apoapsis if you're in a reasonably elliptical orbit already, or raise it (at periapsis) and then do it. A variation on a bi-elliptical transfer might help with the efficiency if you're low on fuel.

seaces: The main thing that stops antennae working over extreme distances isn't interference - it's that the signal disperses so much that it's indistinguishable from background noise (stars and so on also give off low levels of radio waves). I do however think a distance-based limitation would be good for stock. RemoteTech basically provides this (if you disable the signal delay) although this is probably a little too complex for stock, seeing as you basically need to launch a satellite network before you can really use probes for anything (they lose control if they don't have a signal connection to KSC). You can of course do this using the direct line-of-sight to KSC for the first couple satellites, but that requires a very inefficient flight path or a ridiculously high TWR to get apoapsis high enough before you lose connection from orbiting beyond the horizon.

I would have to say no, mainly because it does not have its main wings roughly on a (geometrical) plane with landing gear underneath (or on its back end if it's a tail-sitter). There might be a term for that kind of design though. The altitude it flies at isn't really important - 20-25km is quite common for a "normal" spaceplane.

Actually the most efficient way to do this is to combine the plane change with the circularization. The maths behind this is basically Pythagoras' theorem.

I do actually use that mod, but that doesn't seem to be how it works. The parts "land" much too soon for that to be what it's doing; instead, I think it simply waits until the parts hit the deletion cut-off and then computes terminal velocity based on all attached parachutes deploying and presumably something like MechJeb's atmosphere landing prediction. It also produces slightly incorrect results - if you fly the stages manually, you will very reliably get less return than if you let the mod take care of it. I imagine this is considerably worse with FAR, though I don't use that at the moment. EDIT: The mod just uses the point when ships are deleted in the atmosphere. Confirmed both by observing debris fall back down and mention of implementation in the relevant thread. You can easily get near 100% of the value back - you just need more parachutes; 2 radial ones for a 3x1.25m tank launcher seems to be about right.

There are pretty simple ways that could be brought down to something closer to polynomial complexity without adversely affecting physics accuracy to a noticeable degree, at least in theory; for example processing part physics (and anything else) in stages in a manner similar a parallel prefix sum algorithm. How practical that is in Unity I don't know though, and of course there's always the possibility of complications.

Well yes, but there are plenty of other probe cores that have SAS, but no torque; nobody (that I've seen) has mentioned those (let's not). If the Stayputnik had torque but no SAS I think people might be happier, but it has neither. It's certainly large enough to accommodate a reaction wheel internally, if a little on the light side, but you could probably chalk that up to space-inefficient electronics like we had back in the 50s and 60s.

THX1138: The last time I checked (admittedly, a while ago), KSP's physics (mostly managed by unity afaik) is done on the CPU. The amount of lag I get for even relatively small ships (say, 100-150 parts) on my old hardware would certainly suggest it. Most of the time the GPU's doing diddly squat the entire time, while the CPU's pegged at about 50% (quad core), half of which is KSP; which means it's CPU-bound and mostly serialized (i.e. more or less single-threaded). As to your proposed solution: what happens if the ship is about to enter the atmosphere at the same time you're in the middle of a long, possibly complicated burn that you absolutely cannot stop in the middle of? Or here's a really nasty one: suppose you have not one but two or more ships entering the atmosphere (possibly different atmospheres!) at the same time?

RedDwarfIV: The argument so far has been about the SAS itself rather than torque. The thing is, some people (not including myself) feel not having SAS makes the probe useless or at least too difficult to use to be practical.

Yeah I pretty much expected this to have been suggested before. It's not (at least not obviously) covered by the do not suggest list though. It is on the "already suggested" list though, but I'm guessing that's where you found it?

I'm not sure but I would imagine so. That's not necessarily an issue though - obviously the game's code is not finished. Many many things have massive overhauls yet to come that are probably going to require massive re-writes of certain areas of the code. My point is, this is obviously not something that requires thousands upon thousands of lines of code to accomplish; the mod authors probably wouldn't bother if it was. Interstellar partly uses the tweakables system, I'm not sure about MechJeb but its abilities increase as you acquire more advanced nodes on the tech tree, and various parts from interstellar improve in a similar fashion.

I believe there's a mod somewhere that makes physics work on ships that enter the atmosphere outside of your control, but I have no idea if it's still maintained or what it's called. The problem is you can time-warp when you're in another ship. How should the game handle your trajectory through the atmosphere? If the ship has wings things get really complicated really, really fast. If the aerodynamics model was any good at all, it would get really really complicated, really, really, really fast.

Interstellar and MechJeb both manage to implement this kind of behaviour just fine without a new core system.

Err, what screenshot? You didn't post one. Never mind, either forums derped or you edited it and it's not showing the edit. However, to answer the title: it gets deleted if it goes below about 30km. No refunds, any Kerbals on board are killed. If periapsis is above that, it just stays in orbit. Atmospheric drag does not apply unless it's within 2.5km of the active ship (this also will prevent deletion). You should be fine to leave that one though until you match the target orbit. It's so far out it probably won't enter the atmosphere any time soon.

Meanwhile, if you use advanced search to only search the titles, it's the second and third item in the list; this thread is the first, at least for me.

*sigh* You know what? I'm not even going to bother to be thorough this time; you clearly just try to make everything a fallacy to falsify the argument. In a small nutshell: Quote1: response is a strawman and frankly moronic. You need to train engineers (and scientists). Quote2: no, that is not a distraction, it's finishing off an example to demonstrate engineers (or scientists) and stayputnik suffer precisely the same problems. Quote3: your argument there as stated was a strawman; that was explaining why. Quote5: *facepalm* no, just no. Quote6: The fact you think something is lame is subjective: it is an opinion. Definition of objective: adjective (of a person or their judgement) not influenced by personal feelings or opinions in considering and representing facts. Quote7: Whether or not the OP's opinion was exaggerated is completely irrelevant. Their opinion is clearly that they do not like the stayputnik. This is your beloved red herring fallacy. As for it being "objective", no: opinions are subjective by definition: different people can have different opinions. Quote9: Game balance is subjective; different people have quite wildly varying opinions of how the game should be. A game is generally considered "balanced" when the majority of players are satisfied with it. There is no objective standard for how a particular game should be balanced. Quote10: Pointing out the errors to this level of scrutiny is an absurd waste of everyone's time. Everyday language does not require this degree of rigor. As for the devs, clearly you must hold the devs in a very low regard if you feel they're incapable of rejecting stupid arguments. Your closing point: This is a game about rocket science; it's not supposed to be easy. For many, many people the entire fun of the game is crashing and burning. Over, and over again. Obviously it gets frustrating after a point, but that's what tutorials and so on are for: to help you when you can't figure it out on your own.

The game doesn't actually care if the satellite really is keostationary, only if it's close enough to the orbit. The problem sounds like your inclination is just too far out of alignment. To fix that, wait until you're at your Ascending Node (AN) or Descending Node (DN) relative to the orbit - these are shown on the target orbit - and then burn (for a prograde orbit) south or north respectively until the orbits are aligned. The numbers on the nodes should read a value close to 0 and possibly start jumping all over the orbit when you're done. If the number reads 180, you're going in completely the wrong direction

You see that white box in the top right? Also, if it doesn't work first try, use the advanced search.

Try doing a totally clean install of KSP (wipe everything), but make sure you grab your save file first. (KSP/saves/<mysave> - get the whole folder) and then installing the most up to date (release) version of those mods. The problem is most likely some very strange confusion going on in the code and nothing to do with your craft file, but of course that could be broken as well.

Next to impossible? What? Kerbal Engineer is not even remotely required to do that. You have navball indicators and a map for a reason. You can totally just eyeball the whole thing by pointing pro/retrograde, (anti-)normal and (anti-)radial. I would highly recommend doing the orbiting tutorial if you don't understand the navball. It's been so long I forget whether it covers plane change and radial burns though.

I'm not sure Jeb counts as a skilled pilot. Badass yes, skilled? Questionable. On a more serious note: if you have Jeb in the cockpit, SAS should work.

I'm just going to leave this here from the other thread, since you never responded to it (perhaps you just haven't noticed it yet), regarding the 1.875m parts: As indicated I'd be fine with a larger scale of parts, although make it exactly 5 meters for consistency (4x 1.25m). However, why no EVA on the mk1 pod? It has a big-ass door making up about a quarter of the capsule! I don't think Jeb really needs air in there with his spacesuit on