Kowgan

Members
  • Content Count

    914
  • Joined

  • Last visited

Community Reputation

453 Excellent

1 Follower

About Kowgan

  • Rank
    Cosmic Cartographer

Recent Profile Visitors

3,071 profile views
  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.