toadicus

smjjames, I'm not sure what happened with the archive you got, but something was wrong in the ToadicusTools packaged therein. Here's a new version that is not wrong: [zip] [tar.gz] [tar.xz] It also has the debug messages no longer printing to the screen. They still go to your log, to help me debug. As always, please provide as much info about reproducing problems as possible, and whenever possible try to duplicate problems with simple assemblies of stock parts -- it really speeds things up for me, and therefore gets fixes to you faster. If a problem ONLY occurs with a mod part, identify that part specifically and again try to reproduce it with the smallest possible assembly. If "smallest possible" is still pretty big, consider sharing the craft file on KerbalX so I can isolate the mods and parts I need. Thanks guys.

smjjames, I'm guessing your exceptions are the result of not using the ToadicusTools bundled with the dev build. I can't be sure of that, because I haven't tested things that way, but it makes sense to me. The words on your screen are just debug code I left compiled in. I noticed that when I played last night; sorry for the noise. cipherpunks, are you saying that staging hung up every time you hovered over an icon in the list in the first case? Can you elaborate a bit on the steps you took that led to that behavior? Also, what is the part in your staging list with the "+" looking In the second case, I see everything working fine a lot, but then sometimes something null winds up in the staging list. I'll look in to that. *edit*: For clarity, when you say "it 'hangs' here", do you mean KSP freezes, or do you mean the staging list gets stuck? *edit2*: In general, please provide as much detail as you can about what you were doing that led to any troubles. I played with this build (more or less) for a few hours and built a big station module launcher and staging never did anything funky the whole time, so I need to know what I need to do to reproduce your steps. Also cipherpunks, I see that you've got a patch that adds ModuleStagingToggle to engines; are you adding it to anything else? Seeing any custom patches for ModuleStagingToggle may be useful. Further, can if you remove those special patches can you reproduce your issue?

jab136, VOID uses VesselSimulator from KerbalEngineer to do all the engine calcs. They're aware of some issues with their jet simulations; a future update should help with stock jets at least; I've offered to help them test with AJE as well. gendalf, I've found and fixed the disappearing stage info window issue. New update with that fix will happen when 1.0.3 releases.

Yes, that's where. Those are "max" values, not nominal values. The official way to change it would be with a ModuleManager patch (definitely do this if you're going to distribute your changes): @TRACKING_STATION_RANGES[*] { @range,1 = 400000000000 } The ",1" is a zero-based index, so that example would change the second entry (Tracking Station Level 2). Non-career games use only the third entry.

jpkerman, I'm still looking to foster a more-directed environment for user-contributed configs for part mods. Hopefully I'll get something moving in that regard this coming week sometime. A part of me really wants to jump in and help you all write configs for all the parts you could ever want to use, but another part of me knows that's a rabbit hole from which one scarcely returns with one's sanity. I've got a couple of ideas for a middle ground; we'll see what happens. On the vessel type thing: my main complaint -- after basic realism -- is that vessel type is arbitrary. You can pick vessel type from the Rename Vessel dialogue any time you please, so it's not so much a restriction as a potential nuisance. Sure, a player here or there (perhaps yourself included) might find it a useful guideline to stick by, but because it's fundamentally arbitrary, I'd just as soon write it in the description and let you take it from there. I think a 5 antenna pool actually works really well, and smunisto's got something good going with that for his Origami patches. Go back a couple pages and check them out; see if you can use some of his rationale to help you with the AIES parts. I don't know anything about the AIES parts or what they look like and do, but if they line up well enough, you could pick three of them to patch the stock parts, and two to be longer range, or some other permutation on that idea. Or you could try to find a 7-part balance! The possibilities are literally endless, and that's the whole problem. I'd like to help, and I'll do what I can. Good luck.

Alright my faithful TweakableStaging testers; here's a dev build: [zip] [tar.gz] [tar.xz] This contains the fixes for ladders and engine fairings I mentioned the other day, and has even more revisions to the logic behind TweakableStaging. I messed around with it for a while this morning and couldn't get it to magically produce extra stages, and in general it felt pretty natural during the build process. Also, it should recognize staging-enabled docking nodes as decouplers now, which might help with building complex craft around decoupling docking nodes.

cipherpunks, that's an issue with KSPAPIExtensions not liking FloatEdits that equal 0, I believe, which has been reported before. A few people have posted workarounds; here's mine: @PART[*]:HAS[@MODULE[ModuleTweakableDecouple]&@MODULE[ModuleDecouple]:HAS[#ejectionForce[0]]]:AFTER[TweakableEverything] { @MODULE[ModuleDecouple] { @ejectionForce = 1 } } @PART[*]:HAS[@MODULE[ModuleTweakableDecouple]&@MODULE[ModuleAnchoredDecoupler]:HAS[#ejectionForce[0]]]:AFTER[TweakableEverything] { @MODULE[ModuleAnchoredDecoupler] { @ejectionForce = 1 } } This should bring their ejection force up to 1 kN, which should not cause that issue. I'm hopeful that KSPAPIExtensions will not be necessary after Squad releases 1.0.3.

Skalou, in general science costs will be about the same in most circumstances. In some circumstances, you might see big changes, depending on specifically how your network is laid out. In general none of the probes you have active should become non-viable. There aren't any mods (that I know of) that do a particularly satisfying job of holding the antennas open. This is because Squad's transmit code manually sets them open and closed, step by step, and refuses to work if it's not in the state it wants. I might replace this code at some point in the future, but at this point I'm still calling it. I'd like to improve some of the documentation and communication for this mod, particularly around user-contributed configs. I've got some ideas, but haven't put anything in motion yet. I'm pretty sure Scansat will work just fine. It follows all the rules and transmits using the best IScienceDataTransmitter on the vessel, which is more-or-less necessarily an AntennaRange module when AntennaRange is installed. smunisto, glad I could help.

cipherpunks, no, AntennaRange doesn't have any multi-mode capability at this point. It's not outside the realm of things I might do in the future, though. ModZero, I offered CaptRobau a config for AntennaRange 1.10 compatibility in OPM, since he already distributes a patch with his mod. But, I happened to see that he's on holiday, so here it is: @PART[commDish]:NEEDS[AntennaRange]:AFTER[AntennaRange] { @MODULE[ModuleLimitedDataTransmitter] { @simpleRange = 800000000000 @nominalRange = 22500000000 } } @TRACKING_STATION_RANGES[*]:NEEDS[AntennaRange]:FOR[AntennaRange] { @range,2 = 6000000000000 }

Mulbin, for right now I'm going to say "probably not". As far as I'm aware that's not a particularly realistic model, and at this point I don't have a way to make more than one antenna transmit and thereby spend ElectricCharge. I'm pretty sure I'd have to overhaul Squad's whole transmission subsystem for that, which isn't currently on my to-do list. smunisto, I took another pass at your spreadsheet; see here: https://docs.google.com/spreadsheets/d/13BxJQrxNytTETv-YluwmPEq6xYcQrNRmy7kxHsYaOOc/edit?usp=sharing I'm pretty sure all the math should be updated to reflect the way the mod works, and I think I've done all the right assignments to get the values that you want out of it. Take a look and see if that helps you out.

CaptRobau, the 1.10 update to AntennaRange necessitates a revision to your AntennaRange compatibility patch. Here's my recommendation: @PART[commDish]:NEEDS[AntennaRange]:AFTER[AntennaRange] { @MODULE[ModuleLimitedDataTransmitter] { @simpleRange = 800000000000 @nominalRange = 22500000000 } } @TRACKING_STATION_RANGES[*]:NEEDS[AntennaRange]:FOR[AntennaRange] { @range,2 = 6000000000000 } Hope that helps!

AntennaRange has been updated to version 1.10! This version implements "additive" ranges, which means that antenna links will be symmetric, and also vary based on the connected relay or the upgrade level of the KSC tracking station, as relevant. This hopefully adds a bit of complexity and a bit more realism. Don't like it? Turn it off! As with most features, Additive Ranges are optional. They're enabled by default, but if you disable them, the old asymmetric system will take over using the new antenna property "simpleRange". The ranges released in this version are: [TABLE][TR][TD][TABLE][TR][TD][/TD][TD]From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]To↓[/TD][TD][m][/TD][TD]1.80E+04[/TD][TD]6.30E+09[/TD][TD]3.70E+10[/TD][/TR][TR][TD]Comm. 16[/TD][TD]1.80E+04[/TD][TD]1.80E+04[/TD][TD]1.06E+07[/TD][TD]2.58E+07[/TD][/TR][TR][TD]Comms DTS[/TD][TD]6.30E+09[/TD][TD]1.06E+07[/TD][TD]6.30E+09[/TD][TD]1.53E+10[/TD][/TR][TR][TD]Comm. 88-88[/TD][TD]3.70E+10[/TD][TD]2.58E+07[/TD][TD]1.53E+10[/TD][TD]3.70E+10[/TD][/TR][TR][TD]KSC1[/TD][TD]8.00E+05[/TD][TD]1.20E+05[/TD][TD]7.10E+07[/TD][TD]1.72E+08[/TD][/TR][TR][TD]KSC2[/TD][TD]2.00E+11[/TD][TD]6.00E+07[/TD][TD]3.55E+10[/TD][TD]8.60E+10[/TD][/TR][TR][TD]KSC3[/TD][TD]2.00E+12[/TD][TD]1.90E+08[/TD][TD]1.12E+11[/TD][TD]2.72E+11[/TD][/TR][/TABLE][/TD][TD][TABLE][TR][TD]|[/TD][TD][/TD][TD][/TD][TD][/TD][TD][/TD][/TR][TR][TD]|[/TD][TD]To↓ From→[/TD][TD]Comm. 16[/TD][TD]Comms DTS[/TD][TD]Comm. 88-88[/TD][/TR][TR][TD]|[/TD][TD]Comm. 16[/TD][TD]<Kerbin Orbit[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Kerbin->Mun[/TD][/TR][TR][TD]|[/TD][TD]Comms DTS[/TD][TD]Kerbisynchronous Orbit[/TD][TD]Jool's Moons[/TD][TD]Jool's Moons[/TD][/TR][TR][TD]|[/TD][TD]Comm. 88-88[/TD][TD]Kerbin->Mun[/TD][TD]Jool's Moons[/TD][TD]Kerbin->Duna[/TD][/TR][TR][TD]|[/TD][TD]KSC1[/TD][TD]Low Kerbin Orbit[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin SOI[/TD][/TR][TR][TD]|[/TD][TD]KSC2[/TD][TD]Kerbin->Minmus[/TD][TD]Kerbin->Duna[/TD][TD]Kerbin->Jool[/TD][/TR][TR][TD]|[/TD][TD]KSC3[/TD][TD]Kerbin SOI[/TD][TD]Kerbin->Jool[/TD][TD]Kerbin->Eeloo[/TD][/TR][/TABLE][/TD][/TR][/TABLE] If you use a custom patch to support your favorite part mod, this patch might help to bring it more in line with the default AntennaRange behavior. It also might really not. The best option is to offer the author an update to the patch in question! { @MODULE[ModuleLimitedDataTransmitter] { simpleRange = #$nominalRange$ @nominalRange /= 3221 } } @PART[*]:HAS[@MODULE[ModuleLimitedDataTransmitter]:HAS[!simpleRangenominalRange[>99999999]]:NEEDS[AntennaRange]:AFTER[AntennaRange] { @MODULE[ModuleLimitedDataTransmitter] { simpleRange = #$nominalRange$ @nominalRange /= 6 } }@PART[*]:HAS[@MODULE[ModuleLimitedDataTransmitter]:HAS[!simpleRangenominalRange[<100000000]]:NEEDS[AntennaRange]:AFTER[AntennaRange] CHANGELOG: v.1.10 [2015-06-13] * Now supports "additive" ranges! Relay links will now be symmetric by default, and range limits will vary based on the connected relay or level of KSC's tracking station. * Various optimizations throughout to reduce perfomance drop due to large relay networks.

I'm interpreting "the only add-on that I am currently running is DebrisFix" as meaning "I don't have AntennaRange installed." Stock doesn't have an experiment named "sciencelab" and AntennaRange doesn't add one. Wherever that message is coming from, one of my mods is not causing it, at least not directly.

mcalisi, as helpful as I'd like to be, if you're not using my mod I'm not sure how I can help you. I can tell you that there is not a stock experiment definition for "sciencelab", so I'm guessing (just guessing, though) that you have some other mod that is broken and/or installed incorrectly. As smunisto says, you should probably have a look at the Support (Modded Installs) forum. Good luck!

That might also be something that Throttle Controlled Avionics (Continued) could help you with, depending on just what you're trying to do. In terms of a really simple addon that does nothing but add action group entires for throttle control... that is something I could write, and I could make it dynamic so there wouldn't need to be 20 action group entries per engine; you could essentially set the thrust limiter, click "convert thrust limit to action group" or something like that, and -- hey presto -- new action group in the menu. If that's something in which there is broad interest, I could potentially be persuaded to make a modlet for it.

Update: TweakableJettison is "fixed", in that it now protects itself more aggressively against inconsistently-configured parts. Those two NovaPunch parts, for example, have ModuleJettison modules, which claim we'll find a jettison fairing transform in the part model called "fairing", but no such fairing exists in the part model. That's not something I can change; the fix on my end is to disable TweakableJettison when I find cases like it. TweakableLadders is fixed, and is no longer backwards in the editor. Hopefully another weekend update if I can get a chance to look at TweakableStaging before then.

smunisto, fixed the KSC ranges for you. Since your 90-09 was already set up to self-balance itself based on the nominalRange you wanted, it did so. The Farseer might need to be redone manually. Sneaky Edit: Dun dun duh...

smunisto, I'm sorry, the ranges in my spreadsheets and configs for the KSCs are actually the maximum ranges, not the nominal ranges. So all of your calculations are high by sqrt(sqrt(8)). That's my bad; I didn't properly inform you about that, and wasn't consistent enough to cover the gap. Kerbas_ad_astra is also right; the maximum range to KSC tooltip in the editors is wrong. Fixed now by commit #84925a48.

Svm420, you'd need to write a mod to handle the conversion of one resource to another during the fill stage. A way to handle it entirely within the mod would be for me to fix module selection so you could change what propellent is used by the EVA thrusters to nitrogen. Then you could also change the resource storage to nitrogen, and tell it to fill from a pod. Actually, you might be able to do that already, if in fact the resource used by EVA thrusters is a configurable property of Squad's module. I'll have to look in to that. As I recall, last time I investigated the API and the EVA part behaviour, Isp is not a configurable value of Squad's module. I'll check on that again while I'm looking into the above. Sigma88, no it's not. There's no config-time awareness of game saves, etc. That also doesn't make a ton of sense to me; in general it seems like it would be a better idea to write a module that could be applied to the EVA parts in any event, and then alter the behavior of that module based on the tech nodes, career/sandbox mode, building levels, or what-have-you.

OvermindDL1 and smjjames, thanks. I'm guessing it's a "late start" issue, where something that LateUpdate (which usually only runs after start) hasn't finished starting yet, which happens sometimes in heavily-modded installs. It might also be that the NovaPunch parts are using ModuleJettison in a way that Squad does not, and I'm not anticipating. I'll try to dig in to that this weekend. Kerbas_ad_astra, thanks for the patch! I'll look in to the "nothing's in staging" issue; I have a guess as to what's going on. Neutrinovore, I vaguely remember something about ladder animations being backwards back when I first wrote TweakableAnimateGeneric. Maybe I un-backwardsed it in the 1.11 release when I rewrote the animation stuff. I'll look in to that as well. In general regarding TweakableStaging: I'm going to try a couple of things to maintain "smart" staging behaviour that adds stages for disabled parts that have "fallen off" the bottom of the list as you've worked when you re-enable them, without adding stages when we don't need them. If it doesn't work, though, I'm going to just stick them on the bottom and you'll have to re-sort things yourself.

EVAManager only adds and changes modules to/on the EVA Kerbal "part". If someone wrote a "pack all chutes" module, they could use EVAManager to add that module to EVA Kerbals to enable its use. On its own, EVAManager provides very little user-facing functionality.

Miravlix, sorry if I misunderstood the tone of your previous post. Let's see how the next version works out; as was said, it should have the side effect of making relays prefer Kerbin much more often. It's still not always going to prefer a 200× longer connection, but it will sometimes. I really like how the dev build feels. But if you want something specifically different that can't be accomplished by customizing the ranges (it probably can be), I could potentially put in an "always prefer Kerbin when available" toggle. But, that's going to have some effects that I think many people (myself included) won't want; like all of your Jool moon satellites using a really slow connection back to Kerbin instead of the high speed relay network you put in orbit, just because they can. There are a couple of other options we could explore, as well. BUT, let's give that a couple of weeks. I'll be releasing the new version with the geometric ranges soon; give that a week or two, play with some numbers in your cfgs, and then bring this up again. Glad you like it, MrBonobo! Also glad MeCripp could help you out with those patches. Note that all custom patches are probably going to need to be redesigned a bit when the new version comes out. I may offer a little "hotfix" patch that tries to identify parts patched by obsolete patches and do some simple math to avoid them being broken and maybe try to help out their ranges a bit, but especially short-range patches (like MeCripp's) will want some revisions. Just a side note; if I ever provide official patches for compatibility with other mods, I'd like it to be in collaboration with those mod makers. In the meantime, I'd like to provide a more useful venue for user-contributed patches to be found, where users can help curate the collection. Maybe I'll set up a wiki at my github repo for such a use, where users can collect links and add comments like "outdated" or "long range" or "short range" or something. We'll see!

OvermindDL1, what are the "base and building phases"? Please provide a full log after a run of the game that exhibits the problem. Thanks!

One more dev build: [zip] [tar.gz] [tar.xz] I consider this a "release candidate". It has no meaningful changes from yesterday's build, but should now correctly report useful ranges in tooltips in the editor and R&D while using additive ranges. I'm holding back a release pending vardicd's next report and a day or two of report-free testing of this build.

Kerbas_ad_astra has given a true and accurate reporting. Relays are picked to maximize cheapness for the live vehicle. That's intentional and will not change, because you the player are looking at the live vehicle right now, and one of the primary intentions of the mod is to offer you a tangible reward -- a savings of your real time -- for building a network where things are close enough for you to get cheap connections. In the live build, that's determined strictly by proximity. The closest viable relay is your target, period. In the dev build, link ranges to different targets may differ, and the "maximum range" to Kerbin will pretty much always be much higher than the "maximum range" to another target. The "cheapest receiver" is then picked based on the minimum proportion of current distance / maximum range. Since your maximum range to Kerbin is much larger than your maximum range to other things, Kerbin will be preferred much more often than it currently is. That said, if something is literally 200,000 times closer to you than the surface of Kerbin, as you describe... it's probably going to be cheaper. Now that you hopefully understand the functionality, if you'd like to calm down and make a feature request and a reasoned case as to why I should consider it, I'm always happy to listen.