NathanKell

Tigermisu: You need 70 drag/ton, however you get it. That means, for instance, one radial parachute for each .9 tons of other mass. I probably should lower the requirement slightly so it's .15t parachute for 1.15 tons mass, so you know for every ton of structure you need a radial chute. Makes calcs easier. Note that's per ton of DRY mass. I believe KER will tell you a stage's dry mass; I only use MJ so I do it by hand (you get a feel for it, as Geckgo says). gwitchy: Geckgo is right on here too (thanks, Geckgo), but it gets a bit more complicated if you use FAR, because CoL shifts in transonic and again in supersonic flight. On the other hand, FAR makes (well-built!) planes a DREAM to fly. Don't leave home without it. Finally, when I add spaceplane recycling support, I hope to add a bonus for "on the runway" so you should get your .95x back then. power5000: Huh. Didn't even know timer resets on mission load. When I have a chance I'll look into that.

e-dog, any chance we could adjust the height of where the fairing starts to curve inward? Useful both for normal and interstage fairings.

Torminator, the duplicate may not, but the fact that shielded command parts stay shielded does. Command pods have the drag of a well-designed rocket. Going by Cd. And practical tests: Reentry: 1600m/s at 700m....no chute for you!

Fair enough. pWings, for the procedural adapter (that does this) uses bones rather than straight single-axis scaling. Sorry, forgot that's how you were doing it. Re: the SRBs, I'd be fine with the engine part just not showing on the outside--call it a fairing, like how the bottom of many RL rockets hide their nozzles inside a fairing. Just show the nozzle on the bottom-of-the-cylinder texture. Heck, your stock texture endcap already looks kinda like a nozzle.

Ok. It must be something in the code change from 0.9.5.x to 0.9.6.x (when ferram updated the fairing code) that adds duplicates to command parts. Thanks for proving I'm (my install's) not crazy! (Or we're both crazy together...)

jrandom, that's because of the difference between surface and orbital velocity. You may be flying south-west, but Kerbin's surface is traveling south-east fast enough to make up the difference. 180m/s is less than surface rotation, IIRC. ferram, alas things are now worse. Command pods won't get _unshielded_ when fairings decouple. The first isShielded line never changes, but once shielded...the second line never changes back from True, either, when fairings decouple. So, a question for the entire thread--am I the only one experiencing the two isShielded lines for parts with command modules? Right-click and see what you get, if you would! Many thanks.

@ferram: I don't know whether that fixed things or not. I mean, on the one hand, _one_ of the IsShielded lines says true. On the other hand, the other says false. Seems like you're adding the Fairing module (or drag module?) twice to command pods?

Use a text editor with regular expressions and it's pretty easy to swap terminators, actually.

Thanks, Starwaster--that did it!

Ok, it's definitely something in 0.9.6: I rolled back to 0.9.5.51 and the dual-mention disappeared and they started getting shielded again!

Weird issue: I can almost never get "r" to work for the interstage adapter. Is it intended that r is to work with it?

@ferram, No problem--new version sounds great! Re: fairings--nope. Full bug report: With only Procedural Fairings and FAR installed (latest each), Command Modules (manned and unmanned) show two (related?) problems: 1. isShielded appears twice in the right-click menu 2. they remain unshielded (isShielded = false) despite being inside fairings. I have tried with regular fairings (two-side) and the interstage adapter (four-side), and with regular and fuselage fairings. Here is the output log: I note there are some null reference exceptions... noshield_output_log.txt

So, I have two and a half requests, if I might: 1. Procedural SRBs. Should be nearly the same code, just need to add a second key so we can select thrust level (which will also determine burntime, assuming standard Isp) and write to a moduleengine. 2. Superstretchy tank that can stretch in/out at both ends independently. Fueled adapters and rocket noses! The half-request: have nodesize scale with floor(radius/1.25), both for aesthetics and (much more importantly!) FAR support.

Especially since that might increase performance, right? Not invoking on multiple partmodules?

AtomicRocketBooster, you're starting it too _late_. Start it at like 0.5km.

What's weird is that Proc Fairings seem exempt from that problem--and everything else behind that fairing wall, including things that extend farther out, _do_ register as shielded! As to winglets: if you have them straight up or straight down, I don't know if it makes a difference. But if they're any way off 90 degrees, then it's because the dihedral helps and anhedral hurts roll stability.

That looks epic! A request, if I might: can you separate the two Mercury nose caps like you did for Gemini? So we have a small RCS pod (as Mercury has, like Gemini), then the main chute, then the decoupling cap?

@ferram, ah, right, it's lift post-change-in-AoA. Must have just been some weird issue with that rocket, then, that made it tip madly like that. Alas I have another issue to report--perhaps related to the drag issue? perhaps not--involving procedural fairings. For some reason my probe cores are not being shielded. Speaking of drag--with those craft I posted, do you experience the same issue I do with it, or have you not had a chance to peek yet? (No worries if you haven't yet! Just checking. )

Pretty new to github myself, actually. Wish I were linux full-time, but for various reasons while I maintain linux on the rest of the family's machines I run Windows on mine...meh. If you want to mess around with MC[E] on linux, grab nobody44's old source, replace it with the new source, and then add references to the extra files in the makefile. They develop on linux, IIRC (or at least the makefile sure looked recent!). malkuth has been doing the releases and is currently on vacation--if I get your stuff added, and maybe add some kind of spaceplane recovery (no promises!) I'll see about a release myself. But no promises, alas.

Can I just second the "speaks the Queen's English" bit? So refreshing! As I said there, moving is eating almost all my time, but I'll try to get your code working tonight. Also, given the variety of missions you have in this pack, I think I'll need to use only it with KATO, not the hodgepodge I was using. Expect some free advertising in the next update. And thank _you_ for the pack--without packs, what would one do with MC? A suggestion, though, if I might--considering the timing of high-speed / high-altitude tests IRL, would you consider dropping the prerequisites for the spaceplane chain, at least for the first few missions? (Spaceplanes 06 should not occur before at least AKSF 08 of course, if not AKSF 13 as you have it) I'd also suggest making only SP3 prereq for 6 and 7, not SP5. If you're looking for more early (historical) missions re: Mun, I'd suggest adding flyby and far-side free return missions--heck, just look at the USSR's Luna program. It'd be awesome if you could start a mission as an impactor, miss, and retroactively call it a flyby / "First Cosmic Ship."

gm537, when you go to "save as" your file, put the filename in quotes, like "mypkg.mpkg" That will override Notepad's default behavior of appending .txt to everything. Or use Notepad++ or some other real editor Geckgo: I'll try to add this this evening. Thanks for the code! BTW we do take pull requests (Sorry I've been so MIA, folks--moving is an utter pain!)

And another Aerodynamic Center issue... Trying to figure out why my sounding rocket is pitching over to 60 deg pitch on launch, I find I'm getting massive lift from just a fairing.

Cool, thanks! For parts that clip models together, do you calculate drag per model, or drag based on the (CSG) union of the parts? Because if the former...bad news for, e.g. the ReStock pack! (Example: Mk2 cockpit inside a Mk2 adapter is used for the Mk2b cockpit: it makes a nice, aerodynamic widebody cockpit great for lifting bodies...unless it suffers double the drag.)

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!