Jethro Bodine

Update: so after a bit of trial and error, I believe I may have fixed my problem. I went into the config settings for Kerbin and changed "drawOverCloudsAltitude" from 100000 to 1000000. There seems to be slightly more aliasing around the edge of the planet, but otherwise my issues with Kerbin going dark have vanished.

Okay, I take back what I said. Camera position, or more specifically, magnification appears to be the culprit. Here are two screenshots where I have only slightly altered the zoom level with my mouse scroll wheel: Before After It would seem the further I zoom out the camera, the more likely for this darkening effect to occur. And once I discover the threshold, I can correct this by simply zooming in a bit closer. Again, if this is a known issue, my apologies.

Not certain if this is a bug, known issue, or a feature I'm just too dumb to recognize, but this has been happening relatively often since 246: Before After (Dark Phase) The "dark phase" lasts approximately 5-10 seconds, then goes back to the "before" state. It typically happens ~100km, but can occur at greater and lesser altitudes as well. Camera angle doesn't appear relevant; the phenomenon will happen and resolve itself even from a fixed camera position. I'm curious if this isn't Longitude related, but haven't had the time to investigate extensively. Here's my current Scatterer settings. Most features have been disabled. Other installed mods include EnvironmentalVisualEnhancements and MechJeb, though it seems unlikely the latter should have any impact. Running KSP_x64 in OpenGL under Windows 7. All in all it's a relatively minor quirk, easily overlooked, but if there's a way to prevent or correct it, that'd be nice too.

That's true, hehe, but I really would rather not have to re-adjust my monitor for every other purpose/application than playing KSP.

Hehe, up for any requests? Seriously though, you're probably best suited to answer this... would it be possible to make an addon that allowed some basic color correction/fine tuning to stock KSP? Nothing crazy fancy or sophisticated... maybe just a little brightness/contrast and color saturation control? I'd love my colors to have a bit more "pop" than stock, but hesitant to resort to injectors like ReShade or SweetFX. Is what I'm talking about within the realm of possibility, or more trouble than it would be worth?

So as I'm making progress customizing and fine tuning my EVE setup, I've gotta say I'm curious about the "EVE_ATMOSPHERE" section. Is there documentation or examples of this feature? Or is it simply not fully implemented yet? I tried fiddling around with it, but the best I could do was change color values.

You're too modest, Rbray.. but thank you for your quick reply! I'm guessing the cube mapping textures are what I'd be looking for in higher resolution?

Hello there! I have a (perhaps dumb) question I was hoping someone might be able to help with. I'm trying to add a "Snoopy cap" to all my male Kerbalnauts, and have been using the above texture (kerbalHead.png) in the "Default" folder of TextureReplacer. I'm fairly certain I didn't have any issues prior to 1.1 KSP, but now I'm getting results like this: If you look closely, the scientist Kerbals have turned albino (all white), and the others are all wearing the Snoopy cap. Is there a way I can correct this? I just want my Kerbals in space suits to have the Snoopy cap. Thank you!

Hey rbray! Just wanted to preface this post with a hearty thank you for the hours upon hours of enrichment you've added to my game. I really, really appreciate all you've done for the community! Now for some dopey questions... Is there a way to reduce/minimize the appearance of tiling in clouds? I could have sworn there was a setting I could adjust in previous versions of EvE, but I'm clueless what to change in the reboot. Also, and I appreciate this is probably just a limitation of scaling up a bitmap, but is there a way to reduce/minimize the artifacting (as seen in the above image) or pixelation of clouds at low altitudes? Last but not least-and I'm not even sure if this is an EvE thing or a stock KSP "issue"-I've noticed what appears to be "z-fighting" between the terrain and shoreline at various altitudes. Ideally, and perhaps unrelated, I'd like to soften the transition to make the contrast less pronounced. Regardless of that however, there is a "shimmer" where it would appear the game client is trying to resolve the shape of bodies of water. Kinda hard to demonstrate with a still image, but I'm wondering if it's possibly related to the city textures?

Forgive me if this has been requested before or currently exists in some manner and has eluded my Google-Fu, but I would be grateful if someone could implement an addon that would allow color balance and saturation adjustment from within KSP. I'm currently using a third party injector (ReShade) to accomplish this, and it's relatively effective, but I'd much prefer something a little more native with less overhead. It might just appeal to my personal taste, but here are some examples of what I'm trying to accomplish: Before After Before After

Take a peek at the author's (alexustas) profile. He's got similar IVAs for the Mk1-2 Command Pod and the Mk1 Cockpit.

Would love to see a perhaps more compact variant of the Extendable Docking Port released for other vehicles like the ALCOR and MK1-2 Pod.

From what I could gather, she uses the IVA visor (on the loading screen) as an EVA visor. I was able to "fix" it in TextureReplacer by using the same image for kerbalVisor and EVAvisor. I'll have to give this a try! Thanks!

Val has a visor for me. However it's using "kerbalVisor", rather than the "EVAvisor" texture.

Boy I'm a knucklehead. I can't believe I fat-fingered "$" instead of "@". I guess that's what I get for typing with mittens. And yes, hotrockets was also modifying ionengine. Good call, sebi! Thanks again everyone. Everything is working as intended now.

Wow, I'm a colossal dumb dumb. Still getting unexpected results though. Here's my revised scripts: @PART[ionEngine]:Final { @MODULE[ModuleEngines] { @PROPELLANT[XenonGas] { DrawGauge = True } } } Doesn't draw the fuel gauge. Is there something inherent to XenonGas (note: correct spelling ) that prevents this function? And here's my revised intake script: $PART[IntakeRadialLong]:Final { @MODULE[ModuleResourceIntake] { @area = 0.25 } } Got this: That's two copies of the intake. One has the default part values, the other has my modified @area value. This really has me puzzled. I have no idea why it is it creating a second part rather than just modifying the original. Is it possible there's a conflict with other scripts? Or maybe my ModuleManager.ConfigCache file is corrupted? Would it hurt anything to delete the latter? Thanks again!

Clearly I'm doing something wrong. Perhaps someone can help? I was attempting to add "DrawGauge = True" to the stock ion engine. Initially, I went with: @PART[ionEngine]:Final { @MODULE[ModuleEngines] { @PROPELLANT[XeonGas] { DrawGauge = True } } } But that didn't work; the stock engine remained unchanged. So I decided to get a bit more aggressive and tried this: @PART[ionEngine]:Final { !MODULE[ModuleEngines] {} MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform exhaustDamage = False ignitionThreshold = 0.1 minThrust = 0 maxThrust = 2 heatProduction = 0 PROPELLANT { name = ElectricCharge ratio = 1.8 } PROPELLANT { name = XenonGas ratio = 0.1 DrawGauge = True } atmosphereCurve { key = 0 4200 } } } Eureka! That worked! I got "DrawGauge = True" to display as intended. However on closer inspection I realized I had another problem. My part now had two engine modules: the one I added with drawgauge and the stock version. It would appear the line "!MODULE[ModuleEngines] {}" was not deleting the default engine. Similarly, I tried to alter the Mk-2 Structural Intake. First I went with: $PART[IntakeRadialLong]:Final { @MODULE[ModuleResourceIntake] { area = 0.25 } } That resulted in two (seemingly) identical parts. That's right; I didn't have just one Mk-2 Structural Intake show up in the VAB, I had two. And it didn't appear to change the intake area in either. So like the ion engine, I tried this: $PART[IntakeRadialLong]:Final { !MODULE[ModuleResourceIntake] { } MODULE { name = ModuleResourceIntake resourceName = IntakeAir checkForOxygen = true area = 0.25 intakeSpeed = 10 intakeTransformName = Intake } } Once again I got two separate intakes in my parts catalog, but at least this time one did have the proper change to area. I'm really confused. I can kinda see why the ion engine might be getting a 2nd module, assuming I got the syntax wrong using !MODULE, but why would (essentially) the same edit create an entirely separate part for the Mk-2 intake? Thanks in advance for any help/tips!

Bro, I'm still enjoying the heck out of the old, old, old version of the mod. And I couldn't even begin to express how much your mods (ActiveTextureManagement, especially) have enhanced my KSP experience. There's absolutely no need to apologize. The new stuff looks freakin' amazing and I'm 100% certain will be worth the wait. Take your time, and many, many, many thanks!

Holy karp! I didn't see this coming - MUST HAVE! I spent the past three days fiddling around with helicopters - it's like you read my mind, helldiver. This looks amazing... can't wait! I know you don't take requests, but a Sikorsky or Chinook for heavy lifting, rescue, & recovery would be pretty sweet. Just saying.

Bring sunscreen, trust me. Also, not sure if you're planning on going to Epcot, but if you do, book dinner reservations for the United Kingdom Pavilion. Not for the food, mind you - but for the fireworks. It's the best seat in the whole themepark if you can get reservations for their outdoor patio. Have a fun and safe trip!

<---Target audience very much appreciates this!

I'm not sure how licensing works over there, but perhaps taking a look at http://www.nexusmods.com/skyrim/ might be useful? I know they have a *ton* of HD texture packs for grass/mountain/sand/water.

As suggested by vanlock, a humble request for RuBisCO and Thesonicgalaxy (and anyone else releasing custom packs for EnvironmentalVisualEnhancements)... Would you please consider including a separate .txt file of *just* the additions/modifications you've made, or at least //comment your changes extensively? It would make it much easier for those of us merging different packs into our own custom settings file. Thanks!

There once was a time when people actually paid for music too. Crazy, right?

Should be fixed in rbray's next release.