Jump to content

sumghai

Moderator
  • Posts

    4,248
  • Joined

  • Last visited

Posts posted by sumghai

  1. [MOD - Merged related threads into same topic]

    @gregdeen19, please note that new users require moderators to approve their first few posts, so I'd advise editing your existing topic to add more information instead of making multiple threads.

    To post images on this forum, you will need to first upload them to an external third-party image host (e.g. Imgur), then copy and paste each image's direct URL into your forums post editor window.

  2. 1 hour ago, munix said:

    Is there any rule on the forums regarding having to specify licenses of any other software than mods which this is not? And if so, then for example this thread also breaks it

    As per the official Add-On Posting Rules, the rules apply equally to both add-ons/mods for the game itself and standalone applications such as this save editor. As long as it is posted or otherwise made available via official services managed by Squad, Private Division, Intercept Games and Take-Two Interactive, these rules apply.

    Official tools and software developed and provided by Squad, Private Division, Intercept Games and Take-Two Interactive are exempt from the add-on posting rules, due to their official status.

  3. I'd love to port my SDHI Service Module System mod over to KSP 2, and maybe even revive the perpetually-in-alpha FusTek Station Parts project to take advantage of KSP 2's graphics/API.

    But until official modding support and a ModuleManager equivalent comes to KSP 2, I'm holding off on doing anything. I don't particularly care for the existing third-party injectors, simply because they're unofficial and competing with each other, thus splitting the playerbase and modding community, not to mention potentially breaking changes when the base game updates.

  4. I'll probably wait until the official mod loader comes out, and I have a better idea of what parts/API will be added to the game, before I look into modding for KSP2.

    I've learned the hard way through my intermittent attempts at reviving/revamping the FusTek Station Parts mod that updates in Early Access often necessitate fundamental changes to how I mod, and I'd rather not repeat that Sisyphean experience.

  5. Personally, I think that for KSP2's career mode (or equivalent), mission simulations should have very limited fidelity, and be dependent on player progress:

    • At the start of the game, the player agency knows little to nothing about other planets (other than they "exist")
    • Players would first launch probes with scientific instruments to the Mun, Minimus and other nearby celestial bodies
    • Using instrument data, the player can then generate very basic simulations to test subsequent missions
    • The more missions and/or scientific instruments flown to a celestial body, the more accurate the simulations should be

    I also would prefer the scientific instrument unlock better simulations in a manner appropriate to each instrument - for instance, if your first probe to the Mun has a gravity sensor, your first simulation will include a basic gravity reading, but if not, your simulation will not account for gravity differences.

    I'd rather not see gamification in the form of trading genericized science points or cash for simulation fidelity.

    In short, simulations should really be for the late game, and the rest of the gameplay should encourage people to venture out and make mistakes.

  6. I think it would be nice if KSP2 took a similar approach to Ludeon Studio's RimWorld, and made the translation templates available on an open-source code repository like GitHub.

    Users would provide translations to these repos, which the developers can then periodically integrate into each game update.

    It would be interesting to see how moderation/vetting is managed - Ludeon generally lets the community self-manage translation accuracy / appropriateness, as it may not be practical for Intercept Games to appoint a language-specific moderator for every locale they want to support.

  7. For traversable IVAs to be a thing, I'd be interested to see how the developers address the following:

    • Internal collisions: Probably by having a simplified invisible collision mesh to go along with the more detailed diffuse/specular visual mesh
    • When to decouple internal physics from external physics (e.g. a Kerbal bumping against an interior wall shouldn't push the spacecraft off-course)
    • Preventing Kerbals from getting wedged/stuck (e.g. by making sure IVA collision meshes are all convex)
    • Camera clipping / zoom level control for first person vs. third-person views
  8. 16 hours ago, Stone Blue said:

    I've poked this mod, too.
    So, I'm guessing with the green light, Sumghai probably checked the "Play Automatically" box in Unity, for that one... at least the always-on rotation (animation), seems to bear that out.

    I found the same with defining multiple light names in the cfg key. I found out, you can fix that, simply by naming *both* light game objects, the *same* name, *in the model, before export*. ;) Works just like naming seperate animation tracks, the *same* name, to get them *all* to play as a single animation ;)

    I'm close to having these fixed, except for one small, but major problem: They work like they are supposed to, *except*, they only rotate once, then turn off.
    The problem is, i cant seem to get the animation to keep looping while activated. :(

    Yeah, this was essentially the problem I had - they rotate once, then stop.

    And getting multiple light objects with the same name to play nice is also an issue that has plagued the SDHI SMS mod as well - I've struggled to get the docking port lights and emissives working properly again.

    In any case, if you do manage to figure this out, drop me a PM, and I'll fold your fixes into an official release.

  9. 6 hours ago, Rakete said:

    Since KSP has received it's last update, a repaired version of this mod would be great. @sumghai

    As much as I'd like that, the final update fundamentally changed how emissives and animations works, which basically broke the core functionality of this mod.

    It's the exact same problem that's plaguing the docking lights and docking hatch window emissives from the SDHI Service Module System mod.

  10. I'm slowly getting back into the groove of things, so here's what the revised docking port will look like with the new Clamp-O-Tron mesh:

    BGDeN4y.png

    02uAent.png

    Current issues:

    • The docking light LED emissive animation seem to be fine in the VAB/SPH, but are running inverted (!) in the flight scene (i.e. LEDs not glowing when the light is on, but start glowing when the light is switched off). I'm at a loss as to why this is the case, considering stock light animations play in the right direction for all scenes.
    • The docking light LEDs need to be animated separately from the docking port window emissives, but ModuleLight and ModuleColorChanger don't play nicely on the same part with multiple independent emissives involved. Luckily, @Nerteahas suggested I could make use of some of his code from his NearFutureUtils' ModuleAdvancedColorChanger, which does seem to work independently of ModuleLight. I'll eventually compile my own plugin to include in SDHI SMS.

    So yeah, apologies for the delay, folks, but the KSP 1.12 update process hasn't exactly been smooth sailing.

×
×
  • Create New...