toadicus

No worries: all these new features are abd will always be optional.

The AntennaRange restrictions on line of sight and probe control are independently optional. I have the same feelings as you do regarding probe control, and don't use that limitation in my own career save. The Toolbar button in the space center will pop up a configuration window and let you set those options. I have intentionally not required a relay back to KSC specifically because, in my view, it's a rather baseless restriction. Back in the days of the first manned spaceflights, NASA was not dependent upon space-based infrastructure to talk to their pilots, but also had more than a 10 minute window to do so while they whizzed over Texas every hour or two. They used surface-based infrastructure to effect these early communications. The Apollo missions going all the way to the Moon also used surface-based infrastructure. IMO it's unreasonable to assume that the Kerbals do not have similar capacities even at the very start of a career save. Were I to add such a limitation, I probably would actually not allow any artificial point on Kerbin to act as a relay. Instead, I'd require that an antenna be installed suitably close to KSC as "the KSC relay", and thus require the player to develop every single point of communications infrastructure -- even the "home base" antenna. But, IMO, that is not a fun or interesting requirement. Sending suborbital missions comprising an antenna on a parachute isn't challenging enough to be a fun task, and doesn't really contribute to the development of a meaningful skillset in terms of gameplay. If it's not well-founded in the "reality" of the game world, isn't fun, and isn't educational, it's just busywork for its own sake. I welcome discussion on this topic. Maybe there is a right way to make building a short range communications network in the early game a good addition! I encourage you (and anyone else) to recommend and defend an implementation that meets at least two of the three criteria above: grounded in reality, fun, or educational. I don't know all the ins and outs or disabling RemoteTech2 (having never used it myself), but my supposition would be that in order to convert a career save from RT2 to AR, one would need to: Make a backup of your entire persistence folder (/path/to/KSP_platform/saves/<yourSaveNameHere> Remove the RT2 dll and other plugin files. The Textures subfolder and MM patches (root-level *.cfg files) can probably be removed as well. The RT2 Parts subfolder needs to stay or you will lose active flights. MeCripp has published a set of MM patches for converting RT2 parts (and many others) to AntennaRange relays. You might ask him if this is the latest, but the last link I saw was back here. To this and the recent presentation conversation: I've got a few thoughts on adding some network-level presentation. Nothing firm enough to implement yet, but I'm mulling it all over. If anyone has further thoughts on the topic I would welcome them.

OK, I've just finished some launchpad testing with TweakableEverything, ModuleManager 2.1.2, HotRockets R7, and Final Frontier 0.3.9, with no ill effects. Let me know if MM 2.1.2 fixes the issues you've been seeing with TweakableEverything and MM 2.1! If not, the usual request for debug logs (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) stands.

Poke made: http://forum.kerbalspaceprogram.com/threads/59005?p=1149408#post1149408 Thanks!

@rbray89, consider yourself poked. . Thanks for the great mods!

Does "mess with" mean "break forever" or "do changes to avoid breaking forever, but might not be working at 100% yet so be careful because forever-breaking remains within the realm of possibility until suitable testing has occured"?

It's going to be until late today before I get a chance to do any testing (I must confess, I actually played the game a little this morning... my bad!), but one thing I noticed is that HotRockets is packaging ModuleManager 2.1, which is going to be after the next MM release fixes some persistence-breaking issues. I haven't done any testing of TweakableEverything with 2.1 and from my read of a conversation between NavyFish, swamp_ig, and sarbian, I'm pretty sure TweakableEverything is currently being used as a test case for debugging MM 2.1. In short: I officially recommend that you DO NOT use MM 2.1 with TweakableEverything until I've had a chance to test with it. Do you have the same issues with HotRockets if you use MM 2.0.7 or 2.0.8 (included in the TE archives)?

I don't actually know; I was at work when I compiled the fix and haven't got back to my computer to test it at all. That is what I hoped it would do, but I'm not certain it will. If you've tried it, maybe you can tell me! There is a lot going on in that log... Final Frontier is making a lot of noise during startup , and Protractor has some issues before the main menu as well. I've also never seen mono.DLL and Assembly-Csharp.DLL throw exceptions on load... I'll try a couple of the mods you've got that I don't and see if I can make something stick. I've been wanting to try hot rockets anyway.

So, I've taught myself, generally, how to draw pretty lines. The next hurdle in this particular area comes from this: Right now, if a relay isn't used in helping the active vessel phone home, I maintain the bare minimum amount of data on it. If a relay is on a vessel that's too far away for any of the antennae being used in our path back to Kerbin to talk to it, I don't maintain any information on it at all. Also, relays don't store any information at all about what relays they could have used, but aren't because they're not the best choice or can't because those relays can't make a path home. So, in terms of pretty lines, I'm left with two basic concepts: Draw pretty lines only for the path back to Kerbin. In my view this is not very useful. Pretty lines that show you how you're getting home don't really tell you anything you don't already know: a path exists back to Kerbin. In all likelihood, you can intuit this path: "well my lander has a whip antenna and it's going back to the medium dish antenna on the drop ship which is going back to the long range dish on the mothership, which is either going straight back to Kerbin, or happening to hit that satellite I left at Duna that one time." The important information -- that a path exists -- is a given and the "how" doesn't seem very useful to me. "Why not?" is a much better question, but as I mentioned above I don't store any information that would help generate that graph. Run an independent behavior just to model the whole network and draw it on the map. This has two possible drawbacks. The first and most obvious is that I haven't already done any of this work and I would need to invest time in it. Second, it might come with a performance hit. I've tried to optimize and cache as many of the queries as I can, but part of that optimization is intentionally ignoring things I can afford to ignore. So, what is it that you guys are looking for? What makes a useful pretty-lines system?

In my view, the primary failing with that concept is the lack of a change to maxValue on the tweakable. I've found it very hard to use tweakables with more than about 20 steps. The resolution is just too fine; a tiny movement of the mouse goes several steps. If all you're changing is the stepIncrement, you can get really fine control, but you'd need a $90 mouse to actually use it. If I'm right in guessing maxValue as the primary driver for redrawing the action menu, tweaking it has the same problem as adjusting it in logic.

You, sir, get a cookie. edit: damn, that's a big cookie

Obsessed, I've looked over your log and I'm not certain TweakableEverything is causing your problem. It is causing those hasAncestorPart messages, and if you want to see if properly gating those calls helps anything, here's a fixed TweakableStaging dll that will avoid calling hasAncestorPart when it catches an event with bad data or the part hasn't finished starting up properly. If that fixes your issue, color me surprised. I'd be more concerned about the NullReferenceException spam around EditorLogic.CheckSymPartsAttach(), which doesn't happen until later on and I'm guessing (just guessing) that it is happening when you pick up those pistons and dance them around to show off the bad frame rate for the video. Since no mod is directly implicated in that -- it's not happening during a mod call, and there's no mod error right around it, and all of your parts have been started for a few seconds already as evidenced by the KER "Total simulation time" spam -- it's really hard to even guess why that might be happening.

As for the Min/Max not showing up for the Pistons. It's because it isn't set up yet to handle anything that isn't a rotateJoint. It's currently working as it should. <sheepish>That's me. TweakableStaging is responsible for that noise. I noticed the same issue yesterday trying to copy a bunch of radiators around. It is officially on my to do list!</sheepish>

Alas; were it so easy, I would have done it already. The problem isn't that I can't get it done for a reasonable amount of effort without making the UX terrible... the problem is that I can't get it done for a reasonable amount of effort at all. It's a request I'm well aware of, and when the time comes, I'll let everybody know. Hmm, should be simple enough. I had been using the Squad values as "minimums", but I could probably add an option.

You probably have another mod installed causing an incompatibility. Can you get me a copy of your debug log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux (& Mac?): ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log)?

The exception I'd make to that is that right now, DeadlyReentry is shipping MM2.1. Personally, I'm not unpacking that until newer versions of MM fix the issue.

I'm reasonably certain you could design a UI_FloatRange tweakable to have such variability in its resolution. Here's some code that would get close; be warned I'm just typing this into the forum from memory so I may have some names or syntax wrong. float bigStep = 02.f; // Because that's what's in Zodius' graphic float smallStep = 1f / 30f; // Because that's what's in Zodius' text /* * Probably useful to have an extension method like uiControlCurrent here, or at least * some logic to grab uiControlEditor if we're not in flight. */ UI_FloatRange myScaleTweakable = this.Fields["myScaleField"].uiControlFlight; if (this.myScaleField <= 1f && myScaleTweakable.stepIncrement == bigStep) { myScaleTweakable.stepIncrement = smallStep; myScaleTweakable.maxValue = 1f; } else if (this.myScaleField >= 1f && myScaleTweakable.stepIncrement == smallStep) { myScaleTweakable.stepIncrement = bigStep; myScaleTweakable.maxValue = 5f; } Now, UI_Control member updates aren't always drawn to the action menu right away, so it's possible that this wouldn't happen until the context menu was dismissed and recreated. You could probably force a dismissal, but I don't know specifically how.

My modules aren't even on the parts in those screenshots; that "locked" indicator is just the normal status of the ModuleAnimateGeneric. Do you have two copies of ModuleManager lying around by chance? Its election process was disabled recently. If not, something else is up. I'd need a log to know more.

I haven't tested any of my mods with MM 2.1 yet, and since it's currently savebreaking I don't really plan on going that direction until a future MM release fixes the savebreaking, enough time passes that breaking saves isn't a big deal, or some update to MM and other mods that use it makes such an upgrade necessary. Too, I know that NavyFish is actually using TweakableEverything as a test case to help swamp_ig and sarbian debug the next MM release. I wouldn't be too surprised if MM 2.1 breaks this mod or your save game.

So that's something that I've looked into here, and also for TweakableEverything, and the basic answer is "really really". Squad's ModuleDataTransmitter actually checks the animation state to be sure it is where it should be. If I prevent the antenna from retracting after a transmission, the antenna never works again. To do it right, I'd need to complete re-implement the transmitter. That's something I've considered doing for a few reasons... but at this point I'm not going that route.

I need to know a little more about what you're trying to do. Are you using your AntennaRange cfg file in place of or in addition to mine? Are you trying to change the stock animation behavior? If not, is the stock animation behavior broken with my cfg? The Squad part cfgs already assign DeployFxModules = 0 for longAntenna and CommDish, and additionally ProgressFxModules = 1 for mediumDishAntenna. Your cfg is assigning them again without an operator, so you are adding an additional value which the Squad code is unlikely to ever look at. If you're trying to change those values you should be using @ or %, since the definition already exists, e.g. @PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 1500000 maxPowerFactor = 8 maxDataFactor = 4 [B]@DeployFxModules = 0[/B] } } However, that is not necessary; Squad's code already has DeployFXModules = 0 defined so such a line is literally just clobbering the value with the same number. I just tested my cfg on a relatively mod-light install with both of these cfgs: @PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 1500000 maxPowerFactor = 8 maxDataFactor = 4 } } @PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 30000000 maxPowerFactor = 8 maxDataFactor = 4 } } @PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 80000000000 maxPowerFactor = 8 maxDataFactor = 4 } } @PART[longAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { %MODULE[ModuleDataTransmitter] { %name = ModuleLimitedDataTransmitter nominalRange = 1500000 maxPowerFactor = 8 maxDataFactor = 4 } } @PART[mediumDishAntenna]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { %MODULE[ModuleDataTransmitter] { %name = ModuleLimitedDataTransmitter nominalRange = 30000000 maxPowerFactor = 8 maxDataFactor = 4 } } @PART[commDish]:FOR[AntennaRange]:NEEDS[!RemoteTech2] { %MODULE[ModuleDataTransmitter] { %name = ModuleLimitedDataTransmitter nominalRange = 80000000000 maxPowerFactor = 8 maxDataFactor = 4 } } In both cases, the antennae deployed when transmitting, then retracted. Manual operation of the antenna also worked.

I'm not 100% sure on this (maybe you know something about MM that I don't), but I think your :HAS[~ModuleDataTransmitter[]] clause on each part is entirely superfluous. According to the documentation the ~ operator applies to properties, not modules, so ~ModuleDataTransmitter would be checking for parts that do not have a "ModuleDataTransmitter = fooBar" value defintion, rather than those that do not have a ModuleDataTransmitter module. To check for the latter, you could use :HAS[!MODULE[ModuleDataTransmitter]], but since you are wanting to change the definition if it exists, or add it if it does not, you don't actually want to check for that. The %MODULE {} syntax later on is sufficient for the effect you're looking for.

I don't have any idea how to make the pretty lines. But, if I get a chance I'll take a look at learning. Did you unpack the latest ToadicusTools library from the AntennaRange archive? The versions currently included in TweakableEverything and VOID are missing that method. I'm working on a new deployment strategy that will prevent such confusion in the future.

@JeffreyCor So... does anything actually work in your install? There are so many exceptions in these logs that I'd be surprised if anything works at all. Exceptions are thrown for every part with a tweakable; modules are not being added to parts correctly at some stage or another and mot of the tweakable modules can't find their base Squad module to wrap during startup. It looks like that chain of events might start with RemoteTech2 (known to be generally incompatible last I checked), but honestly it's hard to tell. That chain of events goes on to impact Interstellar modules as well. Later on (presumably once you get into flight?) ModuleEngines runs into an exception while trying to update its connected resources; do your engines even burn? The slowdown you're running into probably has to do with the exception spam. In Windows the debug log is written synchronously, so when you're writing dozens or hundreds or exception traces per second, you're at the mercy of your hard drive speed. I'd recommend you start removing mods and see if you can find which one starts the chain of doom. You're looking to get rid of stuff like this in your output_log.txt: NullReferenceException: Object reference not set to an instance of an object at RemoteTech.ModuleSPU.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Parsing vector2 (Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) NullReferenceException: Object reference not set to an instance of an object at ToadicusTools.Tools.InitializeTweakable[ModuleTweakableReactionWheel] (.UI_FloatRange floatRange, System.Single& localField, System.Single& remoteField, Single centerValue, Single lowerMult, Single upperMult, Boolean clobberEverywhere) [0x00000] in <filename unknown>:0 at ToadicusTools.Tools.InitializeTweakable[ModuleTweakableReactionWheel] (.UI_FloatRange floatRange, System.Single& localField, System.Single& remoteField, Single centerValue, Boolean clobberEverywhere) [0x00000] in <filename unknown>:0 at TweakableEverything.ModuleTweakableReactionWheel.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Parsing vector2 (Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) NullReferenceException: Object reference not set to an instance of an object at ToadicusTools.Tools.InitializeTweakable[ModuleTweakableGimbal] (.UI_FloatRange floatRange, System.Single& localField, System.Single& remoteField, Single centerValue, Single lowerMult, Single upperMult, Boolean clobberEverywhere) [0x00000] in <filename unknown>:0 at TweakableEverything.ModuleTweakableGimbal.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at RemoteTech.ModuleSPUPassive.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at RemoteTech.ModuleSPUPassive.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[Vessel,OpenResourceSystem.ORSResourceManager].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceOvermanager.hasManagerForVessel (.Vessel vess) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceSuppliableModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at FNPlugin.FNSolarPanelWasteHeatModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[Vessel,OpenResourceSystem.ORSResourceManager].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceOvermanager.hasManagerForVessel (.Vessel vess) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceSuppliableModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at FNPlugin.FNSolarPanelWasteHeatModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[Vessel,OpenResourceSystem.ORSResourceManager].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceOvermanager.hasManagerForVessel (.Vessel vess) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceSuppliableModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at FNPlugin.FNSolarPanelWasteHeatModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[Vessel,OpenResourceSystem.ORSResourceManager].ContainsKey (.Vessel key) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceOvermanager.hasManagerForVessel (.Vessel vess) [0x00000] in <filename unknown>:0 at OpenResourceSystem.ORSResourceSuppliableModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at FNPlugin.FNSolarPanelWasteHeatModule.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Parsing vector2 (Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53) NullReferenceException: Object reference not set to an instance of an object at ToadicusTools.Tools.InitializeTweakable[ModuleTweakableDecouple] (.UI_FloatRange floatRange, System.Single& localField, System.Single& remoteField, Single centerValue, Single lowerMult, Single upperMult, Boolean clobberEverywhere) [0x00000] in <filename unknown>:0 at TweakableEverything.ModuleTweakableDecouple.OnStart (StartState state) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+ .MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) RemoteTech2 would be where I'd start. You might also downgrade to ModuleManager 2.0.7; 2.1.0 is throwing an exception while parsing something from the "LLL" folder, and it's new enough that most authors (including myself) haven't tested it with their mods yet. Other mods throwing exceptions as the game loads include: HullCameraVDS CactEye KSPCalendar MechJeb Environmental Visual Enhancements (probably harmless; I get this one too)

Let me know how it goes! Honestly I've never used RemoteTech so I have no idea what the differences are. But, based on what I think I've gleaned about RemoteTech from watching Scott Manley's videos, here are some guesses: AntennaRange... does not have any time delay or any facility for programming future actions. does not have additive ranges; everything is transmitter-side (so if you have a whip antenna out at Jool, it can't phone home even if there is a big dish around Kerbin). does not require antennae to target other antennae and does not have any limit to the number of relays that can be "connected" at any time. not a difference per JeffreyCor does not have those cool lines that show you which relays are connected to each other. does not maintain a persistent model of the relay network; everything is calculated dynamically as contact is required (constantly, when probe connectivity is enabled and you're flying a probe). allows line-of-sight and connectivity requirements to be disabled.