diomedea

Steam uses a very good system, as it downloads only the files changed from one to another release. It is certainly possible to know, comparing files, what is different from the original (steam synced) KSP install, against any folder you copied elsewhere (one tool allowing to compare files across whole folders is WinMerge, but others certainly exist). Comparing tools should also allow to automatically update all newer files, at least in one direction (e.g. from the steam synced to other folder) and effectively would only copy those files, as you desire. However, KSP installs aren't that large to really require file diff techniques, IMHO copying the whole content of the synced steam folder remains the easiest option.

OK, tested with the situation in the persistent.sfs from the folder you provided. That space station has very little EC initially, so the antenna can't complete transmission. The new mechanic about Science transmission should prevent data loss and restore Experiments, in case of interrupted transmission (unless partial is allowed). However, with your vessel that doesn't seem to work correctly (going to report this issue so it can be dealt with in future). I'd advise to either wait for enough EC stored with the station, so the transmission can be completed, or to use the "review data" button from the mobile lab action menu, and transmit data from the menu that appears. I tested and found both the above work correctly.

Weird you're having that. Small-step rotation (5°) still works fine here with the Left Shift key down (not the Right Shift key), and have heard nobody noticed such issue during 1.0.5 testing. Would be interesting to know what caused your issue, sorry have no better hint to be of help .

Please upload a savegame and provide specific directions (if needed) to allow us to recreate your issue .

KSP includes more features with every release, and often improves the accuracy of existing ones. But sure that has a price, more CPU cycles required to handle all this. Low framerate can be either caused by the physics (the engine takes too long to complete complex computations) or by graphics (complex scene to be rendered). Given what changed in 1.0.5, I would bet the issue is with physics. There is no magical solution to this issue. Some improvement can be expected by changing the "Max Physics Delta-Time per Frame" setting, a best value for your system may be found. Real improvements are expected with KSP 1.1, where multithreaded physics should be a reality thanks to the new Unity 5 engine. But in case you noticed some signs of downgrade (relative to 1.0.4) that could be tied to a specific problem, more info would be needed to determine what is the cause: could be a routine is taking excessively long and could be optimized to perform better thanks to the info you may report. In that case, would be helpful if you uploaded a specific game situation (a savegame when the issues occur) and provided directions to recreate the situation from that savegame (e.g. enter flight mode with a specific vessel, do some specific action with that vessel). Could be useful to also provide your settings (upload your settings.cfg) and output.log (from KSP_Data), provide info about your system (CPU, RAM), could upload a pic of the KSP screen when framerate issues are occurring with the debug menu open (Alt-F12) and the performance tab selected.

At last. That's something I hoped for the last time I posted in this thread.

Actually, the link you posted above goes to the KerbalStuff page of the mod (perhaps that's what you call the file browser), not directly the download. KSP Mod Admin (KSP MA) actually expects links to be from those mod pages, to apply version control comparing info it has with what appears on those pages. You can use that link indirectly, in KSP MA, with the "Visit version control URL" buttons; that info is actually required for the "check for update" functions in KSP MA. To download a mod from KS, you need to use the link to the download page (e.g. for that mod is https://kerbalstuff.com/mod/352/SpaceY%20Heavy%20Lifters%20Parts%20Pack/download/1.4) accessible from the page linked. KSP MA does the same when a mod needs be updated using KS as source, it retrieves the download link from those pages. KSP MA will do so when e.g. commanded to "update mods".

Good find, I am observing the same. An almost identical bug was observed during Experimental testing months ago and solved, somehow this came back and wasn't spotted earlier this time. Going to make a report, hopefully will be taken care.

Please know we moderators are under a non-disclosure agreement about coming features. Even in case we were actively testing them for the upcoming release, no hint should be given. There's actually a good reason, developers know all too well features they are developing can be scraped even at the very last moment, often because tied to a major bug which requires a lot longer to fix than the time left before release. Or, because their efforts had to be diverted to something more important. Any feature announced can be source for serious hype, but if not delivered that turns into bashing. Squad employees are the only who can make such public announcements.

The information reported isn't enough to really help and I can't find any previously reported issue about joystick axes not centered in KSP. There was some about axes bindings, but your issue seems different. KSP itself has no settings about centering axes; what couldn't be otherwise, as not even Unity allows any setting regarding axes centering. Given the above, the issue would normally be found in your system. Apart from the very axes position signal the joystick sends, the information is processed by the device driver, DirectX Input, and (if exists) any joystick software able to "correct" the center position. Unity and therefore KSP would only see the axes values after all the processing by those software layers. I would bet you already checked the center axes issue only occurs with KSP, and isn't present also with system software (e.g. the joystick control panel). Actually, because of the mismatch you report about the actions performed, I have a suspect another input device is registered with your system, and for some reason it "fights" with the joystick. Each device has its own identifier with the system, but Unity just lists them by a single number, e.g. INPUT_DEVICES { <name> = 0, 1, ... }. If for any reason you registered the KSP settings with one configuration, and then the configuration changes (you attached or detached an input device), KSP may get confused and use the wrong device number. This is one issue going to be fixed soon. So, in case, please try keeping the same input devices while registering settings and playing KSP. In case the above has no effect, we need more info about your problem: - make and model of the joystick, version of its drivers installed; - version of the Operating System; - DXDiag.txt save (should you need help with that, start "DXDiag.exe" from the system command, save info with the button at the bottom of the DXdiag window); - KSP/settings.cfg (that file is renewed at each KSP start, upload a copy of when the issue is occurring).

Short answer: No. Longer answer: It can't be excluded that modifications may be created so to allow them to work with the KSP Demo (but, would be a violation of the terms of use). The KSP loader that fetches all dll plugins when KSP is started, doesn't work with the Demo; therefore none of the existing plugins can be run with it.

Shouldn't be hard to solve. All settings are stored in a single file within the KSP main folder, interestingly named "settings.cfg". A pristine install of KSP has no "settings.cfg" file; it is created on the first run, and actually updated each time KSP is started. So, to "reset" all settings to factory defaults, you need to do nothing more than delete the "settings.cfg" file. If however you saved other settings that you may wish to retain, and the issue is only about the screen resolution, you may edit the file (it is a simple textfile, can be edited fine with notepad). The resolution lines, and the default values with a brand new install (so you may put those values with those lines) are: SCREEN_RESOLUTION_WIDTH = 1280 SCREEN_RESOLUTION_HEIGHT = 720

Bodies.ini has the SMA and GM values for each body, but indeed not directly the orbital period. Orbital Period = 2 * PI * √ (SMA(x)^3 / GM(y)), of course the gravitational parameter GM is from the mainbody, the SMA is from the actual body you want to compute. E.g. for Kerbin: SMA(kerbin) = 13599840.256; GM(Sun) = 1172332794.832490700 (data from stock KSP and KSPTOT, but the equation works with anything); Orbital Period = 9,203,544.6175 s

I also tested the Jumpo 4. Nice plane. Have to completely agree with the comments above. Without struts, the ISRU (being that heavy and far away from the connecting port) moves within the cargobay. A slight pitch control applied was enough to cause instaboom (first message shown in log, ISRU detaching from the large RW aft, certainly the RW touches the bay frame while the ISRU mass * lateral acceleration is more than what the joint can stand). After strutting the cargo, I could easily perform some aerobatic, the plane is quite maneuverable; see a 14+ g turn here:

Had to remove a bunch of posts that were derailing this thread. I invite everybody to not stray into contentious subjects, KSP is not the place to stir users into reactions.

Can see the in home streaming comes from Steam, KSP has nothing really to do with it. Probably that's also why other users don't report issues with the Play button, if they don't use in home streaming. Can't see a way to install a KSP beta (or even alpha) through Steam. The only possibility is to choose the previous "stable release" rather than the current one, but it's already 4 releases since KSP went out of beta. It could be possible to ask Squad for a beta release (against proof of purchase for KSP) and the zipped file would be made available to you, but not through Steam. Can't say Steam would allow such KSP copy to be run through its streaming system, if even a copy out of Steam itself has issues. Sorry to not be able to help. Hope Steam/Valve listens and solves the issue.

Hi Gothraga, well, can't really say what the prob is about the Steam Play button. But sure it doesn't depend on KSP, it's with Valve. And I can't even find the issue, that Play button works fine for me. However, please know what follows: unlike many of the games distributed by Valve, KSP runs on its own = has absolutely no need to be run from Steam. You can even take the whole KSP install folder from the SteamApps library, and move anywhere on your machine: KSP will still work just as fine if launched through its own launcher.exe or directly from KSP.exe (even if those are run through a link you may create yourself). And actually making your own links is the best way to allow for customization of how the game can be run (allowing any of the Unity CommandLine Arguments to be associated with the link).

Yes, sort of a training period, every senior mod is helpful and keen about what the new moderators may have trouble with, full of good advice and happy to let them test and improve their skills. You all confirm junior mods, right?

A lot of work was done to properly balance drag and the atmospheric properties for KSP 1.0 (and improved for 1.0.4), to ensure a successful slowdown with command pods. Just rechecked, and can confirm it still works, a Mk-1 pod + mk16 chute reentering vertically from 100 Km altitude, by itself stabilizes with the bottom down and slows to a safe speed at about 3000 m ASL, good for opening chute and slowing to safe descent speed 500 m ASL. About exactly the parameters by design. However, tested again attaching the science module at the bottom of the Mk-1 pod (what I believe is the configuration in the OP). The science module is very light (0.2 tons) compared to the pod (0.84 tons), however has a larger shape and therefore drag cube: it exerts more drag and that is enough to make the vessel sink nose-down. My test showed the nose-down vessel couldn't slow enough when reentering vertically from 100 Km, and that's certainly due to the lower Cd in the Vt equation. Sorry, but that vessel configuration doesn't allow a safe reentry. The drag coefficient (Cd) of the pod changes with attitude, tip Cd of a conical shape ~ 0.5 while tail Cd is ~ 1 (actual Cd also changes with Mach speed, Reynolds number). As others suggested, changing attitude to present a wider area (A) to the flow works to slow down more, and that also gives a larger Cd. In my very early career flights when very few parts are unlocked, I use basic fins on the sides of crafts, perfectly balanced to achieve neutral stability, and steer the vessel to present those fins to the flow and increase the area and therefore drag: works very well.

Indeed, opening multiple unwarranted threads on a same subject is a form of spam (and community rule 2.3.a applies in these cases). Also, it steers away from an already opened thread, fragmenting discussion. Please keep discussion on the first-opened thread on the subject. This one deserves closure.

As you may note, there is a whole section of the forum ("Modelling and Texturing Discussion") about the subject, plenty of help (and helpful modellers look there and are able to help further, in case you still can't find what you need in one of the many threads already opened). Of course your topic was moved in there too, as it is where it belongs.

Believe the concept of "terminal velocity" is what you need: Vt = sqrt( 2*m*g /(ÃÂ*A*Cd)). As the vessel sinks in the atmosphere, it encounters air with greater density (ÃÂ). Unless the ratio of mass/projected area (m/A) of the vessel is too high, or the whole atmosphere is not dense enough compared to gravity (g) (e.g. Duna), it will slow down enough due to increasing air density for a safe chute opening (in the range of 250 m/s). Keep open the chute window (right-clicking on it) to read if is safe to open or not, when speed is down enough it will show safe and your chute won't get destroyed.

Fairings are perfect to make a shroud. In the pic below, fairings are shrouding the command pod, the fairings base (obviously reversed 180°) atop a decoupler and with the LES topping it. Proven to work.

That link works perfectly fine. If it doesn't for you, it's an issue on your side, e.g. your firewall may be blocking it. CKAN may not work for a wide number of reasons, one being that link is about a MM version not officially released (therefore not yet indexed in the metadata).

Within the KSP install folder you'll find a "saves" subfolder. For every game you start, you'll find a sub-subfolder in it by that game name. What you need is just to copy the savegame (persistent.sfs) from the subfolder, but clearly you need a similarly named sub-subfolder in all PC. Copying the whole sub-subfolder (including ships) seems a easier way to keep games synced.