diomedea

Thread locked per OP request.

Whenever KSP shows issues at loading time, I find useful to read the KSP.log file (created by KSP each time it starts within he root KSP folder). Mind uploading it (in whole, do with a online service e.g. Dropbox) and link here? Hope to be able to get what KSP is stumbling on from info on that file, of course you could still go with all the suggestions here.

What is unclear in the challenge as stated " You will have to launch an uncontrolled vessel from a mothership orbiting Moho " ? Doesn't seem your question doesn't find answer. However, please show us you can do from orbiting anything else, even Sun. It's up to you to show how skillful you are, we are waiting to cheer your success. And maybe even your failure, if well done.

Exactly this!

It's to you, and to anybody else, to try and find ways they like to meet the challenge. However if the probe isn't in orbit while the ball is launched, you're not really following how the challenge was set up. Being in orbit, means it is required its periapsis is higher than the body surface.

That makes the mothership be not in orbit, but at most on a suborbital trajectory going itself to impact at the hole location. If that was allowed, would be same to have the mothership just "drop" the ball while flying stationary a few meters above the hole: not orbiting. Please let me know if you can devise a way to throw something at the hole while even outside Moho's SOI, but still not having the mothership directly aimed at the hole itself. I bet that's possible, but would require more skill than from within the SOI. Please allow me, though I'm not "Squad staff", to show this challenge was successfully tested. Did this days ago, I refrained to show before as my method makes things pretty easy and would take away some of the fun. Oh, should someone be concerned, I enabled the "No crash" cheat to have the "ball" be intact inside the hole and allow to take the final pictures.

Making a artificial hole on Moho by slamming a impacter on its surface at several Km/s could work for another challenge. Believe for this one the requirement is to get in the already existing (and widely known) Mo-hole. Seems hard enough to even exactly overfly the location, given its latitude, coming from any interplanetary uncorrectable orbit; I'm curious to know how you plan to make that.

mhh, @Deddly's around perhaps?

You just choose one of your liking, the License Selection Guide gives good advice, but should you need further info, there's plenty on the web (websites for GPL, CC, MIT, and all others are full of info); if all the above still comes short, you may still require more info here (even in PM).

The optimal hop is the one that requires less energy. With the hypothesis of perfectly spherical body and no rotation, all energy involved in the hop is the kinetic energy at launch (and conversely, at landing). Kinetic energy is function (given mass of the vessel a constant) of only speed2, so the elliptic trajectory characterized by lower speed at the point of launch is your solution. As shown here, at any point in a elliptical trajectory v2 = [k/p](1+e2-2 cos(θ)) (k = MG, p = semi-latus rectum, e = eccentricity, θ = true anomaly)

All the above answers are giving good advice. Ideas in themselves are not covered by a license, that is used to protect actual work. Ideas are protected by patents (in general, meant to protect intellectual property), though have to meet requisites to be granted a patent (e.g. novelty, usefulness, non-obviousness). Indeed a number of ideas have been covered by patents in IT, and I would not exclude some in add-ons could be patentable too. But while our rules require a license be stated for any add-on (even a non-license, what is important is the author lets clearly know what rights he wants to grant to others, so his work can't be used without consent), there is no requirement to patent ideas, and so far no modder I know here showed to have made one. On the other side, a few modders have clearly stated what is in their add-ons is their own intellectual property, and so far I have always seen such statements respected in this community. On yet another side, it could well be an idea came from someone who we don't know about, but a modder found it and liked to implement it in his work. As suggested already, I would always give credit to the original author who first showed a specific idea (though, such idea could not always have the patents "requisites", e.g. may not be a novelty if not within our community). And before using one idea, I would try to contact the original author and have his approval. But because ideas are not registered unless patented (or at least there's a formal statement we could use to track one to an author), lack of evidence about ownership doesn't mean the idea can't be reused (contrary to all published works by community members, where property is evident in itself and lack of a license means no rights have been granted to reuse the work).

Don't have a sure recipe for this. KSP is one of those games that seem to perform better in Windowed than fullscreen on my machine too, though fullscreen here isn't as bad as described in the OP. Googling for evidence on the issue, couldn't find any who shows to have a clear idea about what causes performance differences between the two modes. But differences are frequently seen, in some cases (with some games) better in fullscreen, with others better in windowed. The only thing they seem to agree is in fullscreen the game gets full exclusive control of the GFX to pilot the intended display, while in windowed all output is mediated through the OS, the window acts as a graphics buffer, which should be of help to reduce artifacts. However, a few sites (e.g. here) also report about fullscreen and V-sync. If I get that right, windowed has V-sync off by default, but when fullscreen has it on, it reduces performance (measured as FPS), which could be seen as stutter if FPS goes very low. Could be that helps with KSP in the OP case too.

Guess the tundra orbit is inclined 110° to the equator (KSP doesn't really handle axial tilt of bodies, in reality Earth has 23.4° tilt and orbits could be defined in relation to the ecliptic instead of the equator as a reference plane; if this was in relation to the ecliptic the solution would require a different approach tied to spherical geometry). What is required is to launch, at the correct azimuth (which is already known, e.g. using equation here) when the launch location lies on that orbital plane (or rather, just a bit before, to allow for the amount of time while ascent brings to match inclination with the orbit from the initial inclination = 0°; generally by the time a vessel gets suborbital inclination is matched, the burn to bring to orbital speed shouldn't change inclination). Knowing where an orbital plane crosses the equatorial plane is easy: the AN/DN nodes of the orbit give that. Should the launch location lie on the equator (kind of like KSC on Kerbin), one needs to wait until the hour angle of KSC matches the LAN (for a launch at positive inclination) or the LAN+180° (for launch at negative inclination). For a launch location at latitude, one needs to compute the difference in hour angle, for where the launch location lies on the orbital plane instead (a spherical trig problem, using 4-part cotangent formula (CT-5) with inclination-90° (angle opposite to the ΔHour_angle side of the triangle), latitude, 90° (angle from meridian where latitude is taken to the parallel where the ΔHour_angle is measured) gives, once simplified: ΔHour_angle = ArcCot(cot(inclination)/sin(latitude). With latitude = 28.6 and inclination = 110°, ΔHour_angle = 9.8834°. Believe one knows that difference is positive when latitude is positive and the node is AN, or latitude negative and the node DN. So, if one can see where the orbit crosses the equatorial plane, and applies that ΔHour_angle difference, should be launching exactly when the launch position lies on that orbital plane.

Let's say you have already set one of the apsides at your intended altitude (100 Km). Your maneuver node to circularize has to be placed exactly at that apsis. If at apoapsis, you need burn prograde to raise the periapsis; if at periapsis, you need burn retrograde to lower apoapsis, in both cases to change the other apsis altitude. If the maneuver is done exactly at the apsis, that apsis altitude won't change and neither the apsis position; if done earlier or later, you'll also have the apsis position rotate and change altitude. With finite time maneuvers (taking some time to execute) you need to start the burn half the burn duration before reaching the apsis, so thrust components before and after the apsis balance out deviations. Should you have an orbit that crosses your intended altitude (100 Km) but neither of the apsides are at that altitude, you may burn radial while at that altitude to change altitude and position of both apsides (that's less efficient however than burning at both apsides to correct the altitude of the opposite one).

Now that this long-standing issue is fixed, believe is time to close this thread. Thanks all for discussing. (what you're doing here? Go show your imgur albums now)

You are almost right. What is saved are not velocities, but orbital elements with each vessel, and relative position and rotation of all parts with all vessels. Orbital elements are used to determine current speed, but that isn't what causes stress and spontaneous disassembly. Relative positions are however compared to the nodes positions (same for rotations), the difference is handled by the Unity Physics engine as a tensor, a set of oriented forces that would reduce the error in all axes and angles. The physics engine simulates elasticity, so joints are free to flex, forces are there to bring the error back (wasn't for outside forces on the vessel, e.g. thrust, gravity, drag and lift, nor inertia, parts won't ever be displaced). Each node has a maximum allowed displacement, beyond that the engine ceases to treat the joint as elastic and makes it break. Before a vessel is put on rails (saved and no more computed for physics interaction) is always better to wait a bit without acceleration, so to have all joints reduce the errors caused by acceleration and therefore the resulting forces. When coming off-rails, the engine goes with those saved errors, but something goes off (I guess the forces are used to compute accelerations, which is integrated with time to update those positional errors; but while before a save time to integrate acceleration was a delta between two frames, when getting off-rails delta time is larger and the integrated acceleration brings to a new positional error greater then what allowed, resulting in a break).

Congratulations. You have just negated not only physical evidence, but even the mathematical notion behind continuous functions. Drag is a continuous function (including rear drag), it doesn't magically cease to exist "just because" there is some mass exiting the rear. The mass exiting the engine provides thrust, there is one specific throttle setting when exhaust mass (at the exhaust speed) is exactly equal to the mass required to make continuity with the external airflow, which is also the condition to avoid flow turbulence (a result of the rear drag): that specific setting is where thrust = rear drag. Any further, we have thrust > rear drag and the engine provides net acceleration. Rear drag keeps existing, you may also conceive that as the amount of dynamic pressure the airflow exerts on the exhaust mass (as opposed to static atmospheric pressure, that we know reduces effective exhaust velocity and Isp), so this dynamic pressure also reduces the effective exhaust velocity (please note, this isn't the amount of dynamic pressure registered on the nose of a vessel, which is function of air density and mach speed; this is the pressure caused by convergence of the flow at the rear of the vessel, which is yet another way to see continuity, indeed included in the general continuum Navier-Stokes equation). As for the video, I have no wonder different parts in KSP have different dragcubes. The rear drag is a function from the equivalent rear area from the drag cube of the rearward part in a stack. One could still say e.g. the flea has such a bad rear drag (certainly has a larger rear drag compared to side drag, than other SRBs) that even a structural fuselage makes it better. Or (given how KSP simulates things), one could say e.g. the flea has a short inefficient nozzle, so even adding a fuselage section makes it work better (which could be true in reality, but isn't how KSP works).

@Kobymaru, let me start with some considerations. You have implemented a MechJeb2-like algorithm. Believe you know the equation it embeds (as you showed in the OP) is analytical, unaware of changes in gravity and TWR during the descent. Both me and you linked in the posts above two different approaches for a numerical computation, using integration in time to handle changing both gravity and TWR. The reason I showed an approach based on energy instead was to still be able to solve this problem with an analytical approach. At least, it allows that in regard to gravity (as potential energy is computed considering the different gravity at altitude and landing); I have no solution for a change in vessel mass, therefore TWR (so, my approach works best if the mass of fuel burnt during descent is a small fraction of the total vessel mass). Before getting into more equations, let me show one consideration about "gravity losses" that is often lost. While almost everybody seems to agree about the Oberth effect, which happens when thrust is applied to increment speed (so, energy changes the more the current speed is, going by the dEk/dt = F * v equation), very few seem to make that the change in energy required to bring a suborbital in a orbital trajectory is also described in the same guise. The loss in speed known as "gravity losses" isn't but a Oberth effect in reverse (less then enough speed to achieve circular orbit). Exactly as the Oberth effect, it is totally explained when dealing with energy, instead of with speed. Therefore, the reason you showed requiring to compute gravity losses because of a finite burntime, doesn't exist at all when computing energy instead: we only need to know the amount of energy we have at start and the amount we want at end of the maneuver, how that energy is changed (Thrust/m = acceleration) makes the time of burn change but not the energy equation. Another important consideration. Energy is a scalar, which means by itself can't show the correct direction for a speed change. On the vertical direction (exposed in my previous post), the same total energy applies to a same vessel that, at one specific altitude, is climbing or is descending by the same absolute vertical speed. Of course, without atmospheric drag, a climbing vessel will sooner or later (barring exiting SOI) be descending at exactly the same vertical speed at the same altitude, so the equations don't really need consider the case (we compute burntime only with the descending part of this trajectory). When dealing with only horizontal components, we don't need to include potential but only kinetic energy; however to solve the problem requires to ensure the final horizontal speed is oriented as the radial component due to the body rotation (meaning, final horizontal speed has to exist only in the E/W component, positive with E, parallel to the equator, and be exactly = 2*π* radius* cos(latitude)/(rotation period)). The above "final horizontal speed" can clearly be used to provide the "final kinetic energy due to horizontal speed", which is the value we need to achieve (but, due to the scalar nature, we can't just subtract final from initial kinetic energy, we need to consider the whole change in energy, or "work", performed). It seems easy to consider that, however steep or mild the descent profile, all changes in energy in both N/S and E/W components need be completed before (not necessarily at) impact time. "Before" meaning the last part of the descent will be pretty vertical, while "after" is more alike what a plane does at landing. Now, different coders have different approaches to solve this kind of problems. I like to handle calculations separate on each of 3D components; however the vectorial sum of required thrust when time is equal on all axes gives exactly the retrograde direction (which is neat). Components wise, total thrust would be made on each axis: for vertical, effective thrust = Thrust * sin(pitch); for E/W, effective thrust = Thrust *cos(pitch)*sin(heading); for N/S, effective thrust = Thrust *cos(pitch)*cos(heading). Of course effective thrust is what would be used in each of the components equations, e.g. for E/W: tbE/W = ΔvE/W / (effective thrust E/W / m). Given tb should be the same (at least with both horizontal components) means the heading is invariant during descent; if pitch was invariant too, tb would be the same in all three components (that is what would happen if the trajectory before the descent burn was already suborbital, crossing the body surface exactly at the landing site). This last consideration shows (at least to me) why changing pitch during descent isn't really an issue: the end result still is to achieve the final energy state at the right time, the descent can mix a late deorbiting burn with the landing burn to perform a "reversed gravity turn" which is pretty efficient, but the most efficient of all trajectories would require the deorbiting burn be done well before so to have an almost flat trajectory during descent (very risky, however). Just, exactly, the reverse profile of a gravity turn launch trajectory from an airless body. Having pitch change during descent only makes our "gravity losses" more prominent, but when we so choose, the effect is actually to have a longer burn time in horizontal than with vertical. Now, with all the above shown, I'm in doubt if this method actually fits your needs. No TWR variance is considered, and method works best with flat descents instead of allowing pitching (but, should either pitch or thrust be actively changed during descent, all precomputed analytical solutions would be invalid and need be recomputed in real time). In the end, what makes the MechJeb2 approach work in practice is just this, even if not totally accurate it is kept updated in real time (and, given TWR increases due to burnt fuel, the resulting error is towards safety).

As DXDiag reports no issues, I won't probably find anything useful; however others may know better so I'll suggest to upload the report anyway. Besides, just comparing some of the data against the report from an installation where no issues are found, could allow to point to discrepancies. The issue may be tied to something written in device properties (mostly written by the device installer in the registry; a number determined by the system itself, in particular dealing with the USB chain), but certainly I won't be able to spot something wrong. Searching evidence with the properties would imply to check entries against other USB devices on your system, I'd look if other devices which are polled very frequently (e.g. mice) share a part of the same chain. It's very interesting you wrote the issue is related to the order devices are recognized by the system: that's also my idea of the possible cause. If you could change USB port, or even disconnect other devices to find one configuration that works, then keep track of how the chain to the HOTAS is configured in properties, comparing different configurations should allow to notice something specific at the root of the issue. However this is going to be a long boring exercise, best if was done by QA with device producers.

This issue seems to exist since times old but can't find any evidence it was ever correctly diagnosed, therefore never truly fixed. Don't know if there's more to @damowang2's post than Unity forum threads like this (that provides absolutely no help to determine why the issue), probably more useful is this old issue on the KSP bugtracker. I have a Saitek X52Pro, not a X56. I always use the Saitek drivers (without any middleware like AdvancedFlyByWire). I never experienced any lag from my HOTAS in KSP nor in other Unity games. For how little I could tell, a number of other KSP users also have a Saitek HOTAS but don't have lag. That makes finding the cause of this issue really difficult: the drivers may really be part of the problem, but only if there's something else with the OS that fights them; unfortunately nothing written up to now helped determine what (I could only consider showing a DXDiag save with Windows OS, hopefully it would tell if there's any conflict among input devices or with USB. Unfortunately seems nobody who reported this issue till now considered this worth showing).

I only use dedicated GFX cards, so can't directly tell how good an integrated GPU works with KSP. But, even with all the power of a fast GPU and lots of VRAM, that's where my PC shows the bottleneck with KSP (GPU load is often > 90%). Even changed to a faster GPU (the most powerful my PC could handle) and still that's what could be causing FPS drops most of time. KSP isn't a graphically intensive game, unlike many others that really require a very powerful GPU to create awesome, realistic scenery (my GPU runs just fine with those). But, KSP is really intensive with physics calculations, in particular when flying large vessels (many hundred parts, physicsless parts excluded). Most of the basic calculations with physics are handled by modern GPU, to relieve the CPU of a large mass of parallel computing. E.g., Unity (the engine behind KSP) makes large use of PhysX library to offload the CPU from all those calcs. To really evaluate how large a load KSP is taking from your GPU, I always use Process Explorer which can be set to show a column with the GPU load for any running application (I'm still wondering why MS Task Manager has no such useful info). Please download, install, setup and try PE with KSP running (while flying a large vessel, some hundred parts at least), the value shown for GPU will tell you, better than any of our estimates, if your internal GPU is up to the task or not.

Should you manage to ensure compatibility with Ampyear (not only about reserve batteries, that add-on adds custom modules e.g. AYPart with many parts in a savegame) I would certainly switch (back) to Fusebox, now that it gets the love it deserves (and becoming compatible with most other add-ons). Otherwise have to start a whole new save after switching to Fusebox. Anyway, please keep doing as you started with this add-on, it always had great potential, have to thank @Ratzap for how he designed it; but you seem able to solve some of the long-standing issues this add-on kept showing.

Ciao redzep, benvenuto sul forum! Spero ti troverai bene nella comunità, qui toverai aiuto per qualsiasi tua esigenza. Hi redzep, welcome to the forum! Hope you'll be fine with the community here, it will help you in whatever question you may bring.

As the glitches disappear when AMD ReLive is used, makes me guess this may be related to the refresh rate (anything decreasing the GPU rate hides the glitches). Refresh rate can't exceed a maximum tied to screen resolution, having two displays effectively doubles resolution. I would check what happens with: lowering refresh rate in the GPU settings; lowering display resolution (both screens). Clearly also the displays have a maximum rate allowed, though should show a message if that's too high. It's just a possibility, can't actually tell for sure, but should be worth a test.

There is some explanation about negative SMA on Wikipedia including a bit of math that should be simple enough to grasp. Another description is on Orbital Mechanics (where SMA equation at 4.32 is valid for all conics, clearly when excess velocity is > 0 the result of the equation turns negative).