Anquietas314

It would help if you could post screenshots of your payload and the launcher designs you've tried already. Also are you using FAR/NEAR? You should be able to build launchers that can lift payloads of 40 tonnes relatively easily using 2.5m (rockomax) parts in stock. With FAR/NEAR you might need to use the 3.75m parts instead (edit: because you typically build thinner rockets), but it should be doable. Incidentally you can actually build quite complex stations by launching components less than 8 tonnes each (launch fuel tanks empty).

Yep, this is already in the bug tracker. Aside from the debug menu, the only way to work around this is just decline those contracts

I actually encountered this problem early in my 0.90 career save. Initially I assumed it was part of the update or a bug or something, but it turned out I'd just accidentally disabled my ship class on the map/tracking station without noticing . The ship itself was still visible (because I was controlling it I think), but the orbit path wasn't. You can turn it back on using the bar at the top of the tracking station / map view (hidden in map view until mouse over). Of course, it's possible the problem you encountered was something completely different, but hopefully this helps .

It's technically possible to do those missions without upgrading the tracking station, but it is considerably harder if you don't already understand the technique. This old tutorial covers how you can accomplish this - it's from the days before targeting was an option . Funnily enough the assumption that the target is in a 100km orbit is quite appropriate for rescuing kerbals

In general this is true of improving on some "best" algorithm for a particular task (good example: matrix multiplication), but improving on a poor ad-hoc implementation is frequently quite easy. We seem to be dealing with the latter case. The thing is, these are both instances of exactly the same problem: finding the intersection time between the orbit of a player-controlled ship and some fixed, moving sphere which has its own orbit. The only difference is the size of the sphere, which I suppose you could argue makes it trickier due to floating point errors. With physics spheres, the other ship behaves basically the same as, say, Mun, until you actually enter physics range. Sidestepping the detail that the other ship may itself have future SoI changes, but as far as the maths is concerned it doesn't really matter; you'd just need to check the physics intersection happens before the SoI change. Sure, but that's really a fundamental part of programming. Having more of something to process means processing it will take longer; that's completely unavoidable. We can however get it to the point where it takes absolutely absurd numbers (hundreds of thousands to millions) of vessels for it to matter . Heh, I think "excited" is probably the wrong word. Programming is essentially my "day job" (currently unpaid... ), although it is something I thoroughly enjoy .

Socks750: I'm not sure how many mods support it directly by default, but the reason that mod is no longer supported is that its functionality is now (partly) supported by stock. There is the filter extensions mod which can be used to provide mod-based filtering, but it's a bit hands-on. EDIT: it occurs to me you may not be aware of the new features in stock: click the arrow in the top left corner to open the advanced tab. It has module/resource/tech level filtering, among other things.

Okay, well I did say it might work. Your thread has had no posts since october (as of writing this), so it was reasonable to assume nobody was still working on it. Why only 95%? If all you're doing is backing up .craft/.sfs files, it should be fine with all mods, no? Just how large is your persistence file...? Mine has never gotten above 1MB, even with dozens of active vessels. In any case, the S.A.V.E. mod allows you to set a maximum number of backups, which means it's a total non-issue ; seems unlikely you'll need to revert to 20 versions ago . Having a dependency on git is perhaps not the greatest idea though, especially if you're only using it for diff; from experience git is far from the most user-friendly version control system (but the best by far!). Diff is its own separate program you can find on most linux systems; there's a windows version too.

There's a known bug where you can get contracts to do experiments above the maximum altitude for that experiment, however your contract is in fact doable . You need to be below 6000 m above Gilly to do temperature scans. It's a tight margin, but it is possible

Perhaps post a screenshot of the station? Also, check the station's carbon dioxide level is/was not almost maxed out - that's also lethal to the Kerbals.

Did your station run out of electricity? You need that to keep them warm . Space is cold. Very cold. As for replacing the Kerbals, I don't know of any mods that let you resurrect dead crew, but you could try editing the save file. I'm not sure how you replace dead crew though.

I'll just add that this only works if your center of mass won't shift (much) due to fuel consumption, or you can accurately predict where it will be when you're docking. I have used that thruster arrangement a few times though with varying degrees of success , though I used the thruster blocks (RCS thrusters are expensive... linear ones more so).

Essentially yes, but in fairness the performance improvements would probably go unnoticed by most people; not everyone has 200+ vessels (including debris)

LordFerret: OP basically wants to be able to leave SAS on, but have it use the reaction wheels only, even with RCS active, with the idea being to have SAS hold the ship still "for free", while using translation controls to move left/right/etc.

Technically yes but then you have a problem if you're using a USB keyboard and want to press 3 keys at once other than F (for example, to move up, left and forward at the same time).

What you propose is actually much more complicated than is necessary to solve the problem. You already know the vessel in question as you're computing the time for its SoI change; it's trivial to just store its id at the same time and use it later to retrieve the vessel, instead of having a for loop (aka a linear search) to find it. This doesn't require any additional overhead to comparing the times, except for the minor detail of having a few extra bytes per element. At worst, that'll cause cache misses slightly more often, but that won't be remotely significant given we're talking about ~16 byte elements (assuming 64 bit time and vessel id). No, it doesn't. What is demonstrated is that the current implementation is stupidly inefficient for what it's trying to do. Computing intersections between a sphere and either an ellipse, parabola (rare) or hyperbola is trivially inexpensive; it should be no more than 100 floating point operations per test (that is, orbit/sphere intersection), although I don't have the exact algorithm to hand to give a more precise estimate. That depends on what you're talking about. If 500 of something is enough to cause significant overhead when done every frame (let's say 60 fps, so 30000 per second), then that 500 is way more than necessary to benefit from parallelization. With bag of tasks in particular, the overheads from making the task parallel are almost negligible assuming appropriate use of thread pooling, a lockfree data structure for the tasks, etc.

You should try FAR/NEAR. Also, anything that involves more explosions caused by user incompetence (rather than physics weirdness, bugs/glitches and such) is awesome for a game like KSP. I've been playing the game so long that there's almost nothing I can't do quite reliably within 3 attempts and (unintended) explosions are rare. That makes the game really boring if you don't enjoy the process of assembling things in orbit or role playing or similar.

While I agree KSP shouldn't necessarily follow real-world physics to the letter, they do at least need to be reasonably close, especially given KSP is teaching loads of people the basics of rocket science. Aerodynamics is incredibly important to get right. Stations: Launch them in multiple pieces. If we have something like procedural fairings and aerodynamics is similar to FAR/NEAR, launching giant payloads won't actually be that difficult once you get used to doing a proper gravity turn. The one time I did try FAR, it only took me about 5-6 attempts to launch a ridiculously huge payload that was bigger (but lighter) than the launcher, and the problem was learning to do a proper gravity turn that didn't rip the rocket apart due to aerodynamic stresses, not getting the payload up there. Pancake rockets: mostly necessary because of the "souposphere" we have at the moment. Try playing with FAR/NEAR; you'll find you need a far smaller rocket to launch a given payload to orbit once you get the hang of it. Even with FAR, asparagus staging is still perfectly viable if you have nose cones or fairings on everything, as long as you're not talking a 5-layer 50-stage beast that drops tanks at a rate of 3 per second EDIT: Like Added bonus of realistic aerodynamics: landing on (and returning from) Eve will be far easier than it currently is.

I wasn't able to find a text list from a quick google search, but by Scott Manley covers them.

Why on earth would you check every vessel? Only one of them is going to have that SoI change; store both the time and the vessel (id) in question as part of the event. You're right that a priority queue would be a waste of time though; a simple vector (the dynamic array kind) would be faster than any other data structure for that even using the dumbest approach (storing the nearest events at the front of the vector) up to a few thousand elements. Yay cache-locality! A good (and simple) solution would be to use a vector with the elements at the back of the vector being the ones that will happen soonest. Adding near-future events and removing ones that just happened is dirt cheap, adding far-future ones doesn't need to happen often and due to cache locality is a non-issue until you're getting towards thousands of vessels with SoI changes. While it's not as simple as on-rail SoI changes, you can technically consider entering physics range of another vessel to be similar to an SoI change, especially if you're using time-warp at the time. The ship you're controlling does actually have a known trajectory whenever it's not accelerating, but computing intersections with other vessels' physics range spheres in the current SoI for only the actively controlled ship should be cheap enough to be a non-issue even if you're doing it every frame. You could of course use something smarter as you suggested, but it wouldn't be worth it unless you have hundreds to thousands of other vessels in the current SoI. Having a large number of (independent) small calculations is exactly the sort of situation where parallelization will give massive performance improvements (if done correctly), especially if it's done using GPU acceleration. An efficient bag of tasks implementation will work just fine too though, but the improvement will be smaller than with a GPU.

In short, no. It's all or nothing with RCS/SAS, at least for now. It's possible there's a mod out there somewhere, but in my experience unless you're flying some absurdly large ship, it shouldn't be a serious issue to just leave both on while docking. It's rare that I don't have craploads of spare RCS fuel if I add RCS tanks to the ship - if I don't, then usually I can dock with just the capsule's fuel, but the margin's generally too close for my liking. The trick's to be careful and not overdo it EDIT: I should add that you don't often need RCS at all for most designs unless you're docking. Very large ships are obviously an exception, but in most cases one or two reaction wheels appropriate to the ship size are more than sufficient for maneuvering.

eddiew: that thing can get to orbit? That's honestly impressive; nice work! Now try to get a useful payload to orbit with it

Don't worry too much about the runway - almost any design doesn't quite behave on the runway; yay physics glitches. As long as it's only a slight tendency to turn left or right it doesn't matter very much; if you enable turning on the front wheels it should be easy to correct it (be careful!). Above 10-15km intake air distribution is probably at least part of your issue; try the solutions suggested. You may want to make the intake types a little more evenly balanced to the number and type of engines you have as well; as they are, it's going to be difficult to get them balanced properly since the shock cones have much more intake area than the radial ones. Even if you can't get them balanced perfectly, making sure the "assignment" is symmetrical should be good enough to keep it stable. Technically it should fly fairly well as it is if you can make thrust stay symmetrical, but it's not going to be the most abuse-tolerant design ever . The intakes are "close enough" to the center of mass (especially given most of the radials are just behind it) to not be a serious concern given the cockpit etc, but it would certainly help with stability to move the radial ones as far back as possible. As others have said you could try moving the rudders further back too, although realistically it'll just give the plane more yaw authority to overcome minor tendencies to yaw left or right. A couple things I didn't address before: 1) Can it lift off the runway cleanly before flying off the end of it? If not, add more wing parts. If so, never mind. 2) Later in the flight (particularly when everything's nearly empty) your plane is likely to have issues due to fuel arrangement; the center of mass will move backwards until it's behind center of lift. For designs with a lot of control authority that's not necessarily a major problem, but in your case it'll make the plane want to pull up, possibly beyond your control. Sliding the side tanks forward so the center of mass is nearer the middle of the plane, as well as emptying the tanks nearest the nose and tail of the plane should help with that. If all of those tanks are full, you have way more fuel than you need on that thing to circumnavigate Kerbin at least twice in a single flight . I don't see any rocket engines on the design either, so be sure to drain the oxidizer from the bicouplers unless it helps with balancing; it's just excess weight. Same goes for the monoprop in the cockpit .

Strictly speaking that mod just makes it easier to use the stock functionality (and adds a few new icons and such), but none the less it's a great help.

We're going to need screenshots of the plane showing center of mass, center of lift and center of thrust to accurately diagnose the problem. Also, are you using stock aero, FAR or NEAR (or anything else)? I doubt adding lift will fix your problem though; it sounds like either asymmetric thrust or dodgy(/missing) rudder placement. From your screenshot, the design seems to be mostly fine. What altitude does the issue occur at? If it's above say 15km then it's probably the early stages of asymmetric flame-out. You can use the intake placement trick (there's a thread in the tutorials forum), or the intake build aid mod (far less tedious) to fix that. I should add: if your plane is yawing left or right, it will generally tend to bank (lean left/right) as well.

Yes, in the advanced mode like I said. It's the huge + button in the left hand pane; you pick an icon, give it a name, click the big green tick to confirm . It will only show your custom category in the advanced tab though, but since that's where subassemblies now reside, you want it open most of the time anyway . EDIT: A screenshot I dug up from google (can't run the game on this computer - my other one's broken): That + button at the bottom of the list.