toadicus

Assuming that's what "sunTracking" means and that it's actually implemented in the solar panel code, almost certainly. I'll look in to it.

TweakableDockingNode is now TweakableEverything! This poorly-named mod has been updated to version 0.5.2 and adds docking port control action groupage, decoupler force tweakage, and solar panel toggle-age. I will happily consider requests for additional tweakables, and will investigate those that I consider to be reasonable and valuable additions to the stock playstyle. I won't be adding a "stop using fuel" tweakable or a "make my ISP over 9000" tweakable or anything like that; my intent is not to change game balance, but to add quality-of-life improvements, especially for ship building. Squad's tooltip code doesn't automatically update when you "unhide" a value, so I've left the "advanced options" toggle alone for now. If you think it would be a fantastic idea for me to have it, you might back up my suggestion to Squad over here. CHANGELOG: v.0.5.2 [2014-01-05] * Changed the name to TweakableEverything, because I'm terrible at names. * Added TweakableSolarPanels * Added TweakableDecouplers * TweakableDockingNode: Provided "Control from here" for use in action groups. * TweakableDockingNode: Added acquire range slider. Done. Done. Done, but I'm not sure I could handle any more babies than the ones I already have. I... might be able to do that. There is a "maximum roll" field, which is compared to the dot product of some "up" vectors. I'll mess around with it and see if it does what you want. A more robust and currently-existing solution would be the docking washers from Infernal Robotics. EDIT: After some quick experimentation, this at least won't be easy. I'll take another pass at it when I've got more time, but the Infernal Robotics parts are probably the better solution. The numbers I used were actually harvested from the docking node transforms, and so ought to have reflected the exact location against which the docking ports compare the location of incoming ports. But these look prettier, so I have incorporated them. Thanks!

Currently, tweakable menus will update their appearance and automatically "hide" options that are currently being displayed when their guiActive[Editor] field is set to false. However, they do not do the same when the field is set to true, requiring the user to right-click on the part again in order to see the effect of the change. This is particularly relevant to adding "advanced" menus to parts that would be unhidden by toggling a "show advanced" tweakable or similar.

I don't know specifically how the values are applied, but from the names, they should be: Acquire Force - How hard one port will "pull" on another port to facilitate docking. This is the "magnet" or "magic" docking pull. Acquire Torque - How hard one port will "turn" another port to straight out an incoming vessel. This is what corrects minor misalignments and causes the "wobble" when one docks from an angle. Ejection Force - How hard one port will "push" on another port after undocking. This is what causes the ships to move apart (sometimes very slightly) after undocking. Re-enegage Distance - How far a port must move from another before it is allowed to redock. This is why ships need to back away before docking on the same port again. I am planning to add acquireRange, which is how close you must be before the acquireForce and acquireTorque will be applied. I'm also considering hiding these "advanced options" behind a toggle, since they are a bit esoteric and average players would probably do best to leave them alone. Thoughts, anyone? Yes, at this time these are only available in editor mode. Since the notion behind tweakable values is often intended to represent "customization", I felt that limiting the advanced options to the editor seemed reasonable in service of balance, as did the fairly limited ranges I put on the values. I'm open to hearing dissenting opinions on this, though. Probably. I'll investigate that this morning. I'll consider releasing a separate but related mod that handles solar panel starting states. To all: thanks for the great response!

Like this? TweakableDockingNode has been updated to version 0.5.1! This adds tweakables for acquisition force and torque, ejection force, and re-engage distance. Note that if you zero out your re-engage distance, you probably won't be able to undock your ports. The range on each of the tweakables is twice the default value; the step is 1/10th. These options are only available in the editor.

Please see the continuation of this addon here. Ever wanted to open a shielded docking port in the editor, or start your ship with crossfeed disabled across your docking ports? Maybe adjust the ejection force of your decouplers, or open a solar panel? The poorly-named TweakableEverything exists to provide exactly such features. Shielded and lateral docking ports can be opened in the editor and fitted with other stackable parts. Decoupler ejection force can be tweaked, and solar panels can be opened in the editor. These options and more leverage the new Tweakables system for your fun and profit¹. Featured Tweakables: Docking Port Decouple Staging Toggle Docking Port Ejection Force Slider Docking Port "Magnet" Force Slider Docking Port "Magnet" Torque Slider Docking Port Re-engage Distance Slider Docking Port Shield Toggle EVA Thruster Pack Gimbal Range Slider Gimbal Reverse Control Toggle Intake Enable/Disable in Editor Parachute Deployment Time Factor Sliders Reaction Wheel Torque Sliders (Yaw, Pitch, Roll) SAS Autopilot Upgrade Slider (Career mode only) Solar Panel/Radiator Deployment Toggle Solar Panel/Radiator Sun Tracking Toggle Bonus Features: Docking port "Control from here" now available for use in action groups. Resource flow enable/disable/toggle now available for use in action groups. Gimbal "reverse control" available for use in action groups. TweakableEverything is so named not because it makes everything tweakable (that would be ludicrous), but because it is Everything that I have made Tweakable. But, since you might not want all of it, I have broken things out into separate libraries. If, for example, you don't want TweakableSolarPanels, just delete TweakableSolarPanels.dll and TweakableSolarPanels.cfg from your TweakableEverything folder. I won't be offended -- promise! COMPATIBILITY: The TweakableGimbals module is known to be generally incompatible with HoneyFox's TweakableGimbal, which provides a more advanced set of tweakables for gimballed engines. If you are interested in using HoneyFox's TweakableGimbal alongside TweakableEverything's other functionality, just remove or don't install TweakableGimbals.dll and TweakableGimbals.cfg from the archives below. DOWNLOADS: GitHub for 1.16-beta: [zip] SpaceDock: [zip] Not SpaceDock: [zip] [tar.gz] [tar.xz] CHARITY: Do you like what you see here so much that you can't imagine downloading it without first parting with your hard-earned money? If so, this specially-crafted PayPal donation button will help you to take the currency of your choice and make it my money instead of your money. More seriously though: donations are 100% optional and entirely at your own discretion. If you do choose to donate, I'll appreciate it! INSTALL: 1. Unpack archive into /path/to/KSP_folder/. 2. ??? 3. Profit¹! USAGE: * Add Squad's docking ports to your vessels and tweak to your heart's content. CHANGELOG: LICENSE:

AntennaRange has been updated to version 0.6.0! This includes full compatibility with 0.23 and ModuleManager 1.5.6, along with the new relay feature. The relaying feature is intentionally simple. That is, if your ship has a short range antenna, but is in range of a longer range antenna that can communicate back to Kerbin, it will do so. At this time, no attempt is being made to model electric use on the relay vessels; this mechanic is intended to feel rewarding for those interested in putting together a relay system (say, a flat dish antenna in orbit of Minmus so your probes can just use whips, or a big dish in high Jool orbit with a few flat dishes in low orbits, so once again your probes can use whips). Because of the limited number of antenna parts and because this mechanic is intended to be optional, range is not additive: if you want to use a whip from far away, you need a bigger antenna within whip range. @CaptRobau, I am looking in to a way to match the look and feel of Squad's text while maintaining control over what my messages look like, but the messages are all private members in Squad's code, and fonts are a little weird in Unity. I'll push a revision when I get that sorted.

As a follow up to this, it looks like sometimes when this happens, the selected part doesn't want to be dropped (i.e. clicked down not on a part or the parts pane). Anybody else run in to this?

Does anyone know a graceful way to either separate or delete a part or tree of parts from the editor? I am building a plugin for a part that, depending upon a tweakable configuration value, may or may not permit other parts to be stacked on it. I need some sort of handling for when the tweakable value invalidates part stacking, and either detach the parts (and put them on the mouse, perhaps) or delete the parts (and make the user sad, perhaps). I've looked into preventing the tweakable from working, but I can't find a way to make that fail gracefully (I can refuse to change the value when the button is pressed, but that doesn't change the status of the tweakable while the tweakable tip is still open). TIA! EDIT: It looks like setting a selected part via EditorLogic.fetch.SelectedPart = part; puts it on the mouse, fulfilling option number 1.

If you don't mind being something of a guinea pig, download the testing DLL linked in this post and copy it over the AntennaRange.dll file in your spaceport installation. Then you could send a relay sat up to "rescue" your probes! And you could tell me if it breaks anything terribly. One report I have heard is that there is some weirdness to do with adding the module to ships launched and/or designed before installing AntennaRange. There's no good work around for this; MechJeb has the same basic issue: if you don't open up a ship there's nothing I can do to save the module information needed for AntennaRange's relaying to work. The "design" report is a weird one and I think I have a way around that. But at the very least you'll need to open up all existing flights in progress for AntennaRange to add its module data to the antenna.

I haven't tested VOID with Kerbal Engineer, and it doesn't surprise me that something breaks. I'll try to take a look at that in the next week or so. Glad you like it! I'll think about the close buttons... I'm not sure I could do that and keep the windows looking "clean" at the same time.

Hope you find it useful! For your information, and that of any other interested parties, ToolbarButtonWrapper is fully updated for version 1.2.1. I also switched to a static factory method and added some static methods and properties to help determine if the Toolbar is present, so that API users can keep all of the reflection code out of their main classes, if that's their preference. For example: ToolbarButtonWrapper button; if (ToolbarButtonWrapper.ToolbarManagerPresent) { button = ToolbarButtonWrapper.TryWrapToolbarButton("name", "id"); // other button-y stuff } else { // fallback icon-y stuff } nothke, if you have an idea for a new VOID icon, I'd love to see what you come up with. I have "power on" and "power off" states currently shown on the icon. Beautiful work!

VOID has been updated to version 0.9.19! This version updates the Kerbal Engineer Redux code to KER 0.6.2.0, fixing some display bugs in the editor and adding support for multi mode engines (e.g. RAPIER). CHANGELOG: v.0.9.19 [2013-12-20] * Updated KER libraries for 0.23 compatibility improvements. * Back-end changes in ToolbarButtonWrapper. Hmm, good thought. I'll get that in the next version. Just in case there remains any ambiguity, configurable-precision values are denoted with a small superscript "i" at the end of the label as of 0.9.14. They will respond to right- and left-clicks anywhere on their row to cycle backward and forward through the available precision levels.

VOID also uses it, optionally via late binding similar to KAC.

AntennaRange "rewards" the use of antennas at short range by increasing the data packet size. Basically, each antenna has a "nominal" range. At this range, the antenna behaves exactly as it does in Squad's vanilla implementation. At longer range, the MiT-per-packet stays the same, but the power use increases. At shorter range, the power use stays the same, but the MiT-per-packet increases. For example, if you're using a whip antenna in low Kerbin orbit, you will have a very high data rate and small experiments will transmit back in a single packet. If you were using it out beyond Kerbo-stationary orbit, it would take the standard four packets, but each of those packets would cost extra power to send. The "nominal" range for the whip antenna is a bit short of 5 megameters altitude; around there, it will behave a great deal as it does in the stock KSP implementation.

OK, folks. I've got a build that implements basic relaying. Antennas will look for nearby relays that can talk to Kerbin, and will use the "cheapest for me" target. So, if you're at the Mun with any antenna, and have a comms satellite or mothership in Munar orbit with a medium dish antenna, it will always transmit "via" that nearby relay instead of going back to Kerbin. This does NOT attempt to do anything with resource consumption on unloaded ships; if you build a giant chain of whip antennas all the way to Eeloo, a ship at Eeloo will use the nearest relay on the cheap even though technically going through all those relays would be less efficient. If you're looking for that level of challenge, RemoteTech is probably the solution for you. I have done almost zero playtesting with this yet, so I'm considering it to be an experimental build and not uploading it to SpacePort yet. A new .dll is available here; just drop this over the previous AntennaRange.dll and you're good to go. You'll need AntennaRange.cfg from a previous version (no changes there, don't worry). So, if you're game for it, please go test and let me know how it works for you! Otherwise, once I've had a chance to do more than the basic "does it work" edge tests, I'll get a new package uploaded.

Yes! I've updated it for compatibility; the new version is available at the links on the front page here. I've updated the KSP version reference in the thread title to clarify. The code I use from Kerbal Engineer Redux is still a little stale, but I'll be updating it soon.

I depend on code from Kerbal Engineer to do all the delta-v and TWR calcs. I'm going to wait a few days to see if he publishes a fix before I dig into fixing it myself. Thanks for the report!

I've done some quick testing, and from the looks of things, AntennaRange is fully compatible with KSP 0.23.0 and ModuleManager 1.5. Enjoy! Glad you like it! I've always enjoyed reading your AARs. Hmm, I do like this idea. I'll do a quick investigation this week, hopefully, and see if I can just knock it out quickly, or if it needs to take a backseat to a couple other projects I've got going on. Thanks for the feedback!

I didn't have any other mods installed; except VOID, which doesn't do anything like active texture reducing. It was a clean KSP 0.23.0 install, plus clean installs of VOID and Toolbar 1.2.0, to test compatibility. Do you want me to test Toolbar with nothing but your test buttons or something like that?

VOID has been updated to version 0.9.18! This version fixes compatibility with KSP 0.23.0. starcitsura, thanks for your report CHANGELOG: v.0.9.18 [2013-12-17] * FEATURE: KSP 0.23 compatibility. This fixes issues with the orbital pane and editor HUD not displaying. * WORKAROUND: All textures changed to .png to avoid KSP's new ugly .tga compression.

There appears to be an Issue with the way KSP is loading .tga textures. Here's my VOID icon and your reposition and open textures in tga: I converted them all to png (no other changes at all), and everything looks clean again:

Trigger, jl, something to bear in mind is that there is an Actual Issue with loading PNG textures in 64-bit linux. There is a workaround to disable some 32-bit MMX code in the executable by flipping a couple of bits in the Linux compatibility thread... this has helped me tremendously. So, jl, if you haven't applied that yet, you might want to.

There's a class for that. Feel free to use it if it's helpful to you.

Thanks for the report, as usual! To (1), no, they're loading. The smaller images are literally just shrunk versions of the bigger ones... I need to get one of my more graphically-inclined associates to lend a hand with that. Until then, it's a bit ugly. (2) and (3) are actually the same issue; I hadn't set any Visibility for the toolbar buttons, so buttons for both the editor core and the flight core were showing in every scene. So! VOID has been updated to version 0.9.17! This update corrects the visibility of the Toolbar buttons when using Blizzy's Toolbar. v.0.9.17 [2013-12-14] * BUGFIX: Corrected the visibility of the Toolbar buttons when using Blizzy's Toolbar.