toadicus

Thanks for the report!

TweakableEverything has been updated to version 0.6.4! This version fixed exploits and bugs, improves the behavior of tweaked docking nodes, and adds a new module, TweakableAnimateGeneric, which allows items like antennas, science parts, and certain mod parts to be opened and closed, retracted and deployed, etc., in the editor. CHANGELOG: v.0.6.4 [2014-02-27] * Fixed an exploit around slider tweaks getting infinitely larger (or smaller) upper limits as parts were duplicated in the editor. * Built a new generic animation wrapper backend for all of the tweaks that deal with animations. * TweakableDockingNodes: Hopefully fixed a bug that involved animated ports sometimes being unable to undock from things. * NEW MODULE TweakableAnimateGeneric: Adds a toggle for all parts that use Squad's ModuleAnimateGeneric, such as antennae, allowing them to be extended and retracted, etc., in the editor. * Added configurable bounds to all modules with slider tweaks. After loading a part featuring such a tweak, a plugin config .xml file will appear that will allow blanket caps to the slider range multipliers. Certain modules also allow per-part config multiplier adjustments. So long as the command seat doesn't do everything completely different from everything, that should be doable.

I've taken a look through things, and it doesn't look to me like there's a way for me to do that. Sorry!

I can probably make it work both ways.

In my next pass, I'm hoping to make a lot of the basis numbers I use more configurable. Right now the tweakable number ranges are bracketed from 0 to 2×n, where n is Squad's number, which I think is appropriate in terms of balance. That said, I would like to make that "2" a configurable value, so if you want to make a specific part range from 0 to 5×n you'd have the facility to do so with a minor cfg addition.

No, not at this point. While I don't hate the idea, it's a little out of my depth from a simulation standpoint and I'm already way behind in development. I do consider this a wish-list item. The basic reason for this is that I use two separate drivers (two AddOns, from KSP's perspective) for the in-flight and in-editor VOID implementations. So the two buttons are the VOID Flight button and the VOID Editor button. But, there's no way to tell them apart, and Toolbar shows them both in both scenes, once they've both been added. That's probably something I should try to streamline.

Mickey, the translation was bad enough that I'm not completely sure what you were trying to say. But I think you are asking if VOID shows engineering statistics for each stage of the rocket, and if it can be configured to show thrust-to-weight ratios for different planets, the way Kerbal Engineer Redux can. If I'm right about that, the answer is "no." Since I am using Kerbal Engineer Redux code to do the engineering statistics, I am intentionally not duplicating all of its functionality as a courtesy to cybutek. If you want that functionality, my policy is to direct you to Kerbal Engineer Redux. All sorted, then? I'm guessing it may have had to do with Toolbar's new "new icon" detection stuff. Sierra, can you tell me a bit more about your lander, or share the craft file (and any part mods needed to build it)? I've noticed similar issues, I believe to do mostly with parts of ships that are built "upside down", particularly on very complicated vessels. There are also sometimes issues with variable-fuel parts like some of the KSP Interstellar thrusters (though in general I've got most of them to work). The engineering code is not mine; it's shared from Kerbal Engineer Redux. So, if we can identify an issue I'll report it to cybutek as a bug, or you can do so yourself.

I haven't had a chance to approach any of the other "Tweakable<Stuff>" authors about collaboration or packaging. I don't have the time to maintain a mod pack right now, but if you (or anyone else) wanted to do so, I'd happily allow TweakableEverything to be included, and help integrate it as necessary. Hah! Yeah... it probably shouldn't do that. I'll see if I can't tackle that in the next week. For now, enjoy launching to the Mun on your decoupler.

AntennaRange has been updated to version 0.6.3! This version fixes a bug where flags in range of transmitters would cause exceptional conditions. CHANGELOG: v.0.6.3 [2014-02-10] * Fixed a bug where flags in range would cause exceptional conditions. If 0.6.3 doesn't fix your issue, would you be willing to share your persistence file with me? I have been chasing another bug to do with relays not always working every time, but I've been having trouble narrowing it down. Maybe a fresh set of conditions will help.

Nope, that's a bug. Thanks!

VOID is a partsless plugin and I do not have any plans to change or allow it to require a part. The whole thing can be turned off by clicking the "Power OFF" button in the main VOID window. When windows are not shown their calculations are not performed, so there's no extra CPU burden just for having the plugin around. I could, in theory, save the power on/off state per vessel, if that's generally thought to be desirable.

This doesn't delete saves, but it may break them or make them nonsense. I accidentally loaded a non-Alternis save into Alternis. It came up OK, but there were a bunch of things that didn't make sense, like ships orbiting a body outside its SOI, and so on. I've not personally looked into the RAM changes. It adds a few textures so it probably adds some RAM usage, but I doubt it's extensive. That's just a guess, though.

Sarbian, I've been meaning to ask: is there a way to clone a part with MM? Suppose I wanted to make a radial drogue chute. I could make my own droguePart.cfg in the radial folder and change the name, description, scale, and parachute module. But if MM supported cloning, I might could do something like: %PART:FROM[parachuteRadial] { name = parachuteRadialDrogue // etc } I think I remember reading something about that in The Days of Yore, but couldn't find anything about it in my cursory look through this thread or your up-front docs. Thanks!

I've had success using limited wildcards to work with specific modules. To do what you're looking for, try: @PART[B9_Cockpit_MK2_Nosecone_ASAS]:Final { @description = LOLOLOLOLOLOLOL @mass = 0.4 @MODULE[*]:HAS[#experimentID[seismicScan]] // Seismic { @experimentActionName = SEISMIC } } And so forth. I've technically only tested that a level further abstract (@PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[seismicScan]]]), but something like that ought to work.

At this point, the conversation is moving outside my realm of expertise. I do know that air brakes serve a different purpose from spoilers, increasing drag without significantly altering lift, but a meaningful "right way" to accomplish this with the stock parts seems well outside the scope of this mod and beyond my current knowledge. I can -- probably -- make a tweakable to invert the control response of aerodynamic control surfaces, but IMO that will not function well to correct the behavior you're seeing into the behavior you're trying to produce (it would invert the normal status of the surface when used as a yaw stabilizer, so you'd need to make sure the invert tweak was getting turned on and off with the brake control). But, I can envision a couple of other limited scenarios where it might be useful, so I'll go ahead and put it on my to do list. That said, if you're genuinely interested in a "right way" to solve air braking using stock parts, I'd take this discussion to the FAR thread or make a new addon suggestion thread and invite ferram4 and the other FAR-thread regulars to comment. They're likely to have a lot more useful insight than I do.

ferram confirmed this much for me, at least:

I agree, it looks like there's something wrong in the control logic that is causing the odd rotation on that surface. I'd argue, personally, that toggling surfaces vastly out of alignment with the pitch axis for spoilers is probably a poor choice regardless, which is probably why it's being overlooked, but yes, there's probably a 2nd/4th quadrant trig ambiguity or similar that should be resolved. That said, fixing the control logic is well outside the scope of this mod. I'm pretty sure they are all pointing the same way on purpose, and that the desire of spoilers is not merely to increase drag, but to apply a net downward force on the craft to reduce lift (where flaps do the opposite; applying a net upward force on the craft to increase lift). The intent is not to balance torque or increase drag, but specifically to push the whole thing "down". That said (again), I will look at the a tweakable for inverting inputs to control surfaces. It should be doable.

ferram, or anyone else here who knows the aero subsystems better than me, I've quoted below a post from a user in my TweakableEverything thread, and my response. If I could get some confirmation, further clarification, or correction from you, I'd really appreciate it. Thanks! Correct me if I'm wrong, but just to be clear the behavior you're questioning is these two: Also, correct this if I'm wrong: you are currently only toggling the "spoiler" control; you are not yawing, rolling, pitching, or flapping. Consider this: I don't think that's a control issue with FAR or something to be tweaked. The issue here is that those winglets are a single-axis control surface (like all/most of the control surfaces in the game), with a rotational axis pointing mostly along the yaw axis, or "up" and slightly "back" relative to the base of the part, as I've indicated. The spoiler control commands surfaces to rotate in around the "pitch" axis, with is nearly orthogonal to the control axis of the part. In KSP, control surfaces will rotate if they think they are capable of affecting the axis being commanded (and are allowed to rotate based on the current action). But, to determine that, they do some trigonometry based on their local transform vector and the commanded rotation vector and the center of inertia of the part, to decide if they can help and if so, which direction they should move to do so. So, because the rotation vector in question is pitch, and because they are both on the same side of the center of inertia relative to the pitch axis ("forward" of it, probably), they both decide to turn the same way. What's strangest to me is that on the other side of the wing, they've chosen opposite directions. This might be a 2nd/4th quadrant ambiguity or something like that. Finally, I would question whether or not you actually want "spoiler" behavior on those winglets. If looks like you're building a VTO spaceplane and those are your vertical stabilizers: you probably do not want them to actuate when you are trying to spoil your aerodynamics. Those are primarily for yaw stability, and I don't think you will get the behavior you want by commanding them on the spoiler controls. So, all of this to say: I could make a tweakable that, in theory, would reverse the direction of a part when commanded as a flap or a spoiler. But, that would not work well with your configuration above because the winglet that is "correctly" turning opposite its mate on the "bottom" of the craft would also reverse (thanks to symmetry).

Correct me if I'm wrong, but just to be clear the behavior you're questioning is these two: Also, correct this if I'm wrong: you are currently only toggling the "spoiler" control; you are not yawing, rolling, pitching, or flapping. Consider this: I don't think that's a control issue with FAR or something to be tweaked. The issue here is that those winglets are a single-axis control surface (like all/most of the control surfaces in the game), with a rotational axis pointing mostly along the yaw axis, or "up" and slightly "back" relative to the base of the part, as I've indicated. The spoiler control commands surfaces to rotate in around the "pitch" axis, with is nearly orthogonal to the control axis of the part. In KSP, control surfaces will rotate if they think they are capable of affecting the axis being commanded (and are allowed to rotate based on the current action). But, to determine that, they do some trigonometry based on their local transform vector and the commanded rotation vector and the center of inertia of the part, to decide if they can help and if so, which direction they should move to do so. So, because the rotation vector in question is pitch, and because they are both on the same side of the center of inertia relative to the pitch axis ("forward" of it, probably), they both decide to turn the same way. What's strangest to me is that on the other side of the wing, they've chosen opposite directions. This might be a 2nd/4th quadrant ambiguity or something like that. Finally, I would question whether or not you actually want "spoiler" behavior on those winglets. If looks like you're building a VTO spaceplane and those are your vertical stabilizers: you probably do not want them to actuate when you are trying to spoil your aerodynamics. Those are primarily for yaw stability, and I don't think you will get the behavior you want by commanding them on the spoiler controls. So, all of this to say: I could make a tweakable that, in theory, would reverse the direction of a part when commanded as a flap or a spoiler. But, that would not work well with your configuration above because the winglet that is "correctly" turning opposite its mate on the "bottom" of the craft would also reverse (thanks to symmetry). I'm going to cross-post this over to the FAR thread to see if ferram (or someone else who knows more about the aero code than I do) can comment as well. I was sick this weekend, and got no testing or coding done. Sorry! It's still on the to-do list.

Can you elaborate on that a little more? I haven't flown a plane without FAR in a super long time, so I want to be sure that when I go to look at things I'm duplicating the behavior you describe as closely as possible.

To be clear, I mean that it doesn't work meaningfully in the Launch Window Planner, not that it doesn't work in AK. When I set up Bop as a moonlet in the launch planner, while nothing bad happens, you can't select it as a target from anywhere, and you can't select anything as a target when it is the origin. So, since Boplet is just an option anyway, I left it out.

Greetings folks! I've long been a fan of Alexmoon's Launch Window Planner, so when I switched to AK and could no longer use it, I was short a useful tool, and being robbed of useful tools by context makes me want to re-create those useful tools within said context. So I did! With Alexmoon's kind permission and under the terms of their license, I transmuted, by means of trivial data entry, the Launch Window Planner for Alternis Kerbol. This does not feature the Bop Moonlet option, in part because it doesn't work. Enjoy!

I'll look in to adding an in-flight tweakable for thrust limiting in EVA. I'll check on the control swapping for command pods, but I'm not sure I'm completely understanding your issue. I'm not at home and can't test right now, but from the looks of things BahamutD's shielded port does not use the same set of logic as the stock shielded ports. In fact, he appears to be avoiding it intentionally. I'll try to look in to it this weekend, but it may not be something I can fix.

Compatibility note and link to your mod added to the OP. Thanks for the consultation!

Correct me if I'm wrong: Consensus is that my TweakableGimbals is a subset of your TweakableGimbals, and that users seeking more advanced customization should toss my dll and use yours instead. If so, I'll put a note to such effect in my OP.