Jump to content

Lt_Duckweed

Members
  • Posts

    264
  • Joined

  • Last visited

Reputation

468 Excellent

Recent Profile Visitors

4,585 profile views
  1. It is not designed to be used as a part of Eve city lights, it needs to be added directly to the planet you are trying to modify as part of a Kopernicus config. In your above example, you would need to create a config file to edit Kerbin using Kopernicus, and have it set the VertexColorMapEmissive in the ScaledSpace node and the Mods node in the PQS and/or Ocean nodes.
  2. Couple of things: the scaled space mesh for your planet (which is used in map view, or when far away or zoomed out in standard view) is stored in the cache file at BeyondJool/Cache/Kotta.bin. Anytime you change the PQS (such as by adding the oblate PQS mod) you must delete the cache file, so that Kopernicus will generate a new one. Secondly, your current period is too low. Using this google doc https://docs.google.com/spreadsheets/d/1QSUjAmyAIACKAFSL_C8qv5GxYc4YTB1eDBRP4TTUl5A/edit?usp=sharing, I input your body's radius and the shortest possible stable period is 6877 seconds. Any faster than this, and the body, if it were actually being physically simulated, would tear itself apart.
  3. I have not tested with a heavily clouded planet like that but it has seemed to work fine with my planet Cind, but Cind only has very faint clouds. I wouldn't be surprised if dense clouds like you show have a similar issue to KopEx.
  4. It does support both triaxial bodies, and prolate bodies. If you use UniformEquipotental with energyMode High, then for appropriate periods you will get triaxial bodies. For prolate bodies, or in an instance where you don't want to faff about with period for a triaxial body, you can simply use the CustomEllipsoid mode and specify the a b and c ratios.
  5. Yeah with how close the three planets are to Kerbol and to each other, I doubt any orbit for any moons could ever be stable around any of the three. The existence of Geet and Subon are ultimately concessions that deviate from realism for gameplay purposes. Subon exists because otherwise Jot can feel empty and a bit pointless, and to serve as a staging ground for inner system infrastructure. Geet exists to ease the delta-v challenge of leaving Blas, via ISRU (for those who chose to do so). Out of curiosity, what happens to Geet and Subon? I assume Geet is ejected, does Subon also get ejected or does it collide with Jot?
  6. It is very difficult to safely reach and land on Cind, but it is just far enough from Kerbol that with very judicious part selection it is possible to stay within thermal limits and pull off a landing. Here is an example of a successful mission pulled off by @JeDoesStuff
  7. QuackPack v1.2.0 Dead Worlds Changelog Dependencies KopernicusExpansionContinued-er dependency removed VertexColorMapEmissive added as bundled dependency VertexHeightOblateAdvanced added as bundled dependency Blas Dimmer, more transparent rings Redone, less saturated colormap Add height noise for more varied, bumpy terrain Add terrain scatters Tweaked, less saturated Scatterer atmosphere Stock atmosphere redone, will look nicer when playing without Scatterer Jot Tweak Scatterer atmosphere slightly Stock atmosphere redone, will look nicer when playing without Scatterer Subon Use VertexHeightOblateAdvanced instead of oblate heightmap Updated normalmap Add terrain scatters Cind Scatter atmosphere redone, now purple to represent the high concentrations of disulfur gas Stock atmosphere redone, will look nicer when playing without Scatterer Add height noise for more varied, bumpy terrain Add terrain scatters Ocean texture redone, now looks more like lava and less like orange juice All emissive effects redone, using VertexColorMapEmissive Download Github SpaceDock Licensing QuackPack is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)
  8. Changelog v1.1.0 New photosphere texture for Kerbol. Brightness curves and optional rescale replaced with configurable options New configuration file at GameData/BetterKerbol/settings.cfg useBetterSize Default value: false Expected values: true, false Effect: Reduce Kerbol's radius by a factor of 4.24x to match scale with the stock system. useProximityBrightening Default value: true Expected values: true, false Effect: Increasing brightness curve when closer to Kerbol than Kerbin SMA. useDistanceDimming Default value: false Expected values: true, false Effect: Decreasing brightness curve when farther from Kerbol than Kerbin SMA. Download GitHub SpaceDock Licensing BetterKerbol is licensed by Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0)
  9. I am actually getting ready to push an update to BetterKerbol pretty soon. I can add an optional patch to revert to the stock light curve behavior.
  10. As of the latest version, the folder should be 001_DuckweedUtils anyways, so you are all good there.
  11. @Tecorian @king of nowhere "Orange Tank SSTO" is somewhat more rare nowadays but used to be common shorthand for an SSTO that can take a 36 ton Jumbo-64 tank to orbit as payload. The key for SSTO spaceplanes is: Reduce drag. Make sure any rcs, solar panels, radiators, etc are stuffed inside a payload or cargo bay, and only open it up once in space. Make sure you don't have any flat blunt surfaces with open attachment nodes facing directly into or away from the airstream (you need to cap the node with a part which approximately matches the size of the flat surface (example: 1.25m nosecone on the front of a 2.5m tank won't help much. Use a 2.5m nosecone). If you want to get fancy, try using "Wing Incidence" to build in the angle of attack on your wings. Wings in KSP need some angle of attack to generate lift, but fuselage parts with an angle of attack generate lots and lots of drag, so you want the body pointing prograde and the wings angled up so that you can get lots of lift from them. Proper ascent is very important. Engines are heavy, so you want as few as you can get away with, so you want to add just enough rapiers to take off by the end of the runway (even if that is done by literally falling off the end of the runway), and punch through the speed of sound. If your rapiers can get you to at least ~450m/s at sea level, you are good to go for the rest of the flight. Once you reach ~450m/s at sea level, you want to slowly start ascending, gently nosing up over ~30 seconds up to an angle of around 20-25 degrees. Hold this until you are getting close to 10km altitude, then begin leveling off very slowly. The ideal goal is to hit 18-20km at the same time as you hit around 1400-1500 m/s and finish leveling out. The goal now is to very slowly climb to around 21-22km while you finish gaining all the speed you can on rapier jet mode. You want to get to at least 1600m/s, even better if you can get over 1650m/s or even 1675m/s. Then, you want to turn on your nervs (if you have them) and swap the rapiers into closed cycle rocket mode (if you have oxidizer). You don't really need to pull up here other than a tiny handful of degrees. Your sheer speed and you approach orbital velocity will naturally push your apoapsis out of the atmosphere and raise your nose. Then you just coast your apoapsis and perform a small circularization burn to enter orbit. Some further tips: It may be that the above ascent profile makes you explode from overheating. Generally this is due to one of two things: either you have too much twr and accelerated too fast at too low an altitude, or you didn't use heat resistant parts. Ideally you redesign for lower twr (since that means less dry mass and thus more dv) or use more heat resistant parts in the areas that were most vulnerable. Generally, some good benchmark numbers when starting out are that you should aim for at least 20-25 tons of mass on the runway per rapier engine, and 1 wing area per 4-6 tons of mass on the runway (you can see wing area of a wing part by right clicking it in the part selection menu on the left in the VAB). The engine number can comfortably be pushed above 30, even to 36tons, when you are quite practiced at building efficient craft, and experts can go even higher than that when taking off from the flat area around the KSC instead of the runway, but 20-25 is good to start. As for designing a craft specifically for hauling an orange tank, you have to make a decision early on: will you use a fairing open at one end, or a Mk3 bay, to carry the fuel tank? Using a fairing is a lot lighter, but requires more expertise to build an effective plane, so we can throw that aside for now. You will need a long MK3 bay to hold the tank, and you can probably also squeeze in a reaction wheel, batteries, and solar panels in it on one end. If you don't want the craft to be crewed, we also need a probe core of some kind. We can probably target a total mass of the craft of 120 tons to start, so we will need around 5-6 rapiers, and 20 to 30 total wing area. One of the best wings for the job is the big s wing. It comes with free liquid fuel storage of 300 units in each wing, which saves on tanks, and has a wing area of 5, so you need 2-3 pairs of them. Then we add control surfaces, landing gear, and any other goodies you want. Lastly, we want to pack any remaining mass budget with fuel tanks. As a general rule of thumb, I have found that even with a very efficient ascent, you need at least twice as much mass of lf/ox mix for rapier rocket mode as you need pure liquid fuel for jet mode, but probably at least 3x as much so we have margin for maneuvering is space. Now it's time to test it. Take it out for a spin and see how it performs. Did it do amazing first try and reach orbit? Great, you can either take it as is and start using it, or if you are like me, see what tweaks you can make to make it even more efficient. Did it not do so great, and fail to reach orbit? It's time to debug. Probably if it can't it's an issue with high drag, you can see how much drag each part is producing individually in their part windows by toggling on the "Show aero debug data in part action windows" debug option in the cheat menu, Alt-F12 => Physics => Aero. There is also an option to bring up an Aero data GUI that will show you overall aero stats about your craft. And if you really want to go down the rabbit hole and start your journey to being an SSTO wizard, I recommend watching this video (it's really long but also really worth it): And if you want to take your wizardry up a whole other level, also check out my playlist "Kerbal University". Be warned, it's really dense so only jump in if you really want to go into the nitty gritty:
  12. VertexColorMapEmissive VertexColorMapEmissive is a custom PQS Mod intended for use by planet modders to give more control over planetary emissives than can be achieved with the current alternatives: EVE CityLights and Kopernicus Expansion EmissiveFX Planet pack developers implementing VertexColorMapEmissive are encouraged to bundle it with their mod, for the convenience of users. Examples ScaledSpace: Place a VertexColorMapEmissive node in your ScaledVersion node PQS and/or Ocean Place a VertexColorMapEmissive node in the Mods subnode of your PQS Node and/or the Mods subnode of your Ocean Node Download Github SpaceDock Installation and Use Install ALL listed dependencies, following the links below Download and extract the VertexColorMapEmissive zip file Place the GameData folder into your KSP directory Once installed, simply add VertexColorMapEmissive nodes to the Mods subnode of your PQS Node and/or the Mods subnode of your Ocean Node, and to your ScaledVersion node Reasoning behind creation Qualities I believe an emissive mod should have It should cover ScaledSpace, PQS, and Ocean emissives with a single unified and coherent format. It should allow the use of a full color texture with transparency. it should not have visual artifacts with stock ScaledSpace, PQS, or Oceans. Features and comparison to alternatives VertexColorMapEmissive Pros Full RGBA colormap support Unified solution for ScaledSpace, PQS, and Ocean emissives No ocean z-fighting Cons No detail texture for close range variation Kopernicus Expansion EmissiveFX Pros Supports ScaledSpace, PQS, and Ocean emissives Cons Flat color value Map controls only alpha and brightness Ocean z-fighting EVE CityLights Pros Detail texture for fine detailing up close Cons Flat color value Map controls only alpha and brightness Detail texture tiling can become apparent when map covers a large contiguous portion of the surface Does not support Ocean emissives Parameters and expected values map: The RGBA texture to use as the emissive map brightness: global multiplier to the color channels of the map default value: 1 values greater 1 increase brightness, values less than 1 decrease brightness transparency: global multiplier to the alpha channel of the map default value: 0.5 values greater 1 decrease transparency, values less than 1 increase transparency Requirements ModuleManager Kopernicus FAQ Q. I'm not a planet modder? Do I need this? A. You do not need to install it manually yourself, but if you found this in your GameData, it is because a planet pack you have/had needs/needed it and so it was either included with the mod or auto installed through CKAN Q. Is this compatible with Parallax? A. In all honesty, I have never downloaded Parallax before, so I do not know. Q. Is this compatible with Scatterer oceans? A. No, it will not function with Scatterer oceans, only stock oceans. Licensing VertexColorMapEmissive is licensed under the MIT License
  13. VertexHeightOblateAdvanced 1.1.3 What's new: Tweak folder structure to fix mod load order conflict Download Github SpaceDock
  14. VertexHeightOblateAdvanced 1.1.2 What's new: Fix for VertextHeightOblateAdvanced using terrain altitude instead of radius for deformity calculations. VHOA should now behave consistently independent of load order when used alongside other PQS mods. radius parameter depreciated, radius is now directly inherited from parent PQS. Download Github SpaceDock
  15. It should be possible I think. For more lava-ey lava from far away you will want to edit CindOcean in GameData\QuackPack\textures\pluginData CindEmissiveDetail in GameData\QuackPack\EVE\Textures When actually sitting on the ground near an ocean, there are issues with z-fighting between the emissive texture and the regular ocean texture I never really figured out how to resolve, but to make the ocean texture look better while sitting close to it you will have to change the Cind config to replace the default "water" textures with brand new textures (currently it uses build in KSP textures), which will be more difficult. When I next get around to updating QuackPack, better Cind lava is pretty high on the list.
×
×
  • Create New...