Hupf

Kerbol. Not Kerbin I did some testing with the various heatshields. It seems to me that Skin Temperature of the Heatshield seems to be the limiting factor as the radiators only seem to take away the Core Temperature. Also. With a deployed 10m HS I seem to be able to get lower than with a 1,25m one. I'm a little confused here: yes it does have 3500 vs 3300 max Skin Temp, but shouldn't the much larger surface cause a far greater buildup (i.e. actual Skin Temp) in the first place? With the 10m one I was able to reach 70Mm Ap stable orbit, with the 1,25m one I was stuck at 80Mm IIRC. One other Idea, not tested yet, would be a highly excentric orbit (Ap around Eelo? :D) to minimize the time spent in the vincinity of Kerbol. Haven't done the math yet as to what the flyby time <70Mm would be then, though.

Why have RCS at all on a CommSat? For fine-tuning, I just throttle down the Thrust Limiter tweakable on the engine (which is an Ant for most of these sats anyway).

You have to actually meet all the sub-requirements before the "parent" is ticked off. So once you get a vessel that was put on the launchpad after accepting the contract in orbit of Jool and have a scientist and a pilot on board, then the "Vessel: Discovery One" node will complete (and I believe change to whatever that vessel's name actually is). I usually name my vessels according to the contract for my own convenience, so as to remember its purpose.

What are the exact Apoapsis and Periapsis numbers for each of the satellites? Did you try to get them into exactly the same orbits using HyperEdit and see if the problem persists?

When launching from ground to orbit, the delta-V required is not compareable to the resulting orbital velocity (i.e. display on the speedometer once in space). This would only be applicable when already in orbit and then doing a maneuver (you can try this out by calculating dV for a small craft, then attaching it wit a decoupler to a large booster stage to get it into orbit with all the fuel still there and then detach and perform a maneuver with the calculated amount of delta-v. You should then have enough fuel to finish it). During launch, much of the delta-v is "spent" for fighting against gravity and against atmospheric drag.

I recently bought a SpaceMouse Pro from 3dconnexion and got it to work. In my regular, heavily modded game, I then noticed a new bug that wasn't there before: when switching to IVA, the camera would be rotated 180° on the "pitch" axis, i.e. I would look at an upside down green kerbal face and the backside of the cockpit at hand (chairs etc). I could rotate from there with the SpaceMouse just fine, but the center would be this view and since rotation is limited to half a sphere, It wasn't very practical for flying vessels. After looking out of the window when on the ground, I also noticed that indeed the camera was fine, but the cockpit itself would be "upside down" i.e. point in the wrong direction when in IVA. On the external view, the cockpit is pointing "up". When switching to IVA, the camera is looking towards the sky. However the cockpit is not oriented towards the ground. Switching back to external view and everything is back to normal. So, then I did a bisection of all the installed mods to find out the one(s) responsible and I can reproduce the issue (or a very similar one) if all of the following conditions are met: @RoverDudes USI Tools mod is installed (on a fresh game from source https://github.com/BobPalmer/UmbraSpaceIndustries/releases/tag/0.7.4.0) The SpaceMouse is plugged in Prior to switching to IVA, I wiggle it around a bit to change the viewing angle on the exterior view. Steps to reproduce: Start new sandbox save create vessel with Mk1-2 command pod, small fuel tank and skipper engine launch use SpaceMouse to change viewport (rotate + zoom + translate) enter IVA (either by Keyboard "c" or by "View" on a protrait) observe the view outside the window being tiltet Logs: http://www.file-upload.net/download-11823738/kspspacemousebuglogs.7z.html (note: I did enter the "Fly" mode twice because on the first attempt, I skipped step 4 and the IVA seemed correct then) Video to show the effect: (note: The bug is visible from 1:34 on. Also this is a slightly different effect than on my fully modded install: the ground is only tiltet and not completely flipped around. I wasn't able to reproduce the full 180° initial rotation yet) System details: KSP 1.1.3 x64 (Steam) 3DxSoftware (64-bit Edition) 3.18.0 Windows 10 Pro x64 Version 1511 Intel HD Graphics 5500, Driver version 20.19.15.4300

Things you want to do, which may be done in separate maneuver nodes: Burn at Periapsis to capture in Eve's SOI (so that you change from a hyperbolic to an elliptic orbit). This does not have to reach your desired apoapsis yet, just enough so that you don't leave the system. Also, depending on the circumstances, it may actually be beneficiary to do the second step detailed below before this one - try out which variant uses the least dV in total. Plane change to match Gilly's. If you set Gilly as your target you'll see markers for ascending (AN) and descending node (DN). There, do an appropriate normal/antinormal burn. You conserve more fuel the higher the AN. So try out if it's best with an AN/DN in hyperbolic orbit (if it's still before Pe) or if you first want to do the capture burn and then align planes. It may even be beneficiary to set a maneuver node very early (say current position + 5m) and play around with the normal and prograde markers to effect inclination with a comparatively small burn. Usually a prograde component will assist the "turning" during a normal burn, but you may then have to counter it's effects later at Pe for capturing, so I'm not sure if this is useful here. For the encounter with Gilly, maybe try to use a reverse gravity assist, i.e. set your encounter so that you get into a retrograde orbit, so that Gilly will slow you down (a tiny bit, at least).

First and foremost, the IVAs are gorgeous, I love "<-- right is OUT | left is IN -->2 and also the vast amount of supported mods and their features (e.g. USI recyclers). One small thing I noticed: the various landing legs and the wheels, when the right click menu is opened, will always show the option "Extend" instead of switching to "Retract" when extended. They work just fine both ways though.

I forget if links work through Atmosphere (I believe they do), but what you would calculate is this: Kerbin's equatorial radius r = 600.000km So the satellites should orbit at Ap = Pe = (R - r), and from the picture above we see that at minimum R = sqrt(2) * r (because it is forming an isoscheles orthogonal triangle with sides r, r and R, so r^2 + r^2 = R^2). So we get Pe = (sqrt(2) - 1)*600.000 = 249km. With Atmosphere blocking transmission, it would be 278km.

Mission Report. After an evening of trial & error, it seems I've gotten it to work after initial problems as described by @tjt. System: Windows 10 64 bit. SpaceMouse Pro. The most important thing seems to be to use the " 3DxSoftware " driver (version 3.18.0, found under http://www.3dconnexion.de/service/archived-drivers.html after filtering for Windows 7), not the most recent one (" 3DxWare 10 for Windows (64-bit) "). You can (and should) use the 64 bit version of the driver (and KSP), if applicable. You may select a custom installation and untick all the optional components if only interested in KSP. With the old driver, you may have to launch the "Start driver" start menu entry. In KSP settings menu, the options under 6dof controller are greyed out (but can be configured in the file) and the input axis mappings don't show anything meaningful. However when launching a save, the first thing to notice is that one can roam freely (not just zoom back and forth) in KSC. If that doesn't work, check if all axes enabled in the 3dconnexion properties tool. I had the "only zooming" experience with the out-of-the-box installation of the most recent driver (3DxWare) in the default config (seems to be some sort of mouse wheel emulation also used in browsers etc). After enablilng all axes with 3DxWare, it would stop working altogether. One but I noticed however is that in IVA, the camera is flipped over

@bewing: I actually forgot to mention that mostly this poses a problem for me when in Target Mode (and not seeing the target yet) or deeper in space. The NavHud does exactly what I was looking for and on top of that looks ing awesome! Thanks for the hint.

Situation: in space with slow rotation authority. Wanting to point to any of the navball markers (e.g. Target, Retrograde...) manually. On the navball, I only see the markers that are currently in front of me, so I have to actually turn the ship (sloow) to find out where the others are (i.e. to find out which direction I have to turn to). Is there some sort of hidden feature so that I can "look around" on the navball prior to turning? I can only think of putting parts with "Control from here" ability pointing to various directions.

F1 will not display any confirmation. On Windows, Screenshots go to the KSP installation folder\Screenshots. For example on steam, this commonly is C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\Screenshots

Already been done:

You could always put a http://wiki.kerbalspaceprogram.com/wiki/Tail_Connector_B on the side of a 2.5m nosecone/adapter and rotate+clip it to your needs. For Size 0, I'd just clip an appropriate inline fuel tank attached radially by means of e.g. a cubic octogonal strut. Is it supposed to be aerodynamic? I'm not sure about the drag specifics with these kind of constructions. Is it still adviseable to put a small nosecone on the clipped end?

Numerics. http://www.math.cornell.edu/~demlow/425/chap5.pdf Physically speaking: for example, heat transfer in a reentry situation involves much higher temperature gradients (which are known a priori), so your error estimate will be several dW (pun intended) higher and a threshold would be in place to calculate this with higher precision. OTOH, if all physics is on single precision anyways, then of course this point is partly moot. The question of why GPU isn't used then boils down to: The physics engine would have to be manually re-implemented The data structures and algorithms are badly parallelizable as-is and would have to be re-thought Sooo... KSP 1.3?

Why not use a (non-PhysX, but e.g. OpenCL/DirectCompute/... based implementation) low precision physics simulation on the GPU whereever possible and recalculate (or estimate error a priori) results with double precision on the CPU if certain error margins are exceeded? I'm not familiar with how this would be able to be integrated with the Unity Engine, but in many instances of scientific physics simulation it boils down to find out which parts can be calculated with lower precision (the game already does this with the "on rails" approach).

Have you checked the RemoteTech options button that is available in the KSC screen? I think there's a global enable/disable option there.

There is the CleverSats Contract Pack mod which provides this type of contracts. Alternatively, you could mark them as Debris so at least they don't clutter up the tracking station.

Usually, the requirement to use the flight computer is to have a probe core attached to your vessel (e.g. in addition to your command pod), and to have some sort of connection to a human operator. For example, a crewed vessel with both a command pod and a probe core can use the flight computer even without a connection. Unmanned vessels need an antenna which is active (most are inactive at launch with the exception of the DP-10 and the Launch Stabilizer, so without Unmanned Tech you'll be stuck immediately) and has a working connection e.g. to Ground Control. You can specify for other Antennae that they should start extended in the VAB (works for Omnis, for dishes you can't specify a target here). I usually place a DP-10 somewhere on my boosters for this and extend the satellite's antenna after leaving the athmosphere. The OCTO should be supported by RT as it is a stock part. However it would also be my best bet that somehow your OCTO is otherwise modded and therefore not recognized by RT. If you're playing career, there might be some additional restrictions / tech you have to unlock first; but nothing comes to mind (except e.g. the Unmanned Tech which grants automatic 3km range antenna capability for all probe cores). Maybe try out the same craft in a sandbox save file, then try out different probe cores. Also, don't mind the possibly red color of the flight computer icon - just click on it.

Last time I used https://docs.google.com/spreadsheets/d/10ba8mrHmFVnjWnCaoyTgPB3pY1S4ab8ydDKO8q36sD4/edit?pref=2&pli=1#gid=1168863828 which was (among others) referenced in http://wiki.kerbalspaceprogram.com/wiki/Calculation_tools#Orbit_and_maneuver_calculators

Now that you mention it, might as well be a good old case of "cum hoc ergo propter hoc". I'm usually syncing my save between a laptop and a desktop pc, while keeping mods up-to-date with ckan on both. So after updating the mods on the desktop and continuing playing there, I noticed the behaviour and attributed it to the recent update (with all the changes in the mission control interface). I cannot definitely confirm that on the desktop, the SCANsat contract pack is indeed not installed until next weekend, but on the laptop after upgrading ContractConfigurator to 1.15.3 I could not reproduce the error. If anything else comes up after checking, I'll comment on the issue on GitHub. Otherwise it was an error on my end - sorry to have wasted your time then

Save file & fresh log: http://www.file-upload.net/download-11788820/FailedContract.7z.html Name of the contract: Multispectral Scan of Mun & Minmus

Could you be confusing the Nom-o-Matic 25000-I with the Mobile Processing Lab at the bottom? You can see the radial NoM 5000 at the very bottom of the craft.