NathanKell

You can do either. Both ways are supported. Also, Labs aren't science containers. They're transmission destinations. So the collect/transfer science mechanic does not, and will not, work on them.

When we go to pre-release there will be docs, yes.

It's been awesome, Kasper! Incredibly sad to see you go, and the absolute bestest of wishes in the future!

1. We have no plans at the moment to make use of upgrades. That is for modding support. 2. Who said there were only three tracking stations? I only mentioned two stations' names on-stream, but I did not say how many there were. That's for you to find out.

Sorry, exps. (This is also why I have weeks-old PMs unanswered)

@TiktaalikDreaming Ah, gotcha! Yeah, streaming part 2 atm--I notice that the A10 engine's mass is the same as the A-4 engine's, which seems...optimistic. I'm assuming a nominal 5 tonnes, and also putting the mixture back to Ethalox since I can't imagine them getting 247s off kero and nitric acid--did they later change to acid and kero (like the early Soviet storables attempts)?

So, on a lark I decided to dry doing 1940s Space Program. Did the first ep (an A-9/A-10/A-11 satellite LV, getting 1 tonne into orbit)* without the aid of this, figuring I'd best try this out now. How's the RO configs? *I link because I figure anyone in this thread would probably appreciate it. Also, on the ramjet--saw you said you had some issues configuring it. How so? The stock curves should serve fairly well, it should have a slightly kinked atmCurve and a velCurve something like key = 0 0 0 0 key = 0.29 0 0 key = 0.3 0 0 then the regular curve going up to max at Mach 5 or so

Terrain "squishyness" or floating above the terrain is an RSS issue where due to float imprecision colliders and visuals don't get the same displacement from the body center. Revert to launch and that should clean it up.

No, they should not require changes beyond slight cfg tweaks at most. We're certainly not going to be introducing a whole new system...

Quick note here: I've been insanely busy with 1.2. Raidernick has been doing a great job updating stuff, but help is needed updating the landing legs, that's the remaining stuff that doesn't work in 1.1.x. (unless I'm out of date.) So...halp?

Sorry? We just use Kopernicus like everyone else...

Anything that reports it is shielded will not contribute buoyancy.

The point isn't the ship, any of us can slap together a ship with a bunch of parts. The point is the save. Actually having time to get the ship to a good resource spot (ascent, transfer, landing, etc), getting it all set up, verifying it works...that takes time. The reason for good reasource coverage is so the amounts transferred on the resource network are actually high.

@Cunjo Carl @DoctorDavinci Looked at the saves and craft in question. I think I'd best specify a bit better. Sadly, >500 parts (and probably >1000 parts in total in physics range) does not lead to enough FPS in the Unity editor to be useful in profiling. Also, the part that I really need isn't in the saves (AFAIK given the descriptions). So let me try to narrow down: 1. a 300 part single vessel which has multiple drills, converters, fuel cells, and radiators. 2. A close cluster of 3 or so 100-200 part vessels (or 5 50-100 part vessels, say) with the above. 3 (most important bit) actually placed where they are drilling resources and converting well, preferably on a place like Mun or Minmus but a larger place also works. A full-up in-action save, if you will. In fact, other vessels in the save's persistence are fine, the idea is to get a good sample of actual in-use ISRU but at the stressier end than a single one-or-two-drill vessel. Does that make mores sense? Thanks again.

I'm happy to change the low-end mass calcs to match better the old values if the old values are more accurate for small fairing bases/interstages. I also need to redo the start of the campaign at some point to comport with the upcoming RP-0 changes to the tree.

Apologies. I have not had a chance to pore every post in the thread. Has anyone posted a pure-stock save with a resource mining base with multiple craft doing resource mining in a small area? And/or one craft with many drills and converters?

You may be interested in:

@Iamsodarncool The relative gains should be correct; the difference is that the absolute numbers are very off (1.1.3 is way faster than running that codebase in the 5.2.4 editor, and 1.2 will be way faster in a build than when running in its editor).

They weren't even builds, they were running in Unity itself.

As I mentioned, the numbers in the file are created by rendering the part onto a 256x256 canvas, once each per the six sides. (Area is computed by number_of_opaque_pixels / (256x256), Cd is computed by sum(normal at each pixel) / (256x256), etc).

Making a config is fairly simple if you have a BHP-vs-altitude curve for static and for at-speed (i.e. with ram air). However, all the prop data needs to be updated now that FAR is updated, since many of the props have custom thrust based off old-FAR drag.

Because it needs to occlude what's above and below it in the stack. Otherwise the drag system will think their ends aren't fully occluded. The numbers are as you say, area/Cd/depth in six triplets, then center, then extents. On scaling, it goes like this: X: y scale * z scale for area, keep, X scaling for depth Y: x * z scale, keep, Y scaling Z x * y scale, keep, Z scaling Centers and extents get linearly scaled in each axis. Regarding the questions, drag cubes are rendered using 256x256 textures, so the numbers won't be all that perfect. To keep things in line with other parts, that's why I suggest letting KSP generate them for you and then tweak, rather than creating them from whole cloth. Depth is as you surmise, it just sounds like there's some kind of render issue. It's used for thermo occlusion (to know what parts are hiding other parts, you need to know how wide the part is at its widest point, and how far back that widest point is from its tip). Drag coefficient is just the average dot between the face normal and the inverse of the camera axis. So a hemisphere would have 0.25 here, because the average across its face is 0.25. A plane has 1.0 because its normals are perfectly aligned with the camera axis. A cone or wedge would have cos(halfangle). Etc.

Yep, very much the best it's ever been

Aha! I guess when we redid the masses they went up slightly at the small end, albeit down a lot at the large end. Sorry!

Remove the custom drag cube entry, let the game generate one for you. Then when everything else is done, add a copy of that as the custom entry and edit the Y+ and Y- areas to be the same as a circle of that diameter, rather than a torus (i.e. pretend the hollow bit doesn't exist).