voicey99

.....Orbital Logistics?

I would think that that sort of stuff kinda goes beyond the scope of USI-LS (which has its own thread btw). USI-LS is designed as an 'intermediate' LS mod-i.e. more advanced than a mod like Snacks but nowhere near as punishing as TAC. Having to contend with cosmic rays, radiation belts and shielding just doesn't seem like something a more 'kerbal' mod like USI-LS would do. I did see a few references to reactor radiation on the LS thread, but nothing about space background rads. If you want space rads, check out this mod (not compatible with MKS) as pact of the Realism Overhaul: Also @jd284 since when have kontainers been able to jettison their contents?

Through experimenting in the VAB, I think the formula for additional habtime is simply [kerbalmonths specified÷crew] and for bases with commons it is [total kerbalmonths*multiplier÷{if common's crewcap is exceeded}(crew÷common's crewcap)]. By default all crew slots contribute 1 kerbalmonth (1 KM=30 days) each with a multiplier of 0.25; the multiplier rises to 1 when any habtime module is installed and for bases with commons see the 2nd equation. Considering your inconsistency, I'm guessing you used the ranger habs, the common function of which is currently broken.

It is the maximum number of crew the module can support at 100% efficiency, any more and the effect of the module is reduced per kerbal based on how many kerbals you are over the limit (the crew affected values stack). Not sure of the formula, though.

Indeed, it is extremely overpowered. That's coming from me, making ~10M every couple of weeks with a CMD/REX cargo run and a base with 8-10 1-star kerbals (I'm not sure if its OPM or CBK that nukes XP modifiers and makes it pretty much 1-star only for the mun/minmus circuit). I added a decimal place to the modifiers in the cfg, because it seemed totally wrong to be able to dump a load of kerbals on some forsaken rock and come back later to find they have summoned a 5m-Konainerful of Kash from nowhere. Maybe, instead of simply taking an axe to the rewards, generation rates could be repurposed as a means of driving progression. This means the rewards could tail off over time in accordance with the three Kolonisation ratings, so that planets that have been kolonised more extensively and for longer produce fewer 'free' rewards, instead requiring a planetary manufacturing etc. economy to be set up in order to maintain purpose. If the reward rate also varied per body (so more distant and challenging bodies would produce more rewards), this would also act as an incentive to 'get out there' and kolonise more planets to keep the rewards flowing, and thus produce more complex kolony networks as your reach expands.

Is it me, or are the reaction wheels in the Honeybadger Control Module really weedy? On a 50t vessel, three of these modules placed exactly on the CoM take over 40s to turn it around-and that's without any cargo. In all its 250t, fully loaded glory, it's like turning a blue whale with an ion thruster. Basically, are the flywheels only supposed to be a backup system for the more powerful RCS, do they need a buff, or am I doing it wrong?

Assuming you mean a Github PR, you click the button labelled "fork"-this will clone the repo to your account. Then, open the file you want to change in your fork and click edit-when you've finished, click "commit changes". Now, go into the main MKS repo and click "New Pull Request". Now click "compare across forks" and select your fork from the dropdown, and it will bring up a list of the changes (commits) you've made. Select the relevant commit(s) and finish making the req.

(slightly offtopic here) I should probably be using this mod instead of just tossing the folder out.

I'm using KRnD, and all is well here-well, except for the fact that (when using certain VTOL engines) MechJeb seems to REALLY hate IntakeAtm and Firespitter is spewing NREs at me. Together, they produced 30,000 lines of errors in under a minute. IntakeAtm is likely confusing MJ since it is a kind of pseudofuel that doesn't obey standard rules and the latter might be down to the fact that I deleted the FS parts folder to declutter the aero and engine VAB tabs.

An inline or more station-y looking ISM would indeed be nice, but I ran the numbers about ISMs vs the existing kontainers. ISMs are only ~15% lighter per unit storage unit than the other kontainers (~9200/tonne as opposed to 8000/tonne). This advantage is reversed if you don't use one of the resources in the presets (i.e. it is more weight-efficient to use cylindrical/octagonal kontainers at that point), and ISMs can't be filled in the VAB either. If you want a tiny amount of storage, 1.25 cylinders or ready-paks are better weightwise (does an extra couple of parts make all the difference?). IMO cylinders look pretty well suited an orbital base, as well as being (along with octo-konts) the only way to ship resources from the KSC. On a side note, is there any reason the Salamander doesn't have an integrated antenna? Will submit a PR to add one if that's not the case.

I think how it works is that the rewards you get are based on the number of kerbals of each type in your base, each kerbal will contribute to the science (ScienceBoost), funds (FundsBoost) or reputation (RepBoost) generation depending on their profession-as laid out in the Dashboard-and skill (for funds and sci). This means that the rewards scale with the population of your base (so larger bases earn more) and the experience of its crew. The multipliers for each reward do not scale with the game difficulty setting, but they can be changed (globally) in settings.cfg-I'm not sure whether the stock rep/funds/sci rewards sliders affect MKS, but even if they do it would be useful to have ingame, savegame-specific, MKS-only rewards settings rather than having to change the global cfg when switching between saves or adjust rewards for everything.

I have that on record now. Expect to be quoted whenever someone asks a question, the answer to which is just a few easy clicks away Regardless, the applicants list needs decluttering at the least. Kolonists should always be hired through the KD to avoid the towering AC hiring costs, so there is little point to them gumming up the applicants list when nobody who bothers to compare costs ever hires them from there.

If the AC code is conflict-free, would it be possible to completely remove the MKS professions from the AC and shift the hiring process for kolonists entirely to the KD? This would declutter the applicants list, but might confuse new users who don't know how to read the forums or kspedia.

So the given production values in the VAB are per bit, not per drill? That would make sense, though it could be perhaps a little more obvious to someone who is used to the vanilla drills (where the stated production values are for the drill as a whole).

Would it be more or less efficient to use larger resource drills over smaller ones? Right now it's looking like smaller drills are better-consider the table: Drill Cost Mass EC Usage Production ME-100 250 0.278t 10/s 1/s ME-500 1300 (5.2x prev tier) 1.6t (6x) 40/s (4x) 2/s (2x) ISM 6000 (4.6x) 8.332t (5x) 360/s (9x) 6/2 (3x) As you can see, production does not scale with the negative aspects of the drill, meaning it is significantly more efficient in all areas to use ME-100s for all mining operations requiring more than a dribble of resources (since the larger drills have more configurable bays). Even so, it it still more efficient in all aspects to ship three individually configured ME-100s to produce each of their three resources than it is to ship a single multi-resource ME-500. Beyond ease of use and partcount, the larger drills seem very underpowered (for example, 6 lowly '100s will produce as much as an ISM while costing 1/4 as much, weighing 1/5 as much and using 1/6 the power)-as such, I can't see any practical reason to to use them over an equivalent array of ME-100s (unless there's some mechanic that balances them I'm not aware of?). P.S. the costs of the Tundra PDU and Pioneer are still broken (the entirety of the 17.3k PDU cost comes from the enriched uranium it ships with, and the Pioneer is negative when emptied of machinery).

I believe the kolonisation stats apply to every craft in the SoI, landed or not (this was raised before with Kerbol apparently becoming kolonised).

Actually, it would be really nice if these panels acted as though they were performing the functions of the modules they represent, in order to greatly ease using this ship with MKS/LS-or will the freighter have a bay system like MKS? If yes to the latter, maybe the panels could form part of the single part ship texture and change automatically according to the bay config. That being said, does the bay mechanic allow for having multiple configurable containers in one part (so the kontainers could potentially be integrated into the vessel itself)?

Indeed, I do not have .14. Silly CKAN/AVC, only notifying me about USITools updates.

With the attachment points, will they only ever carry 5m solid-object kontainers? As for docking, I'd probably end up using the ship as a tramp freighter, with each planetary base (except Eve, Tylo and Laythe) having its own shuttle to fly up to the freighter with fuel and resources for export, refuel the freighter, load/unload the imports/exports and bring them the imports back down to the planet, at which point the freighter flies off again to the next point on its triangular trade. These resource transfers would probably be quite large, likely requiring a cargo vessel much larger than could be practically piggybacked onto the freighter (this would be much easier if we had Orbital Logistics to cut out the docking altogether). The IEVA sounds like a novel, but interesting idea. The ship interior likely has large enough dimensions to avoid clipping issues-so in order to exit the ship a kerbal could either exit straight to space or exit the cockpit into this internal area (with the KIS boxes mentioned) and then go through another airlock to get outside?

Oh, I think it will be a case of other ships docking with it, not the other way around, so there should probably be nodes for attaching docking ports as well, unless they can also be integrated (or placed on the ends of the kontainers, which have a node by default). The heaviest it could possibly be (excluding fuel) is 6,274.4t with 6 kontainers of metals, which would give it an acceleration (from the 3MN of thrust quoted in the dev pic) of ~0.045g, which seems somewhat at odds with its ability to pinwheel on a (very large) dime. Still, this is a very early dev concept, with plenty of time to tweak these sorts of things. As an additional observation, maybe the container bays would be better off being a standard attachment face, and in order to attach kontainers there would be a series of (very short and light) adaptors to turn that standard slot into an attachment point for each size of kontainer and tank for more flexibility. If you're willing to make B9 Part Switch a dependency then this could be done with only two parts (a Tank Adaptor and a Kontainer Adaptor) that could be configured between the four sizes of each. Looking forward to seeing the IVA for this thing-I'm betting on buttons galore or some scifi nod-if you make an IVA, that is. From what I've picked up, IVAs are difficult and time-consuming to make so if you choose not to make one that's fine by me.

If Rover made the 3.75m kontainers fit properly inside the FTT cargo bays (so they don't clip through the sides and stick out just enough to explode on re-entry), then a Honeybadger-based craft could be a decent surface-to-starship cargo shuttle for this 300t behemoth that looks to be able to square off very well against the StarLifter-class ships from FTT. One of my pet peeves (and I imagine shared by many other people) with large ships is how many flywheels you need to stick on them in order for them to turn 180o in under a week, and the exterior of that ship doesn't look like it has many attachment nodes, so make sure to give it a hefty internal reaction wheel or at least some decent engine gimbal. From the test images, it looks like it has one or the other-how quick can it do an about-turn while weighing >6kt fully loaded?

Just noting that the assets are all in their own folder (within Kontainers), but parts are not. Back to the DLL issue, looking at that someone has filed a ticket on the git about duplicate categories (specifically, two sets of extra categories-corresponding to two extra DLLs), the spare DLLs are indeed causing problems.

There appears to be a couple of rogue USITools dlls and pdbs in the MKS and LS folders of the "latest" Constellation release that look to be causing part category duplication issues (judging from the fact that the duplicate categories disappeared after deleting the extra files). Also in the same release, Kontainers is missing a Parts folder, so all the part cfgs are dumped in the main mod folder (is this intentional?).

If by efficiency parts you mean workshops etc., then I have nothing that would increase production at all, let alone to levels like Henry Ford had taken over. The three kolony bonuses are (in order) 160%, 140% and 155%. As for thermal efficiency, MKS processing modules don't produce or account for heat. The only heating parts on the base are the PDU reactor (which doesn't even produce enough to sustain its own core temperature) and the drills (which utilise barely 20% if cooling capacity). I don't see any reason for the production to skyrocket like that, either (not complaining, though ). Nothing at all had changed, apart from the machinery level ticking down one and the kolony stats increasing by a tiny amount each. On a side note, if they won't switch back, try editing your persistence file (change IsGrouchy for that kerbal to false if it's stuck on). EDIT: I've had that bug as well from time to time where getting below the homeweeerld altitude (cfgable in KSC screen) will not revive them and they are recovered as tourists. It might be a mod conflict, but this has only happened once for me and was fixed by reverting to a save just before reentry.

On that topic, what is the overall formula for production efficiency? I have a Tundra refinery with 1 Chemicals bay and 2 Refined Exotics bays, with chems running at 125.2% efficiency and REX at 500.9% with 1888/2000 machinery, surplus minerals/chems (and storage) available and a 1-star engineer on board. How does that work? And then, after writing this, it arbitrarily shot up to chem: 446.7% and REX: 1786.9% and the 3xChem refinery next to it to 4020.5%-what is going on?