toadicus

There's been some talk between sirkut and Cpt. Kipard about mechanizing them, and I think that's generally unresolved pending some future work that sirkut has cooking. I'll be adding simple "magic" gendered support to ADN in the near future.

This mod doesn't actually provide the throttle limit slider (that's stock these days), and makes no provision for automatic control. While I could conceivably provide action group entries to let you apply or remove a thrust limiter setting from specific engines, doing automatic leveling or decoupling the throttle from certain engines is definitely out of scope here. That said, I think you might be looking for qfey's Throttle Controlled Avionics. I've never used it myself, but from a quick read of the OP, I think you might find it useful. EDIT: So, I definitely can add something like that, or I could even add a boolean like "isUsed" or something that might be even simpler for you to detect. But, if I'm going to do that, since it has no practical use to the mod itself, I want to make sure that I'm doing it specifically in a way that is useful to you. So, knowing that I haven't read the source of your site at all, is there a specific implementation that would best enable you to do what you're trying to do?

Did you unpack the plugin DLL along with the parts? If you're sure you have it installed right, I'll need a log to comment further. Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log Put it up on paste in, Dropbox, your private server, or however you like to share text online, and link it here or in a pm to me.

VOID has been updated to version 0.14.3! This version adds a new "downrange distance" field to the HUD, Surface & Atmosphere, and DataLogger modules. CHANGELOG: v.0.14.3 [2014-10-19] * VOID_HUD: Added new "Range to KSC" field to the right HUD when landed, splashed down, flying, or suborbital at Kerbin. * VOID_SurfAtmo: Added "Downrange Distance" field. This will be NaN when it doesn't make sense. * VOID_DataLogger: Added "Downrange Distance" field. This will be NaN when it doesn't make sense. * Improved exception handling for all modules.

TweakableEverything has been updated to version 1.5! This version formally deprecates the TweakableLadders module, and removes the "double tweakable" on animated parts in the editors. INSTALLATION NOTE: You should delete TweakableLadders.dll and TweakableLadders.cfg from your GameData/TweakableEverything folder when installing version 1.5. CHANGELOG: v.1.5 [2014-10-19] * TweakableLadders IS NOW DEPRECATED. Squad's tweakable has finally and completely caught up. You should delete TweakableLadders.dll and TweakableLadders.cfg. * TweakableAnimateGeneric: Now disables the default ModuleAnimateGeneric tweakable in the editor, because ours is sexier. * TweakableDockingNode: Removed special animation handling; now using TweakableAnimateGeneric instead. * Minor code changes throughout.

AntennaRange has been updated to version 1.5! This version brings improvements to transmitter behavior when transmission is not possible, which should result in fewer lost experiments. CHANGELOG: [code] v.1.5 [2014-10-19] * Antennas will now try to store data that is handed to them when they cannot transmit it.

Here's a more Linux-y (and Mac-y?) conversion script, using convert from imagemagick and nvcompress from nvidia-texture-tools. It's not entirely foolproof, and my bash-fu is probably terrible, but it works. I don't recommend running this on GameData in a heavily-modded install; it works fine for KWRocketry, Squad, and NASAMission parts, but RoverDude's ART and OKS/MKS parts don't like it at all. #!/bin/bash mbm2png=/tmp/mbm2png/mbm2png64 nvcompress=$(which nvcompress) convert=$(which convert) image_extensions=("mbm" "png" "tga" "jpg") normal_pattern="(NRM|nm|Normal|Norm|_n)\." mbm_pattern="\.mbm$" normal_args="-bc3n -nomips" color_args="-bc3" function isNormal { if [ ! $# -eq 1 ] then echo "isNormal must be called with exactly one argument." 1>&2 exit 2 fi match=$(echo "$1" | grep -Ei $normal_pattern) echo $match } function isMBM { if [ ! $# -eq 1 ] then echo "isMBM must be called with exactly one argument." 1>&2 exit 2 fi match=$(echo "$1" | grep -Ei $mbm_pattern) echo $match } function convertMBM { if [ ! $# -eq 1 ] then echo "convertMBM must be called with exactly one argument." 1>&2 exit 2 fi if [ ! -e "$1" ] then echo "File not found: $1" 1>&2 exit 1 fi $mbm2png "$1" >/dev/null && rm $1 echo "${1/mbm/png}" } if [ $# -eq 0 ] then paths="." else paths="$*" fi for ext in "${image_extensions[@]}" do echo Searching for $ext find "$paths" -iname "*.${ext}" | while read file do [ ! -z "$(isMBM "$file")" ] && file=$(convertMBM "$file") if [ ! -e "$file" ] then echo File not found: "$file", skipping 1>&2 continue fi $convert -flip "$file" "$file" if [ ! -z "$(isNormal "$file")" ] then args="$normal_args" else args="$color_args" fi $nvcompress "$args" "$file" "${file/$ext/dds}" && rm "$file" done done Comments welcomed.

The point is more that these calculations are simple for a human to do based on a design of his or her own, but for the computer to figure out your design, and the mods you're using and how they affect things, and even whether or not there's a connected fuel source, is a bit more complicated. Also, you might only build things that seem sensible to you, but other people throw insane builds at engineering mods just to see if they break. I'm not trying to discourage Trigger from pursuing this; I'm just saying that if he doesn't, don't hold it against him. It's a deep rabbit hole.

The main problem with doing reasonable burn time estimates isn't in the math, it's in knowing what engines are turned on and how much mass they're moving. It's simple if there's only one or two engines on, and they're the same kind of engine, and they're pointed in the same direction. It's much less so if any of those aren't the case (which happens a lot). VOID uses KerbalEngineer to get that information; to do it without would mean duplicating a large portion of KerbalEngineer's functionality.

Hmm. Did this happen when transmitting (or failing to transmit) from an experiment dialog (as opposed to from the antenna itself)? Glad you're enjoying the mod otherwise! Pretty sure I've found a fix for this; working it up now!

Kip, see your PMs from me.

Oops! You're right; I invoked the upload script incorrectly. Archives fixed at all the same links. Thanks!

AntennaRange has been updated to version 1.4.3! This version fixes the issue that allowed probes to be controllable when they should not be. CHANGELOG: v.1.4.3 [2014-10-12] * Fixed an issue that prevented probe control from being interrupted when connections are required but absent.

It's the ten hundred most common English words, but yes, it is a permanent fixture in the kids' room.

I have no idea if this is the right thread, but hoping that it is: My son (5 yo) built "A Kerbal on Top of a Rocket". I felt that picnicking under an umbrella at a table built on to a rocket was well within the Kerbal spirit.

What: For unmanned vessels without a connection available to Kerbin, flight controls are locked out. How: The settings are available via Squad's AppLauncher or Blizzy's Toolbar in the Space Center scene. When: Verison 1.2 added the optional probe connectivity requirement on May 7th, 2014. Where: At any of the links in the original post. Gib: A wood or metal bolt, wedge, or pin for holding part of a machine or structure in place, usually adjusted by a screw or key. Well, that's not OK. I have a feeling this is tied to support for "works when uncrewed" pods like the Taurus HCV. Let me see what I can dig up! Pretty sure I've fixed this. New release should be coming in the next few hours. Thanks! I'm glad you're enjoying it.

So I've tried just about everything I can think of and I cannot duplicate your issue. There are no errors or other indications in your log to suggest a problem. So, here are some debug builds of ToadicusTools.dll and VOID.dll, which will cause a lot of noise on your screen and in your log, but hopefully will help us to uncover the truth. Please follow these steps: Delete or relocate GameData/toolbar-settings.dat. Delete or relocate GameData/VOID/Plugins/PluginData Overwrite ToadicusTools.dll and VOID.dll in place with the debug versions linked above. Open KSP Make a new save, or open an existing clean save Go to the VAB Add a part Using the AppLauncher button, open the VOID configuration panel and check "Use Blizzy's Toolbar" Check the Toolbar menu for VOID icon visibility. "Launch" your part Using the AppLauncher button, open the VOID configuration panel and check "Use Blizzy's Toolbar" Check the Toolbar menu for VOID icon visibility. Force-close the game (click the "X" in the upper-right, or press Alt-F4) Upload the resulting log and link it here or in a PM to me. Thanks!

Have you gone to the Toolbar's "configure visible buttons" menu to enable VOID's button there? Pastebin, hastebin, Dropbox, Google Drive, etc. are all fine with me.

So, I'm not sure what you mean by "will not work". The game runs just fine for in Windows (x32) and Linux (x64) with the Blizzy's Toolbar and VOID installed, and the buttons work just fine. There is currently an issue, if you enable VOID's Toolbar icon in the editor before going to flight mode, when you change to flight mode there will be a VOID Toolbar button that doesn't work, and a VOID AppLauncher button that does work. If you use the AppLauncher button to open up the config and enable the Toolbar button, the problem goes away. If that's not what you're talking about first: make sure you have unpacked the ToadicusTools directory from the VOID archive, and second: get me a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) and a more-thorough description of your problem.

Well, that's not OK. I have a feeling this is tied to support for "works when uncrewed" pods like the Taurus HCV. Let me see what I can dig up!

Glad you're enjoying it! Yes, relays can be made using as many craft as necessary, and will try to follow "shortest path" links (to simulate "lowest power", though technically that's a bit wrong right now). So if you've got a long-range comsat in KSO, a medium-range antenna on your munar orbiter, and a short-range antenna on your munar lander, your lander's signal will technically go lander->ship->comsat->Kerbin, even though the ship's antenna could make it all the way to Kerbin. Unless the comsat is on the other side of the planet right now, in which case you'll go straight to Kerbin.

So, if I'm right in thinking that Greys is saying that PART.scale applies scalar transforms to cfg-local coordinates (e.g. node_stack_... entries), I think slumpie is right, and I also think that Squad should formally deprecate either scale or rescaleFactor and roll its function into the other. Currently: PART.MODEL.scale - A PART's MODEL's scale value applies to both the actual size of the part model and cfg-local coordinates. PART.scale - A PART's scale value applies only to the cfg-local coordinates, e.g. node_stack_XXX. PART.rescaleFactor - A PART's rescaleFactor value applies applies only to the actual size of the part model. So, if you scale your part with PART.MODEL.scale, no worries. Leave the other two alone. If you further scale your part with PART.MODEL.scale and PART.rescaleFactor, change PART.scale to match. It seems to me like the best way to solve this would be: PART.MODEL.scale - A PART's MODEL's scale value applies to both the actual size of the part model and cfg-local coordinates. PART.scale - A PART's scale value applies to both the actual size of the part model and cfg-local coordinates. PART.rescaleFactor - OBSOLETE. No longer applies any transformations. I can't think of a compelling reason to keep the scale of the node coordinates and the part size separately. On the other hand, I've never built a part ever, so what do I know?

TweakableDockingNode does this: !node_stack_bottom = DELETE node_stack_tdn = 0, 0, -.671, 0, 0, 1, 1 node_stack_bottom = 0.0, -0.5753132, 0.0, 0.0, 1.0, 0.0, 1 Last time I checked, it behaved exactly as I described. Granted, that's been a few months... but the order [node_stack_top, node_stack_tdn, node_stack_bottom] worked for me then, and for the users who reported / helped fix the problem.

ModuleManager patches can be used for "quick fixes" to the scaling issues for some/many parts, but it needs to be designed specifically to the method that the part creator was using. ModuleManager doesn't handle any of the data in its target forms, so doing math on the vectors isn't a thing at this point. I made such a patch for KW Rocketry, because both Kyle & Winston are incapacitated at the moment, but since a "one-size fits all" solution doesn't really work, the best way forward for users is to wait for part authors to fix things.

Greys, about nodes not attaching things: are you referring to the behavior where only the first and last nodes defined in a part file will allow parent-style attachments? For example, TweakableEverything adds a third node to the inline docking port. However, this node can only be used for child-style attachments. That is, if I place another part, and then fetch an inline docking port, I can still only attach it to the ship by the "top" or "bottom" nodes: the new node that I added in the middle doesn't work (it sorta looks like it does; it snaps on but the part stays greyed out and if you launch or save etc, it's gone). If I attach it by the "top" or "bottom" node, I can then attach new parts as children to the "middle" node.