toadicus

I'm serious insofar as I do have such software, will port the SI functions, and will post it on the theory that more free code is better than less free code. I'm not entirely sure where it would be used, but weather mods could probably use it as they mature. I am imagine it as useful in a hyper realistic life support mod, too.

I just remembered I've got a C# port of a C library that does psychrometric calculations. I've only ported the inch/pound version because that's what we use at work, but I'll port the SI version soon and get it up to github. Then we can do air conditioning or theoretical meteorology.

I am absolutely OK with being contacted through PM.

That is what I mean. Here are some more numbers: Double-walled aluminum shell, loose-packed wiring (based on half the density of a box of CAT 6 cable... heh): 1.25m - 0.10t 2.5m - 0.35t 3.75m - 0.95t Double-walled aluminum shell, very loose-packed wiring (quarter density): 1.25m - 0.08t 2.5m - 0.27t 3.75m - 0.68t Steel outer shell, aluminum inner shell, loose-packed wiring: 1.25m - 0.18t 2.5m - 0.61t 3.75t - 1.54t Steel outer shell, aluminum inner shell, very loose-packed wiring: 1.25m - 0.16t 2.5m - 0.53t 3.75t - 1.27t Given the cross section I can try to break things down into specific steel and aluminum bits for the larger ports. But, I'd probably actually recommend that you pick and choose some of these numbers above. They're all "close enough" to anything we could be looking for; for comparison Squad's 1.25m port is 0.05t and their 2.5m port is 0.2t; they don't have a 3.75m port, but KW Rocketry's is 1.5t. If I were building these parts I'd probably pick 0.08t for the 1.25, 0.35t for the 2.5, and 1.27t for the 3.75 and call it close enough.

I'd vote for a "both" option. If we don't get both, I'ma just re-tint a copy of the texture and make both myself.

I'm a professional engineer on the less "flashy" side of mechanical engineering; heat transfer and refrigeration. I don't think that's quite what you guys are looking for, but if I can help you find something on that end, let me know. Alas, most of the documents I have easy access are Super Copywritten... but I'll see what I can find upon request.

So if they're 100% solid aluminum... 1.25m - 0.864 Mg 2.5m - 3.26700 Mg 3.75m - 10.66500 Mg Those numbers are rather absurdly large, though, and they would probably actually be largely hollow. Can you get me surface areas, too? I'll do a double-walled heavy gauge sheet metal a couple different ways. I'm thinking now that I'm going to assume they're hollow shells (probably aluminum) with a "loose pack" (20% fill, maybe?) of light-gauge wiring (like data and power transfer cabling) and such inside. EDIT: Did a little more thinking about this. I've got a friend in the industry looking into the thickness of aluminum used in commercial planes, while I'll use for most of the skin... but these should have a structural component as well since you're going to be literally bashing two space ships together with these as the touch point. Can you also get me "cutaway" views through the "center" of each? I'll work up a concept for how the load might be distributed from there.

Left to me I'd probably take volumes of the whole parts and assume they're 100% aluminum. If you've got more specific ideas about this or that bit being made of steel or plastic or so, go ahead and break it up thus.

If you can get me a volume using your modeling program, or at least a linear dimension for the thickness, I can give you my thoughts and let you take it from there.

Kip, I like the second version better in general. It may just be the image, but the grab-latches (I think that's what they are) on the smallest ring look a little "messy" for lack of a better word. Also, the round widgets on the outer two rungs look a little "pixel-y", to me. Again, might just be the image. I generally agree with sentiments that the smaller sizes ought to be thinner. Regarding the mass: personally I'd stick with a fairly realistic mass using aluminum or something as the primary material. If people want to tweak it heavier to get better connection strength with KJR, they can just use a modulemanager patch (I'll even write one if asked).

tg626: Can you help narrow down the problem a bit more by going into a similar "known" scenario and just disabling the engineering calcs in the VOID configuration menu? That will disable calculating delta-V, etc., but basic positional data will still be around. That'll help me understand where the performance issue is. Also, can you confirm that your previous test was done with all of the other panes closed? That said: VOID does a lot of extra calculations especially when the engineering data is on, and the bigger your ship is the more there is to do. Some performance hit is probably unavoidable. But, if it's in a part of the code that I can optimize, I will definitely see what I can do. linuxgurugamer, I haven't looked into everything that Kerbal Engineer does in quite a while. There was a time when VOID had more flight-oriented data available, and also offered part-free operation before KER did. But, I think our functionality has converged quite a bit; I even license KE's code for all my engineering data. VOID offers log output to a .csv file; I don't think KE does that... I glean from some Scott Manley videos that KE has "suicide burn" estimates; VOID doesn't. Oh, and Soonâ„¢ VOID will let you script your own panels and do mathy things in them.

Hey, this has sat idle a long time. Probably because it kept working how I needed it to for so long. But, KerbalStuff's recent certificate update breaks mono's ability to interface with it. CurlSharp, a C# binding for libcurl, is a reasonable work around (and is used by CKAN), but doesn't work reliably for uploads and my C/C++ skills aren't... really there at alll... so I can't change that. So! I've rewritten the whole thing in python, and released it into the public domain. Feel free to use it instead of the C# version until a better solution presents itself. http://git.toad.homelinux.net/projects/PyKStuff.git

VOID has been updated to version 0.17.1! This minor update brings new and varied options for considering time, and fixes some issues with the data logger. Note that the new toggle between "Earth time" and "Kerbin time" duplicates the built-in KSP toggle from the options menu; it's just easier to get to. Sorry this took so long; KerbalStuff's recent certificate update broke mono's TLS support for it (mono's fault, not KerbalStuff's), and the CurlSharp alternative used by CKAN only works reliably for read-only operations. So... I rewrote my whole API wrapper in Python! "But toadicus", you ask, "why didn't you just upload ToadicusTools manually? I mean, it's only a library, and the standalone version is only for CKAN." Ah, you're very right, anonymous rhetorical user! That would have been easier and taken less time. The problem is, though... I'm a nerd. CHANGELOG: v.0.17.1 [2015-04-10] * VOID_DataLogger: Fixed some issues with the header line * General Options: Added options to use solar vs. sidereal time, Earth vs. Kerbin time, and rounded vs true time

Wyrmshadow, docking and undocking is one of the most esoteric bits in the game and lots of mods do things that wind up affecting it. However, I'm unsure how this one could at all, unless it's to do specifically with reducing your re-engage distance to 0 (so even if the ship does undock, it tries to dock again literally immediately thereafter). So, I'd try setting that to a sane number (at least half a meter) and trying again... if it's still going on, I'm happy to take a look, but I'll need 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) in order to do so.

From the looks of things, KAC uses the same integer values as KSP, probably for consistency.

Yes, very simple. I've been looking into the date discrepancy and am now even less inclined to "fix" it... not only does KSP's formatting code pay no attention to the type of time it's counting, it uses childhood values for all the numbers, e.g. an Earth year is 60 * 60 * 24 * 365 = 31536000 seconds long (the actual value is either 31558149.7635456 or 31556925.2507328, depending on what you're counting), and Kerbin's year is just 60 * 60 * 6 * 426, which is also wrong. If you'd like, I'll put a switch in like "Use Broken Time Scales" that should result in agreement with Squad's numbers.

Gaiiden, are you using Earth Time or Kerbin Time in your KSP settings? I know I have a couple of inconsistencies versus KSP's numbers (somewhat intentionally; we've discussed it before), but I'll take another thorough look at it once I know what you're looking at. I don't see that I'm missing any column headers, but I did have Orbital Velocity in the wrong place, which would have had three of the headers looking obviously wrong. I'll test it more thoroughly as soon as I get a chance. I'll take another look at the resource masses. It's all in KER's code, so it takes some extra doing on my part, but I'll try to get to it soon. In general, sorry I haven't been as consistent as usual lately. I've been working a whole lot, and there are something like 6 family birthdays in Feb and March, so my weekends have been busier than usual themselves. I also bought Crusader Kings II... so there's that. I'm trying to get my schedule back in order and hope to be more responsive in the near future.

Pretty! Thanks for the info; that will be helpful in debugging. I figured I was going to break something like that with this change... that's why it's a test release.

OK, so I didn't get a chance to test it this weekend. In the interest of trying to release something sooner rather than later, here's a test version including the fix: [zip] [tar.gz] [tar.xz] Let me know how it goes! Failing that, I'll try to test and release properly next weekend.

The short answer is "no". The long answer is that I can't intercept the control inputs individually without replacing the whole ModuleGimbal module, which applies the same gimbalRange scalar value to all three axes. TweakableGimbals works by negating that value. Since I can't invert it "just sometimes" and I can't change the roll input "just for gimbals", I'd need to write a new gimbal module to replace Squad's that used different values for each axis. I know that's been done a couple times before, but I'm not sure what the most recent adaptation. At this point, it's out of scope here. Sorry! I think I've found the problem, and have solved it for most cases. The issue was to do with TweakableStaging, which was running a full search through the ship for every decoupler in the ship on the first LateUpdate call. That's actually only necessary if you're toggling the staging in the first frame (e.g. if you've set a decoupler to "Disable Staging"), so I added a tiny bit of logic that should make sure we only run in the first frame if we need to. I need to test it before I release to make sure I didn't break anything else... hopefully I'll have a chance to do that tomorrow. Roger that.

Gaiiden, I'll take a quick look, but I know what you're talking about and I'm pretty sure that's Squad's issue, not mine. When you drag particularly near to the bottom end of a floatrange tweakable, it clamps to zero for no apparent reason, even though the rest of the scale all works pretty smoothly. If you want to get finer precision in the general sense you could reduce the thrusterPower of your RCS blocks by half, which would give you more room to tweak at the bottom end of the range before the slider clamps down. If you only want it sometimes and it's fairly predictable, I could theoretically give you a "trim" range from -5..5% that would add to the actual throttle value. dc4bs, I haven't built any megaships for a while, but several of my modules do linear searches of various parts of the ship -- usually just their own part, but sometimes the whole ship -- that might slow things down. If you can get me the craft file (or better yet, upload it to KerbalX so their software can do the hard part of finding the minimum set of mods required for me), I'll see if I can reproduce and nail down some optimizations or at least offer an explanation. Also, does this happen just the first time you load a particular craft before re-saving it after installing TE, or does it happen every time? Because I add module to parts, the first time you load an existing ship save Squad has to go through all the parts and help the modules to all line up correctly. If you save the ship again after that's happened, it shouldn't need to happen again, but if you don't save the ship again it will have to re-run that adaptation every time you load it. A few other mods -- FAR is one -- also repeat similar processes as they add their helper modules. So, you should expect longer loads when loading saved craft the first time after installing mods that add a lot of modules (and TE does), especially for very large ships (because the process is always at least O(n) and sometimes worse).

Are you talking about the EVA pack thruster throttle? If so, the answer is yes... but let me see if I can find a way to let you do it, without making everyone else also do it. I find tweakables with more than 20 or so stops on the line to be super annoying, which is why I coded it to make the increments divide into the total 20 times.

TweakableEverything has been updated to version 1.8.1! This update re-introduces the TweakableLadders module and allows re-packed parachutes to be used as a part of the staging list. CHANGELOG: v.1.8.1 [2015-03-15] * Old module! TweakableLadders is back, because broken tweakables that play long animations in the editor make us sad. * TweakableParachutes: Added logic to re-enable deployment via the staging list after chutes have been repacked.

Sorry guys; I just finished an 80 week and a few 60 hour weeks before that. I've got things going on today, but may be able to get back into the swing of things here tomorrow -- late next week at the latest. Thanks for your patience.

Thanks for the report anyways, damerell. I'm absolutely buried in my day job, but when I am able to come up for air I'll try to implement a throttle so that if many similar transactions come in within an impossibly short period of time, VOID will rate limit them into a single transaction.