jd284

Yeah, I made a ticket about that. Feel free to add your ideas there. I planned to do most of the proposed changes myself, but got stuck when I couldn't compile the code for the longest time. I've fixed that now, so maybe I can go back to it. Probably will need quite a bit of refactoring to get this done, unfortunately.

That's a known issue with KIS, it applies to all parts that don't have crew capacity until you "do something" (like inflate it). Not just MKS although MKS has a lot of such parts. They're bees? I'd love to see how you know this...

You probably need a pilot there first to set up the planetary logistics in the first place. It may be sufficient to get one in orbit. Not sure if this is completely intended but it kind of makes sense to me. Really? Who would hire people without checking their skill level first... a large part of the hiring process is to find the stupid people and then not hire them. I could see that working for the "random kerbal" option where you just need a warm body though. In any case Roverdude has expressed his dislike for using these attributes in game mechanics. The only place where they really matter currently is EL if you enable the "stupid = low productivity" setting.

They don't need to be in the parts, the vessel just needs to have at least one MKS part.

Couldn't this done as MM patch depending on whether TCA is installed or not?

So I finally had enough science to afford this node with the CTT. That was a huge amount of science. But this warp drive is a really cool thing. I built my ship on the Moon (RSS) with MKS+EL. My plan was to rendezvous with my transfer station in LEO, but I guess that's not as straightforward as expected with some 6000 m/s difference in velocity and the minimum altitude of 6400 km for the warp drive. So I suppose the idea is to use the Moon and/or Earth gravity to adjust the velocity of my warp ship until I have the right velocity vector, and then warp as close as I can get without invoking the failsafe? Are there any tools for doing the necessary calculations, like if I have X velocity now and want Y velocity, what altitude should I warp to? Or do I have to do it the hard way? Or do you just wing it by trial-and-error? For the speed it's rather trivial with conservation of energy but velocity is a lot harder. Also SOI transitions, ugh. I now have a new respect for Geordi... PS: Would be nice if the VAB description mentioned that I need to be at a high enough altitude to operate the warp drive, i.e. the planet radius. PPS: At high warp speed, the failsafe altitude isn't very failsafe, the warp "steps" are so large that it's rather easy to warp straight into Earth. I wonder if I could abuse this to warp to LEO, if I tune the final step so that it occurs there and the warp drive shuts down before actually warping into magma.

In my case just ignorance. Just your comment there made me look and realize that the Tundra inflatables can also be configured as greenhouse, I always assumed they were hab only. Possibly because they're called "Habitat"... However, what's still missing is a convenient inflatable storage module like the old OKS ISM so I still use Ranger ISMs here. The flat kontainers are just too massive and part-intensive in comparison. Something in the cylindrical kontainer tank form factor for solids storage would be nice too. Basically stretched flat kontainers.

[edit2] Looking over it again, it seem like you just had the wrong number of bits for the larger drills. That would definitely make them seem underpowered.

Oh I see, that would make sense then. I was just looking at the release timestamps. In that case I guess these two bugs should already be considered fixed. Too bad git can't track which commits went into a compiled DLL to easily see things like that.

Actually in terms of mass and production, all three drills scale perfectly. Drill Production per bit Bits Total Mass MEU-100 1x 1 1x 0.278 (1x) MEU-500 2x 3 6x 1.666 (6x) ISM 6x 5 30x 8.332 (30x) So they actually all scale perfectly for mass, EC usage and production rate, whereas for cost the bigger ones are (relatively) cheaper. [edit] Forgot to put there that the EC usage is 10, 20 and 60 per drill bit exactly matching its production.

I'm compiling from Develop.

Actually I don't know if it does... my highest so far is 157% so it'll take a while before I can test it. Still, orbital stations are not colonies, I mean think about it. Earth has been "colonized" for thousands of years but its space stations are hardly comfy. So I don't think this unlimited hab time should apply to them...

Yep, that's it. Although I really think that should only apply to surface bases and not space stations. Or at least those should have a much higher hab requirement.

Actually, I finally broke down and figured out why I couldn't compile anymore... since Ubuntu upgraded to Mono 4, compiling for .Net 3.5 is no longer supported... and KSP can't deal with 4.0 Linq. So I had to tear out the whole Mono and reinstall 3.12 from the archives. Oh well, now it works again. So the weird thing is, when I compile the current USI-LS git source, the above bug doesn't happen. Also #212 is fixed as well. Just replacing USILifeSupport.dll and nothing else. Yet I can't see any changes between the 0.5.20 release and now. Could it be the release somehow missed the last changes? Although that doesn't seem likely since it does fix the bug it was meant to fix (I think). So dependency issue maybe? No idea where to go from here, although I'm quite happy Val no longer has to die. But if you have an idea how I can help, let me know.

It fixed the recyclers not being shared, but unfortunately it didn't fix #208, which is that recyclers don't operate while not focused (or rather during catch-up). Basically this means recyclers are completely useless if you have more than one ship, because you can only have one focused and recyclers will stop for all other vessels. This just killed Valentina, Bill and Bob even though they had enough Supplies and Fertilizer to last for over 20 days with 10 days left till rendezvous at Earth. But instead of the planned 27.2 supplies/day (24h mode) with the RT-5000 recycler they used 129.6/day and when I checked six days later they were all dead because the NOM 25000-I couldn't keep up with that rate of consumption. I'd like to help debug this more but unfortunately I can't compile any Linq code for some reason (KSP will refuse to load the DLL).

No, I think that bug just incorrectly resets hab when you go on EVA. What you experience may be an intentional effect with MKS when you either have reached 500% Kolonization bonus or have an active Colonization module with enough ColonySupplies

I'd like to add to that the following: clearly the bug is that somehow the OldTrait is incorrectly changed to "Tourist" after thy get grouchy. However you will only notice this after recovery when they don't turn back. But at this time the bug has already happened long ago and a save at that point wouldn't help finding the actual cause. So you would also need to keep checking the persistence file for the OldTrait changing, and then submitting a save just before that happens and with instructions how to reproduce it. (Please note, I'm not trying to give you extra work to do, just trying to save you from doing work to reproduce it and then only having a savegame where it's too late.)

I wish I had loads like that... and I have 2-star engineers. Do you have a huge number of efficiency parts?

The only EL parts you need to keep are the hammer and stakes if you want to use the survey station function. For orbital construction with MKS you don't need any EL parts.

Huh, isn't that what they're meant to be used for? I mean they have those side attachment nodes that are separated just right for ranger modules... For life support, you just need some recyclers supporting the intended crew size, a source of fertilizer (from gypsum, minerals or ore depending what you have available at the site) and an agroponics module. Throw in some habs for your people to not get homesick right away and you're done. If you build it with USI-LS parts instead of MKS you're perfectly sustainable already. For MKS you need to ship in some machinery every few years. It's really pretty easy to get a handle on it, I'd say trying to figure out the math to do this just right depending on the choice of recyclers and fertilizer supply isn't really worth the trouble unless you plan a base for dozens of kerbals. And even then it's better to expand it bit by bit. Just start small and go from there. Try first on Mun or Minmus to get a feeling for how everything works, so you can still ship in whatever you forgot in a few days. Have some extra supplies and fertilizer for when things don't work out as intended and fix things as needed rather than trying to get everything right in the first shot. Once the supplies and fertilizer amounts are going up ever so slightly, i.e. production meets or slightly exceeds demand, you're basically done with a sustainable base.

OK, thanks for the reply. I'll be looking forward to that then.

I'm not sure if this is the right thread, but is it possible to make KAS pipes that act as structs to be purely cosmetic instead? I like using the MKS Flex-O-Tubes (which are retextured KAS pipes using KASModuleStrut) to "close" loops in my bases, to make them look less like tree structures with seemingly huge detours. Basically like this: The green circles are KAS pipe connections that normally connect two vessels into one. The red circle is where I would close a loop. However if I close that loop, the structure flexes a lot on physics load or after coming out of time warp and usually a connection breaks somewhere. Usually not at the red circle but between some of the other parts. It looks like closing the loop like this causes a lot of internal stress in the structure. So would it be possible to make this connection purely cosmetic, without acting like a strut? So basically just display the pipe between the two ports, regardless of their location (within some limits maybe). So when the structure flexes on physics load, this pipe doesn't transfer any forces but remains soft? It'd be great if this could be done with an MM patch somehow.

This is what it looked like in the early stages: It took a lot of time to expand it and now it's completely self-sufficient: The seed for the base was the Karibou you still see there, later I landed the bit with the pioneer module. I used the EL survey station in the pioneer to build the bigger parts on site, and make the smaller ones in the workshop (with OSE). Everything is put together with KIS. Currently home to 12 permanent crew. Currently also hosts 8 visitors who came in with the shuttle on the right. Local logistics really simplified refueling these. Most other craft do a vertical docking on the docking ports sticking out of some of the hubs.

Windows are a great idea! Especially if they light up at night. It'd be nice if that could also make it so the JSI Transparent Pods mod would let you see inside. Otherwise at least adding the reflection setup from @Electrocutor in the previous page would be cool.

Holy... It's Beautiful!. Now I need to go find that for the other parts in my base.