Eklykti

Members
  • Content count

    84
  • Joined

  • Last visited

Community Reputation

37 Excellent

About Eklykti

Contact Methods

  • Website URL http://infoman.diary.ru

Profile Information

  • Location Chisinau
  1. That means that you are not managing your pitch good enough. You should carefully maintain your trajectory so that your vertical speed is close to zero at insertion. If your time to AP is going forward too much when aiming for your initial AP, then probably your initial launch profile was too steep or too shallow. What I usually do is first setting up initial launch parameters in MechJeb ascent profile editor, like 90m/s turn start velocity, 120km turn end altitude, 5deg final angle and 50% shape (this can be all different for different launch vehicles), and set 'Orbit altitude' to my desired apoapsis value. Then I just sit, activate stages manually or sometimes using Smart Parts for side boosters sep after depletion, and watch my current apoapsis value. When it approaches my desired periapsis height, I start reducing final angle value and trying too keep my AP at about the same altitude. This phase of flight continues until the AP is reached, and can include negative pitch angles to avoid AP rising too much. The next phase starts at the AP (which will be the final PE), and now I'm keeping my vertical speed as close to 0 as possible, again by managing angle value at the ascent profile editor, increasing or decreasing it depending on what I see in KER vertical speed display. Usually at the beginning of this phase that pitch angle becomes positive again and slowly drops until you finally reach orbit. In order to not have to determine all these parameters for each flight, avoid constructing a new rocket around your payload each time, and instead have different launch vehicles for different kinds of payloads and destinations saved as subassemblies, keeping launch parameters for each of them in some document that you can read before launch and just enter the values and press Launch.
  2. Should be listed in CKAN by now.
  3. For a long time I've seen videos of people playing Realism Overhaul. Amongst other great features, it has one that allows you to significantly reduce g-force loads of an atmospheric entry, called Descent Mode. It works by moving the capsule's center of mass off-center, and then, when you reenter, aerodynamics will keep your capsule at an angle, generating lift and allowing it to stay longer in the upper parts of the atmosphere, and, in turn, making your descent much more gentle and smooth. Now I decided to extract this functionality from RO and make it a separate mod, called Descent Mode, available at Github and CKAN. Screenshots: Imgur album. Download: Github. License: CC BY-SA. Installation: Copy the DescentMode directory inside your GameData. Warning! Do not install this if you already have Realism Overhaul installed, as it does the same thing and will cause conflicts. Usage: Right click you capsule and select "Turn Descent Mode On". Orient you capsule to retrograde and rotate it such as the ground (brown) is at the top of your navball, and the sky (blue) is at the bottom (180 degrees roll). This is different from the original Realism Overhaul setup, where you have to set 0 roll, because it 1) allows your kerbals to see their planet in the window and 2) makes better lift for mk1-2 pod with Ven's Stock Part Revamp and FAR. Enjoy your descent. Supported pods: Mk1 Command Pod Mk1-2 Command Pod MK2 'VA' Command Pod (Ven's Stock Part Revamp) More to come in the upcoming versions. Great thanks to Realism Overhaul people and the authors of CoMShifter.cs
  4. Well, frak stock fairings then !PART[fairingSize*]:NEEDS[SimpleAdjustableFairings-KWRocketry]{} !PART[KW*Fairing*]:NEEDS[SimpleAdjustableFairings-KWRocketry]{}
  5. In case if it's useful for someone, there's an MM patch to move KSC closer to the water in 10x scale: @Kopernicus:FINAL { @Body[Kerbin] { %SpaceCenter { %latitude = -0.3 %longitude = -74.44 %repositionToSphereSurface = True %repositionToSphereSurfaceAddHeight = True %repositionRadiusOffset = -22 } } }
  6. Sadly there's a severe performance hit with GPP on my system. System specs: Video: 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630] (rev a1) CPU: model name : AMD Athlon(tm) II X2 280 Processor Video RAM: 1 gig System RAM: 12 gigs DDR3 OS: Ubuntu 16.04 Video drivers: nvidia-375/xenial-updates,xenial-security,now 375.39-0ubuntu0.16.04.1 amd64 KSP 1.2.2 64-bit, with just created clean sandbox save. With every mod from a GPP install except GPP directory itself i'm getting my game timer green at almost all times, with small spikes of yellow that I can't really feel. With GPP, Kopernicus, MFI and MM only there's a lot of yellow with some spikes of green, about 1.5 to 2 seconds of real time for each game second. With GPP, EVE, low-res clouds and all other mods installed — all yellow, about 3 to 4 real seconds for each game second, even in space somewhere between Gael and Iota. With GPP, but no EVE, all other mods installed — all yellow, again about 1.5 real seconds for each game second, even in space somewhere between Gael and Iota. So: GPP seems to to have some strong performance issues. GPP's clouds configs have even more performance issues, even with low resolution clouds. I know that my system is not the best gaming machine, but is there a chance that something can be done to improve this situation?
  7. Github shows only source code archives for that
  8. This is what was happening to me in 1.1.3 despite having full data on them, and forced me to uninstall TF in result. They just exploded no matter what
  9. … and plant a flag?
  10. And that's definitely true, even with lgogdownloader it only shows windows build when trying to use the Galaxy API. And installer packages, which are available for other OSes, are only 1.2.2 yet. $ /opt/lgogdownloader/bin/lgogdownloader --galaxy-platform l --galaxy-show-builds 1429864849/0 Galaxy API doesn't have Linux support upd.: but mac os apparently IS supported: $ /opt/lgogdownloader/bin/lgogdownloader --galaxy-platform m --galaxy-show-builds 1429864849/0 { "baseProductId" : "1429864849", "depots" : …
  11. Go blame AMD for that, they just can't into drivers and you just paid for excrements buying their graphics card.
  12. IRL the SRB thrust is not cut out instantly, because there are some leftover chunks of fuel, but at some point it's thrust becomes so low that it can't accelerate own weight, and usually it's dropped at this point while still burning.