Jump to content

RocketRyleigh

Members
  • Posts

    82
  • Joined

  • Last visited

Posts posted by RocketRyleigh

  1. If Bombaatu still wants to know, and if severedsolo feels like checking it out and seeing about a fix, I think Kerbal Construction Time causes an issue with the "Do Some Science!" contract. I was having the same issue as Bombaatu, but uninstalled KCT earlier for unrelated reasons, and now the contract completes upon launch.

    My thought is that maybe the issue is coming from KCT intercepting the launch button to start its building mechanic, so that maybe Exploration Plus is detecting that you've "launched" a mission, but then you don't actually go to the flight scene, and press a second "launch" button through KCT once the build is done.

  2. Question for anyone with experience with KCT in a career game:

    I'm sure they're all made to balanced, but for the presets, would you say that the "Upfree" preset (stock building upgrade system) works well for a long-play career where I don't want to spend forever in the early game? I'm mainly wondering about the impact of only having one build rate per facility relative to the design of KCT.

    Edit: Open to suggestions of other setups too. I want the build-time consideration for sure, cause I combine it with all the stage recovery mods, but I've grinded the Kerbin system a lot in the past and want to get further sooner.

  3. Hi cmet, amazing work on KWP. Just two small questions I might just be missing the answers to:

    With the climatology vs. point weather data, is the idea to use one or the other, or just any combination of the two? Totally works for me if the former, I'm playing on a potato, which leads to question #2:

    Do I have the right impression that point weather data would be the less resource intensive of the two? I'm just assuming that since then it's not calculating global weather data, but one comment from the thread made me second-guess.

  4. I don't know if this is within the scope of what the Kerbalism devs are intending, but would you/do you guys have any interest in some kind of integration with ScrapYard for like, some use of the part tracking for your reliability features?

    My impression is that Oh Scrap! integration doesn't really make sense, but IMO at least, Kerbalism and KCT fit nicely together gameplay-wise, KCT uses ScrapYard's inventory, and so maybe Kerbalism could do something like reduce the reliability on reused parts, so there's a tradeoff between faster vessel construction and parts wearing down from multiple uses.

    Just an idea in the idea box for ya, plus I'd love to see these mods have some kind of interaction.

  5. Hey LGG - you mad genius. I was just wondering if you'd know offhand whether StageRecovery would be able to play with NIMBY at all. Without testing, my hunch is that StageRecovery isn't technically "recovering" vessels, and NIMBY's restriction is placed on normal vessel recovery, so StageRecovery might just ignore NIMBY's beacons. But I'm just guessing and I can't test right now - just figured I'd ask you!

  6. So I checked back on that Kerbalism issue thread, and they were making some points that seem reasonable, and wouldn't necessarily suggest the kind of compatibility between failure systems that the OP of that thread was thinking of (I think maybe they were over-representing an edge-case solution that worked for them as being a general solution).

    A couple of points they mentioned:
     

    Spoiler

    "Nobody ever defined what this issue is really about, apart from showing OhScrap failures in the Kerbalism UI, which would be confusing and not really Kerbalism's job IMO."

    "I don't really see how OhScrap could really integrate with Kerbalism failures, they essentially do the same thing with different gameplay paradigms and technical solutions. If anything, the only "integration" would be tweaking Kerbalism's reliability MM patches in the presence of OhScrap so Kerbalism's reliability only focus on the few areas that aren't already covered by OhScrap."


    So I don't know ultimately if anyone's gonna find it worth it to add specific integration. Personally, I'm torn, but will either go with disabling Kerbalism reliability and using Oh Scrap!, or settling for Kerbalism and like Kerbal Launch Failures for the gameplay I want. Not sure yet though.

    Koffins, though? Locked-in :P

  7. 5 minutes ago, zer0Kerbal said:

    Thank you. Total credit goes to original authors of SYD/OHS ( @severedsolo and @magico13) .

    Of course, but you're responsible for maintaining them for us to keep using :) that definitely counts!
     

    6 minutes ago, zer0Kerbal said:

    Have you checked out my other two mods?

    You mean do I crew all Hallowe'en missions with only dead Kerbals in koffins? I'm damn well going to now, I'll tell you that! :P 

  8. 4 hours ago, zer0Kerbal said:

    @RocketRyleighthank you. +1 :rep:

    https://github.com/zer0Kerbal/OhScrap/issues/45

    https://github.com/Kerbalism/Kerbalism/issues/493#

    If Kerbalism is willing to write a simple two-way API - then integration (fairly tight) is possible and might actually be a way to help Kerbalism to shrink its codebase and assist its developers.

    You're welcome :) I love both of your mods so I definitely hoped they could work together.

    I checked back on the Kerbalism issue thread too, and I don't have enough context to follow completely lol, but if this means we're getting Oh Scrap!/Kerbalism compatibility, that's pretty damn nifty! I do like Kerbalism's whole ecosystem, it's very well conceived, so if we could have Oh Scrap! communicating with Kerbalism's reliability, that'd definitely be ideal!

    Great work on everything in general btw! :) It is fully appreciated <3

  9. On 10/31/2021 at 10:59 PM, Galileo chiu said:

    Does it work with Kerbalism?

    So take a read through this post first to get someone's experience using both Oh Scrap! and Kerbalism's reliability module together:
    https://github.com/Kerbalism/Kerbalism/issues/493

    Another option, the way I have it set up, is to go into the "KerbalismConfig" folder in GameData, open "Settings.cfg", and you're able to literally just disable Kerbalism's reliability module IF you wanted to use Oh Scrap!, and didn't like the way they play together as the player described in the post I linked (personally, I just wanted each mechanic to be handled by only one mod, and prefer Oh Scrap!'s failure system).

  10. On 11/1/2021 at 12:11 PM, jwbrase said:

    Extra nifty would be the ability to specify a datum point on the spacecraft in the hangar, and then, in flight, type in an offset in meters from the datum, punch a button, and have the fuel balancer automatically maintain CoM at that position.

    I don't think this does ALL of what you want, but it's main feature would give you the automatic CoM balancing:

    Hope it helps!

  11. 2 hours ago, OhioBob said:

    I've never seen or heard of a problem like this before.  I can't speculate as to what might be causing it.  You may have to systematically remove your mods until you can identify which one is be causing the conflict.  Short of that, there's not much else I can recommend.

    Well I feel special then :P That's not a big deal at least, I've wiped and reinstalled my mod list many times in the past week lol (mainly cause of memory leak crashes, I'm pushing the envelope lol). I'll try and track down the culprit, and if I can, I'll let you know what it is in case you want to add it to the known issues.

    2 hours ago, OhioBob said:

    That's a known issue.  The JNSQ options only appear the first time you go into your settings.  But you typically only need to set it once.  After that you'll get whatever you set it to the first time even though slider may no longer show all the options.  It's not a problem, so don't worry about it.  If you've moved the slider around and feel you made need to reset it to be certain you have the correct setting, the only way to get the JNSQ options back is to delete the file settings.cfg in your KSP folder.  Deleting that file will force you to redo all of your settings.

    Gotcha, set it and forget it. Sounds good to me! I was only trying to change it after the fact in a vain attempt to fix the memory leak without removing more mods.

    Thanks for the quick response as usual @OhioBob  <3

  12. So I'm running into an issue with bodies not appearing in a heavily modded install. I followed the installation instructions for JNSQ and installed that alone before any other mods, after running unmodded KSP, and it worked fine even when I then added Grannus JNSQ on top. Since then, I installed the rest of my desired mods, and now when I load it up and go to the tracking station, only the Kerbin system, Jool itself, and the two stars are appearing. Two of the biggest additional mods I'm using are MKS and KSPI-E, but there are many more.

    I can provide more info if needed, but if this is an issue that's maybe been answered specifically in the thread already, then maybe someone already knows the answer (I would scrub through to see if anyone asked/answered this, but 82 pages is a lot to ctrl+f through).

    Extra question: What's up with the graphics settings for Terrain Detail with JNSQ installed? At first, it seems to add it's own low/medium/high with a JNSQ prefix in addition to the vanilla low/medium/high all on the same slider. And on top of that, no matter what I last selected, when I next reload the game, the slider is all the way to the left with the text "New Text"  in place of a setting, and I'm just now noticing the slider just seems broken. When I move it at this point, the "New Text" goes away, but now it's alternating between only saying "low" and "high", and "low" and "medium", and isn't changing in a regular way between each "notch" of the slider. Should I just be leaving that slider alone with JNSQ installed?

    Edit: I'm running this all on 1.8.1 and installing mods through CKAN.

  13. Dumb question about using KCT with Bureaucracy:

    I want to turn off KCT's facility upgrade setting to allow Bureaucracy to handle it, but I just want to double-check I'm choosing the right setting, because the wording on the Bureaucracy page just refers to the "Building Upgrade" setting for KCT, which doesn't appear in the settings panel. I'm assuming I want to turn off "KSC Upgrade Times", but I was just unsure because of how much Bureaucracy does with KSC facilities whether that's all I need to turn off in KCT.

  14. 3 hours ago, OhioBob said:

    @RocketRyleigh, below are JNSQ's RemoteTech changes.  Perhaps it will make some sense to you.  It looks to me like it's just multiplying all the antenna ranges by 4.

    I doubt it makes any more sense to me than you lol, but I appreciate you posting the patch for me. It also looks to me like it's multiplying everything by 4, but the part I think I need beyond that is how or if RemoteTech's RangeModelType is affecting JNSQ (since it affects the effective ranges of antennas), and I'd probably need to ask Team Galileo about that. I'm kinda starting to think it might just override RT's range settings, which is fine with me if they're being scaled to fit JNSQ anyways.

    Thanks for your help in any case @OhioBob <3

  15. Thanks for that info at least @OhioBob. I'm not surprised it's you who answered either :P you've always been so helpful on the forums (you helped me with something awhile ago, I think it was Realistic Atmospheres).

    For the moment it sounds like my safest bet is to just leave RemoteTech's settings alone, which I don't mind at all. Although if @JadeOfMaar or any of you other indispensable KSP modders can give any insight on how JNSQ interacts with RT's Root range model or even it's own range multiplier setting, I'll definitely appreciate it, and think it's worth having that info available for anyone else using old mods like me lol.

  16. So I noticed this in the OP and just had a question in relation to RemoteTech:

    Quote

    When starting new saves under JNSQ, we advise that you enter Difficulty Settings and raise the DSN modifier to 4x. JNSQ applies a patch to increase antenna range by 4x, so leave the range modifier at 1 (changing it triggers a bug that may prevent science transmission).

    How might this patch interact with RemoteTech's antenna range settings? In particular, the RangeMultiplier and the RangeModelType. The original advice for using RT's "Root" range model included changing the RangeMultiplier setting to 0.5 (halving the range), since the Root model effectively doubles antenna ranges.

    I'd just like to end up with an equivalent kind of antenna range in JNSQ to using RT's Root model as it'd be balanced in a stock system with the RangeMultiplier halved as advised, but I'm not sure when or how exactly RT's range modifications are being applied compared to JNSQ's, so I'm not sure where to set my RT RangeMultiplier slider when using the Root model to account for JNSQ's 4x increase.

  17. Hi there, I have a couple of questions about this mod.

    Would there be compatibility issues between Station Keeping and a mod like Kessler Syndrome which adds an option to enable vessel orbital decay? And if the mods are compatible, does Station Keeping include some mechanic for resource usage to maintain a given orbit?

    Basically what I'm asking is if Station Keeping can be used alongside Kessler Syndrome to essentially become the old "Orbital Decay" mod.

  18. 1 hour ago, Starwaster said:

    Make sure you've got the following two lines in there: There shouldnt be any temperature highlighting there...

    %gaugeThresholdMult = 1.20460941

    %edgeHighlightThresholdMult = 1.20460941

     

    Hmm, weird, those two lines are definitely in there, but the temperature highlighting remains :/

    If anyone else following this could test this fix as well, more data points would be very helpful:

    3 hours ago, Starwaster said:

    I'm starting to get an idea of how this might be happening... probably because ModuleAeroReentry isn't initializing properly for Kerbals. Why they're getting singled out I don't have 100% worked out yet but there's a file you can download to fix it. It was going to go in the next update but I've been using it with 7.5.0 which is why I don't have exploding Kerbals, apparently.

    https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-KerbalEVA.cfg

    Don't forget to check out that working copy of DRE 7.5.0 @Starwaster; maybe being able to check the before and after of whatever changed in the past week would be helpful.

  19. @Starwaster Okay, so that cfg definitely solves the exploding issue, but has a minor consequence; I guess since you raised some temp values, the stock critical temperature gauge thinks it needs to be displayed for the Kerbal at all times. Is that an unavoidable byproduct of this fix, or just a result of a temporary solution (just out of curiosity; between F2 and Through The Eyes of a Kerbal, I could live with it if need be)?

    Edit: In case it's helpful, the new Thermal Mass and Skin Thermal Mass values are 312.7 kj/K and 15.4 kj/K, respectively.

    Also, it might be worth checking out this copy of DRE, which is 7.5.0 and in which the exploding issue never came up; it was downloaded a few days ago:

    https://www.dropbox.com/sh/p0kphqe2t7cghg4/AAAOLbBScxXqMpzZUxlAxnAwa?dl=0

  20. 1 hour ago, Starwaster said:

    I'm starting to get an idea of how this might be happening... probably because ModuleAeroReentry isn't initializing properly for Kerbals. Why they're getting singled out I don't have 100% worked out yet but there's a file you can download to fix it. It was going to go in the next update but I've been using it with 7.5.0 which is why I don't have exploding Kerbals, apparently.

    https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-KerbalEVA.cfg

    Copy that to your DeadlyReentry folder. You might want to take a minute to read its contents because it actually imposes some harsher limits on the Kerbal internal temperatures... namely, their absolute maximum limit is the temperature of boiling water. Their space suits (skin temp) is more resilient and has better emissive and absorptive properties (contrary to popular belief you can have differing values for each)

    Edit: I made an edit to it a couple of minutes ago so make sure you have that one, in case you downloaded it while I was editing it.

    Was just out walking the dog, so I missed the first upload of that cfg anyways :P I'll grab it now and load up KSP.

    Quote

    "...it actually imposes some harsher limits on the Kerbal internal temperatures... namely, their absolute maximum limit is the temperature of boiling water. Their space suits (skin temp) is more resilient and has better emissive and absorptive properties (contrary to popular belief you can have differing values for each)"

    Alright I'll definitely take a look, but on that description alone it sounds like a good direction to go IMO (I'm a "MOAR realism! MOAR challenge!" type of player :P); harsher Kerbal temp limits just means stricter mission planning, which I enjoy, and really it makes more sense from a realism standpoint.

    Edit: P.S., Glad you're getting somewhere in figuring it out; I hope my feedback was helpful. Thanks very much for your efforts!

  21. 21 minutes ago, Starwaster said:

    And that's WITH Realistic Atmospheres? You mentioned Jool before. What was the altitude? 400 or lower maybe?

    Edit: I don't see Realistic Atmospheres in that log

     

    My tests from today have all been with only DRE; when I tested in orbit at Jool, I'm pretty sure Realistic Atmospheres was still installed, and I set the orbit to 7000000 (going by memory, not in front of my computer right now, but it was set to just a bit higher than the lowest orbit the cheat menu will safely allow for Jool).

    But I think the log I provided in my last post is more relevant, since it's only DRE installed and I got the same immediate exploding on EVA bug that @Headrip reported in orbit (which is more game-breaking than what I thought I saw at Jool).

    For clarity, the last log was with DRE + MM only and in ~80km orbit around Kerbin, where Jeb exploded immediately on EVA.

    Edit: The Jool thing might've been some interaction between Realistic Atmospheres and ReentryParticleEffect, and I don't think it's related to this bug.

×
×
  • Create New...