Gaius

I approve of this product and/or service.

It's being worked on. Expect an official announcement soon.

Oh, ha! Nope, you don't need it -- the Unity libraries it compiles against are actually in the KSP_win directory (under KSP_Data\Managed). See, it's been so long since I monkeyed with this that I don't even remember what I did. I have oldheimers. I do need Unity installed for working on my parts mod, so my confusion is at least excusable. Who knows, maybe someday I'll have time to update that one...

Awesome! This is my favorite mod, I can't play without it, thanks for updating it! Seriously, thanks. I'm in the middle of a move and don't even have Unity installed on my current desktop to do compiles against. I have updated the first post of the original thread to now point to this thread. Good luck and have fun!

Ah, that would be Kommitz' most excellent work.

Nope, those are the only trusses I've had. Perhaps Rareden was using this old mod? Unfortunately, that mod appears to be dead. I might take up the task of making replacements if I can find the time. I too really did love that mod.

Well, a Jumbo-64 is a cylinder with a radius of 1.25m and a height of 7.5m, so an internal volume of 36.816 m3. An FB-O tank at size 4 is a sphere with a 5m radius, so an internal volume of 523.599 m3. So, yes, a size 4 FB-O tank is 14.222 times larger, and spherical tanks generally more efficiently use their internal volume than cylindrical tanks, which actually round their ends a bit on the inside for structural strength, hence the spherical tank actually gets a bit more than 14.222 times the usable internal volume.

You shouldn't compare RTG output to larger power generation systems. You'd never put 26 tons of RTGs on something when a single 1 ton nuclear reactor would generate more power for a fraction of the weight. You use an RTG where you only need a trickle of power and don't want to devote half a ton or more of your spacecraft to the power system. For heavier power generators, compare to something like a SAFE-400 reactor, which weighs half a ton and generates 100kW of electricity (for game purposes, say 100 E/s). In terms of weight/power efficiency, it's literally a couple orders of magnitude better than a PB-NUK-style RTG, but that's reality for you. The advantage of something like a PB-NUK is that it doesn't weigh half a ton, so you use that when you don't need multiple kilowatts of power. That's where the balance lies. Trying to balance larger power generation systems against a wimpy RTG in terms of power per unit of mass is madness.

Thanks for hosting that! I've updated the first post to point to the temporary mirror, but I'll work out a more permanent solution soon (hopefully before 0.24 hits)...

I just wanted to say: Wow! Outstanding job taking my little hack and turning it into something great! I was originally going to quibble (I tend to be on the GPL side of the "license wars"), but at this point I think it's fair to say it's more your mod than mine. Feel free to re-license it as you prefer with my blessing.

Ah, thanks for doing this. I've updated the first post to point to the new download. Sometime before 0.24 gets released, I'll hopefully have time to get an update up on CurseForge myself for a more official release... To the best of my knowledge, the capacity per unit volume of my spherical and pill tanks are within 10% of the stock tanks (except perhaps the xenon tank). I verified the volumes using Wolfram Alpha. It may be you're just unused to looking at spherical volumes. The nosecones might be a bit looser, but certainly not more than 20% off I think. In any case, if you know of anywhere the numbers vary significantly, please be specific and I'll take a closer look at it. Thanks.

Please steal my plugin! Seriously, the plugin has been feature complete for my own purposes for a while now, so having someone else take over the job of maintaining it, keeping in up to date and extending it with new features is doing me a big favor by taking over what for this point would just be work for me, and work I honestly don't have time for at the moment -- this is literally the first time I've had time to even login to the KSP forums in over ten days, and I'm currently both very busy and dealing with personal issues that are probably going to take a few more weeks at minimum before I'll have much time to do any kerbaling. So, I'm going to change the name of this thread to indicate that from now on, this thread will be all about my parts pack and that alone, and the new TweakScale plugin thread will be started by the new maintainer in the very near future. Future releases of my parts pack will be adjusted to depend on the new version of the plugin just like any other third-party mod would. And it will be simply called the TweakScale plugin, since it wouldn't be fair to keep calling it my TweakScale plugin when I'm no longer the sole author. I do have some new parts, or at least some new models (replacing a couple of the welded parts currently in the pack with unique models) already done that I just haven't gotten around to rolling into an update yet, but I'm honestly not sure when I'll have time to do that given current events IRL. But in any case, I'll wait until the dust settles on the new thread so I can release the next version of the parts pack in a way that makes it depend on the new fork instead of maintain its own redundant and dated version of the plugin. And seriously, thanks much for taking over maintenance of the plugin. This is what open source is all about. Throw some code out there, and let some other schmuck do all the work of making it great while you sit back and enjoy the fruits of their labor.

Since it doesn't hurt anything if the mods aren't installed, I will add Kethane and EPL/OCR materials to the default config on the next release. I exclude command pods from the things that automatically get the pump installed because they already have a pretty beefy right-click menu, and I didn't want to clutter that up with even more lines; also, I so rarely want to pump things out of command pods that it's simpler to just do it manually when I do. But it's easy enough to remove the "!MODULE[ModuleCommand]" exception in the relevant config file entries to make it add the pump regardless.

Sorry to everyone I didn't reply to recently, been pretty busy for the last couple weeks, but I'll be back to working on this soon. Loving the pics, BTW, and the evil laughter. Aha! Someone was just asking me about supporting that in a PM! I'll let them know the feature is now in the fork. Thanks for that, I was wondering how to go about doing that, and now I know. Absolutely! Just make sure it unpacks to GameData/Goodspeed/Plugins/Scale.dll, so that if multiple mods use it, they just overwrite the same file instead of having a bunch of same plugin distributed all over the place...

What, no furlongs per fortnight?

I'll see if I can't come up with something. I'm also planning on monoprop balls. Just a matter of finding the right texture... and the time. Do you mean the "rescaleFactor" variable in the config? For parts that use MODEL {...} as mine do, the way rescaleFactor works is horribly broken in the current version of KSP, so really the only right answer to that is "1.0" for now. Instead of changing that, to rescale a part in its config, go into the MODEL {...} section and set the "scale" variable in there. I believe all the reactors use "1.0, 1.0, 1.0" -- set each desired dimension to "0.5" or "2.0" or whatever. Then go to the "node_stack" variables and adjust as necessary. I considered that, but I'd have to set up a separate Spaceport entry for it, and I'm fundamentally lazy... I may do it anyway, though. Originally, it really only worked with my own parts, so I didn't bother, but I've made it sufficiently generic now that it really ought to work with anything, so I'll make a separate download for it next time I update it.

Prior to the ARM release, I would occasionally update MechJeb, try docking, and revert back to build 168, which was the last version I downloaded that had a decently working docking AP. Alas, since the ARM release that's no longer an option. I'm not sure what needed fixing with the docking AP in build 168, but I sorely miss it. It sipped RCS quite efficiently and docked much more quickly and safely for me, 100% of the time. If nothing else, I'd love to see a checkbox in the new one to disable to horrid "backing up" behavior, or a box where I can enter the number for what should be considered a "safe distance" -- the auto-calculated values are absurd for the space stations I usually build, and make it take literally over five minutes to do a docking that it could do perfectly safely in build 168 in a few seconds.

The new update is working well, even immediately after undocking a ship from the station it'll be using as a relay, thanks much for that fix! I have noticed one little oddity, however... I have a probe sitting on the surface of Minmus with the shortest range antenna, with a relay sat orbiting Minmus with a longer range antenna. When I first switch to the ship, or immediately after an F9 reload, if I run an experiment and select transmit, it takes a while and uses a large amount of power. However, if I first right-click the antenna and look at the range stats (doing nothing else other than looking), then run and transmit an experiment, it goes much more quickly and takes less power. I also have a space station orbiting Mun, and a lander that undocks to go down to collect science. Similar situation: if I undock and immediately run an experiment and transmit, it takes a while and uses a lot of power. If I first right-click the antenna, then transmit the experiment (to the station 8m away), it goes much more quickly and uses much less power. Somehow, the mere viewing of the ranges under the right-click menu improves the performance of the antennae. But, other than that little oddity, everything's working great now. Thanks again.

It's an entirely different kind of flying: all together!

Nice! Just a few problems so far: Tabs continue to appear after set to "Visibility: None". Delay before opening submenu setting is awesome! However, it is not persistent. It would also be nice if it could be set a bit higher, like maybe up to 300? When you create a new tab, it has no subgroups, and when you hover over said tab, a weird, expanding box glitch happens, continuously getting wider the longer you hover over it. Besides that, it's looking really nice, thanks!

Yes, but it's unrelated to this mod; MJ also won't currently display the delta-V for a probe with an ion engine using entirely stock parts.

The more common use case, indeed the one I see quite often, is when I separate from multiple self-destructing parts (e.g. an array of boosters) and they all start spamming the exact same countdown, completely covering the screen, when it would be ideal if just one (if not zero) of them were doing it. I for one would absolutely love some way to get rid of that visible countdown spam, even if it was just a config-file variable rather than a full-on tweakable. Although perhaps a better option would be to stop it from redisplaying the exact same message multiple times, i.e. don't bring up a new line saying 5 seconds to go if you're already displaying a line that says 5 seconds to go.

There is no such file [DERP, there is, I found it, although it's not named exactly that; see below]. If you mean KSP.log, it just contains the same errors that are written to the debug log, albeit with timestamps. [LOG 03:31:16.052] Sending data to vessel comms. 1 devices to choose from. Will try to pick the best one [EXC 03:31:16.055] KeyNotFoundException: The given key was not present in the dictionary. [LOG 03:31:21.547] Sending data to vessel comms. 1 devices to choose from. Will try to pick the best one [EXC 03:31:21.549] KeyNotFoundException: The given key was not present in the dictionary. In this case, I hit Transmit, and when it did nothing, waited five seconds and hit it again, when it once again did nothing (other than yarf up errors into the debug log). Pretty sure it's this mod, it's the exact same behavior the mod used to display when it was coughing up exceptions when you attempted to transmit data when too close to a flag, although no flags are nearby this time, and that bug was already patched. EDIT: Confirmed, same error occurs when no other mods are installed. EDIT2: Oops, I derped -- was looking in KSP_win, not KSP_win/KSP_data. In there I found "output_log.txt", which is logging the stack traces quite nicely. Here's the stack trace from my latest attempt: NullReferenceException: Object reference not set to an instance of an object at AntennaRange.RelayDatabase.getVesselRelays (.Vessel vessel, System.Collections.Generic.Dictionary`2& relays) [0x00000] in <filename unknown>:0 at AntennaRange.RelayDatabase.UpdateVessel (.Vessel vessel) [0x00000] in <filename unknown>:0 at AntennaRange.RelayDatabase.AddVessel (.Vessel vessel) [0x00000] in <filename unknown>:0 at AntennaRange.RelayDatabase.get_Item (.Vessel vessel) [0x00000] in <filename unknown>:0 at AntennaRange.Extensions.GetAntennaRelays (.Vessel vessel) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator12`2[Vessel,AntennaRange.IAntennaRelay].MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[AntennaRange.IAntennaRelay].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[AntennaRange.IAntennaRelay]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.ToList[iAntennaRelay] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.FindNearestRelay () [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.get_transmitDistance () [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.CanTransmit () [0x00000] in <filename unknown>:0 at AntennaRange.ModuleLimitedDataTransmitter.CanTransmit () [0x00000] in <filename unknown>:0 at AntennaRange.ModuleLimitedDataTransmitter.TransmitData (System.Collections.Generic.List`1 dataQueue) [0x00000] in <filename unknown>:0 at ModuleScienceExperiment.sendDataToComms (.ScienceData pageData) [0x00000] in <filename unknown>:0 at (wrapper delegate-invoke) Callback`1<ScienceData>:invoke_void__this___ScienceData (ScienceData) at ExperimentsResultDialog.drawWindowContent (Int32 id) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 Interestingly, same behavior, but different exception this time (NullReferenceException instead of KeyNotFoundException). EDIT3: And with a bit of further testing, I got the stack trace from the KeyNotFoundException: KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[system.Guid,System.Int32].get_Item (Guid key) [0x00000] in <filename unknown>:0 at AntennaRange.RelayDatabase.get_Item (.Vessel vessel) [0x00000] in <filename unknown>:0 at AntennaRange.Extensions.GetAntennaRelays (.Vessel vessel) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator12`2[Vessel,AntennaRange.IAntennaRelay].MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[AntennaRange.IAntennaRelay].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[AntennaRange.IAntennaRelay]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.ToList[iAntennaRelay] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.FindNearestRelay () [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.get_transmitDistance () [0x00000] in <filename unknown>:0 at AntennaRange.AntennaRelay.CanTransmit () [0x00000] in <filename unknown>:0 at AntennaRange.ModuleLimitedDataTransmitter.CanTransmit () [0x00000] in <filename unknown>:0 at AntennaRange.ModuleLimitedDataTransmitter.TransmitData (System.Collections.Generic.List`1 dataQueue) [0x00000] in <filename unknown>:0 at ModuleScienceExperiment.sendDataToComms (.ScienceData pageData) [0x00000] in <filename unknown>:0 at (wrapper delegate-invoke) Callback`1<ScienceData>:invoke_void__this___ScienceData (ScienceData) at ExperimentsResultDialog.drawWindowContent (Int32 id) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0

...and 0.23.5 seems to have broken it. When attempting to transmit from Minmus, with a relay satellite in orbit, nothing happens, and the debug log says: [Log]: Sending data to vessel comms. 1 devices to choose from. Will try to pick the best one [Exception]: KeyNotFoundException: The given key was not present in the dictionary.

It should be noted that they changed the ElectricCharge/XenonGas ratio for the stock ion engine when they quadrupled its thrust. The PB-ION2 in the latest update here is still using the old ratio.