celem

Nice... very nice. Might just have to try that.

Ran my last flight in 0.90 I have a number of large-scale projects underway that are not quite done, (some not even nearly done) and I was originally planning on finishing everything up before moving across to 1.0 (to give some time for the bleeding-edge to become cutting-edge). But I got seduced by all the ISRU possibilities and the implications for my current projects, so the switch is happening and just about everything that ever touches atmosphere is being reworked. The final 0.90 flight was a stellar success. I sent a small scientific probe on a partial Grand Tour. Orbits (not fly-bys) of Mun, Minmus, Eve, Gilly, Duna, Ike, Dres. Landings at gilly and minmus. At each SoI the craft takes and transmits a wide-range of readings, before parking up in low Dres orbit with 6k dV still in the tank. Why didn't I keep going with that extra dV you might ask? Well, it was a single kOS script execution. I hit 'run X' on the launchpad and went to bed, woke up next morning to find that it had harvested some 3.5k sci for me overnight and taken around 3 hours for the execution (a good chunk of it being a 20minute ion burn towards the end). The reason it doesnt continue any further is that I havent written that part yet. The reason it actually makes orbit everywhere rather than doing fly-bys is that it actually does its own time-warps to optimal phase angles and takes a long in-game time to make the journey, its far easier to predictably implement in code than trying to teach it to slingshot and fly-by like a pro player. I had to skip the planned Mun landing since my script settings for that body have some issues I havent gotten around to debugging. (see kOS subreddit for its performance in a recent competition.) Time to port it to 1.02! Should only need some launch script replacements, might be my 0.90 FAR launcher can handle 1.02 stock. Gotta get to grips with the new kOS too. Fun times ahead. Im reasonably confident that i can hands-off automate an ISRU/shuttle/orbital refinery setup if I can just figure a way around KAS ground-docking, I dont have the scripted accuracy to make hard-docks on a surface. The idea that i can type run, go to work and come back to find a thousand tons of fuel in orbit is too cool. It would mine, transfer to the shuttle, ascend, dock, transfer, undock, deorbit, spot-land, dock repeat. It can even keep an eye on how many more runs are needed and park up when stuff is full, or even take a secondary destination. Got much of this sort of stuff in code snippets, will just need to weld it all together. (docking in particular I need to reimplement, my solution sucks) Then finally is the ever looming goal of porting everything into RSS because I think I could. -celem, who doesnt fly his own ships anymore, because wheres the challenge in that? Gets his kicks in a text editor these days and by the results on the screen when he gets home/up.

See in theory I would put my converters in orbit, miners on the surface and a dedicated shuttle to ferry between. This because both of these components are significant 'dead-weight' and should move as rarely as possible. In practice I added a second convertor to the static mining rig. This addition means that the ferry can return very nearly empty from orbit, not needing to bring down enough fuel for the next ascent. In this way I have a small refining and storage capability at the minehead for the transporters, and a major refinery in orbit for customers. Loving the new ISRU features. Dove-tails beautifully with my new kOS spot-landing script. I've managed to automate the transfer, ascent, dock, transfer, undock, deorbit and spot-land. The only input I need to make is to hook up a KAS link each time it touches down since my script cant handle a 'real' docking procedure on the surface. I rather liked the idea a while back in this thread about using a claw and rover wheels to make the connection, I could feasibly automate that and have the entire system run hands-off. (Im envisioning a script that once run sends the ferry up and down until the refinery in orbit fills, after which it parks the ferry and returns control to the player. Lets me set it running and bugger off out with my dogs or whatever!) With kOS at least I find spot-landings much easier to code than dockings, my first installation parked all the hardware on the deck and customers came down under script to land within some 100m where they got manually KAS'd into the system. If I were flying everything by hand then I would find orbital docks much simpler than repeated spot-lands. This was true for Mun, might be less-so for Minmus which I find considerably simpler to bullseye specific sites. I've yet to work out an auto spot-lander for an atmosphere though. I had just started making progress when the aero changed so im back to stage 1.

Yeah it doesnt seem to understand what i'm trying to achieve half the time. There are a couple of warnings that are genuinely useful. I've been playing a long time, something in the order of 2500 hours and I just dont forget most of this stuff anymore. Like others above me however, removing RCS from the pods was never my strongpoint. Hatch blocking warnings are....odd. Im still firmly ingrained into the habit of putting nothing anywhere near the hatch, time was even an antenna stuck on the door blocked it opening. Nowadays you can get away with that, but I just dont feel inclined to push it and find out at what point it becomes 'blocked' under the new logic. So business as usual. I try to ignore it most of the time and only briefly scan it right before I hit launch. I still wish the ER had been implemented as more of a bare-bones KER, or that we had gotten that mod rolled into an engineer experience tier or something. Still never really played a true vanilla install, because while I can do all the required math, I dont see the point when someone has scripted it for me.

No the rules dont reverse. Just remember that when we say 'pass in front of the body to slow down, behind to speed up', we are talking about the direction the moon or whatever is going in, its own prograde. Your own direction is fairly moot, as long as you pass on the aft-side of the gravity well you will gain energy and visa-versa. Glad you managed to flip at a moon, its very cost effective. I use it on Ike at Duna a lot too. Longrun the best bet is as stated to tweak your inbound trajectory while still way out of Jool SoI, but knowing how to reverse on a moon is a handy skill. (as is using moon slingshots to achieve huge apoapsis and performing a straight-up reverse out where you have hardly any orbital-velocity, then grav-braking back in.)

I think it was the only stock tank left in my install... I'll finally be all the way to just 1 procTank part. (shrugs) I guess it was only their game-engine I've wanted for a while anyway.

F3 doesnt spell it out for you maybe, but you can fish some intelligence out of it. Much like computer compilers it shows a chain of events, and the most interesting is the first. What hit what? And most crucialy, was there a part between them? If so thats the break. You also mentioned this happens on landing, without seeing the rocket its hard to diagnose, but if your legs are mounted to radial tanks rather than a core tank then its likely the radial attachment flexing and possibly knocking two cans together. I like to use girders to space things when this is happening, it also gives more parts for f3 to squawk about. Parts that are clipping into each other can also react with violent disapproval when they are loaded like this, just because they dont mind being merged in flight, doesnt mean they wont blow if 1 shifts and the other doesnt.

When going into Tylo Im normally in a 10km low orbit, then start scrubbing horizontal over a considerable period of time. Doing this without losing so much vertical that you hit a mountain at hypersonic velocity means burning a good chunk above the retrograde horizon, which in turn wastes dV. The lower your TWR then more you lose. While people are correct in saying these suicide burns are more efficient that is most true for decent TWR or higher. A weak engine will have to pitch so much to maintain vertical that it begins to waste again. (steerage losses) A nuke lander i'll normally bomb in from high orbit and make a very lengthy (and very risky) suicide burn which is mainly vertical since it can then just hug retrograde. With clusters of 48-7S or something i'll do the horizontal suicide from a 10-12km low orbit. This problem is only noticably powerful at Tylo, everything else with enough G to be challenging has atmosphere which does 99% of the work for you. In an ideal world your suicide burn ends at like 50cm. In practice you shoot for a bit higher, maybe 1km, enter a freefall and then make a second vertical suicide burn at maybe 100m. Done this way you can convert your first burn into something that kills horizontal but not all of the vertical (horizon behind retrograde) Maintaning a moderate descent rate across the last 1km/500m might be safe, but it is costly, very costly.

It is one of those things that a lot of us are probably watching for automatically and by this point sub-consciously. Bugs me too and always has.

Mechjeb can even handle rss/ro/far/dre combos which is how i usually play. you just gotta give it the right numbers. and/or learn kOS and write your own autopilot (or borrow a script from someone).

I used to build ground based reactors/power transmittors for the Interstellar mod, had a couple of vehicles that I drove several kilometers across Kerbin that were in excess of 100 tonnes. I was using about 18 of the biggest rover wheels and even got away with warping a bit at 2x while driving on dead-flat. I found that attaching the wheels directly to the body caused more breakages then when mounted to girder 'suspension', when you pass over folds in the ground the wheels twitch and try to reorient, but each does so as it hits the change, if you dont meet changes in slope pretty head-on then a pair of wheels flexing out of synch can cause twisting and more breakage. Regardless, I managed to get them off the runway, down the slope and off up onto the dark green grass 3km or so West. Even drove one down to the waters edge and parked it on a hill.

I've not really tried bringing spaceplanes back in through DRE since I dont build them very often. But heres my goal for a capsule: From 70km orbit I tend to aim around periapsis 35km. Returning from the Mun or Minmus I wont take lower than about 50-55km, G's are the biggest killer in my experience, not heat. Your kerbals cant hold more than a couple of seconds north of 12-13 G's without dying. Several times I've had an interplanetary mission return to Kerbin, aerocapture, then aerobrake and return a bucket of juicy science, and a smear of goo that was the crew 3 minutes ago...

Dont forget Kelderek's excellent point about the rear wheels. I suspect this is much of the cause of the difficulties you have in getting the craft to rotate off the runway. Those back wheels need to be as close to the CoM as they can get while remaining behind it (so that the craft doesnt pop a wheelie when loaded). Otherwise, if you think about physics, specifically levers and moments, then it requires a lot of force to nose the aircraft up since its pivoting around the rear wheels. Obviously lift is doing part of the work, but if its sluggish to rotate, this may well be the culprit. (actually your CoL is behind the back wheels, so lift is actually punishing you by lifting the back-end and preventing rotation and the craft will theoretically lift easier at low speeds, very odd) When it comes to tweaking the CoM and CoL. I know people say the CoM should be ahead of CoL, and this is true, but it should never be that far apart. I usually like the two indicators to be slightly overlapping. Since much of the front of your craft is drymass (the tanks are at the back) then the CoM is going to shift very little during flight and this issue is going to come back and bite you every step of the road to orbit. Finally, the amount of pitch authority you have is partly (largely) dependant on the distance from the CoM to the pitch control surfaces. With your CoM so far back you lose effective pitch from these. This is physics levers again. Id want to shunt the CoM forward a chunk, and the CoL forward significantly (canards up-front will accomplish a lot of this). That way you have a nice long lever for the pitch control surfaces to work with. If you look at historical real world designs you might spot some odd-looking things with really long tails, this is specifically to lengthen that lever. Since its FAR there are some more fun issues for you down the road such as mach tuck (CoL moves backward as you go supersonic), this means you dont want to nestle the two centres too closely together, but still, much closer than they are now.

@OP: The advice to assemble the entire thing in the VAB is definately sound, it lets you get an overview of your completed ship and pick where the joins will be. You have a couple of options regarding how to actually plug the bits together in orbit. Some people will take the module they are installing, add a probe core, torque, power and rcs, then launch it, rendezvous with the assembly point and use the rcs to dock it to the ship under construction. The drawback to this method is that every module must have control, torque, rcs, power, all that stuff. Once your ship is assembled you then more than likely have to disable some rcs ports and torque rings to make the craft balanced. In the longrun this reduces the dV of the finished ship by a bit due to the dead-weight of unnecessary parts (not to mention escalating the part-count) To avoid over-engineering each module like this you can either mount a small docking tug to it and then strap on the launcher, or make the upper-stage of the launcher into the tug. This lets you launch each module exactly as you want it to be on the finished ship, without superfluous control mechanisms. The beauty of this method for me is that you only need 1 tug, usually sent up with the second launch. Future launches can drop immobile/uncontrollable modules next to the assembly and the tug can then slot them in. It takes a little practice to design a tug suitable for installing a variety of modules, its RCS/torque needs to be well balanced with somewhat varying dimensions/masses of module. As far as splitting it into reasonable modules I tend to launch the control unit first, this is capsules/pods/probe cores, batteries/solar and RCS tanks (since they ignore fuel-flow rules). I then add the fuel section, which isnt particularly easy to break up further if you are planning on dropping tankage during your mission (highly advised). Anything that is going to involve a fuel-line needs to be 1 module for instance, since you cant set these up after the VAB, likewise anything on decouplers. I then usually launch the drive section last since engines are massy (though compact). If your craft is to carry landers, satellites, anything like this then these can be plugged into their docking ports once everything else is assembled. Remember to leave a port free if you need to refuel any of the tanks in low kerbin orbit, i usually refuel through the nose where my lander will ultimately sit. Dont be scared to launch empty/part-empty fuel tanks if the mass of a module is getting too much for your launch vehicles. @juanml82: Those wings are probably cosmetic, they are well overblown even assuming he has FAR and might need aerodynamic stability at some point. They look pretty pimp, so I think we'll let him off. If you look really close, I suspect he has landing gear mounted on the end of each fin, which in that case is designed to clear the mainsail and let him land the mothership. His Ions are probably meant for fine-tuning, you are quite right in assuming day-long burns. The mainsail on the back of that ship will be too overpowered to fine-tune distant intercepts. The RCS is probably so that the individual modules of his ship can undock and rearrange themselves, if you look carefully you realise every independant section has its own RCS fuel/ports, probe core and Torque. Finally, RCS is oft-overlooked as an actual propulsion method. With the number of ports on that thing he can thrust harder with RCS than the Ions and it becomes a third propulsion option. (Never forget that 'h' turns your RCS into an engine)

Not so much really... at least not always. You got a nice fairly close intercept displayed on that first pass. If you had tried to adjust over multiple orbits then you would find that Jeb would not be at the point where your orbits crossed on the next lap around Kerbin, his orbit is wider than that of the rescue ship and therefore his orbital period is a chunk longer. On the next lap Jeb would have been still on his way out to the intercept point when the rescue ship passed it. Given enough time then eventually he would come back round again to another close approach, but it could be many orbits down the road. As impyre alludes to, adjusting over multiple orbits works best if the two orbits are very similar to begin with (therefore similar periods). It can also work if the orbits are different but they need to be a bit more specific. For instance if Jeb had an orbital period exactly twice that of the rescue ship then the second orbit would result in Jeb being at opposition (furthest away) at the intercept, but the next orbit again would bring back the nice close approach. This is whats referred to as Phasing Orbits and is a useful trick to learn when you start moving on to docking and orbital assembly. (its why you build stations in a pretty high orbit. I like to build at 150km so that launches from kerbin can set up a phasing orbit beneath them. If you built at 70km then future launches would have to launch higher still to be able to phase correctly. This is also one of the reasons ISS sits up at 300km in our world, to make space for phasing orbits below it (and to avoid atmospheric drag which in reality doesnt have a sharp cutoff))

Its also worth remembering that elliptical orbits are very hard to theoretically model, so hard infact that we humans cannot do it in reality for the planet (or minor body...whatever, dont open that can'o'worms) Pluto. This means that the nice tools we use are damn impressive in being able to get intercepts at all. To quote Paul Schlyter whose page on planetary location I use for programming kOS: I wont include the formula he refers to here, its a wall of math, check the link if you want to appreciate how badass elliptical math can be. Its very very difficult to work with ellipses. In KSP at least the orbit is known, but its still a complicated procedure to align with it. Regarding your question about the point indicated by the 'red arrow'. Yes, this would be the cheapest transfer in terms of the injection burn dV from Kerbin. You wouldnt meet it head-on however as you would depart when Kerbin is opposite that point on the other side of the sun to meet it in the same direction, though its increased orbital velocity at this, the lowest point in its orbit, would make it a bit more expensive to drop into orbit around.

Im fond of leaving them up there. Even if its a spent sample probe (xmitted its data) with no reusable experiments, i'll tend to leave it hanging around until my lab+claw can come along and reset it. I have a number of 'scrapper' designs based around the claw that deorbit or otherwise reposition/repurpose stuff. Because money.

I like this idea, I've been using the navball and 'target' like Laie suggests, however lining it up on the map should work well provided its a fairly regular altitude you rendezvous at. The reason this appeals to me so much is that the spot SalehRam has circled is also the point I aim to hit the atmosphere for KSC re-entry, so i'm well used to finding it on the map.

Good stuff Steven, many thanks. Got the numbers making sense now.

Hmm, that explains what Im seeing. Its only the Orbital component that does this yes? The github docs certainly indicate that Velocity:Surface is relative to the surface of the SoI body. Making Mun:Velocity:Surface the speed the moon passes over Kerbin's surface, and by extension kerbin:velocity:surface must be the speed kerbin is moving across the surface of the sun... Returns the surface-frame velocity. Note that this is the surface velocity relative to the surface of the SOI body, not the orbiting object itself. (i.e. Mun:VELOCITY:SURFACE returns the Mun’s velocity relative to the surface of its SOI body, Kerbin). Or is this just badly worded and all vectors come out relative to the SoI they are run in and not the SoI the body orbits in? (assuming the script is running in kerbin's SoI...which it is right now). I dont want Duna:Velocity:Orbit to be relative to Kerbin unless i specify so, thats needlessly cryptic, by my understanding of the above quoted lines Duna's SoI body is the Sun, Kerbin has jack to do with it. edit: im going back to longitudes anyway i think. I dont want to transform everything out into the Sun's sphere, I suck horribly at vector and matrix math.

Hmm, bit confused here.... Im trying to knock together a transfer window calculator. Had moderate success using BODY:LONGITUDE to get the longitude of the planets over the sun, which lets me pretty simply pluck out the phase angle. I then decided to try a few other things, in particular I decided to try pulling orbital velocity vectors out for each body, which I then planned to put through VANG... Problem is, Kerbin:Velocity:Orbit always returns (0,0,0). All the other planets seem to work fine, and kerbin:velocity:surface seems to also. Why is Kerbin:Velocity:Orbit coming up as an empty vector? Its not the reference point, Kerbol itself is... While im talkin about body velocity... Sun:Velocity:Orbit returns a vector I didnt expect (this is where i expected 0,0,0). Sun:Velocity:Surface is back to triple zeros. What exactly is this suffix returning? I thought it was a vector relative the the SoI body, which for all the bodies i've tried is the Sun, (And for the Sun itself I have no clue what its non-zero orbital velocity vector is meant to mean) Does the Sun rotate at the exact same speed as Kerbin's orbital period or something? (though this would lead to a zero vector for kerbin:surface rather than kerbin:orbit.)

Unfortunately career mode is still not a fully-fledged and balanced game in this respect. I tend to play much like you, if you want any other planets in the Kerbol system to be relevant then you must ban yourself from Kerbins moons. Its a spectacularly easy task to max out the entire tech tree within 2-3 game days with only vague ability to actually design and fly. For instance i dont need minmus, its a 4day flight, why would i do that when i can strike 8 mun biomes in 24 hrs inc transfer and return? Answer of course is just dont visit them, or make 1 token landing on each for the progression contracts but refrain from biome hopping or putting stations in orbit. Either pretty much completes your game directly, since you start reaping 2-4k sci per mission If you want to do contracts, scale the sci rewards way back, i use 20% and they still contribute a big chunk. Also ban yourself from 'Test-part' contracts or remove them entirely from the game, they areway too easy and offer broken amounts of sci. Its often possible to 'launch' something with no engines and/or fuel, recover it 15 seconds later and scoop 100 sci for launchpad part tests. Broken balance-wise. Mods, as you mention can help, either they add more parts, or redistribute what is available. If you are already sitting close to the RAM cap then you will absolutely require the ATM mod to add anythign else (compresses textures, i use it even on otherwise vanilla installs since Squad's stock textures are bloaty) Finally, I did once play a carer back in 0.24 where I tripled the cost of every node in the tech tree. Game is still easy but takes a little longer at least and its less viable to max out inside Kerbin's SoI.

When it comes to touching down on land and not water then I usually use Kerbin as a benchmark for Laythe designs. Kerbins atmosphere starts a bit higher, but isnt quite as thick, so overall a craft follows a similar trajectory on both bodies. I tend to deorbit about 100-110 degrees before my desired touchdown, the exact angle depends on the drag of the design and the starting altitude, but practice on Kerbin as mentioned. If you can deorbit and have things parachute onto KSC then you ought to be able to hit a Laythe landmass. Bombing in from an elliptical orbit makes hitting the spot even simpler, but means more of a suicide burn to kill the velocity you pick up in freefall. Since you have chutes and jet engines for the softland, I wouldnt think the extra dV would be particularly high.

Colonies and stations in particular are quite tricky to get to orbit using stock parts without any kind of assistance. (pure stock) This is because you are dealing with very heavy payloads, and in general 1 ton on the top equates to some 10 or more tons of lifter. Big payloads therefore very quickly lead to truly massive lifters that test your desgn skills and your pc's performance. The biggest single help (to me at least) is the KER mod which gives you the data on your design without you reaching for pen/paper and calculator. If these two things are particular goals of yours (stations and colonies) then you will likely need to learn how to assemble things in orbit efficiently, which means learning to rendezvous and dock. Launching any worthwhile station as a single piece is an exercise in massive rocketry, break it down into logical modules and "plug'n'play". Same principle applies to surface bases, massive grand tour interplanetarys... I tend to stop around 100 tons. Once the payload weighs more than that it gets split so that I dont have to design a custom lifter (since i have some 100t designs saved). You can of course launch anything, you can stack together 10 thousand tons of hardware and blast it into the sky. But not only will your pc cringe, its just not efficient when you look at the cost/payload introduced with career mode.

Boy, you aint kidding. My entry for this challenge hit exactly this issue, it worked beautifully... provided it launched at UT 0. Making a pre-calculated script resilient to this is less of a chore than it seems however, KerboScript is pretty smart and has a lot of options including solid timewarp controls. Adapting a precalculated script to find its intended transfer from any launch time is fairly trivial. (afterall its a window that pops up once per orbital period of your ship for Mun, so probably every 90 minutes or so) Certainly an easier concept than making a script that uses no such pre-calculated data and genuinely finds its own way. Would strongly recommend those interested in diving into this challenge to stop by the subreddit, a number of us have been discussing the various hardships involved and solutions over there. (though you wont see any code, its a contest after all. XD)