Jump to content

voicey99

Members
  • Posts

    1,347
  • Joined

  • Last visited

Everything posted by voicey99

  1. You can get up to one star on Kerbin, two anywhere in space and three stars landed somewhere that's not Kerbin per attendee. The XP cap depends on the skill of the instructor kerbals, but I'm not sure how. There are no automated parts for producing tertiary resources, but you can use efficiency parts for that. The best ones can be installed on MPUs and, owing to how MPUs work, their effect is not affected by lack of crew.
  2. Ok, I'm a bit late to the party on part breakdowns but I've just had another thought. With regards to permanent failures, perhaps they could only have a chance to occur (e.g. 50% at the next breakdown) occur if a part suffers partial failure and you choose to keep running the thing instead of shutting it down for a bit until the repairs guy can go and fix it. It would mean you can still run parts after they suffer a partial failure, but in doing so you would risk causing further, catastrophic damage to the part and justify including what would be a very frustrating scenario while not threatening players who like to stay on the safe side (unmanned bases would be particularly party to this, since they can't be automatically maintained). Your thoughts on that, @DoktorKrogg?
  3. No, though they are consumed alongside SpecParts (maybe?) by the mod OSE Workshop to produce parts that you can attach via KIS. The bit about inflatable modules is that they do save mass, since you can ship the modules in uninflated and inflate them with materialkits after installation so you don't have to lug a large, heavy big top around on a rocket. I believe GC only requires MKTs, though I could be wrong, and the maintenance resource would be the resurrected ReplacementParts with the overhaul resource (if implemented) being Machinery. I see your point about no progression, but this is little issue to most people (you're the first person to comment on it), but changing it would require redesigning the entire manufacturing system from scratch which would take a lot of work and leead to issues elsewhere, so the current system might just be a necessary evil.
  4. It's a known bug with the UI, a fix will be coming with the next release (whenever that is).
  5. The three kolonisation percentages are ratings applied to each planet. They increase over time as kerbals spend time on the planet (requires an MKS part on the vessel), and different specialisations will accrue points in different ones (see this table, RepBoost means they gain Kolonisation points, FundsBoost Geology points and ScienceBoost Botany points). These will add to the Planetary Bonus production multiplier, so as you gain points in them your converter speed will ramp up (see that page for specifics) - all three ratings are capped at 500%. As they increase, you will also accumulate resources (Kolonisation gives Reputation, Geology gives Funds and Botany gives Science) in a Pioneer Module on the base, and these can be collected from time to time. Unmanned drills are exactly the same as normal drills, but they do not apply the Specialist Bonus multiplier, locking it at 1. This means you won't lose efficiency by having an unskilled or no engineer or miner on the base, but you won't gain from having a high-level one either. Their production is slightly less than what you would get with a 4-star engineer. Mobile Processing Units have this feature as well (as well as inbuilt planetary logistics push-only functionality).
  6. This is a problem already - existing inflatable MKS modules are very dodgy with KIS since they have a technical crewcap of 0, so they will delete anything in the inventories of the kerbals you put in there. A dedicated KIS container might also run into these issues, having a technical volume of zero or close to it - maybe the underused USI feature that changes the size of parts according to how full they are (currently found on just the inflatable LFO tank) could be adapted for this?
  7. Yeah, I'll be playing with that off. If you're going to introduce a mechanic, you might want to make it more challenging than simply annoying. Perhaps the amount of RP consumed per maintenance round could be proportional to the difference in failure chance between the base rate and the current rate, so the higher the base rate (which would double every machinery half-life), the faster the actual rate increases (i.e. base rate multiplied by a function of time since last maintenance round) and so you need to spend more and more resources to keep the machine running as it gets older. This also has the added effect of making longer intervals between maintenance cycles more costly - whether this is good or not I don't know, though this could be justified as damaged parts in need or replacement damaging other parts the longer they are left in there. I made a crappy graph in Paint to illustrate what I mean by everything said so far (HL2 being at the same time as the maintenance is a coincidence). That's what I meant by "not an active requirement", though using it in overhauls makes sense (will any other resources be needed?). I wish we could see this USI chat so we can actually see the discussion without you having to relay and paraphrase it.
  8. So, if it's built in to the middle of your base you have to tear the entire thing apart just to get one part out? And place them with KIS? or deploy it as a whole new standalone base? Replacing a part would be a huge and tedious amount of effort, and I still fail to see why an overhaul would't fix it (is logic banned?). Having to make new parts and swap them out on your base just seems unnecessary when you can simply replace the internals. By a fixed hit, do you mean just apply a percentage and never change it? My point is that by the point where the performance hits appear, breakdowns make the production so unreliable and unpredictable it doesn't matter. If you're opposed to any kind of efficiency curve at all, Instead of a curve, after a certain point it would gradually decrease linearly with age (e.g. a few constant percent per half-life, so it would eventually seize up and stop completely after a set time - maybe maintenance could stave off decline?), and this decrease would be dependent on running time and not on production so there would be none of the exponential curves you get with machinery, and you could calculate the production easily given the linear nature of this decrease (i.e. multiplier is 100% * half-lives elapsed after production decrease starts * decrease per HL). By the time a part gets this old though, there is little point in trying to calculate production totals as they would ping around thanks to breakdowns anyway. ReplacementParts used to be a thing, it was depreciated and it's now returning afresh. Machinery will be partially depreciated and relegated to just a mass offset rather than an active requirement (though you may still need it for other things) since it represents just the amount of the part that is filled with machinery, while RP is going to become the active maintenance resource. MaterialKits are a construction resource (you can't fix a machine with a brick), and SP is an intermediate resource (the MKT/SP requirement for switching bays should probably be replaced with RP as well).
  9. If you have a PL-enabled kontainer and a PL-enabled module (MPUs can only push, logistics modules can only push when unmanned and can push and pull when manned by a pilot or quartermaster), when the resource amount on your ship fills up to above 75% of capacity, enough of it will be pushed into hammerspace (with a 5% tax) to empty the storage down to 50%, adding it to the giant planetwide stockpile. If it drops below 25%, enough will be pulled out of the stockpile to fill the kontainer to 50% capacity (no tax for pulling). Large kontainers are not necessarily overkill, since PL can only update once per 6h catchup cycle (when you load a vessel, KSP gives you your backlogged production in 6h chunks). As each kontainer can only effectively utilise half its capacity for this, you need at least 12h worth of production or usage of a resource in order not to lose products to insufficient storage space (if there isn't room for each cycle's output to fit on the vessel, it will be discarded) or running out of input halfway through the cycle. If a failure renders the part completely useless, then they should be rare. I don't see why you shouldn't be able to use the overhaul function to recover from these, since an overhaul is stripping everything out of the part until it's just a shell and replacing it, which would cost you a similar amount of resources to just making a new one. More harsh breakdowns might become more common as the part gets older as well. I posited diminishing efficiency as something that would only kick in (i.e. activate, so it isn't applied at all before this) after many part half-lives once the part gets really old, well past the point where any self-respecting player would have replaced/renewed it long ago. By that point, the parts would be elderly enough that they would struggle to reliably function and you would be constantly running around dealing with breakdowns, so diminishing efficiency would come in at a point where the production uptime is being hammered by breakdowns already and simply sound the death knell for a part than is on its last legs and terminally worn out. Yuup. I always thought drills were getting away with it, since they would be run harder than machinery.
  10. I think it's only P2P, and setting up some kind of chain transfer would be more faff than it's worth if it's even possible. Just use Planetary Logistics, or install a Resource Distributor module (i.e. a Karibou or Malemute rover cab) to extend local logistics range (up to 2 km).
  11. With the part redesign, I mean allow a kerbal to get closer to the CoM so you don't have to fumble around on the outside for the button. As for changing the distance, that's on KIS' end.
  12. I also saw a screenshot of a faraway interaction button in the thread, maybe that was from a previous version of KSP. Anyway, maybe in light of this the 5m kontainer should be redesigned with an indent or tunnel in the centre where EVA kerbals can get close enough to open it, but couldn't you already open them given the truncated oblong design that lets you get closer than 2.5m from the CoM (with the right positioning)?
  13. Hm, on the KIS wiki it states maxDistance controls both item pickups and inventory access. This is corroborated by what I can tell from the DLL, which doesn't appear to have a baked maxDistance and seems to use the one in the cfg file.
  14. It's this formula, which also acts as a multiplier for heat produced (as a % of the VAB value, just add the total % load and multiply the VAB value by that). The best thing to use for MKS stuff is the MKS-brand Thermal Cooling System, which has a huge per-part cooling capacity. I believe it does both.
  15. I meant that a part would have a failure chance to be checked at small intervals (e.g. every day, 3mo is waaay to long), and there would be a base chance for failure that would gradually increase with age to the point where it doubles every HL, rather than a slab system whereby the HL is the failure interval and it won't fail until the next, where it will be double. With respects to overhauls, I planned to separate routine maintenance from overhauls whereby routine maintenance would reset a part's failure chance to the base value (it would increase with time as a multiplier of the base rate), but this base rate would keep ratcheting upwards as the part ages so you will start to get failures even with good maintenance in old parts. An overhaul would reset the base rate to its original showroom value, like you posited for maintenance. I do like the idea of startup failures, though i think these should be introduced as another base chance after quite a few half-lives so they are only a problem for machines reaching the end of their lives. General failures would also only kick in after a HL or two, and efficiency loss would also start to manifest itself in very elderly machines well beyond their design lifetimes to finally kill it off. I would go for Flat, but at small intervals rather than half-lives. Stacked seems quite crude. The case with both of them is that a part should be able to fail at any time (with a reasonable compromise to save on processing power being used to continually flip coins on all converters) rather than at large, set and predictable intervals from manufacture/renewal. Critical unrepairable would not be strictly unrepairable but rather require an overhaul of the part in the same way as resetting the age i.e. you're gutting it and replacing all the machinery inside with new stuff at a significant cost of resources (also resetting age to 0, which regular repairs would not do). Critical repairable would require a cost in ReplacementParts
  16. Hm. Try HyperEditing something with crew capacity over so it triggers him to come back (hab is shared within 150m), and when you edit it away again he should stay normal. If that doesn't work, give me the savefile or something. Drill stats are per drillhead - It says it in the part description. That was my thoughts on part lifespan as well. I said you should be able to restore the part, and (not said then) how long the downtime should be would depend on the part.
  17. Instead of a part suffering a Critical Existence Failure when its health bar reaches zero, what about simply giving it an age stat and a "part half-life" instead? As this age increases past a certain point, breakdowns become more common and after another point efficiency starts to suffer as well, and these effects ramp up over time, and every half-life their effects double until the part is too unreliable and slow to be of any practical use. Also, instead of having to replace the part, what about an option to have an engineer/mechanic go out and, using e.g. half the MatKits required to make it and a substantial quantity of ReplacementParts, overhaul the part to restore it to full working condition - if this part is inline in the centre of a very big base, replacing it is just not an option. IIRC that file only applies to new saves, to change it for saves already in progress you have to change the settings from the KSC screen. I'm not sure if this restores already grouchy kerbals, if it doesn't then open the persistence, find the kerbal's STATUS_DATA listing and change isGrouchy to False.
  18. Use NEEDS[KolonyTools] for DLL detection. Also make sure to run the patches through the Balance Guidelines as well.
  19. AC is the Astronaut Complex. By reload, I mean switch away from it e.g. to the Tracking Station and back so it reloads it. It has a patch to work with TAC-LS (less well than USI-LS). I've got no idea what the other mods on that list are (LLL = Lack Luster Labs aka SXT?).
  20. The Kolonisation folder isn't in the download (whatever it is). You probably can't find all the parts because the version of USITools bundled with the current version of MKS has the custom categories that contain most of the parts broken, replace it with the hotfix here.
  21. So does this mean a base will need constant maintenance to stay in this state, or will a visit from the maintenance guy every few years/months/whatever be enough to keep it running perfectly?
  22. So this means i will use a constant stream of parts in exchange for immunity to breakdowns? That seems fair, though there should be a tradeoff of some description e.g. it would reduce breakdowns to a tiny but nonzero chance (to where they will be very rare, but still happen) or the parts cost would be prohibitively expensive for any base that does not have parts production set up (replacing a part as soon as it shows the slightest sign of damage is going to eat a lot of spares vs only replacing it when it actually starts to fail).
  23. It's not the permatourist bug, that was with tourist kerbals being recovered at KSC and appearing in the AC as tourists (see 3). If they can EVA, they are not tourists - the skill label in their portrait does not update after they change state, you will have to reload the vessel to see it. It probably touristified them during timewarp since they ran out of EC, but detouristified them after the ship updated when it loaded. Do you mean in the AC? They don't - they are supposed to be detouristified when they pass below 25km (?) on Kerbin, and if they don't and you recover them as tourists then it is the bug. Find their STATUS_DATA listing and change their OldTrait to whatever it was before, and do the same with their trait in their KERBAL listing. This fixes them. (no clue, sorry)
  24. Yeah, they should be muuuch cheaper than the primary kerbals. The bug has persistent through several versions, but a fix is coming in the next release (whenever that is).
×
×
  • Create New...