Johould

This has been asked a few times but never answered: what, if anything, does "Crew Affected" mean on parts that provide only simple hab time such as the Hitchhiker?

[quote name='Hannu']This is true only in very special conditions, which are rare in games (and almost everywhere). Simultaneous calculation demands that data is 8 dimensional vectors and n x 8 matrices. Typically there is 4 dimensional vectors and 4 x 4 matrices in physical simulations, 3D models etc. I guess that KSP does not use 8-vectors at all. If data must be rearranged for calculations it takes an advantage. As far as I know single 32 bit floating point operations are not faster than 64 bit operations (in modern CPUs).[/QUOTE] You don't need 8-dimensional objects to use 8-way vector operations, just enough independent operations. If you have more than one 4-element vectors (like a position for each part in your rocket) you can work on two items at once. Heck, a 4x4 matrix operation already has multiple independent row-column dot products to handle. To best use FMA instructions you might even turn the whole calculation on it's side and pack each vector register with just one number from eight separate objects. Point is, just about any code doing lots of math can be optimized to make good use of vector instructions. When you do use vector instructions, processors since at least Pentium 4 and Athlon have at least twice the throughout in single precision (the single precision instructions may not be much "faster", but twice as many single precision numbers fit in a register).

[quote name='Daid']AUCH. Your post just hurts from bad info. Floating point calculations in modern CPUs are done in 80bits, always. 32bit operation? Don't care, first turned into 80 bits internally in the CPU before the math is done. [/QUOTE] That's exactly how x87 floating point works, but those instructions are not quite modern any more. These days compilers prefer sse scalar instructions like MULSS to x87 instructions even for non-vector math. Those instructions only work at the precision of the arguments rather than the 80-bit extended precision x87 works in. Along with that, you do see performance differences - a 64 bit multiply is 4x the work of a 32 bit multiply. I haven't checked recently, but Agner Fog's instruction tables are probably still the place to look (actually, I wouldn't be too surprised if the performance of scalar operations has gotten pretty close, but vector ops will show). I don't think AVX changed things back, but I'm not completely up to date on this stuff myself.

Oh right, it is called "Recoverable" rather than single stage.

Is an "SSTO" allowed to use launch clamps? This came up while trying to stabilize Mikki's Monster - If it's only needed to survive the initial physics jerk, a clamp is cleaner than more landing gear.

Resupplying the base is supposed to be enough. This thing with tourists seems to be a bug in the latest release or in it's interactions with 1.0.5 (which started recording professions in the save file, instead of computing them from names).

Ok, but you should mention that you have to fly exactly prograde for the tailcone to save drag. Flying more carefully, I can get half as much drag from the tailcone, but its drag increases much more quickly with angle - it's even with the shock cone you are pointed 1/2 of the way from the center to the circle of the prograde marker, and gets hugely worse after that. Thanks for the table. The shock cone intake has reasonable drag over a lot wider range of angles, but it's good to know the tailcone can give lower drag if used carefully.

How are you comparing drag? Turning on drag numbers in the right click menu shows more drag from the tailcone under any conditions, and a lot more if it's not pointed exactly prograde.

The "Display Aero Data In Action Menus" deubg option doesn't add any information for wings and control surfaces. Besides eyeballing the "Aero Forces" arrows, is there any good way to compare wing forces to drag numbers?

Oops, the CHANGELOG in my installed files lists the latest version as 0.4.6.0, so maybe the files in your updated mods do need a closer look.

I think if I had explained this well enough, you would have already fixed it. The symptom is an AVC complaint on every startup, saying 0.4.5.0 only supports KSP up to 1.0.4, and the only necessary fix is committing the correct CRP.version file to github (no rereleases of your mods is required - they already have the correct file; updating the version online will fix the AVC warning). This happens because despite the CRP.version included with UKS being entirely correct, AVC's policy is, as KSP_AVC.log says, "Identical remote version found: Using remote version information only.". The local and github copies of CRP.version both claim to describe CRP version 0.4.5.0, so AVC completely ignores the supports KSP versions listed in the local file, and trust the max supported version of 1.0.4 from the download. Changing the URL in the local CRP.version to refer to a copy of the local file is enough to quiet the warning.

The CRP.version included in UKS and such lists compatibility with ksp 1.0.5, but points to a url https://raw.githubusercontent.com/BobPalmer/CommunityResourcePack/master/GameData/CommunityResourcePack/CRP.version which only claims compatibility with 1.0.4 (despite having exactly the same version 0.4.5.0 of CRP), and then AVC complains about it.

The release page at https://github.com/BobPalmer/SrvPack/releases is a little bit screwed up - the download link is 3.3.0, but the rest of the text is copied from the 3.2.0 release.

Rather than going by participant, I'd rather keep all distinct designs. Whether or not they are in the rankings, it's also nice to have every accepted attempt linked from the first post. Maybe check out how the Goddard Problem Challenge has an "attic". As for reusability of planes, I like seeing both kinds of designs, but it's also interesting to see which ones are at least semi-practical, so it would be nice to tag SSTO designs that can't reasonably be recovered (maybe as "SSTO*") if there are too many. But, I'm definitely against requiring enough fuel for landing as part of the scoring flight - minimizing that sounds like a very boring game of 69km aerobraking passes. For defining "reusability", I think being able to *land* from orbit without a payload more closely tracks practicallity - an exposed payload design could still be useful for stocking fuel depots or with payload fairings, and I'd certainly expect them to fly less well without a payload, but as long as they don't disintigrate or incinerate on reentry it could still be used. Reusability with only refueling is too strict for planes - recovering and rebuilding is easy on Kerbin, and jets hardly work anywhere else. I don't know about rockets, maybe SSTO and multi-stage are more interesting as separate challenges there. Strict "SSTO" might track practical goals better too - refuel from a depot and fly the whole thing elsewhere, or recover in one big piece.

Val, I got a fairing working: Fairing applied to Payday Mk.7. Instead of a structural frame or clipping games, this just connects struts to the fairing, and keeps the vessel connected by adding a second docking port at the front of the payload. Takeoff weight is 314.58t. KER reports a terminal velocity of 485m/s at zero pitch on the runway, I think that's actually an improvement. I haven't tried to reach orbit, but it works up through building speed at sealevel. It jiggles a bit on load, but seems stable enough after physics settles down - and surviving takeoff requires pitching promptly up by about seven degrees after rolling off the end of the runway, so I think it's sturdy enough. - - - Updated - - - If it can reach orbit, that takeoff weight should be enough to beat the Mk.4 Scarab for SSTO fraction.

I've been trying to put a frame and struts inside the fairing, with lengthwise struts around the payload, building scaffolding as needed to reach. The only big trick I'm using is surface mounting stuff onto the part under the fairing base, so it sticks through and I can attach struts. Unfortunately I'm using cubic octagonal struts for scaffolding, for the low weight, but my computer can't really handle the part count. I'm calling it a night after a computer crash, but saving about 4t off the Payday launch weight by switching to a fairing looks possible.

Have you tried using a fairing instead of those heavy Mk3 cargo bays?

That might help Kobymaru, who did mention altitude. In my case a 300t plane was under-controlled even at sea level with default settings.

I didn't test docking, but I can confirm it fixes a case of repeated NRE messages after KIS-attaching parts that I was just about to report. (I assume it's the same issue, but just in case, it's reproducible with only KIS 1.2.2 and Pilot Assistant 1.11.10 installed, on the launchpad in a fresh sandbox game, by going EVA and attaching something. The log gets the same message as the other issue, NullReferenceException: Object reference not set to an instance of an object at PilotAssistant.FlightModules.SurfSAS.Update () [0x00000] in <filename unknown>:0 at PilotAssistant.FlightModules.AsstVesselModule.Update () [0x00000] in <filename unknown>:0 My test vessel had a Mk1 can, Bill with an inventory of a screwdriver and cubic octagonal strut, a 2x2 panel node-attached under the can, another 2x2 pannel attached end-to-end to that, and a FL-T100 tank attached to the bottom node of each panel, to keep it from sinking into the pad. Bill gets out, equips the screwdriver, and node-attaches the part to the top of the free panel) - - - Updated - - - If it's responding too slowly, you probably need more proportional response to keep it on target, and if it's overshooting you need more derivative response. I've ended up with something like 1.0 proportional 0.8 derivative to keep a huge plane flying more or less at the target pitch, maybe you could just adjust the scale setting.

I tried to take a look, but couldn't find the string "crew lost" anywhere in the 0.1.5 source. My ship was also launched without supplies, still under 15d MET, and reads "crew lost" despite having one non-orange crewmember who seems to be completely functional (or at least willing to go EVA) since power was restored.

I think I have a similar situation, except it's a non-orange Kerbal occupying the vehicle that reports "crew lost", and now that the power is on he is perfectly happy to go EVA and otherwise work. RoverDude, when you say you only need to pack supplies for trips out of the Kerbin SOI, do you just mean 15 days is enough for a round trip to minimus but supplies are still needed for bases and long missions?

I'm just getting into your mods and didn't have earlier versions, so I guess I'm okay. I assumed "deprecated" meant some old parts were included. The "Activate" and "Toggle" actions on the derp pod seem to be broken - they act just like "Disconnect", and separate the pod from everything else, including any service ring under it. Are any of the action group actions supposed to inflate the pod? ("Evacuate" does work properly).

Are there any files to remove if I don't need the old one? I didn't notice any.

Tewpie, if you used Pilot Assistant to fly the Scarab Mk2, what controller settings did you use?