Jump to content

DeltaDizzy

Members
  • Posts

    1,168
  • Joined

  • Last visited

Posts posted by DeltaDizzy

  1. Per-save Screenshots | Organize your screenshots!

    image.png?width=945&height=292

    Per-save Screenshots makes it so that when you take a screenshot, it is placed into a folder within the game's Screenshots folder that corresponds to your saved game. No more melting pot of all your screenshots, letting you find the ones you want quicker and easier.

    DOWNLOAD
    CKAN (Recommended)

    Manual (GitHub)
    License: MIT

    CKAN is HEAVILY recommended, as it manages the dependencies for you. I will not spend a lot of time troubleshooting manual installs, and will just redirect you to CKAN. To report bugs, file an issue here. Bug reports must include the mod and KSP versions, a copy of your KSP.log file, and minimum reproduction steps.

    Thanks to @OrbitalManeuvers for the suggestion!

  2. 18 minutes ago, Friznit said:

    Heh, sounds like my usual playthroughs, with the added end game objective of "at least one viable colony on another planet that isn't Duna/Mars," which almost invariably breaks me because of transfer windows and life support requirement.  It's quite a challenge not doing replicas with BDB though!

    To be fair I never said anything about the rockets! :P Before this the farthest id gone was a Duna orbiter and Eve lander and wanted to try and fully commit. I did give myself a bit of an out in that I technically only have to orbit each body (and in the case of Jool there is probably some assist wizardry that can be done to recycle orbiters). So far it hasn't been too hard on the lander side but I haven't gone to vacuum planets yet...Dres will be fun (and its orbiter is probably my favorite yet)...

  3. Gotten back into the game recently and have been doing a "visit every planet, land if possible but orbit (for scansat) absolutely" run. Additional rule is no replica payloads and that has made it quite fun indeed! The orbiter program is SUNBEAM and the lander program is FRESNEL.

    SUNBEAM 1

    WL64tvk.png

    FRESNEL 2 (1 went to minmus)

    zsKZHkQ.jpg

    LdpbWY5.png

    VyXENxm.png

    SUNBEAM 2

    jr3M0JB.png

    rKBhNpI.png
    Tomorrow will add on my Eve/Duna orbiters (SUNBEAM Block 2/2+), my Dres orbiter (SUNBEAM Block 3) and later on my eve/duna landers (FRESNEL Block 2)

  4. Minor Planet Sampling| V1.0.1| Unkerballed science with asteroids!

    screenshot4.png

    (image taken in Sandbox)

    Have you ever wondered why Squad added comets and a Rosetta recreation but required kerbals to do any science at either them or asteroids? Wouldn't it be nice to have a reason to send missions to asteroids earlier on in the game, to add value other than mining or proving you can capture one? Minor Planet Sampling solves this by allowing probes to perform the surface sampling experiment that comets and asteroids are equipped with! Due to technical reasons and modding effort required, the vessel doing the collection *must* have a part onboard that can act as a science container, so the Breaking Ground sample arms and the stock surface ore scanner have been given the ability to store one experiment.
     

    REQUIREMENTS

    ModuleManager
    HarmonyKSP
    Neither of these are included in the download!

    DOWNLOAD
    CKAN (Recommended)

    Manual (GitHub)

     License: MIT

    CKAN is HEAVILY recommended, as it manages the dependencies for you. I will not spend a lot of time troubleshooting manual installs, and will just redirect you to CKAN. To report bugs, file an issue here. Bug reports must include the mod and KSP versions, a copy of your KSP.log file, and minimum reproduction steps.

  5. On 2/2/2021 at 6:52 PM, NateDaBeast said:

    OPSEK can be largely (if not completely) made with Tantares, as it's essentially just the Russian Orbital Segment on its own. I don't know much about LOS, but with the number of generic station parts it has I would be surprised if you can't use Tantares to build LOS as well.

  6. 6 minutes ago, Nate Simpson said:

    We’ve heard time and again from this community that quality is paramount, and we feel the same way.

    It’s not enough to deliver a bunch of new features – those features have to be woven together into a
    stable, polished whole. We’re creating a reliable foundation on which players and modders alike can
    build for another decade or more. That involves solving problems that have never been solved before,
    and that takes time.

    At least for me, KSP 2 being polished, stable, and well-rounded is worth the wait.

  7. 17 minutes ago, Souptime said:

    Whats the difference between soft and hard deprecations?

    A soft deprecation is just making the parts inaccessible from in-game (like removing them from the tech tree and the editor part lists). The parts are still loaded, so existing crafts still work fine. Hard-deprecation is when the files themselves are deleted from the mod distribution, breaking any crafts that use those parts. Generally soft-deprecation happens first to give players a chance to retire anything using those parts before they are hard-deprecated.

  8. Tech Tag Foundation

    Background

    For some time now, @KerbalKore  and I have been working on a pseudo-historical tech tree (named CWPT) , with parallel American, Soviet, and European branches. The vast majority of the US branch  uses Bluedog Design Bureau. However, BDB has several hundred parts, and configuring each one individually would be a mammoth undertaking. In light of this, we decided to instead 'tag' every part, thus allowing us to use tags to group parts and greatly lessen the workload. Soon enough, I realized this could also be helpful for other tech trees wanting to incorporate BDB, resulting in the decision to split out the tags into a standalone mod to be released first (after the tree itself has had months of delays due to IRL circumstances).  I also realized that the tags as they exist now are not the best suited for generic use, as they group parts into the real rockets/spacecraft. This makes sense if you aim for a historical-ish progression, but not so good for a purely gameplay/balancing-focused progression. 

    How it works

    TTF is essentially a giant ModuleManager patch that adds a single line to all supported parts of each supported mod:

    @PART[name]:FIRST:NEEDS[mod]
    {
    	%techtag = tagName
    }

    Then, when a tech tree mod loads, it can assign parts to nodes based on the tag, instead of the part name:

    @PART:HAS[#techtag[tagName]]
    {
    	@TechRequired = nodeName
    }

    Part modders are also given the option to allow the tags to be added directly into the part configs, as is being done with BDB.'

    NOTE:

    It shouldn't really be an issue, but any patches that use or affect the tags MUST run before LAST[TechTagFoundation].  Any custom fields inserted into part configs throw log warnings if they are still there when KSP compiles the parts. To avoid log spam all tags are removed from all parts in the aforementioned ModuleManager pass.

    The Point

    Currently, the tags are simply the names of rocket stages or spacecraft, meant to align with the original goals of CWPT.  In the interest of easing the burden on other tech tree makers, I am asking what level of granularity and what 'categories' of tags should be used.

     

×
×
  • Create New...