toadicus

For the interested; I've got a TweakableEverything dev build available that adds proper support for parts built like this.

You're going to have a lot of trouble finding support here I'm afraid. :/ Squad doesn't support 0.90 or any x64 builds anymore, and neither do most/any mod authors. 1.0 and its successors are not distributed in 64-bit, even if Steam still lets you ask for it (I don't have the game on Steam, so can't tell). That said, crashes during startup in heavily-modded installs are almost always memory related, even in 64-bit, and I can confirm as much from a read through the end of your log files in the crash dumps: From the first one: Load(Texture): Squad/Parts/Command/externalCommandSeat/model000 [B]OutOfMemoryException: Out of memory[/B] at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_specific (intptr,int) at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS.Read (System.String filename) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS+.MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() Load(Texture): Squad/Parts/Command/hitchhikerStorageContainer/cabin [B]DynamicHeapAllocator out of memory[/B] - Could not get memory for large allocationCould not allocate memory: System out of memory! Trying to allocate: 1398128B with 32 alignment. MemoryLabel: Texture And from the second one: Load(Texture): Squad/Parts/Command/cupola/ksp_l_cupola_diff OutOfMemoryException: Out of memory at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_specific (intptr,int) at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS.Read (System.String filename) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS+.MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() Load(Texture): Squad/Parts/Command/cupola/ksp_l_cupola_normal Load(Texture): Squad/Parts/Command/cupola/window Load(Texture): Squad/Parts/Command/externalCommandSeat/model000 OutOfMemoryException: Out of memory at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_specific (intptr,int) at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS.Read (System.String filename) [0x00000] in <filename unknown>:0 at DatabaseLoaderTexture_DDS+.MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() Load(Texture): Squad/Parts/Command/hitchhikerStorageContainer/cabin DynamicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory! Trying to allocate: 1398128B with 32 alignment. MemoryLabel: Texture If you're insistent on running in Windows, there's no reasonable way around using a memory management mod like ActiveTextureManagement. The 64-bit Windows builds were always tremendously unstable and do not actually effectively solve the memory problems. That said, the crash dumps you posted are both 1.0.4 crash dumps, and 1.0.4 is not distributed in 64-bit. Once again, if you're using the hacks to run in 64-bit, you should ask within the 64-bit hack community for support. The log you posted separately appears to be from an entirely crash-free run of the game, so I'm confused as to its relevance here.

New (last?) dev build, this time with TweakableEngineFairings improvements to support parts with multiple shroud modules referencing different attachment nodes. Should fix cipherpunk's report regarding Space-Y adapters. Also now distributing my 0-force decoupler hotfix patch so people can stop reporting the PF interstage issue. Last call for new bugs; looking to release tomorrow-ish. [zip] [tar.gz] [tar.xz]

So to clarify, the SYplate2m1mX0 is not intended to display variably-configured shrouds? Will check on the A5-123 shortly.

NecroBones, please forgive the stupid question... but I'm trying to test my TweakableEngineFairings fix, and I'm not sure I get how your parts are supposed to work. Considering your part SYplate2m1mX0. You've got four stack nodes: node_stack_bottom = 0.0, -0.2, 0.0, 0.0, -1.0, 0.0, 1 node_stack_bottom1 = 0.0, -2.0, 0.0, 0.0, -1.0, 0.0, 2 node_stack_bottom2 = 0.0, -1004.3, 0.0, 0.0, -1.0, 0.0, 2 node_stack_top = 0.0, 0.2, 0.0, 0.0, 1.0, 0.0, 2 In the editor, I see three of these, which I am interpreting as follows: "top", on top as expected; "bottom", flush against the bottom of the part; "bottom1", 2 meters below the part. I think I do not see "bottom2" at all, which makes sense since it's a good kilometer away. You have two ModuleJettison definitions: MODULE { name = ModuleJettison jettisonName = SYplate2m1mX1shroud0 bottomNodeName = bottom1 isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } MODULE { name = ModuleJettison jettisonName = SYplate2m1mX1shroud1 bottomNodeName = bottom2 isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } As far as I know, that means the first module will have a fairing when there is a part on "bottom1". The second module will have a fairing when there is a part on "bottom2". Things are working correctly for me in the former case, but I can't figure out how to test the latter case. TIA!

cipherpunks, pretty sure that's just this KSPAPIExtensions quirk:

Cross-posting from Space-Y's thread. Edit: Yay! A report that isn't a TweakableStaging problem!

cipherpunks, NecroBones, I'm pretty sure I know specifically why TweakableEngineFairings is stepping on certain shrouds for certain parts; it's definitely something I can fix. But probably not until the weekend. For the curious, I watch the named "bottomNode" to see if there's a part on it to help know whether or not there should be a shroud. But, I just grab the first bottomNodeName I see (or maybe the last; I forget specifically), rather than handling it separately per module. Shouldn't be too hard to fix, just need to get a chance to code.

New dev build, more TStaging improvements. [zip] [tar.gz] [tar.xz] The blank spots in the staging list should no longer happen, and parts should no longer wind up "on the side" of the staging list when toggled in certain circumstances. I don't think there's much I can do about staging when vessels dock... I'm not changing the stage in response to docking; just making sure things are on or off as relevant. Doesn't staging get jumbled after docking in stock, too? LGG, I've already got tweaks for both deployment speeds; look at {Semi ,}Deployment Factor. So that only leaves "minDeployment" on your list... but I don't know what that is. Can you elaborate on the effect that you're trying to achieve? The request in your last post ("...all I need... is to change the full deployment altitude") is already done by Squad's "Altitude" tweakable, so I've really got nothing to go on here. cipherpunks, I'll look in to that request soon. Re-enabling Squad's gimbal limiter in flight is probably the way to do that (if I'm correctly understanding what you want), and simple, too!

Toyotawolf, I'm pretty committed to not adding any parts to the default distribution of AntennaRange, for a lot of reasons. I'm not a modeler, so I can't produce them. I also want to keep save-breaking to a minimum; once you install a part mod, you're usually stuck with it until you want to start a new game. If you decide AntennaRange isn't for you, I want you to be able to remove it and keep playing the game. That said, I do what I can to support community efforts to distribute ModuleManager patches to enable AntennaRange functionality on various part mods. I can't remember if there's been a boxsat patch before, but you can make one! The readme here should help you get started: https://github.com/toadicus/AntennaRange/blob/master/README.md scribbleheli, you've missed the release of Pretty Lines and the subsequent release of Symmetric Links! Go have a look at the change log in the OP, or if you like reading commit messages, the git log. A lot of good stuff (if I do say so myself). MrBonobo, best as I can tell we're good to go in 1.0.3/4 without a recompile. If I'm wrong, please let me know. I haven't seen the RT patches in a little while; I'm not sure if they're updated from AR 1.10. If not, the hotfix I posted a page or two back should get them close... but in general they should be rebuilt if they've not been already.

smunisto, I found a bug in AR this weekend that makes things go crazy if the active vessel has no transmitters... but there's no indication in your log that you've hit such a scenario. In fact, all the Update() method that's throwing does is set UI strings for the context menus of transmitter parts. Here's a quick dev version that protects what I think is the only potentially-unsafe reference in that method: [zip] [tar.gz] [tar.xz] Let me know if it changes anything. That doesn't really explain the context lockdown before you go on EVA, though. That almost seems like it thinks you don't have proper control. Do you play with "Require Connection for Probe Control"?

Seeker89, you should be able to do something like this: EVA_RESOURCE { name = Ablator amount = 50 maxAmount = 50 FillFromPod = false } In any .cfg file in GameData. Tune amount and maxAmount to suit. Kolago, can you can try isolate the mod interaction that causes your issue? Are you using any custom EVAManager patches? If so, please post them. I can't recreate your problem out of the box, so I need more information. Also, I (like most mod authors and Squad) do not support "cracked" 64-bit KSP installs in Windows. I'm not sure if that's what you meant by "Win 64 bit / KSP 1.0.2", but if it is, note that -- at the very least -- I'm missing a big piece of consistency with your installation that could prevent me from properly reproducing problems. I'll help if I can, but you'll have to do all the heavy lifting of actually isolating the problem yourself.

cipherpunks, ModuleStagingToggle really isn't configured to work for two modules at this point. I can change that, but not for the next release; I want the get the core functionality stable first. I'd recommend you patch it out of that part entirely, or run that part with staging disabled. I've fixed the ModuleManager "errors" (they're really more like warnings in this case). For now just ignore them; they're harmless.

Olsson, I'll need a log if I'm going to be of any help to you. If installing other mods broke it and uninstalling them doesn't fix it, it's probable that they've affected your save in some way that I am not recovering (and very possibly connect recover). Can you duplicate your issue on a fresh install of KSP+AntennaRange?

vardicd, you're on one of the edges of the solution I'm using, and an optimization is throwing away the proper solution. Basically when I check if a body is blocking line of sight, I draw a line from the source probe to the target probe. Then I draw a perpendicular line from that line to the center of the body in question. If that second line is shorter than the radius of the body (or the radius * .95, if you're using the default fudge factor), the body is blocking. But, before I do that, I do a couple of checks to see if I should bother testing at all. One of those tests is "is the body in question farther from me than my target? if so, assume it is not blocking". This lets me speed things up a lot by not checking against Moho or Jool or the Sun, for example, when I'm trying to resolve line of sight for a Minmus probe to Kerbin. The line of sight check is the slowest piece of logic in the loop, and I've worked hard to speed it up as much as possible. I should probably do something a little differently for probes that are less than radius * 2 distance from the body in question... but just checking for that slows things down a little. I'll take a look and see if I can find a good option.

Alright folks, new dev build. I've tested this a lot in the VAB and a little in flight, with no mod parts. There's one set of steps that appears to cause something funky; I'm not going to tell you what it is to see if any of you get there. [zip] [tar.gz] [tar.xz] When reporting: INCLUDE WHOLE LOGS. This is very important. I've got debug logging turned on in this build and it should emit a lot of helpful data. Please don't pick the bit of the log that you think looks important, like a single stack trace, just give me the whole thing. If you don't want the whole Internet to see your folder name or graphics card, shoot it to me in a PM. Include reproduction steps. If you're not confident of how to reproduce it, at least give as detailed a description of what you were doing and what happened as you can muster. If you post screenshots, describe them or use them to support parts of your reproduction steps. Don't assume I will see what you're trying to convey without a little context. Thanks, as usual.

smjjames, there's no reason I'm aware of that doing science should have anything to do with it. I'm certainly not looking for any science-related changes or events to prompt a change. It could be that something you're doing (perhaps the science-sending, but that doesn't follow any of Squad's transmission logic that I'm aware) is unloading or packing up the other ship or something and causing a different reaction when you board the vessel (boarding always fires onVesselChange, which I do listen for). But, all of the stage juggling should go away completely in the rewrite. It will now be prompted ONLY when you actually click the Enable or Disable Staging buttons. I've also got smart part placement on enable working much more intuitively. I still need to test loading and reloading and reverting and docking and undocking and vessel switching, but at the most basic level I'm much happier with the new implementation. UPDATE: Passing basic loading tests now! Also cipherpunks, the problem with your FASA part, I believe, is that it was getting two ModuleStagingToggles; one from TweakableDockingNodes (which defaults to disabled) and one from TweakableDecouplers (which defaults to enabled). Every update, the TDN copy was disabling staging, and the TDrs copy was enabling it right back. I've amended the TDN patch to only apply a ModuleStagingToggle after TDers and only if there's not already one, and added some election code so even when there are multiple copies only one should be running.

I'm rewriting all the important parts of TweakableStaging, with a particular mind towards making sure stage order isn't messed with at all unless you actually click a button to change something (e.g. "Disable Staging"). So far it's passing the most basic in-editor tests. More news as it breaks.

Okay cipherpunks; I don't know why it's flipflopping like that, but I'll go download FASA and have a look. Don't thank me, Gaiiden, thank Jayne in Serenity, from Firefly. smjjames, I think I know what's causing that; I run a check to be sure icons are where they should be when changing vessels, otherwise staging will magically re-enable itself when you switch using the [ ] keys or similar. I'm pretty sure this is a result of my latest "smart placement" for parts as staging is re-enabled. Time to go rewrite like half the module!

cipherpunks, which version were you using? That doesn't look like the latest dev build (which iirc shouldn't have any screen text). I'll try to test with FASA soon. tg626, none of the modules should be touching the staging list unless you're toggling staging on and off with TweakableStaging. Can you describe what you're doing when the stages are "juggled"? I've half a mind to completely rewrite TweakableStaging; it's starting to damage my calm.

AntennaRange has been updated to version 1.10.1! This version fixes an issue that prevented relays on about half of vessels from targeting relays on about half of vessels. This should correct the circumstance reported by Gribbleshnibit; thanks for reporting! CHANGELOG: v.1.10.1 [2015-06-17] * Fixed a bug that prevented relays on about half of vessels from targeting relays on about half of vessels.

I'm guessing the next version will fix your issue; on average about half of all relays were unavailable to half of all relays. Basically, I build a list of relays that should be checked against during searches. But I also started searches during that the loop that builds the list, which means vessels that come "early" in the list (sorting is probably arbitrary but consistent) do not have access to vessels that come "late" in the list. I didn't notice it because I was always testing with networks covering much smaller distances, and always focusing on the active vessel, which always checks last. I'm now starting searches from a post-loop after the build, so that problem should go away entirely.

Another update: I found the bug preventing vessels from using the active vessel (and actually a lot of other vessels as well) and squashed it. I'll try to release that tonight.

Gribbleshnibit8, by "before the update" do you mean "with dev builds using additive range before the release" or "with version 1.9.x"? Also, because I've made mistakes in the "LOS is off" side of things before, do connections work as anticipated when LOS is on? Also a Comm. 16->Comm. 88-88 connection has a maximum range of 25,806,976 m. That's quite a bit beyond Ike's 3,296,000m apoapsis, but it's worth mentioning in case your 88-88 is in a really high Dunan orbit (well outside Ike's orbit). Are your vessels in range of each other? - - - Updated - - - Update with two more relevant questions: had the active vessel just undocked from the probe to which it should have been transmitting? Sometimes that messes things up, but should fix if you change vessel. From which probe were you observing this lack of connection? I just duplicated something like your scenario, and when I was observing from the relay satellite (in Dunan orbit), the Ike probe did not have a connection but when I was observing from the Ike probe, it did. This is a bug; I'm looking in to it, but it might present a workaround for now.

OK, I think I might have figured out what cipherpunks meant. The build I put up last week introduced a bug where if you had a disabled part and no stages in the list, you couldn't re-enable it unless you added another stageable part to the ship first. I've fixed that. I've also stopped using Squad's "ScheduleSort" method which delays the sort until later, because that was causing occasional exceptions when parts got yanked off the ship right after being put on (for example). I've also found and fixed a bug I uncovered where disabled parts would make enabled symmetry partners. New dev build with less noise in the log (but hopefully enough to be useful) and the fixes above: [zip] [tar.gz] [tar.xz]