diomedea

Thanks for this feature, @sarbian. Just did a couple tests, KSP 1.2.2 (1622), first on DX9 then on DX11 mode. I have two monitors, different max resolution (1920x1080 + 1280x1024). After enabling sideview (Numpad 0) KSP switches from window to fullscreen (or rather, borderless windowed mode at full resolution, as I'm able to alt-tab have another window on top), cursor position and monitor ID is shown top-left of the main monitor, the second monitor also switches fullscreen/windowed-fullresolution but is currently completely black apart for the cursor when moved in there. Moving the cursor around, the correct coordinates are shown; however display id is always shown as 0 with both monitors. Another thing, if I move the cursor while on the second (blank) monitor to the same coordinate it would be over some object in KSP (e.g., buildings in space center) if it was on the first, dialogs appropriate appear over the object; same for left or right-clicks. No crashes this far.

Believe you mean how to have the rover connected to the other vessel in editor (VAB/SPH). 1) build your rover, to include the part that will attach to the other vessel (docking port? separator?) 2) change the root part of your rover to that part going to connect (use the re-root gizmo in editor, 4 key) 3) save the rover as a subassembly (in editor, enable advanced mode, clicking the most top-left arrow button; find and click the subassemblies icon, then click on the root part with the rover and drag to the "subassembly drop zone", you'll be required to enter a name/description and the rover will be saved as a retrievable subassembly) 4) build your other vessel, planning for space where to insert the rover. If required by your design, have the corresponding connecting part (e.g. docking port) 5) re-open the subassemblies tab in editor, click on the saved rover subassembly, and bring it to connect where intended (Note: the editor will rotate the rover to face the same direction of the root part in your vessel, which isn't always what you would do, so use the rotation keys to align properly)

I'd say, if mushrooms had to withstand serious aerodynamic flow, they would have evolved in a drop shape too . More seriously, yes, long thin objects work best (due to limited cross-section and minimal drag from surfaces parallel to the flow), and having tear drop shape at the extremities greatly reduces front and tail drag coefficient (from the dragcubes geometry with the parts, cosine of the flow incidence angle with each exposed face, and the drag multipliers that mimic Reynolds dependency as a function of speed for different attitude). Flat surfaces worked the same as properly curved ones up to KSP 0.90, while the aerodynamic model was very primitive.

Hitting F5 while on the page you need to refresh generally works, but depending on your browser a force refresh could be required, believe this should provide some useful info.

Hi @DuchessVonKibble and welcome to the forum. I assume you wish to download one of the KSP 1.1.3 versions from KSP Store, as that's the only repository Squad controls directly. As I just tried with them all (from the Store) and all worked fine, could be you encountered a temporary glitch. Also, that "performing server migration" message is tied to days ago, so it may have remained in your browser cache if you tried to download at that time (you'll have to update the cache with your browser in case). If you're getting that message from another site selling KSP, you'll have to ask them in case the message persists.

Turbulence is somewhat modeled since KSP 1.0. Back then (and up to version 1.1.3) the debug window included a Physics/DragProfile tab that allowed to see what contribution to drag coefficient (Cd) the different faces would generate, variable with speed (in Mach). The profile with Tail (surfaces facing away from the air flow) was representative of the multiplier applied (or rather the divider, as it always seemed to go in reverse to me); that value changes mainly to represent the onset of turbulence approaching and beyond Mach 1. Of course nothing as accurate as using fluid dynamics models (which would be quite expensive to compute, though Ferram's Aerospace Research add-on makes a very good job doing as close as possible). (Have no idea why DragProfile was removed in KSP 1.2, but it was mainly used as a debug tool for the early versions of the aerodynamic model).

Could be OK if appropriate to a ongoing discussion, e.g. it helps others understand a concept.

They aren't listed anymore as a specific item in the rules (which is actually better IMHO, too many had different ideas of what a reaction image is). That means images appropriate to a ongoing discussion won't be questioned anymore for possible application of a rule that was never intended to curtail all ways of expressing a legitimate viewpoint in pictures. If the content isn't appropriate to a discussion, all of the rules in section 2.2. "Forbidden Content" apply to images too. What is objectionable with reaction images is actually described in those rules, e.g. 2.2.d about rudeness or harassment, or 2.2.m about unnecessarily boosting post counts, with something that does not contribute in any way and actually distracts from the true subject in a thread (if not even worse).

Thanks for your cooperation, however Unlicense (stated already in the OP) is a valid one, same as to declare it Public Domain.

Thread locked (again) due to author being unavailable since long and no ongoing discussion in the meantime. Will reopen at author's request.

As shown by that post you linked, gravity loss integral is a function in 2 variables (g, flight path angle); aerodynamic (drag) loss has 5 variables (speed, air density, drag coefficient, cross-section area to make Drag Force + mass). I'm not considering steering loss as a optimized launch profile would bring that down to 0. With a project I worked on, did polynomial regression on functions with 3 variables. It was mainly a question of method to get the correct poly factors, though a bit time consuming. In my project the functions were precisely known (I could compute the output from a large expression involving integrals and hyperbolic trigonometry), therefore sample data very accurate; yet the R squared from the approximating polynomials (4 terms with each single variable) wasn't always high enough (0.91 to 0.988) and the complete resulting polynomial in three variables (27 terms - 6th degree) could achieve R2 = 0.816 (enough for my needs but still way less precise than the original functions). I hope you can find a way to link some of those variables with drag to be mutually dependent (e.g. cross-section area and mass) so to reduce the terms and degree to something manageable. However the main difficulty I see is with sampling data, to find DV loss in a large enough set to be representative of different vessels, bodies, launch profiles used in practice. With enough accuracy in the measurement of each variable and DV loss to make each sample worth. GTC provides a measure of Total DV and loss of DV (for gravity, drag, steering) in the stats window. It is integrated over time during a whole launch, of course what required is the final result once in orbit. GTC mainly manages thrust to keep time to apoapsis at a precise value, while pitch isn't (currently) commanded other than for initial angle and when reference switches from surface to orbital, it otherwise stays as close to purely prograde as possible at all times.

Impressive! This is a very useful feature, thanks for implementing it . What I would like to see is, if a best estimate at DV is needed, if Astrogator could take advantage from other add-ons specialized in this. Probably MechJeb launch autopilot is fitting, but I'd suggest to verify the possibility to exchange data with Gravity Turn Continued (proceedings with GTC are very different and require some optimization steps, so values would be valid for only the specific ascent profile required and vessel used).

Don't want to show one specific link, as I have yet to find one where Unity officially took position on the issue (may exist, didn't find one yet myself). But Unity forum has a lot threads about such issues (e.g., https://forum.unity3d.com/search/7109274/?q=Mouse+polling&t=post&o=date ).

Ok, if you like, do this test. Have KSP in a window, so you can tab in and out of it. Have all your Part Action Windows (PAW, as the right-click menu with parts is called by the devs) open, and a way to see the FPS (like the performance tab on the debug Window, Mod-F12). As you noticed, the FPS drops (the more so the more controls on PAWs displayed, like blue buttons and sliders). Now tab out of KSP (Mod-Alt), and magically the FPS goes back to the maximum. Tab back in, the FPS drops again. What happened? KSP keeps updating values shown on the GUI, but doesn't accept any commands until its window gains focus back. The reason for all that FPS drop is with the polling cycle with each one of those controls on PAWs, at each frame the program checks if the user is interacting, that is only performed within an active window. Unity has a quite complex way to detect a mouse action with any of the elements drawn on the GUI (since Unity 4.6, older calls to GUI elements still work but often give undesired results) so each check to perform causes a drop in FPS. Should say KSP stretches Unity to the limits, the engine isn't really designed to have so many controls on the GUI at once. So, indeed this is a known issue, but can't be solved unless Unity changes to a more performant interaction model and KSP code is then changed to use that model (have no clue if this will ever happen).

If KSP load bar stops for a while then moves on again, chances are it's the assetbundles being loaded, as @Ultimate Steve reported. An easy way to check what specifically happened is to read the KSP.log file (in the root KSP folder), it includes precise timing for each single operation during initial loading. Just look for lines with "AssetLoader:", each single bundle is conveniently listed and comparing timings you'll know if one in particular is giving issues. If one takes way longer than others, chances are there's an issue with that file. Could be the disk is returning read errors, or the file is damaged. If read errors, would be better to perform a complete scan of the disk, it could be failing, anyway if bad sectors are found would be marked to avoid files being stored there. If a file is damaged, best to reinstall that specifically (method depends: if you use Steam, have the game cache checked and any file not matching will be downloaded again; if you have the zip from the KSP Store, you can extract that specific file from the zip). Or, you may wish to save on loading time losing the ability to consult KSPedia in game, just delete all files within /GameData/Squad/KSPedia.

Good question must say. The tracking mount and motors add considerable mass, plus motors and the control electronics may fail during a mission. Tracking dishes are therefore not that common on spacecraft, while they are almost mandatory on ground (and shipborne) stations. With communication relay, GPS/GLONASS/Galileo, weather, surface imagery and most spy birds in orbit around Earth, there is a specific attitude the whole craft must keep at all times (aiming at a specific spot on the surface), so the communication antennae are mounted to face that direction too. In most cases directivity of the antenna is low, so it has enough gain even if the station it should aim is distant a few degrees from where the main equipment aboard the craft must aim. Size of a dish is directly proportional to gain and inversely to the frequency used, that's also why many birds and probes in deep space generally use K-Ka frequency bands. If higher gain is required and frequency is high enough, instead of a dish a phased array antenna can be used (it has a lot of RF circuitry making it more massive than a dish, but its lobe can be aimed without moving the antenna, no need for a tracking mount). Deep space probes (e.g. Pioneer) have a communication antenna that is the largest piece of equipment aboard, the craft attitude is controlled to have that always aimed at Earth, apart when the scientific instruments need to be aimed at a body. Again it is the whole craft to track a specific direction, not the antenna. However there are cases when the craft is tied to a specific direction because of its mission, e.g. Hubble Space Telescope has a couple tracking antennae for communications. Rovers need a tracking antenna however to keep communication while a body rotates and they move around, like the small dish visible at the rear of Mars Exploration Rovers.

@AshleyFirewing: quite probably one of the .ksp files in GameData/Squad/KSPedia is giving issues. If you downloaded KSP from Steam, you could verify the game cache to be sure all files are good. Anyway, KSPedia files aren't mandatory, you may delete all the contents of KSPedia subfolder if you don't need to read KSPedia in game. To diagnose a specific file, you should turn verbose logging on in settings, then send the log. All the info required to diagnose this are in the KSP.log file (root KSP directory) that also conveniently shows timing for all loading operations allowing to know what causes delays too.

Nah, was my turn. but @UmbralRaptor is fine for me too!

Can't find what follows reported yet (if I missed it, sorry!). Parts with multiple docking ports, when at least 2 ports are docked, can bring to errors in KML. While such parts are not existing in stock KSP, they do in add-ons, I did test with the Command Module Hub from Tokamak Industries (Note: I have a recollection from times old multiple docking ports with a part were an issue in KSP, therefore highly discouraged; however the vessel I used in my tests doesn't raise any trouble (no errors, exceptions, warning in the log and debug console) and works finely in KSP). What I am seeing from examination of the savegame, a part with multiple ports has multiple "ModuleDockingNode" modules; each will have the dockUId field set to uid of the docked part; from the docked parts side, each has the "ModuleDockingNode" module with dockUId set to the corresponding part with multiple ports (so, dockUId can be identical for multiple modules in the save), however the "dockNodeIdx" field is set to a different index for each part. From what little I can get about how KML works, it reports an error due to checking correspondence of the uid, parsing data from only one "ModuleDockingNode" module with each part so failing to find the correct correspondence in case of multiple docking ports with a part. I'm attaching savegame and pictures of KML showing vessel structure (with docked parts) and data of the Hub.

Hi, had the same issue after updating Kerbalism to 1.1.9, the post below gives the rationale of the issue: Unfortunately only newly built vessels have parts set with the new values. Already existing vessels are not updated, scrubbers and pressure control still were set to a value = 1 with all parts. To salvage my ongoing game, I had to manually edit all parts in the savegame to match the "5/3 x crew capacity" value.

Back when I joined there was a short induction, so a more experienced moderator (not necessarily a senior) walked you in the rules and tricks of the business. Then I could still keep asking any in the team whenever in doubt, and get advice on each case as those came. Of course there was also a guide, that I was instructed to read carefully (which I did), and some principles written "in stone" coming from times old. Since the switch to IPS there is a newer guide showing how to do things in it, that's usually the first step for new mods. We actually keep a watch on new moderators, and often rush should they ask for help. When a more complex case comes, if they are around and not already on it, we like to get them involved so they can practice on it.

Hi, unfortunately no analog input from Steam controllers are recognized currently by KSP. Keys should work, but sure that's not enough.

Thanks for the effort. Should say my interest is mainly about a tool to automate what I do manually to get early intercept of asteroids out in solar orbit (example picture), but those are definitely not Hohmann transfers and you were already clear in your previous post this tool will only be computing such transfer trajectories. Indeed a R/V at periapsis is Hohmann-compliant, but that comes too late for most purposes. Also, as you correctly pointed out, KSP only computes and displays patched conics for selected vessels (asteroids included); definitely I need to have the asteroid targeted while manually tweaking the maneuvers, so KSP shows its future conics in different SoI (which is very relevant to allow matching inclination and LAN in my maneuvers while still within a planet SoI). I'm sure it is possible to compute maneuvers for a R/V out in solar orbit without need to have KSP compute the patched conics (there are tools already doing by using Lambert solvers, but none within KSP yet. Such solvers take time to find solutions, which probably makes them unfit for your tool).

If the idea is about an optical telescope, KSC would be the worst place on Kerbin. Very low altitude and close to the sea, also equatorial, therefore thick atmosphere and high humidity. Much better to install optical telescopes on a mountain plateau, out in a dry area. Thinner atmo and no condensation allows far better resolution with images taken in the visible band. Even more so in UV and X-ray bands. Radiotelescopes are a different thing, absorption and diffraction at those frequencies by the atmosphere is very low. Still, the farther away from any powerful radio transmitter, the better to minimize interferences. KSC of course holds the most powerful known radio transmitter on Kerbin.... (My idea, telescopes could be made a thing using Kerbal Konstructs add-on to have them in far away locations).

Thread moved to Add-On Discussions (reason, unfit for Add-On releases being not a release). I'm not currently seeing download links, but links to redistribute copyrighted material (where their license doesn't allow redistribution or derivative work) will be deleted without delay.