tofof

I can confirm for anyone looking in 2021 (ksp 1.11.2, usi exploration 1.4.0) that yes, this patch fixes the bug of RCS thrust plumes visually going the opposite direction expected, and it tones down the plumes to be actual reasonable sizes. Just save this text to a .cfg file anywhere inside GameData and you're all set. Thanks for this, @ChrisF0001.

I believe you're saying that the blue line uses the 'orbital' frame of reference rather than the 'surface' frame of reference. This makes perfect sense, reflecting the orbital frame of reference, if the player is using it -- e.g. during orbital maneuvers. I think this is not ideal however. It would make better sense for the blue line to be calculated using whichever frame of reference is selected on the navball. Alternatively, switch the blue line to a surface frame of reference whenever 'time to impact' is less than some threshold, perhaps as much as 15 minutes. Observe that in the screenshot Dale Christopher posted, his velocity, relative to the surface, is straight downward, not off to the side. In particular, there is no circumstance in which the vessel will appear to follow the blue line at all: the camera moves along with the vessel (i.e. it is stationary in the vessel's frame of reference), and the vessel and surface position are similarly stationary relative to one another (except for vertical motion). I believe this is equivalent to automatically toggling 'fixed body' mode on when the player is in 'surface' mode (or when there's a nearby time-to-impact), and off when not.

@enceos That was already fixed in Kopernicus 1.7.1-5, 29 days ago. Update.

Are the navball circle and square indicators supposed to be medium gray and black? They look more like a bugged or missing texture than a deliberate design to me, which is why I ask.

How does one do this?

I am also getting the Trajectories.bin hang after upgrading Kopernicus. I completely deleted Kopernicus to reinstall it. However, immediate minimal testing suggests it's not actually Trajectories that's breaking things. Testing in KSP 1.7.1.2539 with no other mods loading: Kopernicus 1.7.1-4 + Trajectories official release ---- loads into game, but (duh) trajectories doesn't work Kopernicus 1.7.1-4 + Trajectories after copy/renaming the 16 file to Trajectories17.bin ---- loads into game, trajectories button appears and I assume it works [EDIT: I didn't notice Kopernicus depended on ModularFlightIntegrator, because I was doing things manually instead of through CKAN. Once it's included, you get the hang on loading.] Kopernicus 1.7.1-4 + Trajectories (official OR with 17.bin, makes no difference) + ModularFlightIntegrator 1.2.6.0 ---- hangs on kopernicus\plugins\trajectories.bin during load

BlocNumber never seems to get used. Not with changes made to a ship, not even with completely different ships with no parts in common. I've made templates that force it to be displayed, And I end up with a vessel named "MyTestVessel.name [blocNumber].blocmark 008.num". Arabic/Roman makes no difference. Tested in 1.7.0 and 1.7.1 Mod version 0.5.2.2. installed through CKAN.

Big ugly box around the stars, which aren't vertical either. KSP 1.7.1 Tested on a PortraitStats (only) install, no other non-dependency mods.

I really wanted this to work. For me, it did fix the invisible-parts problem. However, the engines and fueltanks behaved as if they were larger than they actually were - so that there were gaps between connected parts.

My rover took a tumble and apparently killed Bill; he went ragdoll and the craft stopped taking input. Unfortunately for me, this means it kept the previous inputs I'd given it just before that point. The tumbling slowed and slowed more, each time spending more and more of its motion doing a loop on one of the wheels, until... Words don't really do it justice. This would've gone on for days, I suspect, until that patch of Mun was totally without sunlight.

Mk1 cockpit lights: RCS and SAS toggle green/off matching the normal navball RCS/SAS indicators. GEAR and LIGHT toggle green/off matching the normal altitude-display indicators. STAGE is the staging lockout - green when the normal indicator is green, off when the normal indicator is purple. (?) HEAT - obviously related to overheating but unsure of the lighting conditions. (?) HIGHG - obviously related to g-meter but unsure of the lighting conditions. (?) TWR is orange at a fractional (0.8, I assume all of 0.01-0.99) thrust-to-weight ratio. I assume it's green above 1.0 and off with no engine (or fuel?). (?) FUEL - unlit at 40%, unsure of conditions. The six unlabled lights to the right of the indicator lamps are: [blue SAS] [Purple GEAR] [??] [Orange RCS] [Yellow LIGHTS] [??] These light in the named color when the associated lamp is lit. Anyone want to fill in the missing pieces?

Instruments button seems to always read 'no data'. This button does what, exactly?

Has this been updated for current versions?

What determines what category things end up in right now? I'm not sure I understand the difference between 'lander' and 'base' for example.

When was this fixed? The last time this was addressed, dual joysticks were nonfunctional because the game didn\'t distinguish axes/buttons on one from the other. http://kerbalspaceprogram.com/forum/index.php?topic=8511

Very nice. Any thoughts on (in the future) using the data to generate ground tracks? Example (a Molniya orbit):

It doesn\'t look like the calculator is using the correct mass for the Mun. Looking at the source, I believe you\'re using 8.267125E+20 for Munar mass and 1.379 for surface gravity. (And 200km for the radius, which is correct.) Experiments have pretty conclusively concluded Munar mass to be 9.760e20 kg, corresponding to a 1.628 m/s^2 surface gravity. See my post here which contains the consensus data from the experimental measurements from several (3-4) kerbonauts.

To put it shortly: wrong. To put it not shortly: wrooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnnnnnnnnggggggggggggggggggggg. Consider the following situation: You create an elliptical orbit typical of a Mun-shot, with an apoapsis of around 12.5 Mm. (About 1Mm further than it needs to be), aimed such that you will reach your apoapsis at the same time the Mun first crosses the arc of your outbound orbital path. Convention: Consider a coordinate system in which Kerbin is the origin, the \'spawn\' position of the Mun is on the +x axis, the apoapsis point of the vessel\'s orbit is on +y. In this system, the Mun will move CCW from 0 degree angle toward 90 degree angle. What should happen: As the Mun gets closer and closer, its gravity pulls the ship more and more in the +x direction. The (very minor) effect on the y-component of the ship\'s velocity is a small decrease. Kerbin\'s gravity, of course, continually decelerates the ship as projected, such that the ship never reaches a point further than 12.5 Mm from Kerbin. We\'ll assume that the timing is such that the ship ends up on a collision course in the x-direction with the Mun, but it could end up captured or flung hyperbolic, irrelevant. What happens: As the Mun gets closer, suddenly Kerbin fails to exert any pull on your ship whatsoever. As this was effectively the only thing slowing your y-component velocity, your ship shoots past the Mun (ahead of it). By the time you\'re out of the Mun\'s SOI (back in Kerbin\'s), you\'re well past 12.5 Mm altitude, and Kerbin\'s gravity is no longer strong enough to capture you. You end up on an escape trajectory from Kerbin and become stranded in Kerbol orbit. Thought experiment: Remove Kerbin\'s influence for aproximately 2 Million meters of flight time (10.5 to 12.5 Mm altitude), turn it back on when you reach 12.5 Mm altitude, and now try to claim that everything is still the same, no change to your apoapsis has occurred, no stranding is possible from this effect. This poster had it very right.

Oh, is it not required to do a circular orbit? I\'ve been making this challenge FAR more difficult than it needs to be o.o

Not really; I was taking the earlier \'too low\' posts (349 and 439) to be altitudes at which there was a significant chance of running into an obstacle. Something like less than an eighth of an orbit or so before you hit one - that suggests a very high likelihood of seeing a peak at least that high for any given orbit. Finding a 582m peak, on the other hand, doesn\'t really mean a 580m orbit 5m to the side of the peak wouldn\'t have worked perfectly. In fact, if that\'s the highest peak you can find, it .. means it /would/ work perfectly, and so can\'t possibly mean that 582 is \'too low\'.

Humorously, I almost created this challenge about 12 hours earlier, and decided to just stick with the Limbo one for now (in linked thread). Maybe I\'ll try both at once.

I\'d love to know where those mountains are. I came here about to create a \'find the highest peak on the moon\' challenge but figured the Munar Limbo \'find the lowest valley\' was close enough for now. Tip: 439m is too low. The orbit... If only we had a TAWS look-ahead.... The kerbonauts\' faces have never been more perfect. The predictable result ... And finally, the location... This is an animated PNG. If it doesn\'t look that way to you, your browser sucks. That said, I realized what was coming, and had time to press F1 to get the two \'action shots\'. I suppose I might have barely cleared it if I\'d RCS\'d, but I was trying hard not to perturb my orbit, and had already successfully made several other \'scrape-the-fuselage\' clearances of ridges. Crash site was in the area near the capsule/periapsis in the \'orbit\' pic. (Look at the timestamps). Between that and the zoooooomy image, should be easy to find.

Sammmme here, donated $7, got my paypal receipt (Transaction ID: 2NB43030UW738702Y) but nothing from KSP (did not even receive a \'thank you for your donation\'), nothing lost to junk mail. EDIT: Using the link from one of the quoted emails above in this thread (which I realized is the \'store\' button at the top of the forum controls) I do seem to have a completed order with accessible download links, etc. So at least that was successful.

I don\'t get the values in this pack. The \'800\' capacity tank weighs more when full, but the same when empty, as 4 of the \'200\' tanks :-\. If anything, I thought the advantage of 1 large tank over several small ones was the fact that volume increases faster than surface area - more fuel inside the same amount of metal. Since the larger tank is in fact a larger diameter, this should definitely be the case. Also, where is this extra mass coming from? *boggles* It\'s the same when empty: 1 ton (for the \'800\') or 1 ton (4*0.25 for the \'200\'s). So it\'s not the metal. The \'200\'s each contain 200 units of fuel in their remaining 1.75 tons of mass, whereas the \'800\' contains 800 units of fuel in its remaining 8 tons of mass. The \'1600\'s are similar - they\'re exactly twice the mass of the \'800\'s (full or empty). At least that\'s consistent (and since they are simply twice the height, I wouldn\'t expect any particular improvement due to the geometry like I would coming from the 1m \'200\'s.) Literally the only thing I can see that\'s an advantage is the doubled (or quadrupled, in the case of the \'1600\' tank) impact strength - which, again, I found bizarre - if anything I thought that in general, the larger tanks were more fragile (the Atlas would collapse under its own weight if not pressurized, etc.) The extra mass and subsequently reduced performance are just ..weird, though. If nothing else you could put the fuel into the same (rough) shape as a stack of 4 tanks, but use stringers instead of actual partitions between the \'tanks\' and still accomplish a weight savings that way, albeit much less than the improvement from improved geometry. Testing confirmed the crappier TWR - straight up, full throttle, got to 58.5km @ ~2700 m/s using 4x \'200\' tanks, while only reached 51.5km @ 2440 m/s using a single \'800\' tank. These numbers are at burnout. tl;dr - Why are the larger tanks heavier instead of lighter than the small tanks? PS - for what it\'s worth, the \'compressed\' fuel tank seems correct to me. You pay more of a mass penalty for such a small tank - running 4 of them (200 units of fuel) gives a crappier TWR than a single \'200\', as it should be. However, the name is deceptive! Allllll the other tanks, even the FL-R25 RCS tank, have the numbers indicating fuel capacity. This one is called the \'M100\' but has only a capacity of 50. PPS - I think using the 100:1 fuel to weight system that the \'200\' tank was supposed to weigh 2.25, not 2.0. If that was the case it would be functionally identical to the other 3 tanks .. which is still wrong, the fuel:structure weight ratio should improve with tank size, but it would at least be a start.

I think that, unfortunately, the drag model would prevent it from being very accurate, since that can vary substantially from rocket to rocket.