damerell

The mod lets me do that without ticking the box marked "lossless", so I'm afraid I still have no clear idea of what ticking that box does.

I'm not being intentionally obtuse here; nothing in that seems to distinguish it from normal physwarp.

One difficulty there is I think we might have to come up with a clear idea of what it even does. :-/

I think you will find searching this thread for "lossless", especially the discussion from September 2020, to be useful. tl;dr: "lossless" doesn't mean what you (or I) think it means; it's not clear what it _does_ mean; I still suggest the word should be changed since AFAIK everyone first thinks it means what you and I thought it meant.

Wheels: a bit of runway testing suggests the KF wheels are suspiciously efficient but we don't actually get more kinetic energy out than electric energy in. Stock wheels are all over the shop (eg I can be cracking along in an Akita rover at top speed and it's barely using any EC at all) and I suspect the answer is to recommend KF and dig up the old KF configs for stock wheels. There is a bit of a problem here in that kerballed rovers are heavy. The Lunar Rover IRL was 210kg and could carry 490kg of payload, including two human-sized humans, and was an actual recognisable vehicle. If I bolt four Rovemax S2s, a battery, and an external seat to a structural panel, I'm already over 400kg without _any_ payload. An Akita, USI's adorable "small" rover, weighs 650kg by the point you've got four wheels and a seat on it - 490 if you jettison the monoprop, but 714 with a battery and an RTG to make a vehicle you can actually drive anywhere. It seems a bit harsh to have realistic EC usage when you can't build a realistically light rover.

Success! Thank you. For anyone else reading this and trying it, I found it easiest to import both my target part and a Hangar of approximately the right shape and characteristics (eg, don't use the Small VTOLHangar if you don't need the extra docking mesh) into Blender, make the target part be the parent of the meshes I want out of the Hangar, delete the rest of the Hangar, and manipulate the shape and size of the meshes to fit the model. Then the donor part's Hangar configuration lines can be transferred across to the target part's configuration file.

Thanks. That's my fault for not just trying it; I'll just try it and see how it pans out, because the improvised hangar-in-a-part lashup is very much at the "better than nothing" point.

There's a nerf of a factor of about 1000 to find (810kW out * 6 * 13 (CAMREC fuel cell buff) / 60 kw (minimum EC input for one Ore/sec)), or perhaps 500 if we accept asteroids might be a bit magic. This could be applied in three places; Convert-O-Tron input (but equally it can hardly be pulling in 25MW electricity to put out 250kW heat), to Convert-O-Tron output (good because at the moment you can turn about 10kg of stuff you dug up into 5kg of rocket fuel and oxidiser, which would be pretty amazing even on a planet that _is_ full of dead dinosaurs; arguably bad because it breaks "mine Ore here, move it some distance, convert it there" but that was already a bad plan in stock) or to drill output. Changing drill output would either have a knockon effect on mod production chains that don't involve EC production (bad) or produce a puzzling situation where Ore is somehow enormously harder to dig up than anything else. Another advantage of adding only a relatively small nerf to input is that solar-powered drill+conversion rigs remain feasible. Difficult (but that's the point of CAMREC) and you'll probably end up TweakScaling up Gigantors, but feasible; instead conversion will just take a really long time, making it more of a tool for long-term operations than a matter of landing somewhere and refuelling by picking up rocks. Drills also pose a bit of a problem in that their EC input falls with efficiency but their heat output doesn't, but unlike the C-O-T there's no lower limit, so they'll always raise the spectre of a part putting out more heat than the inflow of electricity. I think there comes a point where I shrug my shoulders and say, heat is a bit of a bodge mechanic anyway, particularly since there's no obvious way I can address that short of writing my own replacement for ModuleResourceHarvester. So, a proposal. Increase the EC requirements of active radiators by a factor of 10. This doesn't really help balance ISRU but it does reduce a seemingly absurdly high number. Passive radiators we can leave alone. Increase the Drill-O-Matic to 150 EC/s. On a planet you now pay about 666EC for an Ore. Increase the C-O-T to 250 EC/s. You now pay about 500EC to convert that Ore. Decrease C-O-T output per input Ore by a factor of 75. I think this makes over-unity operation on a planet impossible, and on an asteroid a matter of enormous luck in picking your asteroid (and maybe some of them are just big blobs of hydrocarbons, who knows?)

What happens if you store the relay as a second subassembly and add that? (FWIW I find the +1 button works for me.)

I was able to import the part OK and design the meshes (for anyone else trying to do this, I found the easiest way was to select the vertices of interest and write down their global positions, then just start with an empty file and create the two meshes and the transform in that, only smooshing the original model back in when I was done). Hooray! But can I really use the exported .mu? It's not clear to me how I'd then do the equivalent of the steps in the HOWTO under the heading "Adapting the Model". ETA, mostly for the benefit of anyone else trying it; I tried the Unity editor steps. If I export as FBX 6.1 ASCII as the HOWTO suggests, Unity editor reports the part has no animations. If I export as binary, I get a part which animates spontaneously and inappropriately in the editor. At this point I hit upon the scheme of making some of the Hangar hangars scale anisotropically and giving them almost no mass, and concealing one of them inside my intended part to do the actual work, so I suspect I'm abandoning the idea of making other-mod parts into Hangars.

So I think what this means is that I make a model in Blender with the "three very important objects" described in the HOWTO, which are just shapes, not surfaces. I try and make it the size and shape I think the inside of my target part is (which, thankfully, is "a big cuboid"). I import that into Unity doing something a bit like the HOWTO, and then I smoosh the results into the original part doing something like what the MM patch above does to the Mk2 bay. Is that right? Likely to be nightmarishly hard above and beyond the usual fun-with-Blender?

I would like to retrofit parts from other mods as Hangars. I've read https://github.com/allista/hangar/wiki/HOWTO-for-Modders but this seems to be from the point of view of designing a model from scratch. Is it at all possible to retrofit parts in this way, please?

No such thing! The trusty Mark IV I took around Kerbin weighed in at 55 tonnes.

Correct me if I'm wrong, but each unit seems to provide 2 additional Kerbal-hours (in a Colonisation module; much worse in a medbay but if you're using a medbay you don't have any choice). At 1.5 kg/unit, that means that you expend 4.5 kg payload per Kerbal-day. By comparison, a 3.75m Tundra Kerbitat provides 1820 Kerbal-days of habitation and weighs 9 tonnes. Around 5 kg per Kerbal-day (and it uses EC and it doesn't get lighter during the voyage). However, if we couple that with a second one in Hab-Common mode, we are getting circa 11700 Kerbal-days for 18 tonnes - roughly 1.5 kg per Kerbal-day. So on the face of it it seems ColonySupplies only make sense if they are being manufactured in situ or brought as emergency medical supplies. I briefly said "or if the exact requirements of the mission can be met with a modest quantity, but even the lightest timer multiplier modules would take more mass" but no, if you're toting around a Tundra Kolonisation module you're not gram-shaving.

I fear this is a hardy perennial, but my search-fu is failing me. Home timers decrease, except that a medbay or colonisation module can increase them again... but by how much per unit of ColonySupplies? I can't find that anywhere, and the question of when it becomes worth shipping ColonySupplies rather than just slapping on more Kerbitats is hard to resolve without knowing it. Thanks in advance.

The OP still links to the releases page for the now disused BobPalmer github repo.

Please could https://forum.kerbalspaceprogram.com/index.php?/topic/196855-campaign-for-real-electriccharge/ be moved to Add-On Development? Funereal as the pace is, I think there is now no denying it is an actual mod being developed and not just a set of inchoate gripes.

Coming at this from another angle; the stock heat mechanic is a bit of a bodge just to add difficulty to using drills, but is it really true that ISRU can be over-unity? The maximum Ore concentration is around 15%. The temperature and engineer quality affect output and EC consumption equally, so we can ignore those; so a single Drill-O-Matic might pull up 0.225 Ore/sec for 15 EC/sec. (On an asteroid, it might pull up almost 500 Ore/sec. Sigh.) That's 0.015 Ore/EC; 33 Ore/EC on an asteroid. Take the inverse; it takes 67 EC to get a unit of Ore on the best planet; 0.3 EC to get a unit of Ore on the best asteroid. That Drill-O-Matic's cooling wants a trivial amount of EC so we won't worry about that right now. A Convert-O-Tron will turn 1 unit of ore and 60 EC into 0.9 LF (and the corresponding volume of O) or into 2 units of monoprop, so the total cost to mine and convert one unit of Ore is circa 130 EC (planet) or 60 EC (asteroid). (The C-O-T's cooling cost is also trivial). A stock fuel cell will consume that 0.9 LF in 540 seconds generating 810 EC. Over unity is very definitely possible, even without going near any asteroids, and even without the CAMREC fuel cell buff. This is going to be a colossal nerf. If, say, the Drill-O-Matic was raised to 150 EC/s and the C-O-T to 250 (so both parts at least consumed as much electricity as their heat output), you'd still only be putting in about one MW to get 60MW of fuel cell output out. One problem here is that a realistic profile for an ISRU mission is (a la _The Martian_) to drop a lander for years which will then burn up the resulting LF/O in minutes. That's not very like what one does in KSP.

You say you have Kerbal Foundries installed. KF wheels (including gear) tend to stay put if the brakes are on and roll, not slide, with the brakes off.

I'm impressed with this scheme of plotting the route in advance rather than just setting out due east and hoping. ;-)

I think from the previous Elcano threads it's very much about respecting the spirit of the rules and whether you intended when you set out to leave parts behind. Sail across Kerbin on something with a wheeled vehicle docked on its deck, undock at the edge of the ocean and drive away - not OK. Take off two struts because they're in the way of repairs - absolutely OK.

I'm contemplating a boat trip around Laythe, and so when I saw Scatterer gives actual waves, I installed it. Hooray, this should add a bit of interest to boat trips. However, now I have to ask - anyone got any tips for boat design if you are using Scatterer to give actual waves? Bolting together rocket spares any old way isn't cutting it anymore.

Very reminiscent of my own; comedically large fairing, and something always looks very odd when it pops off because of the way you have a rocket that ends in a vehicle. I fear in real space programs "land on the tail and fall over sideways" isn't an approved technique. :-) How does the self-righting mechanism work, please?

Radiators: it's hard to know what to make of the fixed radiators given they all use the same amount of electricity (and a non-zero amount so they're not completely passive). Also, let's assume the important statistic with stock radiators is Core Heat Transfer since that's 95% of what they get used for; Nertea has mods for a better treatment of heat but fix stock first. Hence the fixed radiators dissipate between 2000kJ and 8000kJ of heat for each input kJ electricity; the nonfixed ones all do 2000. The corresponding factor for the ISS's old cooling system is around 13 (vexingly, I can't find out what the Pump Modules on the current system pull). However, something is janky in KSP to begin with (once we have 1 EC = 1kJ) because, eg, the Drill-O-Matic pulls in 15 EC/s to generate 100kW waste heat. (This makes its input-power-to-weight ratio 12 kW/tonne and output-heat-to-weight ratio 80 kW/tonne; it is difficult to know what's a plausible figure here since RL electric mining machines are miner and motive unit combined, but eg a Wirtgen 200M comes in at very roughly 20kW/tonne). This wants some thought. ETA: much of the trouble here is that stock ISRU (which again is 95% of what radiators _do_) is overall absurdly good; it's quite often possible to power your ISRU by burning what you dug up and refined, which is pretty unlikely to work on planets without a lot of dead dinosaurs lying around. And I made fuel cells _better_. So, conclusion, re-examine own fuel cell numbers just in case, and think again.

Apologies if I'm missing something, but one thing I don't see in this list is an indication of how to turn a ModuleManager file into a released addon - I can zip it up with the license easy enough, but SpaceDock? CKAN? How much do I do, and how much gets done automagically?