Kowgan

Yeah, I suspected that couldn't be right. Maybe there's something to do with warp speed at these altitudes? Idk. ¯\_(ツ)_/¯

The 10km above tallest terrain wasn't designed to help people landing on these locations. Rather, it's a safety margin, so people don't crash while orbiting. Same goes for atmosphere. These are some good numbers to know. It shows the orbital atitude on the chart is innacurate, if they're designed 10km above terrain. Maybe there's something to do with timewarp speed, then? Idk, gotta check that.

IIRC, the low orbit values are "10km above the highest terrain point/peak" for non-atmospheric bodies. These are usually mountains or overall elevated points; not the zero mark ASL. But I'll leave you to these calcs.

I agree that numbers shouldn't ever be below minimum required. and if needed, should be rounded up instead. But are the non-rounded numbers on your chart the absolute minimum in any scenario? In any case, planning expects players to carry extra fuel, especially when manual control is used instead of autopilots. So although rounding down isn't the most appropriate, I woudln't call it totally useless or unhelpful. It's not that big of a deal, is it? In other words: Remind me to round it up to 180m/s on the next update.

V2.7 released - Updated to KSP 1.7.3 - Updated Low-Orbit-to-SOI-Edge values (Thanks @Armisael!) - Updated credits KSPedia version is pending update. Following the old tutorial by DMagic resulted in errors upon generating the .ksp file. As such, I've included the .png file for the KSPedia page in the GitHub source for anyone who's able and willing to generate and share said .ksp file. My regards in advance.

Awesome. I'm working on the update. There's something else. Curiousmetaphor's low orbit altitudes are mostly different from the ones in this - Some are the same; some are higher and some are lower. Nevertheless, the dV numbers to achieve low orbit were kept the same. So, obviously there are some inaccuracies (mostly insignificant), but I reckon they work just fine right now; especially if you take into account that each player will have a different ascent profile, etc. I thought about replacing the diminishing numbers from LO->SOI by increasing the ones in Surface->LO and keep the total dV usage the same, but given how different each celestial body altitude is between those two maps, I decided for keeping the same Surface->LO values and just alter the total dV value usage. Feedback on this will be appreciated, once the update is out.

@Armisael That's some interesting data you gathered there. On the second half of the chart, did you gather those numbers only while warping? If so, what are your results while not warping at the same altitude (minimum orbital alt)? I revisited CuriousMetaphor's Delta-V Map from 2013 and took a look at the notes. His chart is indeed set for minimum orbital altitude, and not the 10km above minimum as seen in this one. The 80km orbit standard was set by Jellycubes in the original chart, followed by Wac's, and, posteriorly, by the current one. The practical numbers were different back then, so maybe 950m/s was accurate from 80km orbit at the time. I'm not sure if Jellycubes grabbed the numbers from Curiousmetaphor and did not consider the 10km difference. Either way, mea culpa for not taking that into account for this chart. I'm happy to review the vacuum numbers, update the chart and credit you, if you're interested.

I don't maintain other existing maps. Ask their creators. I followed this tutorial by DMagic in order to create the .ksp file.

@VITAS Not sure why you were even mentioned here; The double post of this chart has nothing to do with me, you or this thread. @gamerscircle The licensing info on CKAN has been updated, as it apparently wasn't before. The map itself remains the same.

Hey @Emperor of Ilve. I currently only have time to maintain the stock game, but I'm glad to help providing info with the tools needed to create versions for modded games.

@adamv66 It adds the map to your KSPedia, so you can access it in-game.

Yes, you should use Vacuum dV for all calculations. Well, as long as you don't have any mod that changes the aerodynamic model, planet sizes and alike, you should be fine. KER and MJ are showing expected results on your tests. As I have read on other threads, it looks like the aerodynamic models and celestial body properties haven't been changed in quite some time now, so the values for 1.3 should be valid in 1.6. This leaves me to a few options: - Maybe your rocket isn't aerodynamic-friendly, and is causing more drag than it should? (maybe some modded part could be interfering there?) - Maybe gravityturn isn't being optimal at the moment? I personally like to use a profile of 1.5 TWR for most of my payloads - except when I'm launching something extremelly massive and aerodynamic non-friendly, where I prefer to use higher TWR values. But overall, 1.5 until ~40km and then full throttle all the way to victory town seems to work for me. I hope this helps.

@rottielover Thanks for the report, I'll test it and update as needed. Meanwhile, could you do me a favor and: - Confirm your TWR per stage is nominal? - Use the same methods (gravityturn continued) to achieve a 80x80km orbit aroun Kerbin using 3400dV and tell us the remaining dV? Cheers.

I'm afraid there are currently no maintainers for the OPM verison of the map, and it is currently outdated (last update was for OPM version 1.8.1).

Have you read the OP? Visited github? All necessary tools are referenced there.

Add the numbers from point A to point B to go from point A to point B. If you wish to return from point B to Point A, you have to add the numbers again. Remember that segments with Aerobraking indicators are possible to complete with little to no fuel usage.

@Ultimate Steve Inkscape.

@steve_v I figured. Since I learned a copy of Windows will constantly eat disk space over time even when it stays fresh clean, I believe anything, heh.

The question has been pretty much answered, now. Thanks everyone. And at this point, we pretty much can assume SQUAD won't fix the memory leaks that have been around forever, despite the countless requests we had over time. The stock game doesn't crash often, and they technically don't have any obligation to make the game run smoothly while modded. What I can't figure out is how streamers and many other players can run a heavily modded game on Windows for 12+ hours without heavy stuttering and/or crashes. Anyhow, In my case, I have been careful-ish and avoided too many relaunches in a short time, so I have dodged any further crashes so far.

Interesting. That would explain a lot. Also, I wonder if my self-recompiled version of Mouse Aim Flight could have something to do with it. FWIW, I know it already has a glitch where it doesn't correctly remove the stockbar icon, so you can still see that mod's icon when you unload back to the main menu. I wouldn't be surprised if the root of this problem is directly related to the ever-increasing memory comsumption as well. I'm tempted to replace the system32\xinput dll file with the one provided by KSP and see what explodes.

Thanks, @4x4cheesecake. I haven't tried this yet, but according to Lisias: I don't know if the GPU reaching its max memory should be the case since it's not VRAM, but maybe some 32bit DLL being called while the game is consuming over 4GB of RAM could be the case. Not sure. The inconsistency of the crashes is also something to keep in mind. Lately, I've had some 3 or 4 hours sessions with no crashes. And I didn't keep reentering the SPH/Runway every 30 seconds or so. For now, I guess I can just live with it. If I can play 3 hours with no crashes, I'll just boot it up again whenever it happens.

@Lisias That's really good info, thank you. Although my KSP goes a bit over 4GB (4.1, 4.2) without crashes, I guess it makes sense that it only crashes when a 32bit DLL is called. About the GPU Card. I got 2GB on my GPU, and I was wondering if running out of memory on it could cause a crash, but since I've never seen it mentioned before, I thought it would be stupid to think so. Now that you've mentioned it, I guess KSP's (or Unity's infamous) garbage collector might be causing that GPU memory overload, and thus, leading it to a CTD. If that's the case, there's not much I can do. Still, it's good to know the probable causes.

Alright, I managed to crash it again. Same methods, just constantly loading SPH and launching on the runway. output_log.txt error.log I'm considering switching to OpenGL to see if things get better.

I've uninstalled Bonjour (it's useless to me, and I should have done it a long time ago anyway) and will try to reproduce the crash again. I'll post an updated log file if here if it crashes again. Thanks for the support, it's much appreciated

No, \system32\xinput1_3.dll was still there when I swapped these DLL files. Bonjour is a service related to Apple iTunes. I have no clue why it shows up on this error log, though. I should be able to disable it, although I'm not sure how it would affect the game. Then again, nothing in this has made much sense to me so far.