toadicus

Give this a try: http://toad.homelinux.net/KSP/TweakableEverything/TweakableCrossFeed.dll I haven't tested it at all, but it's literally just the crossfeed code stripped out of TweakableDockingNode, so it should work as well as that does. As I said, I'm not adding this to any parts myself, but if you want to use it you can write ModuleManager patches like this: // Change <myPartName> to the "name" field of the part to which you're adding the module, e.g. for the Modular Girder Segment, <myPartName> should be replaced by trussPiece1x. @PART[<myPartName>] { MODULE { name = ModuleTweakableCrossFeed // If you want crossfeed to default to off, uncomment the line below. // fuelCrossFeed = False } } Edit: One bit of cautionary advice: fuel crossfeed in KSP is some dark arcanery. In general, this should prevent fuel from passing through a part when it's set to disabled. But fuel flow follows a lot of weird rules about attach nodes and orientation and who knows what else, so it will not cause fuel to flow across a part that would not normally conduct fuel in its stock behavior.

Sure, I'll change that right now. I'm also considering an addition to the HUD elements that might include vessel mass, burn times, etc., based on the KER thrust calculations. Yes, the HUD windows can be unlocked in the configuration menu. Click on the VOID icon on the toolbar (or the standalone button) and open the "Configuration" window. In that window, look for "Unlock HUD Positions".

My guess is that something in one of the realism kits removes a ModuleRCS from a part that had it previously, after TweakableRCS has already added its helper module. The "right way" to fix this might be to look into the new ordering options in ModuleManager 2.0, but since adoption on that has been slow so far as I can tell and I really have no idea how all the realism stuff is tracked or applied, here's a DLL that should just make TweakableRCS fail more gracefully when it's on a part with no RCS modules. Let me know if that does the trick! Also, if you're not using the TweakableRCS functionality, you can remove it entirely without removing the rest of TweakableEverything: just delete or relocate TweakableRCS.dll and TweakableRCS.cfg from the TweakableEverything folder. On the crew capacity tweak: Short version: I don't think it's going to work in this context. Long version follows: CrewCapacity is tracked in each partPrefab (the set of "master" information read in from the GameData folder when the game is loaded used to create each Part instance during play), in each Part (the combination of prototype and prefab information that makes up a unique instance of a part as represented during play), and in the Internal model. In flight, the latter two are used. If the part reports a small crew capacity, Kerbals will be refused admittance even if the internal model is filled. On the other hand, if the part reports a larger capacity, the internal's seat count will dictate the refusal. This is straightforward to deal with, if it's what I cared about. I can tweak the part's field directly, and can remove and add seats from the internal model's data structure. Unfortunately, in the editor, automatic crew filling is governed by the prefab data. This means that in order to change the way the crew filler behaves, I have to change the prefab. This is undesirable: because the prefab is the "master" data for all future instances of the part, and because the editor does not entirely start parts up the way flight does, changing the prefab has very extensive interactions with future instances of parts. I've found suitable places to reset the prefab value, but it still produces behavior that IMO users will find confusing or unacceptable. Just because I can do something doesn't mean I should. The more I think about it, the more I think that the right way to do this is to use a partless plugin that just gives a "Disable automatic crew assignment" toggle in the editor; on the Toolbar or near the crew assignment button, perhaps. From there the process should be simpler; if I don't care about assigning specific values, I ought to be able to deal with the problem from a different perspective.

Yes; it's a tweakable like everything else here. It should default off, and you can turn it on and off by right-clicking on the port and toggling "Decoupler Staging".

The functionality in TweakableDockingNode is currently only applicable to docking nodes. I've tried to keep it from making a mess of things if you add a ModuleTweakableDockingNode to non-docking node parts, but it might, and it probably wouldn't do anything. I misunderstood your request the first time around. I certainly could build a tweakable to toggle crossfeed for all parts everywhere, but I don't think I'd want to distribute it with the mod as an official component, because it'd kinda make a mess of things. But I'll try to make time to whip something up that you can apply to parts at your own discretion (i.e. via your own ModuleManager configs).

Quick update: I've got some quality-of-life improvements to the docking node decoupler staging thing. I've implemented ArcaneZedric's attach node fix. I've added some special handling that should fix the FAR problem with TweakableEngineFairings. Haven't started on Tʜᴇ Cʟᴀᴡ yet, but hope to get to it this weekend. Looking into the crew capacity tweak. I think there may be a way to make it work and my basic idea right now is this: the tweakable will only affect the value of CrewCapacity in the editor; in flight it will revert to the original value. This should have the effect of preventing the editor from over-filling your pod, while still allowing you to fill it as desired once the flight is active. I mean, hopefully. If everything goes as planned. For working the other way: enticing the editor to fill parts other than the primary pod, I'm not sure yet. At this point that's all locked up in the EditorLogic around launching and drawing the crew selection dialog. If I can find an event or lifecycle function that sneaks in to the right place, I might be able to make something work provided you have sufficient Kerbals on staff. Looking into flags. I need to mess with some ideas, but I've got a couple and at least one should work. Worst case I can probably give flags three new event buttons for EVA Kerbals: reset to due north; rotate 15° clockwise; rotated 15° counter-clockwise. Best case I can hopefully get a slider on the flag itself that lets you pick the heading directly.

Looks like they are (straight out of the code): line += "Mission Elapsed Time (s);Altitude ASL (m);Altitude above terrain (m);Orbital Velocity (m/s);Surface Velocity (m/s);Vertical Speed (m/s);Horizontal Speed (m/s);Gee Force (gees);Temperature (°C);Gravity (m/s²);Atmosphere Density (g/m³);\n"; The first thing I note is that it could use the primary body indication. Also, a few of the items are slightly wrong (mostly just true altitude). It seems like some engineering data might be good, too?

Intriguing idea. I'm not sure how well that would work though. I suspect that from a gameplay point of view it might be difficult keeping track of what docking ports are compatible.Something else might be in the work though. Stay tuned. As Cpt. Kipard hinted, we've developed a plugin to handle the universal docking ports so no one need settle for such a "poor man's" solution. The tweakable idea had occurred to me as well, though! Ooh, good find! Thanks, I will test this and get it into a new version Soonâ„¢. At present no; there's no functional granularity available below the module level. I'll look into the possibility of adding a config file to disable tweakables that you don't want, but I'm not going to break the functionality out into an entirely separate module.

Hmm, I'll have to think about a meaningful way of locking down the precision. It can certainly be done, but I'm not sure what the best way to present it would be. Did you know that you can vary the precision manually by right- and left- clicking on data items with a little superscript "i" next to the label? Does that help any? Hmm, I'll look in to building a little toolbar submenu for the other functions. I personally don't love the idea of making half a dozen extra icons... but if I can find a way to make it easy and optional, I'll try to accomodate. I would like to revisit the editor elements in general. Consider that on the "to do" list. Glad you like it! Yeah, the data logger is still old legacy stuff, which I really haven't paid any attention to because when I asked for input on it I got no response. What would you (and anyone else) like to see in the data logger to make this a useful function? VOID is not a complete replacement for KER in the editors. Since I cybutek was gracious enough to lend his code to VOID's engineering portions, I have taken it on myself to avoid competing directly. The stage-by-stage display and configurability of planet / moon and atmosphere, for instance, are not implemented in VOID. It tells you stats for the whole vehicle and the last stage only, relative to Kerbin's surface gravity, with no atmosphere, since that's how most delta-V statistics are published. I think that VOID should be generally conflict-free with Padishar's KER builds. It may be desirable to remove the VesselSimulation and Engineer.Extensions libraries from the VOID folder if you're using both, but honestly I haven't tested that.

The AdaptiveDockingNode cfg does add some functionality to the stock ports, but as written it does not add additional compatible sizes, since that's inconsistent with the stock behavior and the models look a bit wrong for it. But it's just a config file; if you want to change it, just add more sizes to ValidSizes, comma-separated. Glad to be a part of the team!

The short answer is no. Slightly longer: all of the code that decides how thrusters respond is locked up in Squad's methods, so to manipulate the way thrusters thrust, I'd need to reimplement some significant portion of the module, which is out of scope here. Sorry!

Looks to have fixed it!

Looks to have fixed it!

I'm not sure what's going on here, but it's definitely to do specifically with adding the attachment node to the part. I don't have a fix yet, for a workaround until I do, edit TweakableDockingNode.cfg and comment out these lines: // node_stack_tdn = 0, 0, -.671, 0, 0, 1, 1 ... // @MODULE[ModuleDockingNode] // { // %referenceAttachNode = tdn // } ... // TDNnodeName = tdn // AlwaysAllowStack = True So the dockingPortLateral section should look like: @PART[dockingPortLateral]:Final { // node_stack_tdn = 0, 0, -.671, 0, 0, 1, 1 @MODULE[ModuleAnimateGeneric] { %startEventGUIName = Open Shield %endEventGUIName = Close Shield } // @MODULE[ModuleDockingNode] // { // %referenceAttachNode = tdn // } @MODULE[ModuleTweakableDockingNode] { // TDNnodeName = tdn // AlwaysAllowStack = True deployAnimationControllerName = dockingporthull } } That will disable the attachnode functionality of TweakableDockingNode and allow the part to be placed. I'm looking into a fix, but it's not looking trivial at this point. Crew handling in KSP is fueled by dark magic. Tweaking numbers is easy, but changing auto-fill behavior is probably not. I'll look into it, though!

I've actually posted on this issue some before, but here's a quick summary of my current thoughts: In general, Squad's game rewards play by enabling the player to voluntarily raise the complication level. There's no reason to build a communications satellite or a space station or an airplane in the stock game, but if you want to and think that's fun, go for here and take their blessing. AntennaRange was conceived -- again, in general -- under a similar mindset. Honestly, I wrote the first versions specifically because if I didn't have a rule making me use the bigger communication pieces, I'd never do it, and I think it's a shame that the base game doesn't have any system for enforcing that. That said, I wanted AntennaRange to be primarily rewarding, not punishing; that is, I want the player to feel like the efficiency of their space program has been increased by using the parts "right". That's why the parts feature a data speedup when you're below the nominal range; it is literally a real-time reward for playing the game in the way that I (personally) think is more realistic and more fun. The relay feature was intended as a continuation of this philosophy. If people don't want to build a relay network, and just want to send Communotron 88-88s everywhere they go, that's fine. But if they do, they get rewarded: expensive data transmissions from the surface of Eeloo can happen almost as quickly as if you were in low Kerbin orbit. In my opinion, this allows for and (I hope) fosters creative design in your spacecraft and space programs, without explicitly requiring people to spend a lot of real time setting up complicated communications networks in the name of realism. Now, with all this in mind, I've left these values configurable for a reason, and using ModuleManager (with thanks once against to (the awesome) Ialdabaoth and sarbian) affords a lot of flexibility in how we move things forward. When I was looking over the AEIS parts it occurred to me that it might be a lot of fun to talk to carmics about distributing his antenna parts with some custom AntennaRange configs as an optional "hard mode" pack. I'm also very interested to hear thoughts from those interested here: what do you think should be the "next step" for AntennaRange? As a qualifier: I've said before and will say again that I'm not interested in developing a comprehensive replacement / substitute for RemoteTech. Sounds like I need to revisit the sequence of events that follow a "Transmit Now" click from an experiment dialog.

Done. I can definitely do the action group item, and can almost certainly allow you to tweak the claw opened and closed in the editor. I'm not sure about adding an attachment node as I have with the shielded docking ports: for docking ports, Squad's code already assumes that docking ports should be able to "start docked", and has a special provision built into the state machine to handle such an eventuality. If that's not the case for Tʜᴇ Cʟᴀᴡ, then anything I could do would be contrived and hacky, so I probably wouldn't release it. I'll look into it, though. Arrowmaster has the right of it; no credit here. Definitely a cool feature though! So, I'm still not 100% clear on what happens when Squad's code loads a part with a module it can't find, but I believe it fails fairly nicely. So, while I don't think your craft would fail to load on a stock install, the fairings would likely still exist. To my understanding of the way KSPFields work, there's no way around it in this case. Well... that's not OK. I'll look in to it. If you can get me your debug log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux (& Mac?): ~/.unity3d/Squad/Kerbal\ Space\ Program/Player.log) after a run of the game that exhibits the problem, that would help me target my testing.

Thanks for sharing, MeCripp. The default ranges are the way they are because originally I had no relay options and Squad only provides three antennae, so the range spans were necessarily large. Since AntennaRange is a "stock improvement" mod, I need to keep the default values pretty similar to what they are now. That said, I encourage interested parties to try out your configs for other mods! Increasing antenna diversity is definitely within the spirit of AntennaRange.

It looks like this is actually an issue with the way Simple Part Organizer fetches Module names. I've given Felbourn a detailed report:

Felbourn, I got an incompatibility report from one of my AntennaRange users, and it looks like the bug is maybe sorta on your end. In looking at his log and through your code, I'm pretty sure the issue is line 440, which trims the "useful module name" out of, effectively, PartModule::ToString(). AntennaRange overrides ToString and includes no parentheses, so your Substring is looking from 0 to -1, which is Exceptional. Seems to me it would be easier and safer to use PartModule::moduleName, which should save you most of the trimming and avoid issues with modules that override ToString(). Let me know if / how I can help!

In a similar vein to MeCripp, let me (try to) teach a man to fish. An AntennaRange entry in an MM file should look like this: @PART[<yourPartNameHere>] @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter // This is the distance from Kerbin and/or another relay at which the Antenna performs exactly as designed by AEIS/Squad/Whoever // When outside this range, the power requirements will increase up to maxPowerFactor times. // When inside this range, the data capacity will increase up to maxDataFactor times. nominalRange = <your nominal range here> // This is the maximum amount of power increase the antenna can do at long range. In effect, this manipulates the maximum range. MaximumRange = nominalRange * sqrt(maxPowerFactor) maxPowerFactor = 8 // This is the maximum amount of data speedup the antenna will do at short range. This will be reached at IdealDataRange = nominalRange / sqrt(maxDataFactor) // Below this range the antenna will continue to function ideally. maxDataFactor = 4 } } So, suppose you felt like the CommTech EXP-VR-2T should be useful within 2 AU, which would get you coverage throughout Kerbin, Eve, and Moho's orbits, and sometimes up to Duna (when it's not near opposition). That part would look like: @PART[Antennaexpatvr2] @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter // This is the distance from Kerbin and/or another relay at which the Antenna performs exactly as designed by AEIS/Squad/Whoever // When outside this range, the power requirements will increase up to maxPowerFactor times. // When inside this range, the data capacity will increase up to maxDataFactor times. nominalRange = 9616539270 // This is the maximum amount of power increase the antenna can do at long range. In effect, this manipulates the maximum range. MaximumRange = nominalRange * sqrt(maxPowerFactor) maxPowerFactor = 8 // This is the maximum amount of data speedup the antenna will do at short range. This will be reached at IdealDataRange = nominalRange / sqrt(maxDataFactor) // Below this range the antenna will continue to function ideally. maxDataFactor = 4 } } Hope that helps! If you do get a full set of configs done I'd be interested to see them.

Assuming you had it installed previously in order to assign the action, but then uninstalled the mod and loaded up the craft: I'm not 100% sure what all would happen, but I do know for certain that it wouldn't "control from here" when you pressed the action group. My hunch is that it would fail quietly enough that nothing bad would happen. But, I don't know exactly how actions are read in from the save file or what sort of protections are in place when the module they need is missing; it could go as wrong as failing the load halfway through your ship and loading up a partial craft and then autosaving over your persistence file. My advice? Make a backup of your save, then see what happens! It's the Kerbal way!

TweakableEverything has been updated to version 0.6.6! This update adds a toggle for engine auto-shrouds and an optional staging entry for the docking port decoupler action. It's also still just as compatible with 0.23.5 as the last version! CHANGELOG: v.0.6.6 [2014-04-04] * Added TweakableEngineFarings! Now you can disable autoshrouds for engines as you see fit. * TweakableDockingNode: Added Decoupler Staging toggle. This tweak allows you to active the "Decouple Node" action of a docking node via staging, which should be useful in disengaging LES towers during a successful ascent.

It's update time! And minor version changing time! This update brings 0.23.5 compatibility and improves the breadth of the engineering code using Padishar's experimental KER simulator. CHANGELOG: v.0.10.0 [2014-04-04] * API update for KSP 0.23.5. * Integrated [URL="http://forum.kerbalspaceprogram.com/threads/72062"]experimental KER simulator[/URL] by [URL="http://forum.kerbalspaceprogram.com/members/100092"]Padishar[/URL]. * Improved configurable-precision display for values smaller than 1.

It's 0.23.5! Update time! Major version time! This update brings full 0.23.5 compatibility, solves the last big problem I'm aware of around relaying, and improves relay search performance by several times. CHANGELOG: v.1.0.0 [2014-04-04] * Recompiled against KSP 0.23.5 for compatibility. * Major Surgery on relay-searching code to improve performance and reliability. * Added new event-listeners to improve relay behavior around vessel-changing events like undocking.

Taranis, would it be possible to fix the "time remaining" values to incorporate the influence of recyclers? It'd be really useful for planning long missions to have an at-a-glance look at how long you really have, considering something like 80-90% of your resources will be recycled. Thanks!