• Content Count

  • Joined

  • Last visited

Everything posted by Kowgan

  1. @adamv66 It adds the map to your KSPedia, so you can access it in-game.
  2. 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.
  3. @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.
  4. 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).
  5. Have you read the OP? Visited github? All necessary tools are referenced there.
  6. 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.
  7. @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.
  8. 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.
  9. 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.
  10. 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.
  11. @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.
  12. 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.
  13. 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
  14. 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.
  15. Yes, here's the thread: https://forum.kerbalspaceprogram.com/index.php?/topic/177761-crashes-upon-reloading-vabsphlaunch-excessively/ What confuses me is that the error seems to be related to lack of available RAM. Although I have 16GB of RAM, KSPx64 only uses about 4GB - including during the time of crash - and I still had about 50% RAM free during the crash reported there. So I have no clue why it says I've ran out of memory. But this is unrelated to this thread, so I'll stop the offtopic here.
  16. KSP: 1.4.5 x64 Problem: KSP crashes when either reloading the VAB/SPH or Launching a vessel repeatedly in a short amount of time. Or just generally reloading those scenes too many times, nor necessarily in a short time. Mods installed: Reproduction steps: Load a save, re-enter VAB/SPH/Launch vessel and Revert to building multiple times. Logs: output_log.txt error.log Notes: I was unable to reproduce the issue on Stock KSP, so I might try to narrow it down to a specific mod. But it might be difficult due to the inconsistency of the issue. Sometimes I am able to crash the game within a couple of reloads - Other times, it takes me several attempts unitl it crashes. After a quick research, I've found that usually 0xc0000005 errors are related to the lack of available RAM. In my case, I have 16GB of RAM, running the 64bit version of KSP and having around 50% memory free at the crash moment. KSP was using around 4GB of RAM at that moment. Any help is much appreciated.
  17. Yeah. Well, unfortunately for me, my crashes didn't stop. I'm trying to reproduce the issue under stock KSP and will create a thread soon™. In any case, thanks for the thread. This issue has been going on for a long time, and I'm sure many other players have experienced it. Hopefully this will help most of them.
  18. That's one long discussion, but I'm glad I arrived before it became necro. First of all, thanks for the workaround, @JoE Smash. I've replaced my KSPx64 plugin with the one from system32 and will check if the crashes stop. Now, what doesn't make sense to me is how this is even fixing the problem. - If KSP is using the dll from system32, how is placing that file in the KSP folder gonna result any differently? - If KSP tries but fail to use the KSP Folder version of the dll, then imports the version from system32, why does the game even crash to begin with (since it's importing the 'good' version')? - Most amazingly, how did your KSP stop crashing when you removed the (good?) dll from system32 and replaced it with the (bad?) dll file from the KSP folder? It just doesn't make sense that replacing either File 1 with File 2, OR File 2 with File 1 simply fixes the issue. Then again, it's Windows, so, go figure...
  19. @lajoswinkler I got atmospheric numbers with the help of MJ predictions, data, various missions with different ships and feedback from the community. In-space numbers were calculated by CuriousMetaphor. Maybe this can help you: and https://www.youtube.com/user/PurpleTargets/videos
  20. @martinborgen The only reason elliptical orbit nodes are there are to save fuel when aiming for a planet's moon, instead of the planet itself. So you don't need to waste the extra fuel coming to a low circular orbit. Therefore, planets without moons don't have these nodes.
  21. @Nicias Sorry for the delay. Regarding the time of flight, they're gathered as explained on the image subtitles. They're done through AlexMoon's Launch Window Planner simulations, using 10 different years of possibilities and taking the average value. Some values will be smaller, others will be longer. In order to cover most of the gameplays and styles for all players, the average number was choosen. For life support players, it's best to have a number that won't kill your Kerbals for being too low. Average Time between Windows is something entirely different from Time of Flight, and it was gathered (and tested) with the help of the Protractor mod and its predictions based on fuel-efficient maneuvers during launch windows. Like time of flight, launch windows will vary depending on the year, and an average time was choosen to be used for the same reasons as mentitoned above. As for RSS and OPM updates, unfortunately I can't update those maps myself as I don't have RSS/OPM; as such, I can't work on those numbers. If anyone is willing to help updating those maps, feel free to contact me via PM.
  22. @swjr-swis Took me some time, but I finally did it, right? And whoops. Thanks for the heads up. It's v2.6 indeed.
  23. Sorry, LostOblivion. I'll let it pass for now. I'm considering it for a future update. But as far as I understand, you want the elliptical orbit 80km X 2.8Mm? In any case. V2.6 released - Updated to KSP 1.3 - Fixed Geosync altitude suffix » From 2863.3 Mm to 2,863.33 Km - Updated Antenna values for all planets (and Kerbin moons) - KSPedia version is now much smoother on your eyes I hope you like it. P.S.: Special thanks to @AlexSheFF for the continuous support with the KSPedia versions. It took me a whole day and 4 Unity Engine versions, but I finally managed to build the KSPedia page from here.
  24. Absolutely, @tetryds. It's your mod, I carry absolutely no rights over this or the file I've uploaded.