Jump to content

Synthesis

Members
 View Profile  See their activity

  • Posts

    519

  • Joined

  • Last visited

 Content Type 

Posts posted by Synthesis

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted

    That's weird. I covered the pod and chute with the stock fairings both from a fairing starting point below it, and a fairing starting point attached to the chutes to test this out myself, and it works just fine with RealChutes once I eject the fairings. Are you using a different set of fairings?
    I believe Synthesis was using the original pod boost protect covers that comes with the SDHI pack, which as I mentioned numerous times previously, does not properly occlude drag in stock aero.

    Starwaster will help me write a plugin to fix that, but not yet.

    Ah, okay, the connection with the physics model went over my head--sorry about that.

    Exposure, you're using the in-game generated fairing models, right?

    [1.12.X] RealChute Parachute Systems v1.4.8.3 | 24/01/21

    in KSP1 Mod Releases

    Posted · Edited by Synthesis

    I know this may not be up to stupid_chris, but has anyone had any luck getting around the issue of parachutes refusing to deploy under/next to/in close proximity/not-so-close proximity to fairings?

    I've been looking through issues with Sumghai's SDHI service module escape option system (the parachutes rely on RealChute), and the parachutes flat-out refuse to deploy after they're uncovered (even if I stick a separator in between the parachute-docking port and the fairing itself). That breaks the escape option, naturally, and possibly the ability to actually use the default reentry parachutes (since they're on the same), so no bringing a crew back as such. Has anyone been able to get around the error?

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted · Edited by Synthesis

    Noted.

    I've just pushed another commit to GitHub. This time, based on reverse-engineering of the v1.9 Service Module I've taken out the ring of convex colliders around the upper avionics ring and replaced it with a single non-convex collider.

    My understanding is that non-convex colliders will still allow the Service Module to be grabbable in the VAB/SPH and other parts to be surface attached to it, but this will mean that a discarded Service Module falling to the ground might not interact with the terrain properly (i.e. sinking halfway when hitting the ground rather than exploding). I'm hoping this is an acceptable compromise.

    But anyways, please check that there are no more surface attachment oddities with this commit.

    This is really heading into head-desking territory.

    http://i.imgur.com/2t7A4JJ.png

    The last time I checked, Ven's Stock Revamp interferes with SDHI SMS as the former tries to force some sort of automatic shroud near the base of the command pod and/or the heat shield. You'll have to take it up with Ven to see if he can make an exception for when SDHI is installed..

    Just wanted to add, yes, the new model fixes the collision issue in the VAB. Hurrah!

    Back to experimenting with the parachute. I missed an obvious issue myself: so, with this fairing bug, forget abort stages, I wonder if the SDHI docking parachute might not function on return (even if you discarded the fairing hours/days earlier). Has anyone gone that far?

    EDIT: Yeah, so, idiot that I am, it never occurred to me to check the RealChute end of this--apparently, RealChutes having problems deploying with/near/within visual range of a fairing of some sort is actually not uncommon, according to the RC thread (not sure if that's being worked on). In my case, I may just replace it with a default go-to parachute within the CFG as a temporary fix.

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted

    @Synthesis - with regards to the surfaced-attached parts issue, I took another look at the Service Module colliders, and while I couldn't see anything obvious, I ended up redoing them. Please try out the latest commit on GitHub and let me know if that helps.

    FYI, here's what the Service Modules look like right now - the lower propulsion section is a convex mesh collider in the form of a single cylinder, while the upper ring is made up of 24 convex mesh colliders in the form of flat cuboids.

    http://i.imgur.com/JNzwb88.png

    In any case, the colliders for the ring shouldn't be sticking down far enough to be causing any issues, so I suspect that the problem might be to do with the bounding boxes of certain RCS thrusters or solar panels from other add-ons being too big.

    So, I tried the new MU file, and while the collision model does seem different, it's still having some glitches towards the middle of the cylinder (so there's a "sweet spot" for top and bottom third of the cylinder respectively). Just thought you might want to know, I'm sure these sort of things can take time, and some areas are beyond your control for now.

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted · Edited by Synthesis

    As per the FAQ, this is intentional - the parachutes were optimized specifically for return to Kerbin from LKO/Mun/Minimum. The last thing I want is for newbies to play around with the values, apply incorrect settings, then come crying to me that I've cold-bloodedly murdered their Kerbals.

    I've never had any issues with manual chute deployment, although that probably was back in 0.90 when I still had access to a computer capable of running KSP (I'm currently relegated to working from a laptop that can't run the game). After firing the LES, I simply waited until the pod had reached the apex of its trajectory and slowed down, before manually jettisoning the pod cover/LES combo and opening up the chutes.

    As for the fairing issue, as I've explained numerous times previously (including in the OP), the pod cover and Service Module side fairing panels are incompatible with the new stock aero system, so odd behaviour is to be expected until Starwaster helps me figure out a fix.

    I understand your reasoning behind the fixed parachute values--though I think as of 1.0 it's glitching in the other regard. I've set up a "escape from surface" test a few times where I test the escape tower from the launch pad. The parachute just doesn't want to deploy, either manually or by action group, even after you meet the criteria (negative velocity, etc.) because of the fairings.

    In which case, then yes, probably a 1.0-related glitch. I don't want to sound ungrateful or anything, but bringing it to your attention if you were not aware of it. I'll try out your most recent release this evening and report my findings in the area of parts attachments.

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted

    So, I've been trying to get a working abort stage together with the assembled service module--and I'm running into some obstacles.

    Currently, even if you have Realchute installed, you can't edit the docking ring parachute in the action menu--which is a problem, since you can't set it to automatically deploy earlier.

    That, in turn is a problem because if you just try and deploy it normally, the pod can be lifted by the escape tower effectively, but when you try and deploy the chute, you get the message "Can't deploy, parachute is in fairing" even though the fairing is already clear.

    [1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)

    in KSP1 Mod Releases

    Posted

    Gave the unfinished release a try--so far, working very fine, except it seems mounting parts on the service module under the ring is a little sensitive (move to far in either direction, and your parts will stick "outside" where the fairing would be, even if there is visible space.

    Of course, it is unfinished, so I don't mind in the least--just wanted to report that, very excited to see this completed. I'm pretty sure this is the last 0.90 "must-have" mod I'm waiting to get updated to 1.02. :D

    [1.02] KW Rocketry v2.7 Available - 1.02 Compatibility! - 16/05/2015

    in KSP1 Mod Releases

    Posted

    I had this problem too. I think i found the source.

    I belive it is the DeadlyReentry-KMRocketryFairings.conf. Because the statusbar hang up at KW2mSRBNoseCone and this ist the first part witch is modified in this cfg. I'm nod a modder, but i searches the web an i think therer are some errors in this file.

    This is how the first entry looked. the following entrys looked similar.

    @PART[KW2mSRBNoseCone]
    {
        @maxTemp = 1523.15    emissiveConstant = 0.9
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }

    I think the problem is, that emissiveConstant = 0.9 has not the right operator in front. I looked in the patched KWRocketry Part.cfg and dosn't find an antry for emissiveConstant = 0.9. If i see this correct stands the @-operator for modify, but there is no such entry . Because of that i edit all 'emissiveConstant' in DeadlyReentry-KMRocketryFairings.conf and add a % in front of them (% = modify or add).

    Now the games starts correct for me.

    Thsi is the complete file, yust find DeadlyReentry-KMRocketryFairings.conf in GameData\DeadlyReentry ind youre KSP folder end replace its content with this.

    @PART[KW2mSRBNoseCone]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }
    @PART[KW1mNoseCone]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }
    @PART[KW2mNoseCone]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }
    @PART[KW3mNoseCone]
    {
        @maxTemp = 1523.15
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }
    @PART[KW5mNoseCone]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012
            skinMaxTemp = 2000
        }    
    }
    @PART[KW*FairingCone]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }
    @PART[KW*FairingWall]
    {
        @maxTemp = 1523.15    
        %emissiveConstant = 0.9
        MODULE
        {
            name = ModuleAeroReentry
            skinThicknessFactor = 0.1
            skinHeatConductivity = 0.012        skinMaxTemp = 2000
        }    
    }

    I hope thats not the wrong solution an it works for everyone else.

    And before blaming Starwaster, i think he dosn't update because KWRoketry isn't officaly updated for 1.0 atm.

    Oh, and sorry for any misspelling, my school english isnt very well :(

    That completely did it, thank you very much!

    [1.02] KW Rocketry v2.7 Available - 1.02 Compatibility! - 16/05/2015

    in KSP1 Mod Releases

    Posted

    Has anyone using KW Rocketry started using Deadly Reentry for 1.02? It seems like the two don't agree somehow--at it happens, older versions of KW Rocketry also seem to disagree with the new DR as well (they didn't conflict with DR for 0.90, when it wasn't functional).

    I know it's not up to anyone to fix the incompatibility, but I can't quite figure out what's causing the issue myself. Maybe someone's having better luck.

    [1.12.*] Deadly Reentry v7.9.0 The Barbie Edition, Aug 5th, 2021

    in KSP1 Mod Releases

    Posted · Edited by Synthesis

    So, is anyone getting hang-ups on loading, amid module manager patching? I used the error correction patch, but now I can't complete loading (with or without DDS files supplied by Insane Plumber). Not sure what could be causing it, I know removing DR fixes the issue though.

    Guess I'll look for incompatibilities.

    EDIT: I'll be damned, it was ol' K&W Rocketry. Guess something about it and DR at the same time upsets Module Manager--it happens either with 0.90-compatible KW Rocketry and the up-patched version. Naturally, this isn't your problem Starwaster, but I want to share it in case anyone else runs these two mods together (especially if they've got it working somehow).

    Flags don't appear in Tracking Info Window? (1.0 and 0.90)

    in KSP1 Technical Support (PC, unmodded installs)

    Posted

    So, I was slightly mistake in my diagnosis--but I'm getting the same thing.

    Tracking_zpsoarxsbxq.png

    As it happens, DirectX vs. OpenGL doesn't seem to matter. I'm using the stock red and yellow "stripes" flag (not the transparent default flag that reads "Kerbal Space Program"), and I get a red box instead. I guess the info window just takes a pixel from the corner of the flag and displays that? What flag are you using, Sal?

    OpenGL Mode Doesn't Work

    in KSP1 Technical Support (PC, unmodded installs)

    Posted · Edited by Synthesis

    In my case, it IS resolved by not going into full-screen mode. If I run 1680*1050 or lower windowed, I can use -force-opengl. I load a save game at the space center with my mods and only using 1.5 GB of RAM. If I use full-screen with -force-opengl, no matter the resolution I set I get an error that the resolution can't be set. If I load full-screen with no arguments on the command line, I load with 2.9 GB RAM usage.

    Interesting--when it doesn't work, what happens? Does it hang on the end of loading? That's what happened for me.

    As an experiment, I tried setting it to a lower resolution (1680x1050), setting it to be windowed in normal DirectX, then tried running through OpenGL--the window briefly was at the correct size, then reverted to a different resolution (it always goes to that size in my case), and then hung in the same place (checking the last asset before the spinning planet load screen). Weird. Looks like this new Unity version will not run OpenGL on my system, bummer.

    EDIT: Okay, I played around with the settings a bit more, and I got OpenGL working, hurrah! Let's see if it keeps up after I restart though.

×
×
  • Create New...