toadicus

Hyomoto, the problem with those patches is your nominalRange. Remember that nominalRange is in meters, so you're only prescribing a range of about 30 km -- not actually all the way to Kerbin's center. You probably want a number more like 1000 times bigger than those numbers. With, maxPowerFactor = 4, your maximum tranmission distance will be twice nominal. Hope that helps! The relay functionality updates constantly, but each individual relay will only repeat its search every 5 seconds, so in general it may take up to 5 seconds to register a change in path. I intentionally do not require a connection specifically back to KSC. I explained it some time ago (but am happy to find the quote myself, no worries ): As I said all that time ago, if you've got a good reason for me to change my mind, please go for it.

Squad's code already has some provision for requiring roll orientation. Last time I tested it (which was a long time ago), I couldn't get it to work, but it's worth investigating again. Try setting acquireMinRollDot and captureMinRollDot in the ModuleDockingNode definition to a number very slightly less than 1 (e.g. 0.7 and 0.998, respectively) and see if it starts restricting the roll orientation. If not, I'll work on coding something up. There is already magnet torque, but I'm not certain if it will apply roll. We'll have to experiment with that as well.

politas, can you 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

MeCripp, looks like that answer is "yes". I'll get it in the next version. OWKSP: I'm working up some general improvements to my EVAManager code that will make things a bit better. First, EVA packs will not be magically filed by magical magic, and instead will get their charge from the pod they left (and put it back when they return). I'll also increase the power use and probably reduce the bandwidth. I'm going to try to make it "feel good" to transmit EVA reports from EVA, but make transmitting big experiments (like gravimeter reads) feel more burdensome (aka slow). Then I'll revise the overall efficiency to be in line with the monopole (maybe slightly better), and that's probably going to be all for now. AR2 development is still dangling on the end of the list of things I'd like to do. Whenever I get to that, it'll bring a Serious Revision to this issue. Thanks for the input!

Hey LostOblivion, sorry it took me a couple days to get here. Thanks for the detailed reports; I'll look in to them as soon as I can. EDIT: If you're feeling daring, give this DLL a shot. Looks like Squad is using a different field to describe the thruster's enabled state now, but didn't remove the old one so everything still compiled. This just accesses the new field and compiles -- I haven't so much as loaded the game to test it yet. I'm not sure what's up with the action group thing... I provide the action group items; if they're being removed then Squad must be doing that somehow. I'll try to figure it out. EDIT TWO -- THE RE-EDITENING: It occurs to me that my previous use of "isEnabled" -- a PartModule-level property that used to control the functionality of the RCS thrusters -- may actually have been disabling the module completely and thus removing it from the action group list. Perhaps this is a part of why Squad added rcsEnabled to ModuleRCS, allowing two different levels of functionality within the module. If so, then TE switcing to rcsEnabled may solve both problems.

Yes; I play exclusively with modifications. Yes; I create or maintain five publicly distributed mods, and an extra or two for personal use. I develop mods to improve gameplay for myself and the community, and to challenge and improve my abilities as an amateur programmer. I currently only develop mods in KSP, but I have written mods for other games I've played in the past. I don't write mods in KSP for any technical reason associated with KSP, but instead because I think it's a good game that could be great. The modding API lets mod developers take that step. I create basic play experience improvement modifications -- informational and build assist tools -- along with some gameplay enhancements. I use mods of all sorts to improve realism and playability and expand the breadth and depth of the game. I release my modifications under BSD 3-clause or 2-clause licenses, because I want to foster a "team effort" approach to improving the game, and because I hope that they would be continued were I to disappear from the community. I avoid "viral" licenses like GPL & CC-SA to help avoid license incompatibilities. Feedback on my mods is generally commensurate with their popularity; as my mods increase in user base, the volume of feedback increases. In general there is a reasonably healthy attitude towards collaboration in troubleshooting problems, though the larger the user base becomes, the more "bad" users who are unwilling to help find solutions to their problems become an element. I have not sought "getting started" help and do not significantly interact with the community outside mod development. Within the mod development community, I am an infrequent contributor to most discussions and as such am something of an "outsider" -- that's probably as much my own doing as any "fault" of the modding community. By and large all software is an idea, or a set of ideas. Ideas are immaterial, fungible, and easily copied. I strongly endorse the honest treatment of ideas, and as such strive not to impose any burden on those who would seek to benefit from my ideas. My software is thus "free and open source", but I do not use viral licenses to tell other people how to Not really. In my opinion, the production of KSP as a moddable platform is by far its most valuable asset.

My "Not KerbalStuff" mirror will always have the files available.

Yes, that is technically feasible and is what's being discussed. For example, I do something very similar with TweakableEVA. I just need to get it coded in a way that stays consistent across different tech trees (so instead of detecting Advanced Flight Control, it needs to detect that you have researched any part with ModuleSAS, whether that's in Advanced Flight Control or Custom Banana Technology), and that properly does not add the module to parts already in flight (since the "easy" way to do this is by adding to the prefab, I'm pretty sure it would get added to all the parts everywhere, which is not consistent behavior; this is the tricky part).

Yes, I figured that out as well. Glad to know it's not just myself having the problem. VOID has been updated to version 0.16.4! This fixes the issue with the advanced HUD panel "collapsing" whenever there is not a maneuver node. CHANGELOG: v.0.16.4 [2014-12-28] * HUDAdvanced: Fixed an issue that caused the right HUD to collapse into a vertical column when no maneuver node was present This all seems like correct behavior; the toolbar icon does not and should not appear in the editor until you start building (or load) a ship. VOID doesn't change anything related to your building upgrades in career mode at this point, so if you can't make a maneuver node yet, you can't use VOID's maneuver node functionality. The one thing that stands out is the blank white square; that seems to reflect an incorrectly-loaded texture, which isn't supported by the log you linked later on. Has that problem persisted? When you click on the blank white icon, does the VOID menu window open and close? I looked over your log and everything seems to be in order; the DLLs and textures are all in the right place and KSP is loading them. Are you still having a problem?

Just to clarify, this is with version 0.16.3?

If you want to upgrade Stayputnik, add this MM patch someplace: @PART[probeCoreSphere]:BEFORE[TweakableEverything] { MODULE { name = ModuleSAS SASServiceLevel = 0 } } This will give it a "level 0" ("stability assist" only) autopilot, but no reaction wheel (so you still can't actually use it as an autopilot without extra parts). Then when you develop better autopilots you can produce superior Stayputnik parts -- still provided you put reaction wheels on it. I'll think about "right ways" to make it more upgradeable within the flow of the game.

Well... not Stayputnik (see above). Maybe someday.

Correct; so for example once you research the HECS core, you can upgrade the OKTO core to Level 1. The only core not helped by this is the Stayputnik, because it completely lacks a ModuleSAS to upgrade, solidifying our longstanding suspicions that it sucks and is useless. Enjoy!

TweakableEverything has been updated to version 1.7! This version brings not one or three but two new modules: TweakableParachutes and TweakableSAS! These modules allow the configuration of parachute deployment times and upgrades to SAS levels, respectively. TweakableSAS only makes sense and therefore only operates in career mode, and restricts your upgrades to probe SAS levels unlocked by your tech progress. CHANGELOG: v.1.7 [2014-12-27] * New module! TweakableParachutes allows configuration of parachute deployment times. * New module! TweakableSAS allows upgrading of 'old' probe cores to use newer autopilot programming.

VOID has been updated to version 0.16.3! This version fixes the disappearing HUD lines. CHANGELOG: v.0.16.3 [2014-12-27] * Fixed HUD panes to properly expand to fit their content. * Tweaked default Toolbar behavior to hopefully provide a more predictable experience.

I found myself wondering that when trying to build a contract satellite last night. I don't have the answer yet, but it's also one of my favorite features so you can rest assured that I'm looking.

Welcome aboard, SilentBish! First, make sure you have it installed correctly: the "VOID" and "ToadicusTools" folders from the "GameData" folder in the archive should be present in the "GameData" folder of your KSP installation. If you have no other mods installed, the VOID icon will be in the stock applauncher (top right in most scenes, bottom right in the editors). In the editor, the icon will appear only after you have picked the first part (or loaded a vessel). The icon only shows up in the editor and flight scenes; VOID has no presence in the space center or elsewhere. If you have installed the "Toolbar" mod, you will need to enable VOID's icons in Toolbar via the "Configure visible buttons" option in Toolbar's menu. Again, in the editor this will not be possible until you have picked a part. If there's still no sign of it, you need to get me a log, which you can find in one of these places: 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. You can copy/paste the contents to a site like pastebin.com, or upload it to a site like Google Drive or Dropbox and share a link with me in this thread or via a private message on these forums. The log will help me to determine if you have installed the mod correctly or detect any other problems on my end. Hope that helps, and welcome again!

BaseDrifter, I've responded to this issue in the TweakableEverything thread. Thanks for the report!

Please give the current version of ToadicusTools a try: [zip] [tar.gz] [tar.xz] ToadicusTools got updated with VOID's recent update, and I believe I inadvertently broke API-compatibility with the current version of certain modules in TweakableEverything. This version should fix it; please let me know.

Please get me a log; I'm using the latest version myself and do not have that issue. 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 I'll take a look!

Let me see if I can find the time to upgrade my deployment scripts over the holidays. If so, definitely. If not, I'll just write a ckan file (not a netkan file) and take care of it that way.

Found that, and set up a super-cheaty career save to get a satellite mission on my second launch. Launching a probe with an AR antenna and some solar panels did satisfy the requirement: komodo, if you're absolutely sure your craft satisfies the requirements (remember it needs to be a NEW launch, with a persistent power supply (e.g. solar panels or RTG) and an antenna part (and any other parts the contract requires), go ahead an upload a log; I'll take a look and see if I can at least point you in the right direction.

I know for certain that Fine Print did support AntennaRange back when it was a mod. I've still only spent like 20 minutes actually playing 0.90 so I haven't checked, but if it's not working then they broke it on purpose. I'll look in to it, and try to talk to Arsonide for ideas if need be. Thanks for the heads up!

It looks like that should be pretty straightforward to implement on its own. What's slightly less straightforward is making sure I don't let you tweak the value to something better than the best probe you've developed so far... but I ought to be able to sort something. I've got a prototype of this working; needs more testing but initial results are positive. I don't usually play with TweakScale, but I had it installed and noticed a bit of wonkiness with that a couple of days ago. I'll try to narrow it down.

Right now the endpoint is actually the center of Kerbin; those extra 600 km are Kerbin's radius. I'll fix that one of these days.