cfds

That happens when you use the Multispectral Scanner on a planet that does not have defined biomes. As soon as the devs implement biomes on this planet, ScanSAT will show results.

Skycranes? Pfff, you keep the landing stage below the rover, land upright: And then tip over:

Getting the parameters of the new ellipse from distance from the focal point and your momentary velocity is doable. But the problem with ellipses is that calculations of segments of arc or area have no analytical solutions. So you are restricted to numerical methods to find flight times and similar things.

In my game, O2 seems to be consumed on unloaded ships (and CO2 builds up due to the mentioned scrubbers bug).

I believe there need to be multiple science pools for some experiments. Let's take surface samples from some biome with that can be "milked" for some total amount of science points. We can now split the total science in the following pools: - 10% for a kind of crew report of the sample in its natural environment ("It looks gray and crumbles when I grip it too hard."), turned into data and transmitted full - 20% for basic analysis in a lab (automated or crewed), turned into data and transmitted full - 70% for detailed analysis that can only be done on Kerbin Returning the sample to Kerbin should drain from the last two pools. Exposure examples should take a different distribution: - 40% for automatically gathered data that can be transmitted fully - additional 40% for crewed experiments - 20% for recovery (since we do not learn much new stuff when we have returned to Kerbin) With this technique we would circumvent the "repeatedly transmitting devalues recovering sample" problem and encourage manned missions for exposure experiments. Thoughts?

Using jets as the initial stage for an orange tank lift can look surprisingly elegant: In 10km height I shut down half the jet engines and in 14km the whole thing switches to rocket power.

This a very nice mod, great work e-dog. I only have a small feature wish: could it be made possible that the "toggle fuel crossfeed" of the interstage adapter can be accessed via action groups? Up to now, only right clicking on the part works. On a related note: what does "Decouple" do with the interstage adapter?

Your ideas for an improved science system are spot on. I especially like the disposable experiments, it would add some purpose to permanent space stations. A big part that, as of yet, is completely missing is the cornerstone of every space program ever: taking pictures of celestial objects. I expect cameras in the future, SQUAD guys!

I believe the "LOCK TO" code breaks a bit further with every new version. In 7.0, every LOCK TO that isn't locked to altitude seems to stop working as soon as any loop or wait is started. And it sounds as if the problem got worse with the 0.8x series.

Ok, so the reasons why it will not work are bsically the folowing: - It doesn't work for wings, canards and the like - It would be better than the stock implementation for basic rockets and generally non-wing parts but causes too much work for the CPU

Sorry to drag this Thread up form the grave, but I have some questions: Why is "Drag and lift highly inaccurate at relatively low speeds (V < 500 m/s)"? Is this a problem of the raycasting algorithm? I don't see how the exposed area of a rocket should vary with the speed. I also don't get the problem with the lag. Essentially, you are taking a picture of the craft from the direction in which it is traveling. This should by in no way take longer than the actual drawing of the vessel (unless it is a problem with unity) on the screen and you probably don't have to recalculate the exposed area 25 times a second. What is the problem here?

Personally, I like the idea of procedural parts with snapping to standard diameters and lengths. Apart from the part clutter, it would solve the problems of the wacky lengths that the parts have now...

Motokid, KSP itself means by "stage:liquidfuel" all fuel that is available to the engines that are active in the given stage, not the fuel that is in tanks that are separated with the next staging.

I tested the new release and I think I will revert to the old one, at least until the bugs are fixed. Even the most simple of constructions, two vehicles connected via the winch, tend to spontaneously combust. In my first try, just grabbing the winch and starting to walk was enough to blow up my "fuel truck". And @RuBisCO: please do not test wenches in public forums, there may be minors around

As long better is possible, good is not good enough. Besides, the main problem is that LOCK TO does not work reliable with loops or wait statements, and that should be fixed.

kOS seems to have some really weird problems with LOCK ... TO. The following code is a first step to an autolauncher with thrust adaption against drag losses. set lsPitch to 90. lock steering to heading 90 by lsPitch. lock throttle to 1. stage . lock lsVel to velocity:surface . //lock lsSpeedSq to ( lsVel:x*lsVel:x + lsVel:y*lsVel:y + lsVel:z*lsVel:z ) . //lock lsSpeedSq to ( verticalspeed*verticalspeed + surfacespeed*surfacespeed ) . lock lsSpeedSq to verticalspeed . print lsSpeedSq . lock lsAngle to verticalspeed / (lsSpeedSq^0.5) . //local gravity, will be more dynamic later lock lsGrav to 9.81 . set lsDragConst to (204.4 / 0.2 ) . lock lsPress to 2.71828 ^ (altitude / 5000) . lock lsTermSpeedSq to lsDragConst *lsGrav * lsPress . lock lsTermThrottle to 2 * lsGrav * mass / maxthrust. print lsSpeedSq . when altitude > 9500 then lock lsPitch to 83 - (0.5 * ((altitude - 9500)^0.5)). when altitude > 25000 then lock lsPitch to 20. when (verticalspeed*verticalspeed + surfacespeed*surfacespeed) > lsTermSpeedSq then { lock throttle to lsTermThrottle. print "Too fast!" . }. when altitude > 1000 then { print altitude. print lsSpeedSq. print verticalspeed*verticalspeed + surfacespeed*surfacespeed. print lsTermSpeedSq.}. print lsSpeedSq . wait until altitude > 50000. toggle sas. The problem is that the lock on lsSpeedSq, based on verticalspeed (or velocity:surface), stops working as soon as the WAIT UNTIL statement starts. The lock in lsTermSpeedSq (and by extension that on lsPress) works perfectly, as can be seen with the debug at 1000 altitude: lsTermSpeedSq has the actual value, lsSpeedSq has the same as in the debug PRINT right before the WAIT statement.

Requimrar, I guess the problem you describe is caused by the fact that KSP sees the two ships now as one object with one barycenter but ignores that they are not rigidly connected to it. SAS and RCS try to turn around the center of mass, assuming that the connection IS rigind and fail.

I guess the only way to prevent ground based objects from exploding is to set them on landing struts.

Loops with only a WAIT statement are ignored by KOS. Perhaps something like until 0 { wait 1. set ix to 0. }. will work better.

What qeveren said: supercavitating subs are far less useless than you'd imagine. The most simple countermeasure are probably good, old fashioned mines. The sub has next to no chance to detect them and even the tiniest interruption of the steam bubble will make the craft disintegrate...

I would like to see tweaks to the lengths of the stock parts. Why not make the FL-T400 exactly 1.5m instead of 1.502552m? Generally I envision the following set of "allowed" lengths: For short parts (<1m): 0.1, 0.2, 0.25, 0.4, 0.5, 0.6, 0.75, 0.8 For medium parts multiples of 0.5m: 1.0, 1.5, 2.0, 2.5 For larger parts only integer meters: 3.0, 4.0, ... That way one can easily combine different parts to structures of a given length, for example to build space stations. [Edit for clarification] With "length" I mean the measure along the axis of cylindrical and conical parts, not the diameter.