Fwiffo

It's been a few KSP releases now since the "InputLock" bug surfaced in this and other mods (i.e. since your workaround stopped working). I find it hard to accept Squad has gone this long without giving modders a way to avoid capturing keystrokes entered into other fields (e.g. part search, craft title, etc. textboxes) Is there an official issue open on the bugtracker? Does this help at all? http://forum.kerbalspaceprogram.com/index.php?/topic/151312-preventing-keystroke-fallthrough-on-text-field-usage-between-different-modsinputlockmanager/ Whether it's a Squad-issue or something modders need to do differently, I'd really love to see this annoying problem fixed.

The videos and everything here are very exciting. How close are we to getting out of beta? I noticed the OP still says "Since it's a beta for now avoid using these parts in your main game." Is it safe to use the parts marked "Done" in my main game yet? I'm working on some weldments and would prefer to use the new parts in them, rather than ones that will be depricated. Specifically, I'm talking about the fuel transfer connectors (i.e. cPort1 in old). If the meshes, weights, colliders etc. of the new parts are finalized and the only thing that will change is the parameters in the MODULE's, then that's good enough for me. Also, will the deprecated cPort1 still work (within the limits of KSP 1.2) in my existing craft that are out in space if I uninstall KAS 0.6.<whatever> and install 1.<whatever>? (Realized answer to that is "yes", the old/new mods can coexist side-by-side)

Thanks for the backstory, very interesting! That would be cool. Don't stress over it though if it's a lot of work.

Thanks @Starwaster! It's over a year later but your TL;DR comment still saved me some grief today.

@IgorZ Thanks for that quick response! I'm looking forward to new-KAS. In old-KAS, does it just inherit the actionable distance from something deep in the bowels of KSP, or is there a "global" distance constant somewhere in the KAS code I can override and recompile? (Any idea how the stock evaDistance thing works? If there's a straightforward means to backport this to old-KAS e.g. by inheriting some kind of class attribute from stock, I might be willing to give it a shot)

Hopefully this is the correct forum to ask this. Is there an equivalent attribute for evaDistance on the cPort1 "CC-R2 Connector Port"? If you haven't seen evaDistance, see the stock Materials Bay and other interactable science modules. I've included the connector port in a weldment, and it works great, except it's located a bit far from the part's origin and I need to bump up the distance at which kerbals on EVA can interact with it. Edit: Just learned my trusty old cPort1 will be deprecated. So I guess I am also asking this regarding TJ-1 / TJ-2 and whatever special pump component will replace cPort1. (Please quote or tag me on response as I'm not tracking this thread; thanks!)

@Snark I know how much you just love suggestions about moving the out-of-the-box indicator positions. Everyone's got an opinion ;-). Nevertheless I'm curious, did you consider putting one here? Those static little "indicators" in the default Z-4K art always get me (it looks so much like one of your indicators, I keep thinking that's the real one and all's well). Bonus points if you could make the lightning bolts and their square frames glow (but I know, that would take some new art assets) ;-).

More suggestions for moduleAttributeList.xml: I don't think torqueResponseSpeed attribute should be summed (e.g. when you have multiple reaction wheels). I expect whether you have ten reaction wheels or one, they all respond at the same speed. Should probably just pick the biggest (unless there's a more complicated option for weighted average). I don't think fillAmount attribute should be summed when you have multiple fuel cells or fuel cell arrays. I believe it's a percent, and should stay at whatever it was in preweld (e.g. just pick any one).

Can't say authoritatively what it is, but for what it's worth, I can describe what it looks like. It doesn't seem to scale with bigger, higher-volume parts. e.g. Look at FuelCell.cfg and FuelCellArray.cfg. Even though the latter generally has values 12x the former (e.g. input and output resource Ratio's, and ElectricCharge amount), they both have 0.95 as the FillAmount. It defaults to 1 in code, but is 0.95 in Squad's stock CFG's. If I had to venture a wild guess, I'd posit that it's something to do with how much % of the part's local output resource storage is filled per cycle or frame or something. You always want a converter to store a small amount of the output, maybe this limits how much can be utilized, for whatever reason. It is probably the compliment of TakeAmount, and possibly the 0.95 is used to represent some (5%) of the input resources being lost during conversion. You could try putting FillAmount and TakeAmount attributes on a custom converter part and playing with their values to see what happens. Let us know if you find out more!

Nothing? Anything?

Love that docking bay, @steedcrugeon

Hmm, not sure what was wrong but they're working now.

@TiktaalikDreaming Interesting... I'm not sure if I've ever actually confirmed whether INTERNAL antennas transmit science. This bug report might be interesting to you, not sure if it's related.

Is it just me, or do the centering keys (e.g. V, H) not do anything in the SPH? (They work in the VAB) Also having some issues with Absolute snap not always snapping to global grid. Thought I'd check in here to see if it's intentional or a known thing before gathering more info.

New version: Hopper-Mk4-Beta1 Looks similar to the Mk3, but with a bunch of great tweaks. A picture and some highlights from the changelog:

Ahk. If that happens in unmodded, then it's a Squad issue. If it doesn't happen with other parts, you could try copying the antenna attributes from one of those. Out of curiosity, does the behavior change if you alter it from INTERNAL to DIRECT? For what it's worth, I think: antennaType: INTERNAL for things like probe core, DIRECT for normal antennas (typically with animations which open when transmitting), RELAY presumably for those that receive a signal and bounce it to the rest of the network. packetInterval: Time between sent data packets. Increase to send data faster and use more power. packetSize: How much data sent in each packet. Increase to send data faster. packetResourceCost: How much power it takes to send each packet. Increase to use more power. antennaPower: Range of the antenna. Increase to transmit further. optimumRange, packetFloor, packetCeiling: Not entirely sure, although I could make some inferences based on their names. I'm guessing Squad's original plan was give each antenna an optimum range and reduce its performance characteristics as you diverge from the sweet spot (i.e. get closer or farther away). I'm unclear if that got implemented (possibly only for non "DIRECT" antennas?), and didn't notice much difference briefly playing with these numbers myself.

No, nobody replied. I just merged them as sensibly as I could and kept on rolling. I think the "combined" one worked ok. I know this is a basic suggestion but... Maybe your antennas stop working because they get out of range of KSP or a relay satellite? I haven't ventured into it much but there's some tooling in game ("KerbNet" - see button in map view) that you can use to see if your antennas have a path back to KSP. Also make sure you aren't running out of electrical power on board.

Just to confirm: hullcam-models-as-external-cameras.cfg from Beta2 is no longer needed?

I've been using the dev builds of KER for a while; they're pretty good. I realize there may still be one or two rough edges, but just out of curiosity, what big milestone are we awaiting right now until this gets considered out of "beta" and published to CKAN, etc?

Indeed it's ancient, but it's simple and still works great. In any case it has no bearing on the issue. Will try the latest, thanks.

Hi LGG, sorry I've been away from KSP for a while. Do you still need/want this tested and is the version at the link the latest one I should use? Happy to try it out. LOI = Lander Orientation Improvement. It's a tiny part mod. Sorry about that.

Yep Thanks. I know it's a fairly weird bug report.

Do you mean your mod is not removing the FlagDecal module? I'm referring to when the craft is launched, not when creating the weldment.

Thanks. I think my problem with FlagDecal is that it existed in the Editor but something was dynamically removing it from my craft at launch. This made KSP throw "PartModule indexing mismatch" warnings in the log and in certain edge cases KSP is not able to successfully remap other modules to the new indices (e.g. if the part has multiple ModuleEnviroSensor the last one breaks and shows "NO POWER!" - see #6 here, #3 here, or that earlier post) Over time I learned a bit more about the problem (some of my earlier assumptions were red herrings) and managed a workaround. In the end, I saw different behavior on a part where I kept the flag on, vs. one where I turned it off (right click in Editor and hit Toggle Flag). To get it to work: In the weldment displaying the flag, I had to comment out the "FlagDecal" module, and leave WeldedFlagDecal in place. In the weldment hiding the flag, I had to leave the FlagDecal module in place (otherwise I'd get a white box), and comment out the WeldedFlagDecal module. Does the welder mod dynamically remove the FlagDecal module when you launch your craft? (e.g. Is this something WeldedFlagDecal does when it "takes over" the decal function?). Does it do different behavior depending on if the flag is visible / hidden? It's not the end of the world since the above workaround is effective. It might help if the welder moved the FlagDecal module closer to the end of the file (so when it gets removed it doesn't bump the indices of all the subsequent modules) - although I haven't tested that theory. Anyway, don't stress about it.

Definitely improved. I think there's still a minor issue, though: Ensure you're in "local" offset mode Drop a tank Attach a Mk 1 Illuminator to the side Rotate the light so it points roughly straight down Pick offset mode, click the light to show the offset gizmo, try to move it up/down. You'll notice the gizmo immediately reorients after you click it. Also here's a craft for which my ill-oriented gizmo is completely stuck (can't drag the spotlight at all along two axes, but can move it again if you detach the Mk2 lander can first, or if you drag along third axis then adjust in the other two. Very weird!). Note you need KER installed to open the craft. @Majorjim! or LGG maybe you could download the file and confirm for me? Let me know if you have troubles reproducing.