Archgeek

So does this mean we can capture the Magic Boulder and shove it a polar Ike orbit ourselves? What's its ore concentration?

Scott Manley's video response to the "wrong end pointing towards space" video, followed by various "rocket science is dificult" videos around youtube, followed by a Steam sale. Around .18 if I recall correctly.

'Manually ran the numbers on the Xenon Tempest Mk 3 protoype: Spoiler for maths that belong in a spreadsheet: 44.14km/s minimum vacuum dv from the main drive system alone, using an un-optimized staging scheme -- this thing makes my previous designs look quaint.

10 minutes is a little much. You may want to check you don't have any unused network connectors in the background, like Hamachi or the like -- an old Unity bug makes KSP waste time checking every one of 'em until they each time out...per individual file. If individual textures, or, egregiously, flags are taking seconds to load, check that first.

...I think we just ninja'd each other.

You're very close. I get 2,756.36m/s myself, which is just about dead-on. The tutorial is being dumb, you want 9.81, not 9.82, which gets me 2,759.17m/s, but that's not much of a difference. "ln" is the natural logarithm of the number, the number of times you can multiply the constant 'e' by itself to generate it. It's called that because it happens a lot in nature, like with heat transfer and anything else whose rate of change is tied to a value that comprises it. If you're on Windows, change the calculator to scientific mode in View menu, or hit alt+2. "ln" will be just the left of the parentheses. You should wind up seeing things like ln(wet/dry)*Isp*g = ln(3.59/1.59)*345*9.81 = ln(2.258)*345*9.81 = = 0.8145*345*9.81 = 2,756.565 (again slightly different, but this time I was rounding a lot and re-entering values from the post).

I'd say, if you're refering to counting degrees/minutes/seconds of arc over which torque is applied, that you've almost got the right of it. Easy mode would be to just use time, though. Present wheel saturation as the persistent amount of time a wheel can apply torque on a given axis -- say a range of +/- 5 seconds of rotational accleration on each axis, presented to the player as a trio of bars labled pitch, yaw, and roll, matching up with the control authority indicators in the lower left corner, but available in a context menu on any part with a wheel (showing the sum for the whole ship in the resources tab and on the part with control). The bar starts with an indicator in the middle and numeric value +/-5.00s, the player sets the ship spinning on one of the axes for two seconds, that saturation bar moves to say +2.13s/-7.87s, then to +4.81/-5.19 when they almost but don't quite get themsleves stopped, then down to +/-5 when SAS settles down. If they want more torque to turn faster, they either leave the wheels off or use RCS and spin the wheels to saturation as a boost, treating them as a sort of torque capacitor. I feel this model would be quite intuitive to desaturate -- as soon as the player sees that torqueing in either direction moves the saturation indicator, it's a pretty small hop to think of moving it by hitting the RCS in the opposite direction of the torque. Throw in a couple of nice shiny buttons in the smarter probe cores to automatically desaturate the wheels in a "wet" (with a gentle RCS burn in the appropriate vectors, to preserve current rotation) or "dry" (spin down the wheels, letting them torque the craft as they will, good for perfectly halting a wheel-induced rotation without SAS's shenanigans) manner, and boom, they're Bob's niece or nephew.

I sense the problem is that at the speed in question, the window in which to do so is exorbitantly tight. Still, it doesn't take a lot of rocket to get a sounding probe up out of the atmosphere -- I'd say design a probe with antenna, thermometer and battery that gets just above say 71km in a straight-up trajectory (so that it loiters at the right altitude for a bit), put it on a cart in a cargo plane, fly that out to Jeb's Outhouse, launch it straight up, take and transmit the reading, and let the atmosphere scrap the ostensibly-cheap probe.

'Pretty sure you don't have to that anymore, with the advent of the "load and merge" option. Just save a launcher with an open node on top and number of stages in the description, design your mission craft, open the needed stages at the bottom of the list, hit load and merge on the launcher, and plop that sucker underneath where it goes.

Interesting solutions proffered here, but I'd say @Padishar's is best. In fact, I'd go slightly further -- keep an active port list for each craft, and on a physics frame concatenate those lists and set a tristate flag on each to -1 or some other value signifying "unchecked". Have the first port set itself false, then scan the whole list for positions and calculate ranges as per usual, setting its flag and that of the first port close enough to true if it finds one, else leaving its own flag false. Then the next port scans the list, skipping the distance calculation for the first, and so on, each skipping any port not unchecked, including itself. This way, for n active ports we only do the distance calculation for Gaussian sum of n, rather than n^2. Such that if there are 20 active ports in the scene, we do the distance calculation 210 times instead of 400, less if the magnetism needs to kick in, and if there are 100 ports open on some monstrosity, 550 instead of 1k. Of course, that little optimisation is dwarfed by the savings of using a port list in the first place -- 100 ports scanning every part in the scene is a lot nastier than 100 ports scanning each other.

Aw man, I never heard about that challenge. 'Would've loved to participate in it. I'm guessing nukes were off the table for the design?

They'd want to include one exception if they were to do that -- you'd want open ports on uncontrolled "debris" (say, reusable propulsion stages you forgot to put a probe core on) to re-arm somehow, and without control on the vessel, you can't quite do that. However, if we make this state more of a performance option and not an in-universe feature, we can make the exception that any open port targeted by the active vessel becomes armed.

When you wish televised or livestreamed launches would kindly put things m/s so you could have a better feel for what's going on, or mention stuff like delta-v to orbit or engine Isp more often.

Yeah, there's no way to search an area of space -- the game only has the list of parts in the scene, which happens to be the physics bubble. If it maintained a list of active ports on each vessel, then it could check each vessel's active port list for distance and save a lot of time. Them and the mk1 and 2 in-line ports, it turns out. That's about right, those and mk1 and 2 in-line docking ports that are currently retracted. Everything else is scanning the whole part list every physics frame.

I made a test rig that went shielded port => small service bay with a .jr in it => mk1 inline port => adapter => mk2 cargo bay with a .jr in it => mk2 inline port => adapter => 2.5m service bay with normal docking port in it => adapter => mk3 cargo bay with sr. in it => mk3 mono tank as a bulkhead => mk3 cargo ramp with sr. in it. Getting the data from the .sfs and figuring out which things were which by cross-referencing the .craft file, I wound up with this: dockingPortLateral (mk1 inline): Disabled dockingPort1 (shielded): Disabled dockingPort3(jr in small service bay): Ready mk2DockingPort:Disabled dockingPortLarge(sr in cargo ramp): Ready dockingPortLarge(sr in mk3 cargo bay): Ready dockingPort2: (size 1 in 2.5m service bay)Ready dockingPort3(jr in mk2 cargo bay): Ready It seems you were quite right, only the animated ports went into the disabled state -- the others were still active regardless of the state of their containers.

It was that or deal with permanent photosynthesis jokes. Sadly, it did not work.

*fingers held aloft in an 'X' pattern accompanied with a protracted hissing sound*

Woah, there was a squadcast again? Sweet, I'll have to go watch that.

Road friction's your friend -- it's how that torque becomees acceleration. You mean rolling resistance, and I'm not even sure where to find that. Granted it comes into play at speed, once you're just holding cruising speed against the wind and wheel bearings wheel stickiness becomes a slight loss, but I'd probably ignore it along with air resistance and just proclaim my result as the theoretical max. After all, I'm after the equivalent of engine vacuum dv.

Hmmm, sounds like I should set up and launch a test rig, then grep the .sfs to find out. Or would that be in the .craft? ...I'm likely to be back with results sometime after work.

...stupid question -- does the shielded docking port, or ports like it like the mk1 and 2 inline ports, do this search when closed? What about open ports in closed service modules, cargo bays, or fairings? If not, this'll change my designs a bit. I'm thinking shielded ports on construction tugs, no more jr.s on tugs meant to work with high-part-count ships, and shielded and inline ports as far as they eye can see.

It's also heck to programatically figure out delta-v for in a staged droptank configuration, isn't it?

Oooh, a bugfix line eh? I'll gleefully take a ticket. Let's leave a trail of green blood, shall we?

HEH, thank you for dredging those up. I was waiting for those to appear and put any nascent arguments to bed.

I've actually tried to calculate that. I went with the number of accelerations to ~67mph, to get me even sets of 30m/s as a yardstick when trying to explain it, with the idea being to get hold of the engine torque per unit gas, convert that to force on the road, and integrate a function of that vs the changing mass of the little 13 gallon tank over the time it'd take to burn it all (requiring I figure out the fuel injector specs/behaviour) to get total acceleration on a flat plane in a vacuum, but the numbers proved too annoying to be worth my while. Though now I wonder how much delta-v I could get hucking my burning fuel out a rocket nozzle on the back instead. I'm sure gas-of-the-line doesn't exactly get the best Isp.