skbernard

agreed, i hate how the vanilla struts leave those hideous clamp piece on my ships... this mod is glorious, and good to see it back up and running, good work toadicus one question does this have both the blue scifi and grey normal strut lines in this pack (i'm at work)

Nah that wouldn't have done it, but it should improve overall performance (once you get past this crash bug) It's likely just a RAM issue, probably too many mods installed You're not gonna like this but pull out b9 and nova and give everything a go If that works then start adding one back at a time You can also try removing parts from those packs you know you don't use

as a side note, you should probably get the latest module manager dll, it's up to 2.3.4

cool, no worries - good luck @ life

make a module manager file and place the following code in it @PART[US_R90_Wedge_ScienceBay]{ @attachRules = 1,1,1,1,0 MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.0, -0.15) evaPartDir = (0,0,-1) storable = True storedSize = 10 attachOnPart = True attachOnEva = False attachOnStatic = False } } i'm at work so i cant verify how it looks on your back right now, but this should be close to fully functional... i think... if it's wonky and tries to attach to any place on any part, set AttachOnPart to false

just to double check... when was the last time a "nightly" was committed to the repository? (other than the license updated - wanna make sure i'm not missing something)

yeah they do take a while, but honestly its gotten me to fly the most i've ever flown before... also talking about the altitude differences in survey missions, i was doing two separate ones at the same time in the same general area and had so much problem with not having a maneuverable enough plane to climb and drop quick enough, i blew right through things at the wrong altitudes and wasnt maneuverable enough (or enough lift probably) to make a hard enough turn to get back on track until i was clicks away... that'll teach me to build better planes...

i dont see anything wrong... maybe they look a little too grey - wouldnt want Kerbin constantly pestered by storm clouds would we?

i could be wrong, but i'm pretty sure the orbit for a Munarstationary orbit (made that word up) is outside the Mun's SOI by like 500km, but i think you can kinda do it by circularizing 500km before the SOI change from Kerbin

i see what you did there...

also... is the HERP going to have the famous E-Model variant, affectionately known as the HERP-E

is this 'Survivability Pack' going to have a .DLL?... because... PLUGINS... /sarcasmOff

lol, best response ever

this is a known issue with EVE:Overhaul, and not one just on Linux distros - as of right now, i dont believe anyone has found a way of fixing this with just modifying the config files

question about plugins and placement, do mods look for dependent plugins via their folder location, or simply that they are actively loaded when the game begins... ultimate question: can i box all my random plugins in one folder under GameData

its in the BoulderCo folder, either in Clouds for 7-4 version or Atmospheres for EVE:Overhaul BoulderCo/Clouds or BoulderCo/Atmosphere

Ah, gotcha

if it is actually clipping the terrain and not something else, try making the 2d cloud layer appear at a higher elevation but my thought is thats its something else - theres some weird dynamic that happens when you play with _FadeDist, _FadeScale, _RimDist, _RimDistSub where they all affect each other in some not clearly predictable ways (at least i havent found complete predictability in it yet)... try this cloud layer and let me know how it works kerbinCloud2D { altitude = 8400 speed = 80 layer2D { detailSpeed = 60 offset = 0,0,0 shadow = false shadowOffset = 0,0,0 macroCloudMaterial { _Color = 1,1,1,1 _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _FalloffPow = 5 _FalloffScale = 3.5 _DetailScale = 1 _DetailOffset = 0,0,0 _DetailDist = 1 _MinLight = 2 _FadeDist = 100 _FadeScale = 100 _RimDist = 0.25 _RimDistSub = 1 } scaledCloudMaterial { _Color = 1,1,1,1 _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _FalloffPow = 2 _FalloffScale = 3 _DetailScale = 6 _DetailOffset = 0,0,0 _DetailDist = 0.0012 _MinLight = 0.5 _FadeDist = 2.25 _FadeScale = 0.00375 _RimDist = 1 _RimDistSub = 0.01 } } } no commits have been made in the past month on any branch except for the license change just released - where are you seeing nightly builds? i'm intrigued...

That blue line is vanilla ksp functionality IIRC, the bug occurs with the planet atmosphere layer in EVE:Overhaul, the one that has the R,G,B, opacity settings and the visibility settings

you're using the default config file that comes with the EVE:Overhaul - replace it with one mentioned a few posts back, by me and it'll be a better experience immediately... with that said there is a bug with EVE:Overhaul where the atmosphere rendered on the dark side of the planet has the same light emission as the atmosphere on the light side (i havent found a way to get rid of this via just config changes) ... on the date issues, the day first makes no sense first because a day alone means nothing, i have no frame of reference and i cant tell when in estimate that is happening... the year by itself lets me narrow the date down from all eternity down to 1 year, thats a great chunk of reduction right there, furthermore , a month by itself allows me to narrow the time down to 1/12th of a year once the year is known, thats a great reduction as well... YYYY,MM,DD makes total sense... UNLESS we're communicating in a way where we can assume to alway be talking about the current year...

The cities are currently in development by Astronomer - the are not a default part of EVE or the EVE:Overhaul - they are part of a configuration pack that Astronomer will be putting out once EVE:Overhaul is released. The current in development version of EVE is the EVE:Overhaul, which works in KSP 0.24.2 but has some bugs and a very bland, boring default cloud/atmosphere configuration file. Download the EVE:Overhaul from here for your correct operating system (x86-Release.zip or x64-Release.zip), then check a few pages back for a better replacement to the default clouds.cfg file.

What version of EVE? The overhaul, the 0.23.5 version (which isnt technically supported in 0.24.2) - ín EVE:Overhaul there's a cloud rendering bug in map view and station view The only way BA works with changing the atmospheres and graphics is through EVE - without EVE, BA doesnt work... also BA does not currently support EVE:Overhaul BA, i believe is configured to use RSS so the placement of lights for cities is based on a scaled up sized Kerbin, either 6.4 times larger or 10 times larger, that would make sense why BA is placing lights in the water on your normal sized Kerbin

no i'm not using BA, WololoW (awesome AoE reference in that name BTW, Phoenicians FTW!) had a good idea for diagnosing the problem, as long as your bits are correct, trying without BA EDIT: I just looked in to BA and it appears that they use the old format of config files, not the format currently used in the Overhaul branch of this mod - i think that's likely your conflict right there

try replacing all the text in your file with the text in the file i've modified below (i've been tweaking things to my preference for Kerbin the past couple of days) and see if it helps at all with your render distance issues i have a few additional stat modifications in mine that aren't present in yours which could help EVE_ATMOSPHERE { Kerbin { kerbinAtmosphere { altitude = 4000 speed = 30 atmosphere { atmosphereMaterial { _Color = 0.41, 0.80, 1, 0.25 _Visibility = 0.00001 } } } kerbinCloudVolumetric { altitude = 3600 speed = 100 layerVolume { texture = BoulderCo/Atmosphere/Textures/kerbin1 offset = 0,0,0 particleMaterial { _Color = 1,1,1,1 _TopTex = BoulderCo/Atmosphere/Textures/particle/1 _LeftTex = BoulderCo/Atmosphere/Textures/particle/2 _FrontTex = BoulderCo/Atmosphere/Textures/particle/3 _DistFade = 0.5 _DistFadeVert = 2e-5 _LightScatter = 1 _MinLight = 10 } } } kerbinCloud2D { altitude = 8000 speed = 100 layer2D { detailSpeed = 60 offset = 0,0,0 shadow = true shadowOffset = 0,0,0 macroCloudMaterial { _Color = 1,1,1,1 _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _FalloffPow = 0.5 _FalloffScale = 0.5 _DetailScale = 0.5 _DetailOffset = 0,0,0 _DetailDist = 0.5 _MinLight = 10.5 _FadeDist = 1 _FadeScale = 1 _RimDist = 1 _RimDistSub = 1 } scaledCloudMaterial { _Color = 1,1,1,1 _MainTex = BoulderCo/Atmosphere/Textures/kerbin1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _FalloffPow = 2 _FalloffScale = 3 _DetailScale = 6 _DetailOffset = 0,0,0 _DetailDist = 0.0012 _MinLight = 0.5 _FadeDist = 2.25 _FadeScale = 0.00375 _RimDist = 1 _RimDistSub = 0.01 } } } } Mun { } Minmus { } Duna { } Ike { } Dres { } Jool { } Laythe { } Vall { } Tylo { } Bop { } Pol { } Eeloo { } Sun { } Moho { } Eve { } Gilly { } }

@BadManiac , @forsaken1111 - the problem, like Harry said, is that you're trying to bluntly and rapidly angle your rocket - with NEAR or FAR you need to gently slice through the air, instead of smacking it with a flat baseball bat in vanilla KSP the game simulates a flat bat flying through the air, smacking the air all the way up to space, but instead of flipping your ship, its makes your rockets work harder and burn more fuel - with proper drag you're actually cutting through the air (if you make your ship correctly and point it correctly) and making it easier on your engines, leaving you up in space in a stable orbit while expending less dV (sometimes over a 1,000dV saved)