Terwin

Members
  • Content count

    910
  • Joined

  • Last visited

Community Reputation

557 Excellent

About Terwin

  • Rank
    Spacecraft Engineer
  1. [1.3] - Modular Kolonization System (MKS)

    Do you have USI-LS installed? I think that habitation, as a life support related function, may be part of USI-LS. That is usually the reason that habitats can do nothing other than whatever efficiency-boost mode they may have. For MKS reactors, you should have a 'Perform Maintenance' action that will top off both nuclear fuel and machinery as applicable. For NF reactors, you may need a module manager patch to allow this action. (I also find NF reactors to be much hotter, hungrier and more fragile than MKS reactors, so I remove the NF MKS reactor patch and stick with MKS reactors myself) Also, a nuclear fuel refinery will automatically deposit any refined fuel in any attached storage(including a reactor), so explicit refueling may not be needed if you have a refinery on your base.(not 100% sure as I always have a manned workshop by the time I am producing nuclear fuel, and a workshop with an engineer in it will automatically perform maintenance every day)
  2. Patch 1.4.3 to be released next week!

    Have you ever had a real Heisen-bug? one that changes when you turn on logging? My first one was in school when we were writing a OS as a team project. No one realized the memory location we were writing our log messages to was actually over-writing part of the code... Sure but manufacturing processes always run on exactly the same environment(aka the real world where Iron is always harder and heavier than aluminum, but aluminum cools faster because it is a better conductor), for software that can only happen when you provide the hardware as well(and keep it in a locked box that the users are not allowed to tinker with). How well would those 'consistent' manufacturing processes work if you had to ship the same manufacturing line to all factories, even though in some of those factories Aluminum is heavier than lead and harder than diamonds, but high-carbon steel has the consistency of tapioca pudding? Could you still guarantee that all of those product lines would ship the same, high-quality products? Tell me, how many CNC systems have you seen that sell for less than $100 and will run on any custom computer you build for it, with no requirements more stringent than 'CPU at least as powerful as computers made at the start of this decade'? Industrial tools will often have embedded computers of one sort or another, but he creator of those tools will also specify the exact specifications of those computers, including every program that should be run on them when working. I am sure that if SQUAD could specify the entirety of your computer(including operating system version, CPU, bios version, Graphics card, ram, all input devices, power supply, all installed software, including driv3er versions, and even the brand and version of the memory cards used) they could perform deeper tests with the specified hardware and prevent such 'obvious' bugs, but they do not have that much control, so they test what they can based on the reported system specifications of their installed base, needing to make a much broader set of tests on lots of different hardware configurations. Also, a $40 game does not necessarily have the testing resources of a $10K-$100K piece of CNC equipment, so the total amount of testing being spread over many more system configurations is probably also much smaller, leaving you with relatively shallow testing for many configurations, and probably none at all for anything uncommon. And don't pretend that the latest thousand dollar GeForce card using a beta release of the next version of the latest driver will behave exactly the same as integrated graphics on a dell economy box from 2005 which has never had its drivers updated. Sure the game may always run exactly the same on the same hardware with the same software running in the background(Deterministic), but I can guarantee that we are not running identical systems and code that works perfectly for me, may well fail to finish the start-up process on your machine(not so deterministic).
  3. [1.3] - Modular Kolonization System (MKS)

    Kerbalism replaces the RoverDude designed stock background processing system(no processing when outside of the 2km simulation range, and then catch-up in 6 hour batches when back under simulation) with a flavor of continuous simulation of all vessels in game(presumably with lots of short-cuts to improve performance). It is well known that Kerbalism does not fully simulate all vessels outside of the current focus, and this breaks many parts of the MKS harvesting and manufacturing processes which depend on either active simulation or the stock background process.
  4. [1.3] - Modular Kolonization System (MKS)

    The MKS install includes a version of GC, but I do not think that it includes the updated version that Allista has packaged for 1.4. Is it possible that you allowed MKS to over-write your GC install?
  5. [1.4.1] Ground Construction

    That is why 106 is the expected value, but Allista was saying, 64.4+64.4=128.8 which is larger than the expected value of 106.
  6. [1.3] USI Life Support [0.5.0]

    @-MadMan- the version of your USI-LS install would be helpful. It is also polite to other members of the forums to put sizable chunks of copied text into spoiler tags.
  7. [1.4.1] Ground Construction

    I think I see your problem: Kit cost is the cost in funds for the DIY kit in the VAB. 700K fund for the kit vs 800K funds for the entire base. Kit Res is the number of material kits (64.4K in your image) It looks like Kit weight and required mass of material kits are both about 70% of the dry mass of the vessel in your example. Not terribly unreasonable as one would expect some waste in packaging and assembly in a hostile environment, especially if you are including some resources in the DIYKit.
  8. [1.4.1] Ground Construction

    I'm not sure about the 8:1 ratio you mentioned, but the biggest advantage of GC is allowing the use of locally sourced materials for building parts/bases. And if you use KIS/KAS you can ship several smaller kits, with the first barely able to produce material kits and provide short-term habitation while you build more kits with parts that can provide more capability and longer habitation. (or you could add OSE Workshop and use GC to build the initial 'starter' base and use OSE to add parts one at a time as wanted/needed) While I believe that there is a plan to allow on-site construction of DIY kits eventually, I find that OSE Workshop is a good stand-in until that is available.
  9. [1.3] - Modular Kolonization System (MKS)

    I use a combination of Ground Construction(for the initial base) and OSE Workshop(to build modules that expand that initial base). After finding a good base location(and deploying any automated miners needed to cover missing resources), I land 3 ships: DIY container, Material Kit container, Construction ship(the only one with crew/habitation) The starter base in the DIY kit can make material kits and only needs a nuclear refinery, a dditional nuclear power(I usually launch with a 10% fueled 1.25m plant in the kit), and a second industrial refinery to be able to make specialized parts and machinery. After that is is just a balancing act as power, production, and habitation are increased.(I usually drop off at least a dozen Kolonists once there is habitation to support them, using their shuttle as the emergency escape vehicle for the entire station crew as all three of the original ships get dismantled or integrated as part of building the base) Note: you need the largest KIS container(5m?) to be able to make 3.75m MKS parts. The first posting in this thread has a link to the github repository where Roverdude deploys his releases. You can get any released version of USITools, MKS, or any other USI product from there.
  10. [1.3] - Modular Kolonization System (MKS)

    Have you installed USI-LS? USI-LS and USI-MKS are thoroughly integrated, but they are still distinct mods and unless you install the entire USI collection(I forget the name for this), you will need to install both MKS and LS if you want MKS bases to have life support and habitation functionalities.
  11. KSP Weekly: The FELT

    That really depends on what you are doing. Wheels, docking ports, and water have all caused major performance headaches in KSP in the past(and in some cases in the present) even for relatively small vessels. It is entirely possible that the port went with the Kerbalism(aka run everything real-time) background processing as opposed to the RoverDude(aka ignore everything outside of the 2km 'active' bubble and just do 6 hour bach updates when things get in range) background processing approach, but I would be surprised if that were the case. What I can say, is that if you do not know which parts cause problems, you can get a slide-show with 50 part vessels even on a top-of-the-line gaming rig because there is a lot of exponential processing in KSP(compare a 50 part vessel with 40 docking ports compared to a 100 part vessel without any docking ports, for example. Every tick, each open docking port will find and examine every other open docking port in physics range and check to see if it needs to do any docking. I think this may have been mitigated in one of the 1.3 versions, but before that it was awful for stations with lots of docking ports) While this sort of thing can be partially mitigated with a high-end (and high-price) CPU, it is a problem for PC and console gamers alike. And this is just the sort of thing you need to expect when dealing with an indie shop. Even though KSP is not owned by an indie shop any more, that sort of problem is not fixed quickly or without a great deal of pain and expense, so while I am expecting the number of problems like this to go down, I deem it highly unlikely that they will be able to eliminate them within the life-span of the game.(and even if they do, it would still take a world-class super-computer to handle the physics calculations for a wackjob level construct in anything like real-time, just because of the math involved) Something you forgot to include in your comparison between KSP and Elite: how many physically-connected objects can you have in a single Elite construct? (keep in mind that for most games, a single vessel is only one piece, while KSP will have a dozen pieces for even simple vessels. This meanins even if they have similar levels of physics details, that 12 piece KSP vessel requires roughly 2^12 times as many calculations as that 1 piece Elite vessel, and a 50 piece KSP vessel takes a similar amount of processing power as Elite having 1.1e15 single-piece vessels in the same scene. Of course KSP actually has does more detailed physics calculations, so those numbers would probably be a low-ball estimate)
  12. [1.3] - Modular Kolonization System (MKS)

    USI-LS needs a way to make fertilizer if MKS is not installed and the 1.25m ISRU is not really useful for ISRU at bases sizes where you have habitation, so it makes a reasonable 'add this for this one function' piece. The rate is also pretty awful(both raw speed and fertilizer per unit of ore), so it is not unbalanced to leave it as-is. (A convert-o-tron 125 weighs 1.25 tons while a crush-o-matic weighs 0.08 tons and has an output that is not less than 1/15 of the small ISRU but does take a lot less raw resources)
  13. While I imagine it must be even worse with the control limitations of a console, asparagus staging on a PC has the same headache, and if you don't go back and double-check each stage, it is easy to make a mistake that will doom your launch. The fairly new fuel flow priority functionality does give an alternative approach to asparagus staging, but even then, if you do not double-check the staging of your decouplers it is easy to doom your launch, and you no longer have engine cut-outs to alert you to the need for staging.
  14. [1.3] USI Life Support [0.5.0]

    @Darinth it is important to remember that the life support panel is not live data, it is only an estimate based on the storage at the time of your last visit and the life support demands of any kerbals on board. If you have energy generation on your vessel, and EC is not draining when it is inside simulation range, then you should be pretty safe to ignore the EC part of the panel. The actual calculations will not take place until the base undergoes catch-up processing the next time you visit it(just like the stock ISRU does). The supplies and habitation numbers are generally of much more concern, but so long as you are producing fertilizer on-site and your supplies stay full when inside the simulation range, you can probably ignore the supplies portion as well. The only times it is safe to ignore the habitation numbers are A) when you have both enough active colonization modules to cover your occupancy count and a surplus production of colony supplies over and above the consumption of your colonization modules and B) when you have sufficient hab time for 'indefinite' habitation on all kerbals(50+ years or 1+ years for pilots and when habitation is 500%+).
  15. [1.3] USI Life Support [0.5.0]

    Just be careful when updating to newer versions, as you do not want random files from previous versions causing odd behavior.