toadicus

Enceos, you need the TweakableRCS and TweakableEVA cfg and dll files, along with ToadicusTools, EVAManager, and KSPAPIExtensions.

robson1000, the SAS tweak only operates in Career mode.

Thanks OddFunction. I'm aware of that issue and will correct it at some point in the future. Right now the AR VOID panel is pretty useless, and if you don't have VOID that message is expected anyway. At any rate, I'll shut it up soon.

Jacke, the "toggle" setting for each window should already be set per scene. If you open career status in KSC, it should not be open when you get to Flight. It's possible that career status is actually the one exception to that rule... I'll take a look.

Gristle, I've added your patch to the wiki. Thanks! jlcarneiro; now calling it a "feature". - - - Updated - - - UPDATE: I've had a friend use his non-owner github account to go edit the wiki page to be sure that people who aren't me can do so, and he has done so without any trouble. He provides the following input: Gristle, BigFatStupidHead, et al; you do need a github account to edit, but once you have one (which is free and easy) editing should be simple. Thanks!

Gristle, can you upload that file someplace polite to make it easy for people to download? I'll edit the wiki for you. OddFunction and jlcarneiro, I've just had a detailed look at the input locks and there is no lock for those controls. In other words, this is an upstream problem (or intentional choice) and I cannot prevent you from using those controls. Try not to use Z and X when you shouldn't.

Yemo, is there a particular reason that obsoleting the Comm 16 is a bad thing? Something to consider here is that "very short range antennas" are only a realistically valid concept wherein both antennas are very low gain and the transmitter has very low power. As I've said before, NASA could hear my children's walkie-talkies from the Moon, but the walkie-talkies are certainly "very short range". The receiving end makes a big difference. If you wanted to get your antenna to Keosynchronous orbit at KSC 3, you'd need a link range of 2.87e6 m, and an antenna range of 2.87e6 * 2.87e6 / 2e12 = 4.11845. That's going to be pretty useless for inter-relay communication, but in general it's going to meet your other criteria. If this is indeed a "very lower power" antenna that's to be expected: if you have a very low power antenna with low gain and I have an antenna with similarly low gain and we are very far apart, we won't be able to hear each other. If someone points a 70 m parabolic dish at you, they'll hear you even if you're using an antenna made from a paperclip unless you're halfway across the solar system. I'd say that you should go ahead and make your part identical to the Comm 16, but make it higher power, on the rationale that it is a smaller (lower gain) antenna using more power to achieve the same bandwidth and the same range. This makes it a less efficient antenna and therefore it won't be the best choice if you can afford to put a Comm 16 on your craft (active craft will consider this when transmitting). This maintains some purpose for the Comm 16 (more efficient) while leaving a niche for yours (cheaper, no extra physics). Handwich, thanks for the thoughts on that presentation. I like them, and have been meaning to revisit that box for a while. I'll see what I can do. EDIT: What if I used EC/sec instead of EC/packet for the power requirement? That seems like a much more intuitive metric and should make comparing antennas easier.

That's never happened to me, and as you might imagine I use this mod all the time. I'll need a log if I'm going to be of any help to you.

So if I'm reading you right, what you want is: A single ship with a small antenna that is useful for very short range communications (short range to what? a nearby relay, a small probe? I understand in theory but I'm not getting what gameplay effect you're trying to achieve) and a large antenna that is useful for "phoning home." First -- AntennaRange does not really respect that kind of distinction. In terms of network resolution for drawing lines, inactive vessels always only use their longest-range antenna. The active vessel will resolve all of its antennas individually, and then decide when you click "transmit data" from an experiment which one of them is cheapest to use. But its "pretty line" will be defined based on the longest range antenna only. Without knowing much more about the gameplay effect you want, I'm not sure where to go from here. I'm guessing you want something that will guarantee it will never talk back to Kerbin, and are frustrated because any meaningfully positive number when multiplied against the large tracking station ranges and then rooted will still generally give you a number equivalent to sqrt(tracking station range), which can be very large (1.4 Mm at least), so you can't guarantee that a short range antenna in low-Kerbin orbit will not just talk straight back to Kerbin. Before I assume too much more -- what is the gameplay effect you're trying to achieve? What is the circumstance where you want your antenna to be useful and the Comm 16 not to be?

It's true that a Comm 16 -> Comm 16 link is very short. 6.5 km is the nominalRange; the maximum range is sqrt(8) times larger than that; 18 km. There's only useful in a handful of edge cases; maybe a rover off a lander, both of which have Comm 16s. The parent ship would surely have a higher gain antenna, though; probably a Comms DTS, and both of those can be heard by a Comms DTS for a very long ways. That Comms DTS can be heard by Kerbin for a very long ways, so all the parts remain useful. The real question to ask when balancing your internal antennas is to ask "when do I envision these antennas being useful?" For example, I want the Comm 16 to primarily be useful in a "child craft" type role, that needs to relay through a bigger antenna before it can phone home. It's universally useful for landers from parent craft with DTS or 88-88 antennas, and can even do small probes throughout their Kerbin subsystem once you upgrade to Tracking Station level 2. So, when are the integrated antennas on your SETI parts supposed to be useful? Are they supposed to be high enough gain to phone home to Kerbin on their own? If so, from how far away? Mun? Minmus? Eve? Duna? Eeloo? Balance the part around that number and the system will do all the rest for you. For example, if you wanted one of your parts to be useful for medium-range (Kerbin->Duna) exploration in the Tracking Station level 3 phase, you'd want an effective link distance of about 3.54e10 m when talking to Tracking Station level 3. Tracking Station level 3 has a max range of 2e12, so your part needs a maximum range = 3.54e10 * 3.54e10 / 2e11 = 5.94e8 m. Do you want to pair with an 88-88 to have effective communications around the Joolian subsystem? That's a range of about 2.26e8 m, so you need a maximum range of 2.26e8 * 2.26e8 / 3.7e10 = 1.38e6 m. Then you decide what makes your antenna a smarter choice than the Comms DTS, which at TS Level 3 can talk much further than Duna. Maybe you want your antenna to be really low power, and adjust its packet cost. Maybe you want your antenna never to suffer penalties for long range; set maxPowerFactor to 1. I use this spreadsheet to help me with this, which you can freely copy; take a look in "Symmetric Link Worksheet". Most of the stuff is just noise for building forum tables; the important things are are in the top left. Inputs are the top row of ranges and the row of maxPowerFactor further down; everything else is automatic. The outputs you actually need for your .cfg file are the nominalRanges given in the row below that, shown bolded and underlined. Further down are a pair of tables to help you better conceptualize what your part can do in different circumstances. This is new and a little more involved than the previous system. But the math isn't hard, and IMO it results in more rewarding gameplay. I talk about the math in more detail in the README. The system is here to stay. I'm happy to help you work on your parts; feel free to shoot me a PM if you need it. What is a link with more than two antennas? If you're talking about distributed telescopic antennas such as in VLBI, that's not supported at all. If you're talking about one antenna that is "receiving" from probe X and "transmitting" to KSC, then those are two separate two-antenna links. There is no limit to the number of links in which an antenna may participate; if you have 20 probes with Comm 16s on the surface of Duna, they will all talk back to Kerbin through your orbital commsat with a Comms DTS (and it won't even know). Charge use is not a factor in determining link range or performance except insofar as it does in the stock system wherein if you don't have enough power you will transmit more slowly. There are a few reasons for this, but they distill down to simplicity -- if I figured charge use into the ranges after config time it would be even harder for people to balance parts -- and stock-alike balance -- Squad's power use, given any of the available interpretations for EC/s -> Watts, is so laughably high that any real treatment of the transmission equation would result in trivially large ranges for literally every antenna in the game.

That's not really a correct assessment. Ranges only get shorter relative to your antenna when your target has a shorter range than you do. When your target has a longer range, your range gets longer. Take a look at the table in the post I linked in #785, which shows both quantitative and qualitative descriptions of link ranges for various antennas. For example, a Comm 16 -> Comm 16 link has a very short range; only up to 18 km, but Comm 16 -> Tracking Station Level 1 gets to 120 km. Comm 16 -> Comms DTS is 10.7 Mm (almost to Mun) -- plenty for a small craft -> mothership sort of scenario, but Comms DTS -> Tracking Station Level 2 gets you past Duna a ways. It's not the most intuitive, but it is realistic and it rarely results in unacceptably poor performance. If you find a case wherein it does, feel free to report it.

"Additive" ranges (which I'm now calling "symmetric" ranges myself) use the geometric mean of both antenna ranges in the link to determine the nominal and maximum ranges. So if you had a hypothetical antenna with max range 8 and another with max range 2, the max range for the linked pair would be sqrt(2*8)=4. By doing this I can now improve link range as you upgrade the KSC tracking station, and put a little more variety in the gameplay behavior as you progress. "Simple" ranges dictate the range of the link based only on the transmitting antenna. So if you have an antenna with range 8, your range to every other antenna is just 8. It winds up requiring much longer ranges on all three antennas. Glad you're enjoying it! ToadicusTools is a common library of utility functions that I use in all of my mods. My mods will almost always depend on it; except while a blue moon when I compile ToadicusTools code into a small mod directly. Yes; probably based on my first concept from this post. Just need to stop working first, which looks like it probably won't happen until next weekend. Addressed the config issue; thanks for the report!

BigFatStupidHead, I don't have a second github account to see what things look like for non-authorized users on the repo, but the docs tell me that "anyone with a github account" should be able to edit it. You shouldn't need any actual knowledge of git to do so, and can write in the markup language of your choice.

I've found this bug and squashed it. I'll release it soon. So, I don't really disagree with that logic, but there aren't a lot of good places to put it. "Advanced Electrics" just doesn't seem thematically right, and neither does "Precision Engineering". "Unmanned Tech" might work; it's in the same tier as as the 88-88, so it basically lets you pick "lower power" versus "longer range" once you get to that tier. That's not something I'm very interested in at this point. Limiting player control is already a mechanic I don't like; making it even harder seems a little misguided to me. I'll think about it; feel free to keep lobbying.

vardicd, that's not far off from my first concept above. In general I like that concept better, I think, particularly in that has the least opportunity for incompatibility with stock saves. In the meantime, I realized I didn't link the patches page on the wiki above; here it is now: https://github.com/toadicus/AntennaRange/wiki/Compatibility-Patches

Thoughts: Because AsteroidDay isn't packaged with stock KSP (yet?), I need to keep the current three-antenna balance. But, because ModuleManager can detect mods just fine, I can check for AsteroidDay and do a custom four-antenna balance with the four Squad antennas. It helps that there's only one of them, so I can do this without tons and tons of effort. But but, because the HG-55 is basically the same as the 88-88 statistically, except slightly lower power and a bit less than half the size (according to my GIMP caliper measuring), physics has an answer for us: if it uses 2/3 the power and has .18 times the area, it should have sqrt(.66 * .18) = .345 times the range. This puts it basically smack-dab in between the DTS and the 88-88, which is an... awkward spot. I'm not sure I like it. But but but, the HG-55 comes at a really awkward point in the tech tree. I mean, automation, Squad? What gives? They're clearly intending this as a "better" part than the 88-88... and I guess it does come with 2/3 less power use... but its placement in the tech tree makes it really hard for me to decide what I should do with it. So, I have two basic ideas. One is to stick with it at 34% of the 88-88 as physics suggests and give it a really low maxPowerFactor (counterintuitively, this is a boon). This means it will always be a superior choice to the DTS. It will get you out to Eeloo, but not far beyond. The 88-88 would be a better choice if I used a nice round number like "2" for the maxPowerFactor; if I went to 1.5 then the HG-55 would always be the best choice unless you needed the range. Here are some numbers for that concept: [TABLE][TR][TD][TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]HG-55[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]1.80E+04[/TD][TD]6.30E+09[/TD][TD]1.26E+10[/TD][TD]3.70E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]1.80E+04[/TD][TD]1.80E+04[/TD][TD]1.06E+07[/TD][TD]1.50E+07[/TD][TD]2.58E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]6.30E+09[/TD][TD]1.06E+07[/TD][TD]6.30E+09[/TD][TD]8.90E+09[/TD][TD]1.53E+10[/TD][/TR][TR][TD]HG-55[/TD][TD]0.00E+00[/TD][TD]0.00E+00[/TD][TD]0.00E+00[/TD][TD]0.00E+00[/TD][TD]0.00E+00[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]3.70E+10[/TD][TD]2.58E+07[/TD][TD]1.53E+10[/TD][TD]2.16E+10[/TD][TD]3.70E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]8.00E+05[/TD][TD]1.20E+05[/TD][TD]7.10E+07[/TD][TD]1.00E+08[/TD][TD]1.72E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.00E+11[/TD][TD]6.00E+07[/TD][TD]3.55E+10[/TD][TD]5.02E+10[/TD][TD]8.60E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]2.00E+12[/TD][TD]1.90E+08[/TD][TD]1.12E+11[/TD][TD]1.59E+11[/TD][TD]2.72E+11[/TD][/TR][/TABLE][/TD][TD][TABLE][TR][TD]|[/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][/TR][TR][TD]|[/TD][TD]To↓ From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]HG-55[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]|[/TD][TD]Comm. 16[/TD][TD]<Kerbin Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbin->Mun[/TD][TD]Kerbin->Mun[/TD][/TR][TR][TD]|[/TD][TD]Comms DTS[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]HG-55[/TD][TD]<Kerbin Orbit[/TD][TD]<Kerbin Orbit[/TD][TD]<Kerbin Orbit[/TD][TD]<Kerbin Orbit[/TD][/TR][TR][TD]|[/TD][TD]Comm. 88-88[/TD][TD]Kerbin->Mun[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna @ Transfer[/TD][TD]Kerbin->Duna[/TD][/TR][TR][TD]|[/TD][TD]KSC1[/TD][TD]Low Kerbin Orbit[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin SOI[/TD][TD]Kerbin SOI[/TD][/TR][TR][TD]|[/TD][TD]KSC2[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Jool[/TD][/TR][TR][TD]|[/TD][TD]KSC3[/TD][TD]Kerbin SOI[/TD][TD]Kerbin->Jool[/TD][TD]Kerbin->Eeloo[/TD][TD]Kerbin->Eeloo[/TD][/TR][/TABLE][/TD][/TR][/TABLE] Another concept would be to throw science to the wind and do a balance based on KSC3 ranges of Kerbin SOI like: Kerbin SOI // Kerbin->Duna // Kerbin->Jool // Kerbin->Eeloo for 16 // DTS // HG-55 // 88-88, respectively. I'd reposition the HG-55 to someplace more central in the tree like; maybe reposition the 16 and the DTS as well. Something like the 16 at Start, the DTS at Survivability (since you get landing legs and service bays there; it's a pretty natural "let's go to a moon" spot and you need the DTS to do so), the HG-55 at one of the 90s down there... probably Miniaturization because it's a potential parent for Electronics and in general feels like it could use a boost. Leave the 88-88 in electronics. Here are some numbers for that kind of concept: [TABLE][TR][TD][TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]HG-55[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]1.80E+04[/TD][TD]6.30E+08[/TD][TD]6.30E+09[/TD][TD]3.70E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]1.80E+04[/TD][TD]1.80E+04[/TD][TD]3.37E+06[/TD][TD]1.06E+07[/TD][TD]2.58E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]6.30E+08[/TD][TD]3.37E+06[/TD][TD]6.30E+08[/TD][TD]1.99E+09[/TD][TD]4.83E+09[/TD][/TR][TR][TD]HG-55[/TD][TD]6.30E+09[/TD][TD]1.06E+07[/TD][TD]1.99E+09[/TD][TD]6.30E+09[/TD][TD]1.53E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]3.70E+10[/TD][TD]2.58E+07[/TD][TD]4.83E+09[/TD][TD]1.53E+10[/TD][TD]3.70E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]8.00E+05[/TD][TD]1.20E+05[/TD][TD]2.24E+07[/TD][TD]7.10E+07[/TD][TD]1.72E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.00E+11[/TD][TD]6.00E+07[/TD][TD]1.12E+10[/TD][TD]3.55E+10[/TD][TD]8.60E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]2.00E+12[/TD][TD]1.90E+08[/TD][TD]3.55E+10[/TD][TD]1.12E+11[/TD][TD]2.72E+11[/TD][/TR][/TABLE][/TD][TD][TABLE][TR][TD]|[/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][/TR][TR][TD]|[/TD][TD]To↓ From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]HG-55[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]|[/TD][TD]Comm. 16[/TD][TD]<Kerbin Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbin->Mun[/TD][/TR][TR][TD]|[/TD][TD]Comms DTS[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]HG-55[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]Comm. 88-88[/TD][TD]Kerbin->Mun[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna[/TD][/TR][TR][TD]|[/TD][TD]KSC1[/TD][TD]Low Kerbin Orbit[/TD][TD]Kerbin->Mun[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin SOI[/TD][/TR][TR][TD]|[/TD][TD]KSC2[/TD][TD]Kerbin->Minmus[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Jool[/TD][/TR][TR][TD]|[/TD][TD]KSC3[/TD][TD]Kerbin SOI[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Jool[/TD][TD]Kerbin->Eeloo[/TD][/TR][/TABLE][/TD][/TR][/TABLE] In spite of Squad's choice that the HG-55 is "better" than the 88-88, because it is the same shape of antenna and demonstrably smaller than the 88-88 I'm determined that it be shorter range in any case. Thoughts and discussion warmly welcomed!

Padrone (et al), I'm still pretty sure this is an issue with KSPAPIExtensions 1.7.4 not playing nicely with 1.7.5. There is literally nothing I'm doing that affects procedural parts' fuel tanks; if a PP fuel tank is the only thing on your screen none of my code is even running. In the one log I've seen on this issue the only item of any note at all was KSPAPIExtensions complaining about itself. Can you run this command (or something like it) from your KSP root directory? find GameData/ -follow -iname "KSPAPI*.dll" | while read lib; do echo $lib; monodis --assembly $lib | grep Version; done If there are any instances of 1.7.4, try removing them (or replacing them with 1.7.5 if you want to be more cautious) and running the game again. If the problem still happens with for sure definitely absolutely no 1.7.4 libraries present, get me a log (~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log) and I'll give it a read and see if I can at least point you in the right direction. As a note, that command will only work if you have mono installed. EDIT: After a quick CKAN update and running that script through my actual "play" folder, I see that NearFuturePropulsion is still packaging 1.7.4. I'm betting it's not the only one.

Can anyone confirm the "blank spots" report with the latest TE, the latest ProceduralParts and/or SmartParts, and KSP 1.0.4? If not, I'm going to continue leaving it alone. MM 2.6.6 will be in the next TE build; it released after we did.

cipherpunks, literally the only difference between KSPAPIExtensions 1.7.4 and 1.7.5 is that it no longer checks the revision number in KSP versions (so 1.0.2 == 1.0.4 as far as the version checker goes). If you install 1.7.5 over the version shipped by PP I'm guessing you'll be fine. Best of luck! EDIT: As an aside; I'm not encouraging people to disregard mod authors' advice about how their libraries should be handled. But, most advice is dispensed under the assumption that at any given time, users will be using (or should be using) the most up-to-date version of all packages involved. Since cipherpunks is intentionally not doing that, he's leaving the mostly-supported world of up-to-date mod interactions behind and creating possibilities for gaps in packaging -- especially with election-based multiple-distribution libraries like KSPAPIExtensions (though theoretically it should work; something must be up with its elector). The cost of operating legacy software is often finding workarounds and "sweet spot" combinations that produce the desired result... with the understanding that you basically can't ask for support when you do so.

Skalou, thanks, I'll take a look. I'm betting they reused the deployable solar panel code almost 100%... I bet I can reuse my tweakablesolarpanels code almost 100% as well. LostOblivion, thanks also! I'll look at those and see whose should live or die. Toggles are usually easy to let Squad keep, but they often do sliders a bit differently (e.g. only 0-100% instead of allowing some "over power" as we typically do). cipherpunks, Padrone, and Entropius, that sounds like (and looks like, from the log provided) a KSPAPIExtensions issue at worst, and a packaging issue on SmartParts' and ProceduralParts' parts at best. I'm going to leave it alone; if it continues after those authors have repackaged with KSPAPIExtension 1.7.5 and you can isolate TE as the problem, let me know. EDIT: And thanks, GaugeForever! I'm glad you like it.

Thanks, Donovan! I will start testing that as soon as I can. Calling all patch authors (you too BigFatStupidHead)! I have finally got around to setting up a wiki over at the AntennaRange github, complete with a "link page" for user-contributed patches. Anyone with a github account should be able to edit the page, and I strongly encourage you to add links to and brief descriptions of your patches there. Once there are a few links on the page, I'll put it in the OP here and we can use it as the "go to" place for users asking for a patch for Mod X. Hopefully this can be a useful tool for everyone.

TweakableEverything has been updated to version 1.12! This version brings fixes to several modules, including a rewrite to TweakableStaging to make sure stages are never re-assigned except when you ask them to be. smjjames, I did fix your bug. cipherpunks, looks like that's probably a report for the FASA devs. CHANGELOG: v.1.12 [2015-06-27] * TweakableEngineFairings: No longer tries to run on parts with malformed ModuleJettison definitions, preventing some Exceptional behavior. * TweakableLadders: No longer appears reversed in the editor. * TweakableStaging: Big rewrite; no longer alters a part's stage position except following very specific user inputs. * TweakableDockingNode: Fixed a bug that caused save-rupturing world breakage when two pre-attached docking ports with staging enabled were staged simultaneously. * TweakableEngineFairings: Now supports parts with multiple (valid) ModuleJettison definitions. * TweakableDecouplers: Temporarily distributing a patch to prevent zero-force decouplers from existing, to avoid what seems like a rounding error in KSPAPIExtensions.

No worries man; that wasn't actually directed at you (or anybody in particular). I'd actually meant to include that in the last release; probably should have used more self-deprecating wishing instead.

If what you're looking for is more textures, it might be worth looking in to Active Texture Management before you drop the concept entirely.

Yep; no more 64-bit. For better or worse (probably better at this point), Squad killed it until further notice as of 1.0. Have a read here for their rationale and to catch up: http://forum.kerbalspaceprogram.com/content/328-The-future-of-Windows-64-bit-builds-for-KSP