toadicus

You can use blizzy's or the old free-floating button. I'm working on integration with the AppLauncher, but I didn't get my hands on the new libraries any sooner than you did, so I'm just getting that effort off the ground. Edit: I've got a stock toolbar button working nicely. Now I just need my artist to get back and make a higher resolution icon so I can give you something that doesn't look awful forever.

Don't tell my boss, but there's a fair chance I've done basically zero work since it became obvious that 0.24 was releasing today.

Updated the download to 1.5. No changes, just compiled against 0.24 assemblies just in case.

AntennaRange has been updated to version 1.4! This version brings 0.24 compatibility and a configurable option for the "fudge factor" used in LOS calculations. CHANGELOG: v.1.4 [2014-07-17] * Updated for KSP 0.24. * Made the "fudge factor" used in line of sight calculations configurable.

VOID has been updated to version 0.13! This version brings 0.24 compatibility, the new TWR panel, and a couple request fulfillments / fixes. CHANGELOG: v.0.13 [2014-07-17] * Updated for KSP 0.24. * NEW MODULE! VOID_TWR is provides a listing of nominal thrust-to-weight ratios at the surface of each celestial body and is available in the editor and in flight. * VOID_VesselInfo: Changed resource mass line to a combo stage / total resource mass line. * VOID_HUDAdvanced: Fixed a totally embarrassing unit display bug.

TweakableEverything has been updated to version 1.3! This version brings 0.24 compatibility, a new TweakableEVA module, and some minor fixes and improvements. CHANGELOG: v.1.3 [2014-07-17] * Updated for KSP 0.24 Compatibility * NEW MODULE TweakableEVA allows for throttling of Kerbals' EVA thruster packs. * TweakableGimbal: Actually now checking the right field for null when the underlying ModuleGimbal has disappeared. * TweakableRCS: Now does thrust limiter assignments in the editor for improved synergy with RCS Build Aid. * TweakableRCS: Thrust limiter step size reduced to 1%.

I don't know where Alshain lives, but I can tell you that America doesn't really do trains, and when we do, I'm pretty sure we get it wrong.

Or when experiencing turbulence... in air-trains?

Glad you're enjoying it! Hmm. I don't have a good facility to enable that kind of behavior as an option, but I may be able to proceduralize the formatting a bit more so that different unit selection behaviors can be picked. You can, for now, adjust the magnitude display of most of the numeric values in the information panes. Making that work in the HUD would be harder, but I'll look in to it.

Yeah, the Mun's terrain is also mostly pretty high elevation, which compounds the problem. I'll be interested to hear what feels like a good "fudge factor" to you once you get the new version. To your other suggestion: I think I can do that now. Probably. I'll have to mess around and see if it works as expected. Ordinarily Kerbals don't carry ElectricCharge, so I'd need to give them some of that, too; I should be able to do it in a way that synergizes with TACLS. Probably won't happen before the 0.24 refresh, but who knows!

I will take a look at gendered requirements again after 0.24 drops and I make sure the plugin works as-is in 0.24. It should be a pretty simple change. The specifics of the implementation would be up to the creators building parts around the plugin, but I've got an idea that should make strictly gendered ports (male->female or neuter:neuter only) and more complex ports (like passinglurker's idea) possible.

Hey all, just dropping a line to say we'll have a little quality of life update whenever 0.24 drops. It'll include configurability for the LOS "fudge factor", 0.24 compatibility, and basically nothing else! Development is underway on the Big Rewrite, but not done yet.

Pre-update forum update: GO! Why hello there, you handsome devil. You'll be glad to know that I've fixed your past foolishness, and fixed the Interplanetary TWR window. That'll be in the next update. Welcome aboard! I don't have calcs for any of those items at this point. I'll take a look and see how feasible they'd be, but I can tell you that the atmospheric calcs would probably depend on a FAR wrapper. I use FAR as a "must have", and if I'm going to develop atmospheric data I'm going to use aerodynamics that are at least semi-real. Time to impact should be pretty doable for airless bodies without FAR, or in a FAR wrapper for atmospheric bodies. I'll let you know. Hmm, I think I did that today. Let's have a look <scours the git logs>. I did! I totally forgot to test it though. Also, I need to proofread my commit messages. It'll be in the next release. The HUD already has a "radar" altitude readout in the "top right" HUD pane. It calls itself "Srf Alt". I really do want to get scriptable panels/HUDs in, and I've got a plan to do so, but it's hard and a little outside my wheelhouse, so I'm somewhat ashamed to say it's in the vaporware stage at the moment. Ooh, that's a good idea. I don't think it'll make the next release, but I'll look into it. The next update is coming Soonâ„¢. If you want it sooner, bug another organization who is offering an update Soonâ„¢.

The LOS code has a 5% "grace" figure in it to make satellite constellations easier with stock tools. That is, line of sight will be granted when the distance from the center of a body to the line ended by both relays is greater than 95% of the radius of the body. On Mun, that should mean that two vehicles at "zero" level on the surface can contact each other from about 127 km apart, or more if the antennas are raised above the surface. Also, terrain is not considered whatsoever: if one antenna is up on the highlands a few kilometers above "zero" level, you'll get even more distance out of the grace number. Considering terrain is complicated and expensive from a calculations standpoint, and pretty much completely useless for orbiting vessels, so at this point I'm not planning to add such a function. I will make the grace figure configurable in config.xml in the next release, though, so you can make things tougher on yourself.

Here's my thinking, based on my observations: "Rover forward" and "Rover backward" controls (whether W&A, I&K, or 8&5) are hold-on toggles that apply 100% power to powered wheels when the key is down. When no controls are down, all powered wheels are at 0%. Rover wheels are frictionless. If noting acts to slow them down, they will keep turning. Rover tires are internally frictionless. No energy is lost to deforming the wheel as it contacts the ground. So, on airless worlds in flat areas, once you get up to speed you will remain at that speed. To slow down, apply reverse power, brake, or navigate up a steep hill. On Kerbin, Eve, and Laythe, air drag still applies to all of your physics-significant parts, and will slow down your rover if power is not applied constantly.

I've reduced the step for TweakableRCS down to 1%: http://git.toad.homelinux.net/projects/TweakableEverything.git/commitdiff/4d82c73 As Obsessed said, that's already in. It's the "Engine Fairing Toggle" mentioned in the first post.

Update picture: GO!

Sarbian, I got a mess of these errors after I watched a service section disintegrate behind a descending pod today: NullReferenceException at (wrapper managed-to-native) UnityEngine.GameObject:get_transform ()^M at PersistentEmitterManager.FixedUpdate () [0x00000] in <filename unknown>:0 I couldn't begin to tell you why that happened, but here's a log in case it's useful: http://ksp.hawkbats.com/output_log_44b752.txt.xz Looks like it could be fairly easily worked around by some exception handling, but if there's a Better Way, I'm sure you'll find it. Let me know how I can help!

Hmm, sorry I haven't got to this yet! I'll take a look when I can. I sat down last night and took a stab a this. I can't use ModuleManager or a prefab search plugin to add modules to EVA Kerbals, so I'm going to need to do some more digging to find the Right Way to do that. The module itself should be simple enough; it might even already be done; but until I can get it onto the EVA Kerbal "part" that doesn't do us any good.

There are a lot of ways that I could address the issue. I'd really prefer to avoid requiring an extra download, because that really is a pretty confusing step: "Mod X has an update! Yay! Don't forget to read the changelog to check if its dependency Mod Y also got an update. If it did, make sure you go get it first!" That's not work that I feel like forcing upon my users, and lacking an automated mod manager setup that would let me assign Mod Y as a dependency and have it auto downloaded, this option mandates that the user be responsible for the extra work. The next best option would be for me to completely re-architect the library into a singleton format (currently it's all static classes), do a version election in the singleton logic, and write version numbers into my .dll files. The big problem with that is that the library includes a lot of extension methods which MUST be static, so I'd also need to completely refactor all of the code that depends on the extension methods in the library to call utility methods from a singleton instead. This is a bunch of work for me and requires me to forgo the use of a nice convention of the C# language, and I'd prefer to avoid such restrictions. After that, I can look at things like auto-downloading the library, or even loading the assembly direct from the web every time a user starts up KSP. But that will cause a Major Kerfuffle with some subset of the userbase that I'd rather avoid. TL;DR: I know my current solution isn't ideal, but all of the other solutions have big downsides as well. If Kerbal Stuff takes off and gets a good, cross-platform mod manager that will respect dependencies as I and many here seem hopeful it will, I will distribute the library separately and let the mod manager do the extra work for users that aren't willing or able to do so. Until then, I'm going to keep doing what I'm doing and if I can use Kerbal Stuff with my current solution until a mod manager gets developed, I will.

I maintain a common tool library for all of my mods, and when it gets updated during one mod update, I have to refresh the other mod downloads as well. My current solution uses a little bash script to update the library in my other mods and re-copy them to my private server, which I currently use for all of my hosting. I like the idea behind Kerbal Stuff and want to host my mods there to support that idea and SirCmpwn's effort, but if I have to browse to the site and update three mods every time I have an update for one of them, it reintroduces a lot of extra work that I have currently solved with a single command invocation. I'm aware of various ways to write scripts to operate websites, but I know that some uploader designs make efforts to thwart such automation in order to prevent abuse. So, I suppose a more pertinent question might be: is the site designed to permit and/or facilitate the use of automated web scripting?

Is there a way to upload files via a command line utility?

Sorry this took a while to get back to you; I moved this weekend and still don't have Internet at the new place. I'll try to get a chance to test that soon. I've never used those specific UI settings before, but can't think of a good reason why they'd be causing the issue. Can you get me a copy of your debug log file (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) after a run of the game that exhibits the problem? The shorter the run the better, so if you could just load up, get to a flight, do the reset, go to the space center, get back to a flight, and then force-close the program, that'd make my job easier. Thanks!

Technically a vote for KER is half a vote for VOID, since VOID uses KER for all of its vessel-side engineering calcs. Thanks for the support though, folks! I love modding, and hearing stuff like this from you guys is a great reminder of why I do it.

Glad you're enjoying it! These little comments do mean a lot.