Jump to content

Kowgan

Members
 View Profile  See their activity

  • Posts

    924

  • Joined

  • Last visited

 Content Type 

Posts posted by Kowgan

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted

    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.

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted · Edited by Kowgan

    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. :)

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted

    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.

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted

    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.

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted

    @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.

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted

    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.

    [1.7.3] Community Delta-V Map 2.7

    in KSP1 Tutorials

    Posted · Edited by Kowgan

    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.

    Crashes upon reloading VAB/SPH/Launch excessively

    in KSP1 Technical Support (PC, modded installs)

    Posted

    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.

    Crashes upon reloading VAB/SPH/Launch excessively

    in KSP1 Technical Support (PC, modded installs)

    Posted · Edited by Kowgan

    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.

    Crashes upon reloading VAB/SPH/Launch excessively

    in KSP1 Technical Support (PC, modded installs)

    Posted

    Thanks, @4x4cheesecake. I haven't tried this yet, but according to Lisias:

    On 8/22/2018 at 10:09 PM, Lisias said:

    I run KSP on a Mac machine, and it's usually eats up 10 to 12G of RAM.

    If your KSPx64 is consistently dying at 4GB of memory allocated by the process, I definitively would bet on some 32 bits DLL somewhere in the System being used by KSP, and getting killed when KSP reaches that memory limit and the get shoot on the feet when it calls that DLL using a memory pointer above that.

    If the XInput trick didn't helped you, there's a good change that something else on your system is getting into this.

    Another thing is VRAM memory. Each texture you add to KSP via mods eats VRAM from the GPU Card. When you exhaust your VRAM, Unity also crashes without any clue about the reason.

    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.

    I believe I solved my constant crashing of Kerbal Space Program myself and thought I would share....

    in KSP1 Technical Support (PC, modded installs)

    Posted · Edited by Kowgan

    @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.

×
×
  • Create New...