toadicus

Looks to me like their docking port hasn't changed, and there's no new docking parts. The patch should still apply just fine.

Ah, but in that you are mistaken my friend! In fact, the fun starts at line 178, though we don't get the real clue until line 220: System.IO.FileNotFoundException: Could not load file or assembly 'ToadicusTools, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Looks like somehow or another you don't have ToadicusTools installed, which is a hard dependency for most of the modules. So, any part with a module tweaked by TweakableEverything except engine fairings, gimbals, and RCS won't start up right or work right at all ever. HTH!

Please do. Like I said, I'm happy to help out if I can, I just can't know if I can help based on what you've given me. If you can get me a debug log, I'll at least be able to offer information.

So, I don't know exactly what the issue is, but this is pretty much certainly a mod interaction issue. Do you have sarbian's DecoupleForX64 v1 or v2? In either case, TweakableDecouplers will not play nicely with DecoupleForX64 unless you have the fixed MM patch I posted here: http://forum.kerbalspaceprogram.com/threads/87127/page5#post1288061. TweakScale isn't my mod at all, and those don't look like exceptions. If you're referring to the exception in the middle of everything at 15:58:27.318, I can't tell you anything about it without a proper debug log (not just KSP.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). I'm happy to take a look and help if I can.

All: the issue with TweakableEverything should be fixed by removing the ":FOR[DecoupleForX64]" from the @PART lines in DecoupleForX64.cfg and changing the decouplerModuleName for stack decouplers. ModuleManager doesn't allow multiple pass declarations and just uses the first; by saying ":FOR[DecoupleForX64]:AFTER[TweakableEverything]", the patch applies during the ":FOR[DecoupleForX64]" pass, long before the TweakableEverything pass. Also, the DecoupleForX64 cfg mistakenly used ModuleAnchoredDecouplerX64 for the ModuleDecoupleX64 decouplerModuleName; just a copypasta mistake. TE and DFX64 should play nicely with this cfg: @PART[*]:HAS[@MODULE[ModuleDecouple]]:AFTER[TweakableEverything] { @MODULE[ModuleDecouple] { @name = ModuleDecoupleX64 } @MODULE[ModuleTweakableDecouple] { @decouplerModuleName = ModuleDecoupleX64 } } @PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:AFTER[TweakableEverything] { @MODULE[ModuleAnchoredDecoupler] { @name = ModuleAnchoredDecouplerX64 } @MODULE[ModuleTweakableDecouple] { @decouplerModuleName = ModuleAnchoredDecouplerX64 } }

You're right, not intentional. I know a bunch of stuff with the GUI was changed up in 0.24; I'll see if I can't track this down. Yeah, I noticed the Resource Mass issue myself while playing yesterday... but I kept playing instead of fixing it. I'll look into it! I'll think about it. I don't really love the idea of putting lines in, and I'm not a great graphics designer so I'm a little worried I wouldn't be able to do it whilst keeping things "looking good". I will look and see if there's something I can do to improve parse-ability, though.

You should definitely be able to get a connection from anywhere in low Kerbin orbit with the Ctron 16; if you're not then something's afoot. Do you have a debug 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) I could look at to see if I can tell what's going wrong? One thing worth doing up front would be to upgrade to ModuleManager 2.2. I updated AntennaRange because MM 2.2 came out; no idea is 2.2 fixes anything in particular, but it's a good idea anyway.

That's a good idea. I have the same thought every time I build a spaceplane; no idea why I didn't think to fix it. I'll look in to it! UPDATE 2: I've coded this up; I'll post it once I get a chance to test it. I'll have a look. I should be able to incorporate this. UPDATE: Looks like the problem was just a couple of issues in the DFX64 ModuleManager patch. I've posted a fix over there. I agree with your edit that TweakableEverything likely has little if anything to do with the crash. Looking at the debug log, the exception fired there is actually in Squad code (might be related to this bug), and the messy-looking exception log from TE is actually just messy logging; the exception was handled in my code and does not cause a problem later on. The crash trace suggests a crash somewhere in the Contracts system; I suspect this is to do with memory issues: it is very unlikely IMO that switching to 64-bit is a silver bullet to let you add all the mods you want. I'd recommend to anyone getting 64-bit crashes that you go get Active Texture Management, even temporarily, to see if that ameliorates your crash issues. Whether it helps or not, that knowledge is useful data to modders and Squad.

I could easily add a "fudge factor" field for dishes and antennas, but it would not be easy for me to make it tweakable because of the way AntennaRange deals with unloaded vessels, so any changes would require a change to the cfg files. That could exist in addition to or in place of the global "fudge factor" (probably the former).

I have updated the plugin for 0.24: http://forum.kerbalspaceprogram.com/threads/79128 Unless Cpt. Kipard knows otherwise, the part portions of the ports should work just fine in just about any version.

So, I tried a quick test to duplicate what I think you're saying. I didn't build a whole station, so it's not entirely fair: I accidentally put a Communotron 88-88 on the lander, so I parked it on the dark side of the Mun to make sure it couldn't phone home without the relay sat. In this circumstance, the satellite's Communotron 16 does not function, and its 88-88 phones back to Kerbin directly. EDIT: It just occured to me in looking at these images that you can't tell from the image above that the second satellite shown below isn't also in orbit already. So, for the record: it's not. So, then I put together the condition I mentioned to you before: The two sats are 120° separated; both in view of the lander. Each sat will use the lander as a relay, because it's more efficient to send data there with the 16 than to use the 88-88. The eventual costs of relaying the data two more times aren't modeled at all at this point. In the Big AR2 Rewrite I'm working on, I think this sort of behaviour will be less common. That is, it should hopefully only happen when it's actually a better route. If you only had one vessel in orbit, and the rescue lander didn't have any long range antennas, it shouldn't have been available as a relay. But, it's possible that I missed an event and when you docked things on orbit, one of them got left in the cache as an un-docked vessel and used. Docking is weird. I'm planning to use KerbalStuff Soon™. There are a couple of API pieces I'm hoping for / waiting patiently for that would really streamline my process. For now, I have a few terabytes of bandwidth with nothing else to do; may as well host my KSP mods. IMO, that actually makes the situation worse. In real life, a more-directive antenna should generally cost less power to get the same bandwidth, or put differently, should get better bandwidth for the same power. Were I to rebalance the antennas using Squad's current system, I'd put all the power usages the same and increase the packet sizes for the dishes, so that they could be superior choices even once in a while. In AR, and AR+SR, they don't become superior choices until the next best choice gets out past optimal range and starts losing efficiency.

So, I still feel strongly that this is a) a mod interaction problem, with which to deal I need the parts of your log that show the other mods you have installed and the stack trace at the end of the crash report, or a memory issue (64-bit KSP on Linux hasn't been free from memory limits, 64-bit on Windows might not be either?). TweakableEVA shouldn't be running any code in the editor whatsoever. That said, I've added some checks to make completely sure that once TweakableEVA does its work in the space center, it does nothing at all until it needs to do tweakable assignments for the EVA part in flight. I've also fixed some problems with my ModuleDB. If you're having trouble with crashes and think TweakableEverything might be to blame, please follow these steps: Get me a full debug 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) Download this development version: http://ksp.hawkbats.com/dev/TweakableEverything-dev.zip If the problem persists, get me a full debug 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) again. Thanks!

Can you please get me the whole log, then? I can't make the game crash in a quick-and-dirty run in 64-bit Windows or 64-bit Linux. Does it happen with no other mods installed, or only a few others? When you say "select a pod", do you mean add a pod as a root part in the editor?

Technically that's not an error, it just looks like one. Something in Squad's code throws an exception when adding things to parts in the space center via the method I'm using, but otherwise works. The same thing happens with TACLS. I've quieted down the log to make it look less like a problem, but that's an expected exception being handled by my code, not an unhandled exception causing havoc. Thanks for reporting, though!

You must have a more up-to-date version of your code than we do. A raw checkout of v0.9-pre2 or master fails to compile against 0.24 for me with errors like: TacLifeSupport\Source\SpaceCenterManager.cs(68,13): error CS0246: The type or namespace name `CrewRoster' could not be found. Are you missing an assembly reference? TacLifeSupport\Source\SpaceCenterManager.cs(70,52): error CS0841: A local variable `crewRoster' cannot be used before it is declared TacLifeSupport\Source\LifeSupportController.cs(67,17): error CS0246: The type or namespace name `CrewRoster' could not be found. Are you missing an assembly reference? TacLifeSupport\Source\LifeSupportController.cs(69,56): error CS0841: A local variable `crewRoster' cannot be used before it is declared CrewRoster doesn't exist in the assembly anymore; it's been replaced with KerbalRoster. Also, KerbalRoster objects aren't enumerable themselves; you have to pick between KerbalRoster::Applicants or KerbalRoster::Crew and enumerate those, and ProtoCrewMember.RosterStatus members had their case changed from ALLCAPS to Capitalized. So, v0.9-pre2 (and probably all versions since 0.6) will throw a TypeLoadException before executing SpaceCenterManager::Start and LifeSupportController::Start (not during execution). Anything that should happen in those methods (such as adding life support modules to the EVA part) won't happen. I don't know if that's causing JefferyCor's crashes (I seriously doubt it; old TACLS binaries don't crash my game), but it certainly does stop TACLS from working properly in 0.24.

As ModZero suggests, this is more like "RT2Lite" at this point. If you already have RT2, AntennaRange may: a) not function correctly; not function at all; or c) break RT2, so in general it's a one-or-the-other option. EDIT: Here's a quote from a few pages back where I go over what I think are the primary differences. EDIT: So, I don't have a super clear picture of exactly what the setup was, but here's the facts. When transmitting from an experiment dialog, Squad's code uses a utility function called GetTransmitterScore to determine the "most efficient" antenna to use. Squad's method of determining that is... pretty suspect, at any rate... so I've helped it out a little bit. Here's my rationale, straight out of the code comments: /* * The next two functions overwrite the behavior of the stock functions and do not perform equivalently, except * in that they both return floats. Here's some quick justification: * * The stock implementation of GetTransmitterScore (which I cannot override) is: * Score = (1 + DataResourceCost) / DataRate * * The stock DataRate and DataResourceCost are: * DataRate = packetSize / packetInterval (units in "bytes" per second) * DataResourceCost = packetResourceCost / packetSize (units in Charge per "byte") * * So, the resulting score is essentially in terms of joules per byte per baud. Rearranging that a bit, it * could also look like joule-seconds per byte per byte, or newton-meter-seconds per byte per byte. Either way, * that metric is not a very reasonable one. * * Two metrics that might make more sense are joules per byte or watts per baud. Since both of those metrics * are closely coupled in Squad's model, they wind up exactly the same once you cancel things out: * * DataRate = packetSize * DataResourceCost = packetResourceCost * * So... hopefully that doesn't screw with anything else. * */ Put concisely, with AntennaRange installed, Squad's code picks antennas based on the most efficient transmission in terms of ElectricCharge per MiT. Then, since Squad's antennas are balanced strangely, the Communotron 16 will always win when all three antennas are performing at their best. Packet Size Packet Cost Score Communotron 16 8 10 1.375 DTS-M1 8 12.5 1.6875 Communotron 88-88 8 20 2.625 Lowest score wins. Now, to your circumstance. From what I can glean from your description, it sounds like you've got two ships / satellites in Munar orbit and a rover on the Munar surface. When you transmit from one of the ships in Munar orbit, it uses the rover to phone home. This is probably because all three vessels are within optimal range for all three antennas, and the rover is closer to the orbital station than the other orbital vessel. If I'm misunderstanding your setup, please let me know. A ship shouldn't be able to use itself as a future relay (that is, the orbital station can't transmit through the rover unless the rover has another route back to Kerbin, e.g. another orbital vessel), and if that's happening it's a bug.

TaranisElsu, I got JefferyCor's report and did a little digging. Here's a cross-post from my TE thread. JefferyCor, unless you've got a version of TACLS that I don't see and that isn't actually called 0.9 Pre 2 and dated 8 days ago, the problem is on his end. CrewRoster changed names in the assembly and he's getting a TypeLoadException during SpaceCenterManager::Start() because the old binary isn't compatible with KSP 0.24. TaranisElsu will need to update his code for the CrewRoster changes (I hear it's called KerbalRoster now) before TACLS will start up correctly.It's a little deceptive, because a lot of the TACLS functionality does appear to start up correctly, but there is at least the one definite incompatibility there. Hope that helps!

JefferyCor, unless you've got a version of TACLS that I don't see and that isn't actually called 0.9 Pre 2 and dated 8 days ago, the problem is on his end. CrewRoster changed names in the assembly and he's getting a TypeLoadException during SpaceCenterManager::Start() because the old binary isn't compatible with KSP 0.24. TaranisElsu will need to update his code for the CrewRoster changes (I hear it's called KerbalRoster now) before TACLS will start up correctly. It's a little deceptive, because a lot of the TACLS does appear to start up correctly, but there is at least the one definite incompatibility there.

I guessed as much, but what with all the mod-updating I haven't actually opened a career save yet. Thanks! Whoops again. OP updated.

OMG TRIPLE POSTING. (Sorry mods ) TweakableEverything has been updated to version 1.3.1! This removes the "Dump" events from EVA packs and does nothing else of consequence. Or even of non-consequence. CHANGELOG: v.1.3.1 [2014-07-17] * TweakableEVA: Fixed to no longer add Debug functionality when not building for Debug targets.

I'm not sure it's possible either, and haven't yet seen this "Conduct Test" button of which you speak. But, I'm guessing I can make something work.

Thanks, my bad. Anyway, looking at that log I'm relatively certain that the problem is with ModStatistics, not TweakableEverything. ModStatistics throws some exceptions during Start when it gets instantiated during the load, and then code from ModStatistics is mentioned in the stack trace at the end of the crash report: (0x0000000103C40000) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x00000000916A0690) (Mono JIT code): (filename not available): System.Collections.Generic.EqualityComparer`1/DefaultComparer<GameScenes>:Equals (GameScenes,GameScenes) + 0xa0 (00000000916A05F0 00000000916A069A) [0000000000564D48 - Unity Root Domain] + 0x0 (0x00000000916A0506) (Mono JIT code): (filename not available): System.Collections.Generic.Dictionary`2<GameScenes, System.TimeSpan>:get_Item (GameScenes) + 0x126 (00000000916A03E0 00000000916A05CC) [0000000000564D48 - Unity Root Domain] + 0x0 (0x000000001F264F17) (Mono JIT code): (filename not available): ModStatistics.ModStatistics:updateSceneTimes () + 0x1b7 (000000001F264D60 000000001F264FCC) [0000000000564D48 - Unity Root Domain] + 0x0 (0x000000001F264B7C) (Mono JIT code): (filename not available): ModStatistics.ModStatistics:FixedUpdate () + 0x8c (000000001F264AF0 000000001F264CB8) [0000000000564D48 - Unity Root Domain] + 0x0 (0x00000000040872DB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x6b (0000000004087270 000000000408734A) [0000000000564D48 - Unity Root Domain] + 0x0 (0x000007FEE4AA36CA) (mono): (filename not available): mono_set_defaults + 0x2b8e (0x000000013F784B49) (KSP_x64): (filename not available): (function-name not available) + 0x0 (0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000000564D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0 ========== END OF STACKTRACE ===================== OUTPUTING STACK TRACE ================== I'd try removing whatever mods depend on ModStatistics to see if TE and all of your other mods work without it, and then report the problem to Majiir. Good luck!

Again, I'll need a debug log and steps to reproduce if I'm going to have much chance of helping you now. Otherwise, I'll be putting my über-modded career set together over the next several days, and if I run into the same problem in 64-bit Linux, I'll fix it then.

I'm going to guess it will, but I can't guarantee it. Try it and find out! If not, let me know; there might be something I can do to help out. Also, you can always redownload the old version (http://ksp.hawkbats.com/AntennaRange/AntennaRange-1-3.zip). EDIT: I've got a stock toolbar button working nicely. Now I just need my artist to get back and make a higher resolution icon so I can give you something that doesn't look awful forever.

JeffreyCor: the win64 version is literally the only place this build has been tested so far; it worked in a vacuum, so I'm going to need more info and a debug 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) if I'm going to be any help to you. Obsessed: Oops! I'll fix that up and rebuild it later this evening. Gotta get the kids in bed first.