Jump to content

troyfawkes

Members
  • Posts

    123
  • Joined

  • Last visited

Posts posted by troyfawkes

  1. Not sure if this was brought up, but rocketry started with the military. I don't think you could talk about the history of rocketry without talking about the V-2 (the German name for it translates to "Retribution Weapon 2"), which was the first man-made object to pass the boundary to space.

    Wikipedia tells me that 3,000 V-2s were fired at the allies during WW2, resulting in upwards of 9,000 deaths (add 12,000 if you count the forced labour to build them). And that's just one example.

    Spaceflight has a dark history.

    I think it's noble that Squad didn't include warheads in the first couple parts of the tech tree and shows the intention of the stock game, but if they did it would have been more realistic. I believe one of the (optional? it's been a while) packs in the RO universe includes wardheads, for example, which makes sense because it fits into our history and a push for greater realism. We also have life support packs that often kill kerbals. The stock game has a million ways a kerbal could die.

    It's definitely not just a black and white issue, and unfortunately the line gets drawn by someone who isn't you (in the general sense, not talking to anyone in particular). In this case, I think Squad would certainly avoid any connection to a mod that simulates a war crime in graphic detail, such as the napalm example, but I can see why it's well within their limit to include BD. It's definitely a balance, though.

  2. I thought this post was going to be a negative rant, but I found it really constructive and thought provoking :)

    I agree on all points, and while I understand the "no one can say which mods should be stock" idea being put forth, I think we could all agree on some basics :) E.g., KAC, KJR and some implementation of an editor/in flight dV display.

    I'd love to see more love put into rocket parts, specifically engine variations, and a complete rethink around planets. Like if they dedicated a large update exclusively targeting things to do on planets/moons, I'd be stoked. Like adding on a mission system rather than just contracts, e.g. land on Duna, set up a base with X criteria, and then follow the progression of 12 contracts around testing parts, bringing scientists or experiments to locations, and returning within a certain window (or something like that). Or really just spend a good chunk of timing thinking of what could be done to make me want to spend a year exploring Duna rather than just launching another random probe or what-have-you.

  3. Hey Angel! Looks like you're getting through a ton of bugs / updates really quickly, congrats :)

    Using 0.9.11 I'm having some trouble with the Homestead. It doesn't switch between its options like everything else does (I tried all your other parts which switch fine). I think this is the associated error:

    [LOG 16:35:48.717] WBIMultipurposeHab [FFF1546C][714.7902]: loadModulesFromTemplate encountered an error: System.NullReferenceException: Object reference not set to an instance of an object
      at WildBlueIndustries.WBIModuleSwitcher.loadModulesFromTemplate (.ConfigNode templateNode) [0x00000] in <filename unknown>:0 

    The Homestead starts as Ironworks and can't be switched, either in the VAB or in Flight/Launchpad. Let me know if you can't reproduce and I'll dig around some more :)

  4. 3 hours ago, TDW said:

    The bug appears to be caused by the texture quality graphics setting in the ksp main menu. If it is set to half or quarter res the textures for the characters don't load properly. If your system allows i would advise setting your textures to full res while this is looked into.

    Looks like that's the issue for sure; changing to full texture quality got it to work. If it's relevant, I also have Dynamic Texture Loader installed.

    @Steven Mading sounds like you guys have figured this out a bit more, but just in case you still need it:

    • Windows 10
    • Steam
    • CKAN
    • 32bit
    • Whatever the default graphics are (my launch options are  -popupwindow -single-instance)
    • NVIDIA GeForce GTX 765M
  5. 9 hours ago, hvacengi said:

    Could you please swing over to github and create an issue for this?  I know we already have an issue submitted with issues for different case of letters in file names, and this should get fixed too.  Did you test it using string literals as well ("anyfile" and "othername")?

    https://github.com/KSP-KOS/KOS/issues/1498

    I did, yeah. I tested it in a bunch of other scenarios as well. I actually can't get rename to work under any circumstance, which is frustrating because I use it extensively in my boot file.

  6. Hey folks, web guy checking in :)

    One super quick trick for getting more regular, speedy server responses is to hook up a CDN. In the case of Spacedock, CloudFlare has a free service that ticks off a thousand little speed best-practice boxes, and setup takes maybe 15 minutes if you know what a DNS is.

    For actual bandwidth usage, you might find that your host's pricing structure is set up for conventional websites and that a site dedicated to warehousing and sharing large files is better served by a targeted provider. I don't know for sure but I think Rackspace and its competitors have solutions specifically designed for bulk file transfer, which means you pay a lot less per GB.

    Hope that helps!

  7. Thought you guys might appreciate this. I was having trouble figuring out how to create a hyper specific Execute Node script using physics instead of constantly checking variables, and I wrote out the solution and my thinking. Some notes:

    • Still not polished, it's basically a purely mathematical solution right now.
    • It takes into account change in mass through burn.
    • It takes into account multiple engines with different Isp.
    • It uses vectors to determine when steering is ready.
    • It knows on load when your burn starts and ends, no graduated checks along the way.

    I'll be doing more of this as it's a really solid way for me to learn how everything works.

  8. 16 hours ago, i208khonsu said:

    I've thought about doing something similar to this, but instead of science requiring ore from different celestial bodies to produce these upgraded parts. For example Mun could ore could offer increased impact strength, Duna would allow over thrusting, Moho could be increased heat tolerance, and the elusive Eve ore would provide better fuel efficiency.

    This sounds really cool and more in keeping with KSP than a lot of ideas. It also adds a reason to go back to various places that you've been to in previous saves, or even in the current campaign to collect more ore to upgrade different parts or further upgrade a current one. If you're actually interested in working on it, I'd be happy to help :)

  9. I love some of the recommendations here. I'd be really interested in seeing:

    1. Part Cost Reduction -- I know you said Strategies should help, but this mod would make a lot of sense in this regard as well (IMO)
    2. Realistic Improvements -- Not real as in tied to a real life counterpart, but like prykpryk said, cap the max upgrade and give diminishing returns as you approach it. You might have to limit this based on improvement category (e.g. a battery with double the capacity is reasonable, but an engine with double the ISP or thrust is not).
    3. Again like prykpryk, if I've got this mod installed my masochistic side would love to have the option of dropping the base values on some of these aspects to as low as 80% of their base effectiveness.

    Super happy you made this mod, you're a creative genius :D

  10. Hullo! I remember seeing this guide previously and it being super useful. I'm going through the math again and everything is broken here! All of the other resources online assume that I know some pretty intense math and don't exactly answer my question. I'd love to see this guide updated to work again :D

  11. AutoPilot PID question!

    I'm struggling with the autopilot at the moment. The default values cause my crafts to flip around like lunatics when looking to point at a vector. I've been fiddling with the values as well to try to find something reasonable, and it's just not going super well. I was wondering if anyone had any PID values that work for them?

    It's kind of silly that my biggest issue isn't calculating an orbit, but rather stopping insane auto corrections on just pointing the right way :'(

  12. Hey guys :)

    Two questions.

    First, I was reading thoughts on HASFILE here (https://github.com/KSP-KOS/KOS/issues/1105). Has that been implemented in any way yet?

    Second, I'm having huge issues with the docking ports helper functions. E.g., ship:dockingports[0]:undock(). It doesn't always work as expected. You can recreate my issue exactly by creating a ship that has 2 docking ports attached to each other and trying to undock() them on the pad. I got around the issue by writing out this function:

    FUNCTION decouple {
        PARAMETER tag.
    
        SET my_part TO SHIP:PARTSTAGGED(tag)[0].
        SET my_mod TO my_part:getmodule("ModuleDockingNode").
        IF my_mod:HASEVENT("decouple node") {
            my_mod:DOEVENT("decouple node").
        } ELSE {
            SET docked_node TO my_part:CHILDREN[0].
            IF my_part:PARENT:name = my_part:name {
                SET docked_node TO my_part:PARENT.
            }
            SET docked_mod TO docked_node:GETMODULE("ModuleDockingNode").    
            IF docked_mod:HASACTION("undock node") {
                docked_mod:DOACTION("undock node", 1).
            }
        }
    }

    This works fairly flawlessly. Am I just doing something horribly wrong with dockingports? Maybe something like this would work to resolve the dockingports issue? Obv. you could refactor to make the function more general.

×
×
  • Create New...