DStaal

Just wanted to comment that Commnet Constellations - as I understand it - is being created by a RemoteTech developer to work out the details of a new mechanic they want to add to RemoteTech. So it's features will likely get reintegrated into RemoteTech at some point in the future. (Though I'm hoping/expecting the separate mod will stay around as well.)

It's from MKS - and it's fairly complicated to describe. Let me post a fairly minimal example from a config: (I could probably make it clearer - but this is close enough, I think.) @PART[KKAOSS_LS_container_greenhouse]:NEEDS[USILifeSupport]:NEEDS[KolonyTools] { MODULE { name = ModuleSwappableConverter bayName = Tank typeName = Bay ResourceCosts = SpecializedParts,5,MaterialKits,1,ElectricCharge,3 } @MODULE[ModuleKPBSConverter] { @name = ModuleResourceConverter_USI UseSpecialistBonus = false // This is an automated part. } MODULE { name = ModuleEfficiencyPart ConverterName = [Greenhouse] eTag = Greenhouse StartActionName = Start [Greenhouse] StopActionName = Stop [Greenhouse] UseBonus = false Efficiency = 1 eMultiplier = 0.5 // Snip } The above adds a ModuleSwappableConverter to the container greenhouse from KPBS. The converter has one 'bay', which can be switched between the ModuleResourceConverter_USI and the ModuleEfficiencyPart's configurations - Both cannot be active at the same time, you have to choose. (By sending an engineer Kerbal EVA, right-clicking on the part, and paying the ResourceCosts to do the switch.) More options to switch to can be configured by adding more ModuleResourceConverter_USI, ModuleResourceHarvester_USI, or ModuleEfficiencyPart modules to the part in the config. More bays can be added by adding more ModuleSwappableConverters to the part in the config. Each bay is independent of the rest, and you can switch any bay to any mode that the part has. You can have more bays than modes (though probably zero modes would be an issue...), or more modes than bays. (Potentially a lot more. The USI drills for instance have around a dozen different modes - with one to three bays.) This means you can have the same part be doing quite different things, depending on how it's configured. A quick example is an ISRU that could be configured to produce LFO or Monopropellant - but not both at the same time. (Or switched to just produce LF - without also being able to produce LFO.) A slightly larger ISRU could be configured to produce both - or to produce just one at double the rate. Anyway: It would be nice to be able to tell which set of modes a particular part was in - but I'm not sure that Indicator Lights is the right way to do that, anyway. But I suspect that it would take more work to support, as which bay you're talking about, how many bays you have, what options there are per-bay, etc. can all be changed in the cfg file (or, as above be altered by MM). So I'm not sure a particular order or numeric filter will ever be sure to catch a specific configuration. An option might be to have a light panel with different lights for each bay/module configuration option - but that could in theory get complicated. (Though in practice most wouldn't be more than 3x4 or so.) Just daydreaming here mostly. I know WildBlueIndustries has a similar system for switching modules via config files as well - although *they* swap textures when they do it, so you can see at a glance which mode each part is in. (Their switch is more extensive as well - You can turn a fuel tank into crew quarters, or a science lab, for example.)

Nice! Now I just need to get my hands on KSP 1.3 and some elbow grease... (Hmm. I wonder how well this works with ModuleSwappableConverter... I'm guessing that's going to be more complicated than this can handle, as it involves seeing what other modules are present in the cfg files...)

Mostly I'm just looking for a way to quickly check the state of the other ship. You can always pull up the right-click menu on a part on the ship you're flying, but it's not always safe or easy to switch ships and pull it up on your target. Being able to look over and say 'yep, it's in angle snap/not in angle snap' is enough that you can then check your settings and know if something needs to be changed. Short version: I hadn't even been thinking about the latter. Former is fine.

I’d probably want to spend some time to get the angle-snap status - honestly, the rest of the statuses don't matter that much to me, but that one it would be really nice to be able to quickly double check, especially on the *other* ship.

The one comment I have is that I don't believe having planets in 180˚ opposing orbits actually is stable - it'd be more realistic to have them in trojan orbits to the larger body. (So Kerbin would be in one of the Earth-Sun trojans, etc.)

Anyway: PR created. I've done minimal testing - I know the lights show up in the correct places. I created a 'USI' folder as part of the PR - hopefully more people will be willing to write USI patches. (And also it makes it so the configs are closer to the stock configs that they're copies of - in case there needs to be cross-updates at some point in the future.)

Probably not - the attachment nodes are kinda hidden, as they are supposed to attach with most of their body inside the main ship. Try just moving them into place - they should snap to the attachment nodes, even if you can't see them.

Another edge-case for you to look at. (Ship mostly works fine, but had a few issues - you can decide whether they are something work working on or not.) Here's the ship: As you can see, a very high and asymmetrical build. (It's designed to be able to do things like right a fallen-over mining station, if needed.) TWR on Minmus (from KER) is just over 2 when fully loaded - after TCA balances it that goes down to about 1.9. Designed to be flown entirely with TCA - it's got 9 'main' engines doing thrust+maneuver, and 12 auxiliary thrusters in pure maneuver mode. Above is after the fairly eventful first flight. First flight was a 'jump to target' hop against Minmus rotation (that is: the opposite direction from a gravity turn) from the top of a plateau (at about 5.4km) to the Greater Flats. Takeoff went smoothly, until during the 2-minute 'jump' burn one of the arms clipped the ground, sending it spinning. TCA stabilized it after some work, only now it was pointing retro-burn - and continuing to try to do the burn. I had to break TCA's jump program at that point to re-orient the vessel, after which it appeared to reset into the jump program. Burn completed, it time-warped to the start on of the declaration burn - and promptly informed me it didn't have enough fuel. Given that it still had over 4,000 d/v of available fuel (refueling stuck craft being another design consideration) this seemed improbable. What it appeared to mean is that it didn't have enough *thrust* to decelerate. Again I broke out of the jump program - this time to point retrograde and burn the best I could. I also disabled the auto-gear, and extended the landing gear (which are ridiculously over-speced - again, so that the craft can lift and handle stuck vessels in need of repair - and were already known to be able to handle a 100 m/s launch accident) - impact was at around 60-70 m/s, but with the landing gear in play the craft just bounced. I re-enabled the auto-gear, and switched to either the stop program or the landing program, I can't recall which - regardless, after control was regained it was put into the landing program and allowed to land wherever was convenient. This then showed the final issue I had: the auto-gear wasn't ready for the extreme length of the landing legs, and the legs were still deploying when they hit the ground, bouncing the craft back up. It was a minor bounce, and the craft was landed acceptably. From there the 'fly-to' program was used to return the craft to it's intended destination. So a quick list of the issues: Clipped the ground during the jump burn. Stabilized to the above backwards. Attempted to start the deceleration burn to late. Delayed extending the gear to late. Anyway. It works, and I'll admit this is a weird design - just thought I'd bring up the corner cases it's hitting. Here's the game log of the above flight if you're interested: http://magehandbook.com/KSP/KSP.log.zip

I'm not sure Oyster speaks fluent English - he may be using a translator to (help) post.

You're on Windows. They got the Windows version out a few days ago, and the Linux version out yesterday. MacOS is sometime early next week. (Unless you're running Galaxy.)

Try detaching/reattaching the parts in the VAB once. I've occasionally seen CLS not update passibility correctly until the parts reattach.

Question becomes how much work do you want to put into supporting this one mod, given that I don't know of any other docking ports that allow you to *change* their snap status. On the other hand, it's a dependency of MKS, and available on it's own, so there's probably a fairly large userbase...

The parts' configs do also have a ModuleDockingNode. I'll have to try them out to see if my patch actually indicates state. (I haven't been trying much at the moment - I still don't have access to 1.3, so I haven't wanted to be playing around with known-outdated stuff.)

The resources transfers are what made me think of it. I'm constantly going 'ok, I'll just transfer like I do with fuel... Oh wait' for science transfers. Crew transfers haven't bugged me as much - probably because there's less clicking around. My automated science rovers might well have 10-20 different experiments, each of which is a separate part, while crew transfers tends to between 3-4 parts (total) on docked ships. Still, I wouldn't turn it down.

I mostly like science in SM - I do wish I could transfer both left->right as well as right->left (I don't typically distinguish between which part should be on which side mentally), and I wish I could get a 'vessel' view of some sort. (Example use: Automated science rover, manned science harvesting craft/lab. Attach rover to manned craft via KIS, transfer all the science over, then reset, unattach, and send rover to next site. At the moment it takes a lot of going 'ok, next experiment, transfer, next experiment...') I've seen some wishing they could transfer lab data around - I haven't had any issues with that personally, but I could see the point.

That update already happened. I have working flexible joints with KJR under 1.2.2.

I'll take a look at it whenever GOG gets around to releasing KSP 1.3.

Glad to know you're still around. I don't use KRnD much - but occasionally it's nice to be able to make a part just a *little* better.

(Check her ISP. She probably means she can't load web pages fast enough...)

It plays a little animation on your screen, and tells you it's installed. (Nothing actually tries to install or anything.)

Sure it was: It clearly indicated that that was all the information he needed to know to know that you weren't running a supported configuration. Given that you listed the version of KSP (not the most recent) and the version of MechJeb (the most recent) that implies that the most recent version of MechJeb is not expected to work in older versions of KSP. (Which in general is as expected with non-part-only mods.)

I *think* it does this. I do like the idea of some listing that can show you 'mods you currently have installed that are updated for newer versions of KSP'. It'd be a major headache saver around KSP updates.

So: KPBS has just updated to include the USI-LS fixes we pushed upstream, but I still don't have 1.3. (GOG hasn't updated yet, from what I can see.) Can someone test the latest pre-release to make sure it works? If so, I'll turn it into an 'official' stage-2 release. https://github.com/DanStaal/KPBStoMKS/releases

Whoot! I just want to acknowledge @Merkov, as he did much of the legwork on the USI-LS rebalance.