Mihara

Well, here's an excerpt. It doesn't look helpful: By the time you see any messages that look at all suspicious, the vessel has already disintegrated. (i.e. "debris" objects start getting mentioned and initialized.) The actual disintegration does not appear to correspond to any event that gets logged. As I mentioned above, though, I think I got it to happen reliably: It always happens when, before jump, there was another vessel (a beacon, in this case) within physics range, and seems to never happen if there was no such vessel. Let me see if this can be observed in isolation...

So I'm having a strange problem with this... Namely, vessels tend to randomly disintegrate -- or rather, get krakened apart, in the original meaning of the word -- upon successful jumps. That is, the jump succeeds, and then, after the ship gets unpacked, parts start falling off, or freeze after getting shifted far off their original positions. This happens about 40% of the time. What's weird is that there is clearly nothing relevant in the logs after that, but Flight Event log mentions structural failures on joints. I have a hunch that 60 frames is too low for HoldVesselUnpack with as many mods installed as I have, (GameEvents for SOI change take time to run, don't they?) but it'll take me some time to verify that... Alternatively, it might be some other mod interfering with the process (BonVoyage-driven rovers also seem to occasionally bend, so it happens at least sometimes with any kind of vessel unpack) but I currently don't have any idea which one. (ReCoupler?...) EDIT: ...It seems to reliably happen when the jump starts when any other vessels are in physics range.

So I've been playing KSP again, and found myself quite frustrated, when, picking a KW P-fairing for its aesthetic properties -- the frame base, to be precise, makes a very nice component for an Orion workalike -- my rocket, finely tuned with the stock fairing first, wouldn't fly the way I wanted. Turned out, it's because the fairing bases are way heavier than a stock fairing plus decoupler. And the 1.875 fairing base has the same mass as the 2.5m fairing base too. Is there any particular reason for it? Or should the masses of these parts be reconsidered?

There are some strange artifacts on the edges when I do tweakscale them: They become partially invisible, depending on the distance from camera -- at least in the editor.

An equilateral triangle structural part. Where have you been yesterday?

Is version 1.4.0-1 meant to be compatible with KSP 1.3.1? CKAN thinks it is, and it installed the update into my copy of 1.3.1 today, but for some reason I don't see any clouds at all anymore...

Which technically makes the agreement void in most jurisdictions I can think of.

It also says "FOR[TacLifeSupport]". For ModuleManager, this implies that the mod so tagged is present, because all patches for a given mod should be tagged so where possible. As a result, everything else that had its own TAC-LS patches started "detecting" it and inserting TAC resources. I got bitten by that too. The fix: Never do that. Use "AFTER[..." instead, because that's what you meant.

Not that huge, as long as you don't concern yourself with simulating flow over time or even distribution. Take a look at this method for example. Things do get a lot more complicated if you do, but still manageable. I fully understand why you wouldn't want to do it, it does go out of the original scope. But well, it would make sense. Far too few things in Kerbal universe make sense. As it is, even when OSE Workshop recycles an item which contains resources, resources do not get reclaimed, so the only way to get them out is to go out and bolt the item to the outside of the vessel, which does not make sense at all. Part count and physics, and the fact that I can't use the nice premade replicas set up for KIS like, say, Phoenix Industries kit, is what's stopping me. Going the other way -- i.e. sending resources down from space -- is even worse than sending them up.

Well, I know they're not actually parts, but something simple like an "fill/empty resources" button which would try to pump pumpable resources in/out of the item into any available containers on the ship shouldn't be too hard... If that didn't involve making UI, (I have an allergy to programming UI) I would just write that myself and send a pull request Oh well. P.S. There's probably also an option of creating an extra tank in the container part the moment a resource-containing part enters its inventory, and destroying it when it's taken out, but that feels like a potential nightmare of bugs, since there would be no reliable way to tell which ones got created by which contained item.

If you, like me, wish to have rotation on construction ports (so that they're easy to adjust to perfection before welding) but prefer regular ports to be handled by KJR (see fix that makes them play together above) and don't care quite as much about their alignment, here's a patch for you. // DockRotate is very sweet, but I *only* want it on the construction ports: // I would rather KJR act on the docking joints. // So taking it off every other port. @PART:HAS[@MODULE[ModuleDockingNode],@MODULE[ModuleDockRotate],!MODULE[ModuleWeldablePort]]:FINAL { !MODULE[ModuleDockRotate] {} }

Something I keep meaning to ask. Occasionally, it makes sense to fill a large KIS container with resource tanks or smaller containers. It certainly is more convenient in some cases than rebuilding a vessel to contain tanks of multiple resources, and there are mods with large KIS storage volumes in convenient vehicles to suit this particular purpose. However, the problem turns up when I need to make use of these resources: To do so, I have to EVA, take the container out, attach it to the station -- whether using a container socket or surface attach -- and pump the resources out. This is only practical in some cases, since the kerbals can't really manipulate resources heavier than one ton, and using multiple kerbals to work with heavier resources in orbit is a dangerous exercise. So, is there a way to get at part resources while they are still inside the KIS container? If there isn't, is there a hope one could be arranged?

Like I said, I didn't look in the logs, so I can't tell you if there's an NRE involved or what, but yeah, that's what happens -- the part doesn't get placed and can't be removed.

That's in 0.2. The particular nosecone is unusual because it's meant to decouple the bottom node, but that bottom node is meant to attach to a node that is physically inside the pod itself -- but it also has a top node, and I'm not sure how is that one meant to be used...

This is very promising, but screws up certain decouplers which are supposed to decouple from things rather than things attached to them, in particular, Tundra Exploration's decoupling nosecone. I think this particular part simply causes the module to crash, although I didn't look in the log, I just wrote a patch to exclude it. @PART[CargoShroud]:FINAL { !MODULE[ModuleDecouplerShroud] {} } I suspect a more elaborate patch to install this module is needed, I'm sure there are other exceptions.

Yep, that's a problem caused by Strategia. Here's how I fixed it: https://github.com/jrossignol/Strategia/pull/70

...I guess I'm just still burned out after having had to drive 3400 km on Tylo back in 0.25 at 4 physical warp. Current BonVoyage in CKAN already supports Feline Rovers, and works wonders precisely for getting all biomes in a single landing. Works especially well if your rover is manned and not dependent on solar power, because then BonVoyage drives at night, and at speeds you would be hard pressed to maintain manually for quite as long.

...Maybe, a better solution is not driving quite so far. BonVoyage helps immensely when using rovers, I hardly even drive them myself further than 500 meters anymore.

Found a pretty annoying bug. PPD-EVAC-U-8 Service Airlock has a permanently obstructed hatch. The previous model of this part didn't have that problem.

MKS hab ring offers 497.5 extra hab-months for just 5.1888 tons dry mass, though. I understand the scale probably shouldn't be linear, but what should it be, and why?

It's a bus. That is, the IVA is set up in two levels horizontally, and while it's fairly versatile, it doesn't look like a place meant to be used for long. A rover or a purely orbital station-to-station transfer vehicle. So it probably should have supplies, but the amount should match the available habitation levels. I tried tracking down the original NASA concept art that this was inspired by to find out what it was supposed to be, and while I know it exists, I haven't found the source.

There is such a thing as a mu->blender importer, so there's always some hope until even that fails. That, however, might turn out to be too much work.

So I recompiled this for 1.3 and it works fine. Lovely plugin, though I would prefer to be able to set the abort conditions in the editor, which doesn't seem to work. Any particular reason this hasn't seen an update release? P.S. Oh, and the best way to use it in my opinion: // Install automatic escape controller into escape tower parts. // Other abort modes can live with the controller part. @PART[LaunchEscapeSystem,SDHI_LES,SmallEscapeTowerHGR,HeavyLES] { MODULE { name = ModuleAAS } }

Woot, it's the new one! I was expecting to see the old one, not sure why. Does the IVA render at all? I see it's commented out, but the file is there. My take on the USI-LS config for the new centrifuge. Since there are no sensible balancing guidelines for that, I just took the numbers of the larger inflatable centrifuge from MKS and assumed the habitation bonus conferred as well as the electric charge consumed are proportional to mass, so take it with a grain of salt. @PART[centrifugeSmall]:NEEDS[USILifeSupport] { MODULE { name = ModuleLifeSupport } MODULE { name = USI_ModuleFieldRepair } MODULE { name = ModuleHabitation BaseKerbalMonths = 288 CrewCapacity = 0 BaseHabMultiplier = 0 ConverterName = Habitat StartActionName = Start Habitat StopActionName = Stop Habitat INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 7.2 } } }

Got a bug report. There are now two sets of lifesupport patches in the distribution -- one in "lifesupport" and one in "patches". Both get applied, resulting in multiple copies of life support modules. I am pretty sure this confuses USI-LS at least, (two identical right click menu items collide, it starts lying about the remaining hab time) not sure about the others. Previously, life support configuration was part of the part config itself, so that's definitely new. Also, shouldn't TIorbitalorb have a hab module too?