Search the Community

I am about to land on Eve and want to make it extremely efficient!

Hi everybody. I recently downloaded the Other Worlds mod, but I forgot to uncheck the boxes to avoid installing other mods. And after that, my EVE mod broke down. please help me fix this

Eve is the hardest stock planet to return from, and so any full-scale (manned) Eve mission is going to involve some sort of either gigantic or glitchy lander design. Sending a gigantic lander through interplanetary space in turn requires an even bigger launch system. I've found it can get out of hand really fast, often surpassing the stock part diameters tank sizes into gigantic tangles of asparagus staging. I'm just wondering what y'all's launch systems look like for Eve. Do you go for aesthetics? Over-engineered dV budgets? Low mass? SSTO? I personally tried to go for an aesthetically pleasing rocket: What are y'all's designs?

Pood's OPM-VO (Outer Planets Mod - Visual Overhaul) Latest Release - v.0.3.5 "The Matoro" Pre-Release Beta - 23rd Sept. 17 Due to some users having issues with compatibility, please find below a list of the dependencies and the current builds used to run OPM-VO. Please ensure that you are running at least these versions of the dependencies or later releases: Dependencies: EVE: https://github.com/WazWaz/EnvironmentalVisualEnhancements/releases/download/EVE-1.2.2-1/EnvironmentalVisualEnhancements-1.2.2.1.zip (Release build 1.2.2-1) Scatterer: https://spacedock.info/mod/141/scatterer/download/0.0320b (Release build 0.0320b) Kopernicus: https://github.com/Kopernicus/Kopernicus/releases/download/release-1.3.1-3/Kopernicus-1.3.1-3.zip (Release build 1.3.1-3) Module Manager: https://github.com/sarbian/ModuleManager/releases (Get latest release build) Outer Planets Mod: https://github.com/Galileo88/OPM_Galileo/releases/download/1.2.4/OPM_Galileo.v1.2.4.zip (Unofficial KSP 1.3.1 build 1.2.4) Suggested Mods: Stock Visual Enhancements: https://github.com/Galileo88/StockVisualEnhancements/releases/latest - Galileo and I work together to ensure our mods are compatible and SVE gives the stock planets great atmospheric and visual effects. Stock Visual Terrain: https://github.com/Galileo88/Stock-Visual-Terrain/releases/latest - The texture pack that's built alongside SVE to make the stock bodies look amazing. -------------------------------------------------------- For all information regarding downloading/installing/using/licensing etc. for this mod, please refer to the Readme. This mod includes version checking using MiniAVC. If you opt-in, it will use the internet to check whether there is a new version available. Data is only read from the internet and no personal information is sent. For a more comprehensive version checking experience, please download the KSP-AVC Plugin. Changelog: v0.3.4 - 08th Apr. 17 - Edited Tekto's & Urlums EVE cloud layers slightly, amended SVE integration due to SVE's new file structure and added in Kopernicus' new Ring Shader effects for all bodies (if Jool rings are present, they are maintained). Kopernicus' Ring Shader update is not incorporated in the latest Kopernicus release yet, however, the patch can be downloaded here to be installed into your Kopernicus directory: https://mega.nz/#!vUowhKgB!PAIeK8M1KlBOXhcBNglxGTq6MzSiqFxF27fAXYOD8_w v0.3.3 - 02nd Apr. 17 - Added Sigma OPM-Tilt support, slight change to Urlum's rim exposure and now leveraging SVE's cloud detail textures if SVE is installed, if not, uses own placeholder texture as before. v0.3.2 - 01st Apr. 17 - Forgot to render Tekto's oceans... doh! Ocean shaders on Tekto have been enabled by adjusting Ocean Alpha values. v0.3.1 - 01st Apr. 17 - Fixed scatterer's configs so they play well with other mods and don't repeatedly add OPM body configs to other body's ones. v0.3.0 - 30th Mar. 17 - KSP 1.2.2 Compatibility update. v0.2.0 - 8th May. 16 - Rebuilt from ground up for KSP 1.1.2; Thatmo work has not been included. v0.1.2 - 11th Jan. 16 - Included support for OPM Tilt and Kopernicus Expansion. Compatibility with KSPRC has been fixed by including updated pqs.cfg file for KSPRC (bundled in distribution). v0.1.1 - 8th Jan. 16 - Forgot to include Scatterer files within .zip (Doh!) v0.1.0 - 6th Jan. 16 - Initial Release - First GitHub commit & beta release --------------------- Original Initial Post: With the release of EVE for 1.0.5 and Scatterer gaining multi-planet support I decided to jump right in and start messing around with configs for OPM as I rarely play KSP without it. As the two mods are still very much in their infancy really with respect to 1.0.5 and their latest releases I am learning as I go and have never shown any of my previous tinkerings with EVE in the past on these forums (I used to run a modified AVP-I, AVP-EoO and KSPRC mashup in previous versions of KSP). I initally started working on Tekto as it has a pretty crazy atmosphere in OPM canon. Current progress can be seen here: I also have very hazy mist clouds rumbling over the lowlands that look a lot like heat haze up close. These are very much still WIP and I am still learning new tricks/techniques with EVE's new volumetric cloud options. The look I have gone for is a very chaotic, dense atmosphere that is suffering from a sever over abundance of a toxic gas that could be generated from underwater plant life or similar. After visiting MatoroIgnika's Twitch stream he commented to me that he loves Thatmo and how it should look like a Triton analog, so... next on to Thatmo! Like Triton, Thatmo has a very think atmosphere but it can be visualised from orbit. It is very hard to convey through screenshots but a very thin, wispy cloud cover has been added, viewable from orbit. Down on the moon's surface, clouds are visible somewhat more than they are from orbit purely for the fun aspect of actually seeing the atmosphere present. Triton's albedo coefficient is one of the highest in our whole solar system and so I decided to make Thatmo very reflective and bright to convey the shiny, ice like nature of the moon. Its pretty blinding down on the surface. As the surface of the moon is refracting light through its ice layers I have also introduced a chromatic aberration-like quality, visible when in orbit. Finally at this point I have been tinkering heavily with texture generation for Gas Giants (as OPM has 3 of them!) using curling noise for procedural fluid flow to try and create some really interesting base texture maps for the gas planets. It has been pretty laborious switching between Linux running the generations and Windows for Photoshop texturing (I don't like GIMP at all) but its getting a lot easier to manage now I am use to the process. I should be able to utilise this technique to also create completely procedural cloud texture maps also with a bit of work that could range from thick stormy stuff ala Venus down to very light, high atmo wisps. As you can see there are a lot of different style outcomes using the same texture by changing the input parameters. Let me know what you like and what you think would suit each gas planet as I can create a variety of effects. Generation takes around 20 minutes and then I have to wrap a cubemap back into an rectilinear texture for use within KSP. All of this is really in its infancy and I created this thread as a place to store my ongoing efforts whilst also being able to receive some feedback. Progress may come in fits and spurts around work; I get two weeks off over the Christmas period I may be able to cram a load of texturing in. Depending on how far I continue the final piece of the long-term puzzle would be re-texturing the base moon textures to hi-res variants. Feedback is greatly appreciated and any thoughts or critiques are appreciated, even though at the moment all you are able to look at is screenshots. Once things become more substantial I will upload configs and textures in a pack for testing out within KSP. At this point I will apply a suitable license. Update 12th Dec. 15 - Been doing a little tinkering to test some different variables in the texture generation and thought... "why not upload some short clips on Steamable?" So: Sarnus - Test WIP Neidon - Test WIP Update 3rd Jan. 16 - Porting Tekto to new EVE syntax. Fog on Tekto 1 - Showing fog and dust clouds at low level. Fog on Tekto 2 - Showing the post processing depth buffer level at low level. Update: 6th Jan. 16 - v0.1.0 Beta Release - Initial Release (see changelog for further updates) Whad'ya think?

i have the worlds first mission to land on eve and the one to plant a flag on eve as well i spent hours reading multiple posts on varying different websites and trying out multiple different designs and after finding one that worked ok i added a 10m heat shield on the side closest to CoM but it flipped over i have tried everything from moving around the CoM to swapping the side the heat shield is on and i just cant figure out why it keeps flipping over i cant figure out why the insert image from URL keeps showing as red so i will just put the link to the screen shot here https://steamcommunity.com/profiles/76561198409027321/screenshot/2460738484202939217/

Just wondering if anyone could make this or has made it, im aware rss reborn has volumetrics for the the earth, mars, venus and titan, but the gas giants are missing the volumetrics support. A config for this, or a tutorial on how to make configs for the volumetric clouds would be amazing to have. i have read the wiki provided by blackrack but i'm not really sure where to start. Any help would be massively, massively appreciated. Thanks in advance!

I've started working on a patch for the volumetric clouds version of EVE and JNSQ. The biggest issue I'm having is that the cloud texture clips into mountains when viewed from certain altitudes. The obvious solution of just increasing the cloud height causes issues with the appearance of the volumetric clouds when seen at lower altitudes, since I have to move them up almost two kilometers. I thought messing with Scatterer's "flattenScaledSpaceMesh" would help but that didn't do anything. Do I have any other options besides just raising the clouds?

Given the extreme environment of Eve, I’ve always wondered what effect this has on engine performances. The Vector, Dart and Mammoth are often recommended for Eve, but I never really saw any quantitative numbers backing them up. Fortunately, the staging interface in the VAB lets us set the environment to Eve at sea level and it’s only a matter of using math to derive Isp values from the deltaV values. As expected, I found that the Vector, Dart and Mammoth do pretty well while most other engines suck. Interestingly, the Thud also performs pretty okay. The highest Isp values for Eve are: Dart: 267; Vector: 152; Thud: 101; Mammoth-II: 97; Mainsail: 96; Spider: 74. All others are below 50 (except possibly the Rapier; I forgot to test that one). The Isp values translate to the highest thrust values: Mammoth: 1332; Mainsail: 501; Vector: 411; Bottle-Rocket: 230; Clydesdale: 228; Dart: 142; Kickback: 115; Thud: 92. Using Eve’s gravity of 16.68 m/s2 (1.7x Kerbin), the highest TWR values are: Dart: 8.5; Vector: 6.2; Hammer: 5.6; Mammoth-II: 5.3; Mainsail: 5.0; Thud: 3.5; Kickback: 3.3. Optimal launch configuration While the Dart has the highest efficiency and TWR, it lacks absolute thrust and an efficient engine is useless if it can’t get its payload off the ground. Since the delta-V calculation doesn’t account for gravity pulling the rocket down, I find that instead the most useful quantity for a launch is the total change in momentum (or impulse) that an engine can deliver, which is equal to the net upward force integrated over time: J = integral (F - g*(mpayload + mengine+ mfuselage + mfuel - R*t)) dt Here F is the engine thrust, g is the local specific gravity and R is the fuel burn rate in kg/s. We can assume that for most cases mfuselage = 0.125 * mfuel . The total burn time can be calculated from t = mfuel /R. The equation then results in: J = (g/R) * ((F/g - mpayload - mengine)*mfuel - 0.625*mfuel2) By solving for dJ/dmfuel = 0, we can find the amount of fuel for which the maximum impulse is achieved: mfuel = 0.8*(F/g - mpayload - mengine) Interestingly, this means that for every ton of payload, you need to substract 800kg of fuel to keep the impulse maximized. From this, we also get the optimal launch TWR: TWR = 1 + (F/g - mpayload - mengine) / (9*F/g + mpayload + mengine) This means optimal launch TWR is always <1.111, getting lower with increasing payloads and gravity, depending on the engine. By adding the optimal fuel mass to the impulse equation, we find the maximum impulse: Jmax = 0.4*(g/R)*(F/g - mpayload - mengine)2 Since g=16.68 m/s2 for Eve, and F, R and mengine are constant for each engine, the only remaining free variable is mpayload. Engine comparison As you can see, the Mammoth-II can potentially deliver the most impulse by far for any payload. In second place is the Vector for payloads below 12t, but above 12t the Mainsail would be a better second choice. Without any payload, the Dart has almost as much maximum impulse as the Mainsail, but that quickly drops off. However, to get the most out of the Mammoth, you’d need an enormous amount of fuel. Without local production, this would all need to be brought in from Kerbin and you would need to manage to land it on Eve without burning up in the dense atmosphere or smashing too hard into the surface due to the high gravity. So, maybe the best value to look at would instead be the maximum impulse per kg of starting mass. The math becomes a bit more complicated at this point, but the Dart would now become the best choice for payloads below 2.5t. Between 2.5t and 5.3t the best choice would be the Vector and for payloads above that the Mammoth-II brings the most impulse per kg: Now, do keep in mind that these are the values per engine. Given the LG size of the Mammoth-II, you could argue it should actually be compared to 7 SM or 3 MD engines for similar footprints. In that case, the Mammoth becomes completely inferior to 7 Vectors and would only be better than 7 Darts for impractically heavy payloads of over 40t. It would perform about the same as 3 Mainsails or 36 Thuds: 7 Vectors would however require much more fuel for maximum impulse than a single Mammoth. So yet another way is to compare the amounts of engines that need a similar starting mass to achieve their optimal impulses. For very large payloads, that would be the case for either 7 Darts, 3 Vectors or 1 Mammoth-II. For smaller payloads, the 7 Darts would deliver far more momentum, followed by the 3 Vectors: Staging configurations For a final comparison, I considered a payload of about 3t (a command pod, a Terrier, sufficient fuel for a circularization burn and some appendices) and an asparagus staging configuration. Using 7 Dart engines would require 3.6t of fuel for the center engine and 13t of fuel for each of the 3 outer stages (so 6.5t per engine), giving a total of 24,000 kNs of impulse and a starting mass of 58t. Using 3 Vectors would require 14t of fuel for the center engine and 34t of fuel for the outer stage (so 17t per engine), giving a total of 22,500 kNs of impulse and a starting mass of 70t. A single Mammoth-II would require 50t of fuel for a total impulse of 18,300 kNs, with a starting mass of 74t. Again the Dart comes out on top, but I do have to note that I used sea-level values for all stages. Performances of the Vector and the Mammoth would especially improve a lot while gaining altitude, while the Dart would only improve a bit. You could consider using a Vector at the center stage with 6 Darts on the outer stage, but the additional fuel for the Vector would then count as a higher payload for the prior stages. This makes the Darts much less effective and it would only result in a total of 19,300 kNs of impulse, while having a starting mass of 74t. In fact, since the Dart suffers so much from higher payloads, asparagus staging is probably not even the most efficient way to use it. Just using 7 Darts without staging would give us a much larger impulse of 43,200 KNs, for a starting mass of just 55t. Using drop tanks while keeping all the engines would be even better. Of course, this doesn’t account for the effects of drag as a result of the wider rocket and the increased acceleration, so the best results might actually be achieved by an in-between solution. Conclusion Given all these results, I would at least have to conclude that the Mammoth-II and the Mainsail are never good picks, at least not when they have to be brought in from Kerbin. The optimal choice would be to use Darts. For larger payloads the Vector is a viable choice to lower the amount of engines, or when stabilizers aren't enough and you really need thrust vectoring (which the Dart doesn’t have). The only advantage that the Thud brings is that it’s radially attachable, but you would need a lot of them to make them work. This was pretty interesting to work out as preparation towards the Under Pressure mission, but it's all just theoretical. I don't have a lot of actual experience with Eve, so I'm wondering how this all corresponds with your experiences.

Out of nowhere those black patches appeared on my sandbox save, idk what are they cities lights ? On map view they doesn't exist, but cities map do. Any help ?

Note: GGE and GGE-Moons are now integrated with KSRSS! Unlike most mods I can send a thousand screenshots and you still won't understand the beauty of this mod. So here's two videos! Still confused? This mod includes a variety of other features such as: -16k Textures with 6 bands for Jupiter. -16k Textures with 8 bands for Saturn. -10k Rings for Saturn. -4k Textures for Uranus with 4 bands. -8k Textures for Neptune with 5 bands. -All bands utilize UV Noise causing them to wiggle and move over time. -Tilt for Jupiter, Uranus and Neptune. -New optional rings for Saturn, Jupiter and Uranus. -Scatterer fixes for KSRSS's gas giants. -Fixes Titan in KSRSS. -Full revamps of Io, Europa, Ganymede and Callisto. Gallery bellow Compatibility This mod is not standalone is designed to work with other visual packs. In other words this mod works with other visual packs. This mod is also designed to be compatible with both RSS and KSRSS with no additional patches needed. Download | LATEST RELEASE 0.6 Primary -https://github.com/ballisticfox/GasGiantsEnhanced/releases/tag/v0.6 Backup/CKAN - https://spacedock.info/mod/2969/Gas Giants Enhanced Notice & Licensing This mod is still very "tech-demoish". Gameplay friendliness is not completely guaranteed and you may have serious performance hits using this mod. This mod is license under CC-BY-NC-SA. You may use textures in this mod. Credit must be given. May not redistribute textures for commercial purposes. Must be under CC-BY-NC-SA. Credits files are provided in each texture set, if you want to use the textures, just throw the credits from the folder into your texture folder. Want more? The final plan of this mod is to completely remake all current gas giant moons and add more minor moons.

The KSP community has created many AMAZING graphical mods using EVE(Enviromental Visual Enhancements), and I want to do the same. My question is, how do I use the mod to create a cloud layer? What should I do if I want to add citylights to a specific celestial body? Any help would be greatly appreciated.

22 years ago, Kerbin was hit by a comet. The 16 kerbals of the Space Station Ranger used its remaining fuel deposits to flee to Eve during the lucky transfer window it got. Arriving at Eve, the crew landed in their various Kerbin reentry pods and began to build underground bases to shield from the radiation and the harsh environment. Now, the 34,000 residents of Eve's only city New Kerbin City but on Eve hopes to return to Kerbin. They do not know how they could escape the thick atmosphere and strong gravity, but these hardened Kerbals knew one thing. It would not be easy. ----------------------------------------------- Yup. A new career game. But not just any career. This time, the KSC is on Eve and HARD MODE. No quicksaves, no reverts, tougher contracts and funds. And Unkerballed Start. And SimpleConstruction. And all their dependencies. But why SimpleConstruction? Because the Goal for this career is to COLONISE KERBIN. This mission report will have some story elements. Jeb: Like this. ----------------------------------------------- Let's get to it.

There is a kerbal wiki about this: Faz - Kerbal Space Program Wiki. It should be considered for ksp2 if the dev's want it.

I was experimenting with high altitude propeller assisted launch vehicles for low eve orbit. I can just about reach 20k in height before loosing speed and flipping out. The propellers don’t rotate the craft and are at the com. They are constantly getting fed power so I don’t see what I’m doing wrong. I want to be able to reach 30k or higher to save vessel mass but I was wondering if anyone has help for this issue. Also the launcher can go into orbit. It just needs props that can go that height.

Considering that planes are probably the single biggest upgrade over stock ksp1, i figured id make a challenge that would incorporate them nicely well providing unique challenges to both new and experienced plane builders Once atmospheric heating is enabled, the maximum speeds that people will be able to achieve will likely be a lot lower, so this is a limited time opportunity to set an all time record that likely wont be broken in the future. The eVe.max challenge is: achieve the highest speed possible on eve under 1000m (sea lvl) Rules: 1. It does not matter how you get to eve, cheats are encouraged for eve transport. Id recommend using lazy orbit to ''land'' your self ~2000m above eve's surface to start the run. 2.The speed record MUST BE below 1000m, higher altitude runs will not count. 3. V.max must be reached in level flight (no diving). 4. No infinite fuel. 5. Craft doesnt have to be manned, but it will need a powerful enough antenna to maintain legit contact with ksc if you choose to make it a drone. 6. There will be separate leaderboards for kraken drive craft. 7. No staging How to enter: 1. Submit a picture of your craft at its highest top speed with both the speed indicator and altimeter (set to altitude above sea level) visible. 2. Have fun Leaderboards Vanilla: ID Date V.max Alt. 1 Sequence 3/21 472 951 2 3 4 5 6 Kraken drive: ID Date V.max Alt. 1 2 3 4 5 6

As part of the Apollo Applications Program, a manned flyby of Venus was planned by NASA in the 1960's. Similarly, the former Soviets had planned a flyby of Venus for their TMK-E variant rocket. Obviously, neither program saw the light of day. No worries! We can recreate what should have been our gloriously bright future in our currently not-so-glorious, mediocre present! KSC is proud to announce: KERPERNICUS : KER-MANNED MISSIONS TO EVE Challenge Tiers: [EASY DIFFICULTY] : Complete a flyby of Eve, take a screenshot in orbit, return your Kerbals safely, all in ONE GO! Your Reward: [CHALLENGE DIFFICULTY]: Complete a two-way crewed mission to Eve. Land your Kerbals, take a screenshot of them dancing alongside their flag, and return them to Kerbin alive! EXTRA POINTS if you encounter a Kraken-attack and successfully recover the mission! Your Reward: [IMPOSSIBLE DIFFICULTY] : IN KSP2 PRE-PATCH VERSION (First release version of KSP2 Early Access) Complete a two-way crewed mission to Eve. Land your Kerbals, take a screenshot of them dancing alongside their flag, and return them to Kerbin alive. Your well-deserved Trophy: Post your screenshots and Mission Report in the comments! If you need a high-quality, background transparency version of the badges, let me know! Good luck!

Last month when I was surfing in the forum for topics about 0.17, I found a topic about Eve return. I was shocked by this idea, which was treated as impossible before. I did tons of testing but none of these designs succeed entering Eve orbit. But, just before I give up, a video of Scott Manley appeared. He made it. I copied his craft and made some tiny tweaks, reduced this craft's part count. So, let's return his miracle!

OMG FAM, IT'S FINALLY HERE!!! I had always wanted to build a custom PC, and had made an agreement with my wife that we would probably wait until KSP2 came out. Well, I'm typing this out on my new PC, that I finished just a few days before the release. i5-12400 rx 6650 xt 32GB DDR5 2TB M.2 Drive for games 500MB M.2 Drive for OS and programs 4TB 2.5" SSD Drive for media And as much RGB as I could find for 20% more FPS Well, you can guess what I spent my day doing, but I figured you might also want to see. I'm playing the game on 1080 Medium settings. I started off with a good ol' mission to the Mun, and was able to make a return trip as well. From there, I decided to try a trip to Eve. I also figured out how to make GIFs of my mission, but can't figure out how to embed them here. Here they are if you want to see some cool GIFs. https://imgur.com/4nap7oy https://imgur.com/jfYrq9E https://imgur.com/kZKd5vk https://imgur.com/jvNJpGF I guess I'm going to have to send a rescue mission, but that will have to wait until tomorrow.

The challenge is simple. Using only ion engines from the very beginning, get a kerbal to Eve's surface, plant a flag, and return to kerbin. ONLY Ion engines allowed Stock No rcs You can use a rover to move your launch site to a higher place No abusing Launch Stability Enhancers or anything like that to make your launch higher. The first stage must be a reasonable distance from the ground Or is it actually impossible EDIT: You can positively overclock ion engines, but not negatively (for infinite fuel) SCORING: +100 points for completing the challenge +50 points if you did not move your launch site +50 points if you did not use batteries +20 points if you did not use RTGS x1.2 points if you get 220 points (Did all the above)

Hello guys, my game is crashing after some time, but I cannot find the culprit or the cause The crash happens with the Unity window and a "loading bar", here is the crash logs https://www.mediafire.com/file/9a8vgy87y6x6u3s/Crash_2023-01-23_130827080.rar/file My system configs are: (This pc is kinda old but still holding on hehe) Mods list:

For a while now I’ve been having mission-critical issues with Eve landers mainly with the 10-meter inflatable heat shield colliding with the lander alongside making the ship a reasonable size. I was wondering if there was a way to mitigate that particular issue. Thanks in advance.

Explodium Breathing Engines "Jet" engines that (actually!) use Eve's atmosphere and Oxidizer. License: MIT License except for re-coloured textures, which were derived from art belonging to Squad / Deported B.V. Download from SpaceDock or from GitHub. Supports KSP 1.12. and supports RealPlume Stock and now Waterfall. It had to happen. After good success with @GregroxMun's Alien Space Programs and @OhioBob's Eve Optimized Engines, along with an old discussion about atmospheric engines using oxidizer instead of liquid fuel, I just had to ask how hard it would be to make jet engines that would breathe "explodium vapour" likely found in Eve's atmosphere and burn it with oxidizer to produce efficient thrust. @JadeOfMaar and @wasml pointed me in the right direction, @DStaal filled in a few blanks, and I hacked together some parts. Introducing Explodium Breathing Engines. A set of cloned configuration files from stock jet engine parts that use oxidizer only, and a new resource configuration found hypothetically in Eve's atmosphere: "Explodium Vapour" evaporated from Eve's Explodium Sea. This vapour may also be present on other planets in popular planet packs. Further rebalancing has happened based on resource abundance and a pure ethane (C2H6) reaction with oxygen. Resource abundance now has a direct impact on engine performance. This is turning from proof-of-concept into something realistic, while still being fun to use. There really is some science behind this that I explain at the project's Wiki, and hammered out in a more recent add-on discussion thread. Modified parts include explodium versions of all intakes, oxidizer + explodium versions of nacelles, oxidizer only tanks and wet wings, and underworld-themed engines: J-21 "Hades" J-34 "Zephyrus" J-91 "Atlas" J-405 "Sphinx" J-X5 "Beelzebub" and let's not forget our favourite: CR-8 L.U.C.I.F.E.R. (Large Unkerbal Cycle-Interchanging Fueled Explodium Rocket) Introducing for 1.7, engines for gas giants, failed or otherwise. Consider this a counter-challenge for Team Galileo: J-22 "Dorothy" J-35 "Scarecrow" J-406 "Lion" J-X6 "Tinman" J-92 "Wizard" and finally the CR-9 S.L.I.P.P.E.R. (Science-Light Impossibly PerPosterous Explodium Rocket) All parts should have a distinct appearance to separate them from stock parts. I put all of the modified parts and ExpVapour resource configurations in a GitHub repository. MIT license to match OhioBob's choice for the Eve Optimized Engines. I'd be glad to let others into the project who know better than I do. The to-do list includes: (The to-do list is finished!) Rewrite parts as Module Manager patches to remove dependency on Squad art (Done!) Fix the intakes to work on Eve only, somehow (Done! Intakes are now zero EC harvesters.) Fix the resource config if needed, integrate with Community Resource Pack (Not necessary as it turns out.) Rebalance engine performance based on tester feedback (we might be almost done!) Produce different artwork to identify the explodium-based parts (I'm just missing some tricky parts.) Create RealPlume configurations; I'd like to do a different colour plume for these like the blue from an ethane flame (This was quite easy, as it turned out.) Maybe get some help with CKAN, publish to Space Dock (SpaceDock done, CKAN should be done) Known problems, should not impact play: Ore mining contracts will appear in Career mode when you unlock tech nodes with harvester parts. This might be a game design problem with contracts lumping all resource harvesters together. Pay attention to contract requirements, because there might be a "Gather 2000 units of Explodium Vapour" contract that won't make sense because there are no containers for it. No colourized textures are available for the Atlas engine or Big-OX wings. The wings don't take well to colourization, and the Atlas causes null reference exceptions if using an alternate texture. Harvesters have a small amount of ExpVapour loaded by default. This means engines will work for a few seconds at launch from Kerbin, but will quickly run out of vapour. This may be needed in KSP 1.3 though. Slow frame rates may happen if using the RealPlume configurations. Update SmokeScreen to 2.7.4 or later to address this. (KSP 1.3) Stationary harvesters will harvest zero ExV, such as craft on launch clamps or with wheel brakes engaged. Once motion starts, harvesters will start harvesting. (KSP 1.3) Engine resource shows up as "Ex V" instead of "Explodium Vapour" in VAB or SPH. Other resource name strings not affected for some reason. To use this part pack, grab a release from GitHub or SpaceDock, and put the "GameData\ExplodiumBreathingEngines" folder into your GameData folder. To use a RealPlume configuration, install RealPlume-Stock and update its SmokeScreen installation to 2.7.4 or later. If you don't install RealPlume, you'll still get a different engine plume for some engines but most will use the stock jet plumes. To use Waterfall plumes, install the Waterfall framework. Now with more Fire! Change log:

EVE. The final boss of KSP, the challenge is to head to Eve and back with no transfer windows or maneuver nodes . If you complete this, Please comment with video or photo evidence! P.S that screenshot is not mine. One I found on Imgur.com

Hi! I decided to do this challenge because I lost Val in an eve rover accident a day ago (don't worry, just Missing in action, but Jeb, her husband doesn't know that she is missing yet ) so, I decided to challenge you to return from Eve in the smallest spaceraft as possible. The rules are the next: The spacecraft must arrive to Eve without cheat menu (else, you're not allowed to compete) 1.1. You must record a video of ur whole mission, from the VAB to Eve, and then back to Kerbin to prove you got this criteria Your spacecraft must not only be the smallest possible, but also the lightest possible. The spacecraft must be Manned (but with kerbals, not with humans) You must get back to kerbin with a singe launch! (Don't rescue your Kerbal(s) or else u will get unqualified) You must LAND on Eve, else you will be unqualified You get 4 extra points by landing on Gilly before/after landing on Eve Mods and expansion DLC are forbidden If there's a tie, I'll judge by number of parts of your ship

Through my efforts in developing the mod Sol, I developed two different techniques for different visual needs that I believe uniquely distinguished Sol amongst other visual mod packs. Though that mod is now canceled due to still ongoing issues with the community, I do still want to see that these techniques make it into other mods, and rather than having people trying to reverse-engineer them through copies of my mod that, regardless of licensing, I still do not approve of being redistributed, I figure I may as well lay out a proper tutorial on these concepts so that people can just simply do as I did, and create their own mods. As part of this tutorial, you will want to have a photo editing software such as Photoshop or GIMP that can export to the .dds file format. I personally recommend GIMP because its free and relatively hassle free. I also recommend becoming familiar with NASA's Visible Earth website, found here, as the website is a treasure trove of not only inspiration, but extremely high quality visuals from which your work can be derived. All of the imagery of Sol was derived from the available imagery on the website, and through this tutorial you'll see how I translated the raw satellite imagery into workable textures for the game, and how the Dynamic system works. I will also acknowledge that this is a beefy post; I am a very verbose and thorough person, and through this reading I would hope it should give some idea as to how I think through things. DYNAMICS Intro: Dynamics is my term for a method of inducing EVE's innate layer functions to mimic the way in which Earthbound cloud systems form and dissipate over time. While EVE is not quite sophisticated enough to provide a true simulation, it does have the tools necessary to provide an uncanny approximation IF one puts in the effort to realize it. The How: How Dynamics works is fundamentally dependent on the nature of the detail texture. In EVE, two primary textures are responsible for the look of a cloud layer. These are listed as Main Tex, and Detail Tex. Main Tex to put it in simple terms provides the macro shape of a cloud, meaning that even if your texture is just flat Microsoft Paint drawings, it will take to the shape of what was drawn. Detail Tex is an additional texture that is overlaid on top of the Main Tex, and as its name implies, is meant to provide additional detail to the texture, and depending on the modder, most examples have used Detail Tex as a means of pushing the fidelity of the overall clouds. However, the key thing about Detail Tex is that it is sensitive to transparency, meaning that if your detail texture is transparent in any part of it, that transparent section will also translate to its application to the main texture, rendering that part of main tex transparent as well. This is the fundamental key to how dynamics works, and I discovered that this worked some years ago during development for the mod Ad Astra, and my early attempts with it are still viewable through that mod by looking to the planet Lindor and its Dark Spot, which forms and dissipates regularly over time. Originally, however, this technique for me was only meant to serve as a means of providing just specific macro level cloud systems, like the Dark Spot, or the eventual Typhoon that featured in Sol. Until I had an epiphany, I was still very much married to the idea of global Cube Maps being the key to higher quality visuals, but Cube Maps have their short comings. For one, the global coverage means that quality is hard to keep consistent across the entire texture (without painstakingly hand-painting it), and this only gets worse depending on the quality of your source and the method with which the cube map itself was generated, and for two, its very static; the clouds will always look the same no matter what, with only the underlying terrain changing. To put it short, cube maps are a pain to work with and unless you are very fortunate, or have the patience to paint it by hand, they still ultimately have shortcomings that leave one wanting. But Dynamics provides another option, and in fact, provides an option that is much better suited to the sort of game Kerbal Space Program is, where memory is of vital importance. Using Dynamics to create global cloud coverage can not only provide much higher quality and far better consistency, effectively allowing one to have texture qualities as high as one wants without any quality loss from downscaling, it also allows you to do so without an egregious impact to the memory footprint of the mod compared to what would be necessary to replicate the same visual fidelity using other methods. And as a bonus, you get the Dynamics effect itself, allowing your global coverage to never look the same twice. So, with all that explanation aside (though there's still quite a bit more), lets get into the nitty gritty. To start, we need to identify and locate a source cloud map that we are going to derive what we will be calling cloud patterns, or cpats. For this, I utilized (and prefer) the Blue Marble imagery available at Visible Earth. I took the highest resolution that was available, and in GIMP, I combined both the E and W files into one, which should provide you with something looks like this: While the large file size, 43k in this case, can be rough to work with depending on your computer's specs, do keep in mind that you only need to work with it long enough to extract a cpat. To do this, the process is quite simple. For this purpose, we are going to assume that we want to have our cpats be at 16k, which is the maximum resolution that KSP can support. To mark out a strict 16k selection, we are going to select our selection tool, and set it to Fixed with a resolution of 16384 x 8192; your settings should resemble the below: Once you have this, you can click and drag anywhere on your image, and a selection box should appear that you can then drag around. We want the image to be rectangular, as this will prevent our final cpat from being distorted. From there, all you have to do is select some part of your source map that you think looks good or interesting to have as a potential pattern. For this, I selected this section: Next, copy the selection, and create a new file in the same resolution (16384x8192), and paste in your image. Add the pasted image as a new layer, and either merge it with the extraneous background or layer, or simply delete that layer. ========================================================================================================================================================== What this process does is allow for the higher resolution image to be translated to a lower resolution image, without any real loss in quality from more traditional down-scaling methods. We do lose the additional data from the rest of the map, but this on purpose, as we do not want all of that extraneous data anyway, and because we can always just make more cpats. (for Sol, I settled on three primary cloud patterns, with a fourth intended for noctilucent cloud formations) Next, we will need to extract the clouds themselves from the black background. First, ensure that the image has been set to “RGB”, by clicking on Image > Mode > RGB. Then, click on Colors > Color to Alpha. The Color to Alpha tool will automatically render your selected color transparent. By default it will have selected White, but naturally we want to change this to black. As a first pass, we can click okay once this is completed, and now your texture should look like this: However, we are not quite finished with this step yet. Due to the nature of satellite imagery, a lot of artifacts may be present that you do not want, and this is especially true if you are extracting clouds from images that also include terrain. To sus these artifacts out, make a new layer and fill it with some color; I typically use a dull blue as it gives me some sense of what the clouds will eventually look like. ========================================================================================================================================================== Once you do this, zoom in and inspect your texture, and essentially you are looking for anything you don't quite like. While my example texture was already cleaned up, I was able to find this section in the upper right: Without the blue background, details like this may have been easy to overlook until you've already gone through the process of getting the cpat into the game. To correct this particular issue, its simply a matter of erasing the offending details. ========================================================================================================================================================== A helpful tip if you are extracting clouds from images that feature terrain or other artifacts (such as sunlight reflecting off an ocean; a common occurrence in satellite imagery), is to merge your cpat with your color layer, and then repeat the Color to Alpha process, this time picking the blue color. You may have to click around on the offending spot, and play with the Opacity and Transparency thresholds (which adjust how strict the software is in erasing the chosen color), but eventually you will find a sweet spot that largely, if not completely, erases the artifacts. Any additional artifacts you find beyond that, simply need to be erased. ========================================================================================================================================================== Now, yet again, we are not finished. Zooming back out, you'll notice that your cloud texture likely extends off the bounds the image. This naturally, will not do for our purposes, unless you're for some reason wanting to do Minecraft clouds. To correct unfortunately requires sacrifice. We will need to erase and blend the clouds in such a way that they stay within the bounds of the image, but also still look like clouds. For this purpose, I recommend locating a quality brush pack for GIMP (utilize sites such as deviantart) that specifically provide brush shapes that mimic clouds or smoke. While I cannot say what tools I have (as I acquired them long ago and their names in my system lend no clues to their origin, other than I know they came from deviantart), the important aspect is that you want cloud or smoke shapes to work with, as they will naturally lend themselves to forming the shapes you want. ========================================================================================================================================================== Once you have one, experiment with the settings and see what results you can get. Ideally for Dynamics, we want the clouds to comprise around 50-60% of the total image, with a good mix of both smaller and larger cloud formations, as this ratio is required to allow for Dynamics to function as expected. I recommend prioritizing the lowest quality or least appealing areas of your image first, before tackling the edges or removing large macro elements from the pattern. With enough experimentation, you should end up with something akin to this image: As you can see above, you may also find it advantageous to flip or mirror the image. There is no hard rule to whether or not that is desirable; your artistic eye simply needs to guide you, and remember that there is no cost in experimentation here. If it ends up looking bad, start over and try again. Now, to prepare the image for use in KSP, we need to actually turn it into two different textures. One will be our main tex, and the other our detail tex. The eventual randomized interaction between the two textures, which we will set up once we are in-game, is what enables Dynamics to do what it do. ========================================================================================================================================================== Now, the transparent image as we have it is already set up, and this will be our detail texture. First, insure you have save this as an .xcf so that you can always come back to it, and ensure that your background color layer is set to invisible, so you are left with just the layer with the clouds. Then export the image as a .dds. Ensure your settings match this: For this, we name this as cpat1_d Once that has completed exporting, we can move on to to the main texture. To generate this, I do not recommend just doubling up on the detail texture. The reason for this is because the interaction between the transparent sections of both textures tends to not look that great in my experience, so instead what we want to do is create a texture that captures the macro shapes of the pattern, but “fills in” some much of the transparencies, allowing for the detail texture to define those alone. ========================================================================================================================================================== The process for this is simple. Duplicate the layer multiple times, and as you do so you'll notice the pattern become progressively bolder as the stacked layers fill in transparencies. I recommend doing this around 4-6 times. Once you have them, merge the copied layers together into one, and you should result in an image like this: The difference here may appear to be subtle, but that is ideal. You do not want it to be too bold, but the pattern should be considerably fuller than its detail counterpart. Export this as a second .dds, this time simply as cpat1 With these two textures in hand, you have all you need to make Dynamics work. Add them to your mod directory, and load up the game. In the EVE Gui, accessed by Alt-0, or within the tracking station by clicking on the EVE Gui button, create a new layer and name it cpat1. ========================================================================================================================================================== From here, the settings you choose are more or less up to you, your tastes, and what you want to do. I can, however give you some general tips going down the line of the options you have available to you. Altitude – Generally speaking, you don't want clouds to be too high up in the atmosphere, especially at lower scale Solar Systems, as this will look very off from what it should be compared to real life. While achieving the realistic is not completely possible without moving up to Real Scale, you can approximate it, and for this, I recommend a cloud height around 7-10km, and I recommend that for all of your cloud patterns that you make the altitude identical, or only with slight variances. Kill Body Rotation – This generally is only recommended for things meant to stay stuck to the polar regions. Speed/Detail Speed – Speed governs how fast Main Tex moves across the world, while Detail speed, as you can imagine, governs how fast the Detail Tex moves within its application to the Main Tex. For these, I recommend keeping them relatively low, no more than 20 or 30, but ideally closer to the 2-10 region. You can use negative numbers, and this will help to vary up the directions the two textures move in, which is highly useful if you want to use the same cpat twice, saving both on memory and allowing for a more fuller globe. Offset – This setting appears to move the texture away from a particular center point, however it is quite limited and typically only works well if you specifically need something to hang, with no movement, in a specific location on the planet. This is useful for providing things like lava flows, algae blooms, smoke clouds, meteors, etc. Rotation – These settings naturally govern how the layer itself rotates as it moves. You can use these to set up singular cyclonic storms, however do note that due to shortcomings in the Offset setting (namely that it doesn't allow you to offset where the center point of a layer is), you may not be able to get your cyclone to behave properly except on one location on the planet. Hopefully in future versions of EVE these settings can be expanded on to allow for greater control. Arc – I've never seen any reason to use this. It controls how much of your texture displays over one half of the planet, but the effect does not seem to be entirely useful. Color – This is more or less self-explanitory, though I will note that you can exceed the 255 numbers, as well as go negative if you wish. This is useful for balancing EVE's interactions with scatterer, enabling you to get clouds that do not look too starkly white, but while also still getting the vibrant terminators that settings in scatterer can provide you. Detail Scale – This is a critical setting for Dynamics, and it must be set to 1, otherwise dynamics will not work as intended. Using scales higher than one will shrink and repeat the detail texture, which is not what we want; we want Main Tex and Detail Tex to be 1:1. Detail Distance – This setting affects how the layer appears at various zoom distances. A setting of -2E-07 is recommended here. DistFade – If this setting has an effect, I have not been able to identify it. DistFadeVert – I recommend using the same as Detail Distance, though like DistFade I am not certain what effect this setting has. UV Noise Settings – If you have a useful UV texture, I would recommend following the advice of others who have dealt with these. I have not, so I will not speak to them authoritatively. ========================================================================================================================================================== Finally, you also want to ensure you have enabled Layer 2D. Most of the settings in here should be left alone, other than MinLight and ShadowFactor. Minlight when set to a positive number will cause your cloud layer to appear on the night side at various brightnesses. This is mostly used for Auroras and other lighted effects, but as I will cover in the City Lights section, this also has use for enabling an effect that I find is stupidly called “cloud glow”. Shadow factor is up to personal tastes, but it is good to note that higher values will induce unnatural darkness on the ground, so be wary; it may look good in orbit but you may second guess the value if your rocket launch in the sun is being cast into darkness by a tiny speck of cloud texture. Once all of these settings are ready, you're done! Apply the layer and save it to your config. Once you change scenes, or press the Map Eve Clouds button in the Scatterer GUI, you can enter time warp and see how your new cloud pattern periodically forms and dissipates at random over time. By adding additional cpats, repeating them, and varying their settings, you can achieve global cloud coverage that is always dynamic, and seldom boring. Performance wise, it is fully dependent on how many repeated cpat layers you have going at once, and naturally the resolution you created the textures at. For Sol, I settled on a repetition of four, with each of the three main cpats being repeated four times with varied speed and detail speed settings to achieve a global coverage that I was satisfied with. With smaller resolution textures, you could potentially push this number to greater heights, though I will note that it is possible to have too much layered over top of one another at once, so be wary. ========================================================================================================================================================== As an added bonus, I am also going to, much less thoroughly, explain how to achieve the apparently lost “art” of cloud glow, an effect that was apparently quite popular in older visual mods prior to a change in EVE that changed how the Minlight setting worked. The solution, incredibly, to bringing the effect back was astonishingly simple and brain dead. Are you ready? Use two citylight configs. Its dumb, it shouldn't work, but it does. In order to achieve the effect, like we see here: What you want to do is take your CityLights texture, and apply a substantial Gaussian Blur filter to it. It shouldn't be so high that it becomes indiscernible where the lights were, but it shouldn't be so low that the lights are only slightly blurry. Once you have this, you will also need to create new detail textures for what we will call CityLights_G As a result of how the CityLights feature works in EVE, you will need set your day texture to a blank, nothing texture, as small as you can get it. This is necessary to prevent the glow from appearing on the day side of the planet. To maintain consistency, I recommend taking your night texture, and applying the same gaussian blur filter to it; you want most of the details to vanish in the blur for this one. I call these dayglow and nightglow respectively. Now, due to EVE being unable to support the creation of two simultaneous CityLights for the same body in its GUI, this will instead have to be done through the configs directly. Simply take your CityLights config file, copy and paste it, and rename it to CityLights_G or whatever other name you would like to give. In the settings, change the texture paths to your new textures. Once you're done, save the config, and it just simply works. While you will not be able to toy with the _G layer itself in-game, it is relatively trivial to make any adjustments to its config. To achieve the final piece of the cloud glow puzzle, you simply need to enable Minlight on your cloud layers. For this, I recommend a setting between 0.2 and 0.4, as this will allow the clouds to still show up on the night side, but will prevent them from being starkly visible even on the Moon, which is a shortcoming of the old method to this effect. The _G layer will shine through the now visible clouds (provided the texture is transparent) and, with some possible adjustments to the _G texture, you can achieve a look that mimics the real life nature of lights being scattered and dispersed across a cloud at night. @ballisticfox0