NathanKell

Ah, another question. How does FAR handle parts with multiple MODEL {} blocks? IMS you're calculating taper and width straight off the model, right? So do you just iterate over all vertices or something to get bounding boxes? Because otherwise I could see how multiple-model parts would be...problematic. Or do you just recurse over all models?

No problem! Here you are. Stock + Proc Fairings, which I trust is OK! (I had remotetech antennae on when I tested it, but all were behind the fairing and have been stripped from the craft files I'm uploading.) https://www.dropbox.com/s/r556i28o26k1gbo/625Test.zip FTest0 is the 0.625m rocket. NOTE: I had to change the node size of the Oscar-Bs to 0 via an addition to your CFG, since stock KSP has them at 1. Also, the AC (CoL ) problem is there with a vengeance--the upper stage is uncontrollable at low altitude due to the issue with what appears to be no drag for the engine (!). I had to mess with the balance between stages and my ascent path to make sure it only fired at high altitude. FTest1 is something with close to identical staging, but to do that I had to use the mini radials in addition to the LV-909, which messes up drag (Cd at liftoff jumps from 1b's [below] 0.015 to 0.022 or so). FTest1b is something with near-identical liftoff TWR, but different staging--there you really see the difference in drag!

Loving this. Two requests, one presumably easier than the other. 1. Can you set the transform origin to be the top of the tank? That will (a) make attachment much easier and ( make stretching more (IMO) sensible, especially since in KSP we usually build down. 2. Procedural SRBs. Seems like the code code easily be used to make procedural solid rockets. And that would be incredibly useful! (You'd need one more key to set burn rate, aka thrust).

@ferram, it's not that issue I'm afraid--these rockets were close to hand for the screenshots, but I've verified it with totally stock rockets too (and made sure the oscars have size-0 nodes, etc.). I can send you pure-stock craft files if you want.

Now, my own issue. For my mission log (and for early MCE missions) I've been launching lots of 0.625m rockets. And I find they suffer FAR (heh) higher drag losses than the 1.25m stack size rockets, for me at least. Example: with roughly equivalent TWRs, I get about 3x the drag loss for the 0.625m rocket, which means >500m/s more cost to orbit. Pics of said rockets: (and note that while the example here uses an SRB first stage, I see the same thing with a liquid first stage--I know the SRB has a shorter burn time, which contributes, but it's true of the upper stage too.) In flight: Also, a weird problem with the upper stage of the mini rocket: With no engine (looks normal for CoL) With engine (WEIRD):

I can answer 2-4. Recommended ascent profile is start turn early--anywhere from 200m+, certainly no more than 1km or so--and end it by, say, 45km. 2. (For a 2-stage rocket with TWR->MAX of 1.5->2.5 each, I did .7km start, 38km end, shape 38, and did 3140m/s to 80x80km. Can be optimized further.) 3. Which stage? They're very important for your lowest stage. If you add them to upper stages, make sure you add even more to your lower stage, such that CoL is lower than CoM in the VAB. You WANT lots of lift at the bottom! That's how you get stability. 4. Yup!

Yay! Finally a heavy nosecone so I don't have to fake it with low-impact-tolerance fuel tanks! Also, just a pet peeve, but it's Centaur, not Centar.

Check TohouTorpedo's thread. They're working on such a thing.

That was the first thing I used them to do, yes.

PM Sent. They're straight-up 1/2 size rescales of the stock boosters, so 1/8th to all stats. Technically, if they use the same fuel, it should only be 1/4 thrust (cube-square), but even with 1/8 thrust they STILL have too much thrust when empty and my payloads overstress.

Same here, although I just make the one probe core aligned correctly (and make something else, with a node free, as root, so I can use subassemblies). Haven't used the MJ part since, oh, June.

Updated the reserved info post, finally. Also, a challenge: cookie for each kerbalized reference you can find! Some are obvious, some are...not.

Explorer 1 The First Maneuverable Satellite Mission: Explorer 1 Mission Control: Kerbican Space Agency Launch Vehicle: Koddard II Objective: First satellite launch of Explorer Program Description: Launch the Explorer satellite to a circular orbit, change planes, and recover satellite just offshore. Outcome: Success Details: LV used is the Koddard II launcher: the Koddard I upper stage with a solid booster stage based on Krodinan technology. Explorer satellite has onboard OMS for use in orbital maneuvers and deorbiting. Koddard launcher will bring Explorer 1 to near-orbit (such that upper stage will burn up in atmosphere). OMS will complete orbital insertion to 80x80km orbit, then burn at descending node to bring inclination to 0. Explorer 1 will orbit for one week, after which it will engage in a pinpoint deorbit burn to splash down just offshore of KSC. Background: Galvanized by the Kerman launch of Wikinger 1, the Kerbicans knew two things. First, they would no longer be first in orbit. Second, they could still show up the Kermans. Explorer was a much more advanced satellite system: it could stay in orbit indefinitely, and it contained its own integrated propulsion system with the capacity for practically unlimited restarts of the maneuvering engine. To demonstrate the superiority of their technology, the Kerbicans designed a flight plan to show off what Explorer could do. Only the satellite itself would reach orbit, and once in orbit it would fire the OMS to make its orbit precisely circular and with zero inclination relative to the equator. It would then proceed to orbit for a week, doing occasional correction burns, before engaging in a final pinpoint deorbit burn that would see the satellite splash down (it was hoped) only a few hundred meters off-shore. This required the use of two tracking stations in addition to Mission Control, and preprogrammed maneuvers stored in the satellite's flight computer--as a demonstration, the inclination change would take place on the far side of Kerbin, entirely under autonomous control. Flight Events: T-01:00:00 Explorer 1 on Koddard II launcher assembled. T+00:00:00 Liftoff! T+00:00:18 Pitch program begins. T+00:00:50 Stage separation; solid fuel booster staged away. T+00:02:48 MECO; fuel exhausted. Explorer 1 will coast to Karman line, then stage away sustainer and fairings. Handover to Cape Jeju. T+00:04:05 Explorer 1 stages away carrier rocket, orients for orbital insertion burn. T+00:05:12 Explorer 1 begins orbital insertion burn, target orbit 80x80km. OMS ignites for first time to perform burn. T+00:06:40 OMS cutoff; 80x80km orbit established. T+02:48:31 Explorer 1 restarts OMS for plane change. Existing inclination: 0.11 degrees. Target inclination: 0 degrees. Achieved: 0.01 degrees. (Explorer 1 orbits for 1 week; time will now be from start of last day in orbit.) T+06:13:55 In range of Cape Azan tracking station, Explorer 1 restarts OMS for deorbit burn, target: KSC. OMS fuel exhausted for burn. T+06:16:22 Explorer 1 passes Karman line, orbital velocity 2131.5m/s Explorer 1 loses contact during reentry. Here it can be seen passing above KSC. T+06:20:01 Explorer 1 deploys parachute above KSC. T+06:21:41 Parachute fully deploys. T+06:23:57 Explorer 1 splashes down, less than a kilometer offshore. Mission complete!

I think the issue on your rover isn't that you have to control from MJ, but from a properly aligned part. That's why the suggestion for a properly-aligned docking port. MJ gets all info from the command part. So if the command part is pointed up, MJ will think your rover's forward velocity is 0 (well, not always 0--sometimes you're climbing hills) and thus always increase speed. If your command part is properly aligned, though, it should work fine. Same with heading, BTW.

My decel isn't somewhat lacking until <1M And that's actually a danger with drogues--the semi-deploy drag is 3, vs 1, so they actually have _more_ drag early than main chutes. Which can be Bad News if you're already near max-G. If you're really worried by G, pop mains first, then drogues when G lowers (5-10s later?). This should obviously be well above 2.5km though. Gawd, deorbiting a spent booster stage, I think I popped my chutes at 1.8km once--survived, but barely. Wow that thing had low drag. Then again I haven't launched a pod in some time--probes have such low drag that YMMV with pods.

G-force? Seriously, the time between 3M and 1M for me, at least, is max-G. And then G falls off massively when subsonic. So if you're riding the redline, there's some good reason to wait on deployment.

Not sure whether non-active vessels really contribute that much to slowdown, btw--vessels on rails have almost all physics calcs disabled, so it shouldn't put much strain on the system. I mean, KSP defaults to something like 2500 pieces of debris as max--and debris vessels are, AFAIK, no different from non-debris vessels in terms of calcs run. Stargate525, you can set lat-lon requirements for landing--check all the missions that require landing at KSC as an optional goal, like in the NT pack. And all planets will have lat/lon.

If you clip things into the bay doors, be prepared for an explosion on physics-enable. Not always, but usually. Especially a problem for wings when the bay is in the centerline of a spaceplane.

My best on 0.20 was 3100m/s. .21 seems to require a little bit more. Then again, my 0.625m rockets with cheapo SRB first stages require something like 3500. I've never really had problems with asparagus designs in FAR (not that I use them regularly, but I have used them at times). Make sure you have sufficient fins at the bottom of each stack (so your COL will remain below COM) and you'll probably be fine. It'll take more delatV than an optimized rocket, but it'll still take way less deltaV than it used to. Example: Temstar's Zenith series (6-booster asparagus) will put 1.5x the rated payload in orbit, with no issues at all.

Khalashnikovf, you can set max # of a part to 0 to disallow it. Check the old missioncontroller thread, nobody44 outlines how to do that. Regarding save/load: when I have time (currently helping my parents move) I want to move all the data into a confignode in the persistence file, like Kethane does now. That will fix all issues regarding sync. For now, here's how it works. As malkuth says, you're not charged until you hit space. So you're free to revert until then. Once you start getting charged or getting rewards, and you want to revert, you have to go to configure->rewind BEFORE you revert. That will rewind all costs since the scene last loaded (i.e. VAB->pad), so it will also rewind any payouts you've had. That also works for loading games. If you load a game, complete a mission, and want to reload to before you completed it, rewind BEFORE you quickload. Regarding spaceplanes: it's the same issue for powered landings generally. Need to add a check for if there's >1.5 TWR (or so) and, say, 1000m/s deltaV remaining in a spent stage for it to do a powered landing. Can do a similar check for spaceplanes, but if the object has some number of wings, allow a lower TWR.

Oh, right, in which case it would have to be compiled with reference to the MF dll, I think, since it will have to write to variables in that module class. Or MF would have to be rewritten to handle this.

Modules are non-destructive. You can easily add "reflective" MFS support to this by adding the MFS module, and stock KSP will ignore it. Check how ProcWings handles FAR integration. Awesome mod, btw--I'll try as soon as I get back to desktop. Been waiting so long for this!

The author is busy with some bad stuff in RL, per the ModuleManager (or was it Modular Fuels?) thread. Will be back as soon as can though.

Honeyfox, nobody44 was (is) apparently working on just that. Snillum101, that sounds like it would work.

_Is_ there any way to change node positions on the fly? Thought that was the issue.