AccidentalDisassembly

1.44 should work for just about everything, but it depends on what mods you have installed - it can cause strange things to happen if you use TweakableEverything, for example, but removing a couple of TE's .dll files can help

I think it's because it's not SCALEEXPONENTS {} anymore, it's TWEAKSCALEEXPONENTS {} - change that and, in theory and with some luck, all should work...

Oh! Well, maybe it did then, maybe I just assumed that my large science haul was from that but it wasn't... I'm not sure, it just seemed high. You may be right though...

Gotcha, makes sense - but it did result in me getting something like 600 science from one Mun surface sample. Do you think there's a way to look at the total science available for an experiment (like ScienceLibrary or [X] Science or whatever) and then just limit the science for a given experiment to that value? Meaning you can have multiple copies of the same experiment, so you can get 100% of the science from it, like you can if you take a surface sample (which gives something like 80%), then take another for the remaining 20% - but you can't get more than 100%? Also, limiting size based on Mits sounds like a cool idea.

Very cool. I really look forward to having this mod - I think it's just so handy not to have to go around with your Kerbal and collect stuff, so much easier to return stuff from probes too that you shoot a lander off of! I also noticed - sorry, I just keep coming up with stuff - that in some cases, with the normal science containers (not autocollect), I seemed to be able to store many copies of the same experiment, like surface samples. I could just keep getting samples, using the containers to collect the science, getting more samples.. Maybe there's some code that can limit the total science stored for a given experiment to the total science available to get from it, or something?

Nope, not like that - the scene is either totally normal (can zoom, rotate, use main menu, click on toolbar stuff, etc.) except you can't click on any KSC buildings, or now, alternatively, the entire scene is black, but you can also still use menus, click on toolbar stuff (which is visible), etc. I may - MAY! - have narrowed it down to something in ScienceContainers 0.71, but can't be sure yet. Need to do more testing...

I wish I could help with the parts, but sadly I'm absolutely positive I'd be useless. Another thing I wanted to point out about the mod as it currently exists - I don't know this for a fact, I have really been struggling to figure out what is causing a problem I've been having, but I suspect that one of the DLLs in the 0.71 download *may* cause (alone or in combination with one of a ton of other mods) a problem where returning to the KSC from another body (switch to a craft on the Mun or Minmus or something, then go back to the space center) causes a black screen & input lock. But really am not sure whether it's your mod or not. Removing the ConfigurableScienceData folder seems to have solved the problem.. Anyhoo, could be a total coincidence, but maybe something worth looking at too.

Just FYI - there's not a 0.9.3 release available on GitHub yet! Though I assume downloading the master and taking the Pilot Assistant directory from that will work too, naturally.

OK. I moved all mods out of my own custom directory that had a DLL associated with them - others are just parts. Reinstalled them in the normal way, except for the KSP Bomb mod, which I simply removed temporarily. I went through the same process as last time this happened, with a few differences: 1) A (new) sandbox save, whereas the other was career, because I didn't want to go through an entire career to test this. 2) Somewhat different parts on the rocket, since it was sandbox and I could make my life easier. And the result was indeed different, though no less frustrating. This time, after doing the exact same kind of trajectory to Minmus (get orbit in Kerbin, transfer to Minmus, orbit, then crash), returning to the KSC resulted in an entirely black screen - the game didn't crash, but no scene was loaded, I guess. Could still hear the KSC sounds, and using ESC to quit to the main menu (and then the game) worked. But the KSC itself didn't load, the game window was black except for overlay items like the toolbar, debug window, etc. New log: https://dl.dropboxusercontent.com/u/59567837/output_logNoClick2.txt Mods I have installed, and versions (hopefully correct - I've put "latest" where I am positive I have updated them in the last few days or have the latest version): In case it's useful Toolbar 1.7.7 USI Tools (RoverDude) and associated mods: ART, CRP, Karbonite, Karb+, AES - latest. AdaptiveDockingNode: 1.5.1 B9: 5.2.6 Baha's engines (1.11), adjustable gear (1.0.4), armory (latest) Chatterer (0.7.1) CIT/active struts: 1.0.7.1 CollisionFX: 2.0 Community Tech Tree: 1.1 ConnectedLivingSpace: 1.0.11.0 Contract Science Modifier: 0.2 Contracts Window: 2.2 CrossFeedEnabler: Installed 24th oct, don't think there's a newer one Davon Throttle Control: 0.71 DDSLoader: 1.7 DeadlyReentry: 6.3.2 beta Diazo stuff: latest DistantObject: latest Dmagic Orbital: 0.9.0.2 Enhanced NavBall: 1.3.3 EPL: 4.4.0 FAR: 14.4 FinePrint: 0.59 Firespitter: latest (as repackaged with other mods recently) Hangar Extender: 2.0 Fusebox: 1.1 GoodSpeed Pump: the last one that was released Hangar: 1.3 (non-beta) ChaseCamera: 1.4.0 RasterProp: latest KAS: 0.4.9 KerbalFoundries: 1.7 KJR: latest KerbinSide: latest packs, latest Konstructs KineTech: one that came with B9 KM Gimbal: 2.0 KOSMOS - just parts, I think. ScienceLibrary: Latest released KW: just parts, I think. LLL: latest InfernalRobotics: 19.2 MarkIV: latest (just parts) MechJeb: 2.4 RCSFX: 0.3, I think HotRockets: Latest, whenever that was MissionController: latest MFT: latest NavBallDocking align: pretty sure latest NearFuture: latest ORSX: with Karbonite, most recent from most recent Karbonite version PartCatalog: 3.8 PartHighlighter: latest PartWizard: latest Pilot Assistant: latest Procedural stuff: latest Quantum struts: 1.1 RCSBuild: latest RealChute: latest RealRoster: 2.1b (latest) ResGen: with b9 RetroFuture: latest RLA: latest Scansat: latest dev ScienceAlert: latest SelectRoot: latest, whenever that was ShipManifest: from oct 28, 0.3.3.2b or something Landertron: latest SmokeScreen: latest StageRecovery: latest Stock bug & scaling fixes: latest SXT: latest Texture Replacer: latest TimeControl: latest Trajectories:1.0.0 (latest) TweakableEverything: 1.4 TweakScale 1.44 ... I think that covers it.

The ones I move to that directory seem to be working fine, but I'll take them out and see what happens. I am doubtful that will do anything - I mean, unless given DLLs specifically want something from a particular directory? My understanding is that almost every time a mod needs to be installed in a specific directory, it is because of MODEL{} nodes referencing textures in specific directories, but maybe that's wrong. TS 1.44 is the latest stable-ish version, sadly; 1.47 is OK but causes weird masses. We'll see what happens here..

Seems that every time I visit another body (Mun, Minmus in this case), when I return to the space center - like when a probe crashes into the surface and I return to KSC, as opposed to reverting to launch or the VAB - I can't click on any buildings. Have to exit the game and restart to regain functionality. Here's my output_log: https://dl.dropboxusercontent.com/u/59567837/output_logNoClick.txt 1. All of the mods I am running are up to date. 2. They're all installed correctly. 3. Googling and forum searching didn't turn anything up, but who knows. 4. I checked the help sticky (including Windows-specific); nothing there. 5. Windows 8.1 64-bit, but using KSP x32. 6. I have removed and replaced many mods (the ones that aren't just parts) to try to figure out if one or the other mod is causing the problem - can't tell. 7. Doesn't happen when returning to the Space Center from Kerbin orbit. Anyone able to help me figure out what the heck is causing this?

Well, there are actual bugs in 1.47 too, especially related to part mass - both on stock and on modded stuff. With regard to the modded stuff, anyway, it would make parts with MFT on them (or FS fuel switching, possibly, not sure) gain mass every time their scale was changed, so they got up to the billions of tons pretty quick.

In case it interests anyone other than me, here is a MM config I wrote that adds secondary stack nodes to most (probably missed a few) 2x1 parts that didn't already have them. Meaning the 2x1 standard tank, for example, how has 3 nodes on top and 3 on bottom, one in the middle and two others to the side that you can attach 1x1 parts to. I also did stackSymmetry = 1 on these parts so you can attach stuff symmetrically (hopefully). Here's a link: https://dl.dropboxusercontent.com/u/59567837/AddNodesToLLL.cfg License, I guess? You can do whatever you want with it, but if you want to use/redistribute it, a line somewhere with a credit would be cool!

I'd just like to point out that putting these inside the SCALETYPE is exactly what I suggested you do =) Glad it works, though I can't REALLY take any credit since I have no idea why it would work inside SCALETYPE and not out - except in the case that, for some reason, doing it outside the SCALETYPE was conflicting with some other variable somehow (because defined globally?). That doesn't really make sense though, so... Don't know what was wrong with TweakScale 1.44 related to the tracks, but it lacks the autoscale feature and seems stable...

Awesome! Very cool update. EDIT: One quick thing - it seems the airlock doors are not getting textured (LLL/Parts/Utility/Airlock) And a question - how come things like 3x1 and 4x1 hulls / tanks are disabled by default...? (am just deleting those lines from the disabler cfg) SECOND EDIT: appears some model files are missing from this version (3x1 stuff and many adaptors - no directories for them in LLL/Models/) And finally, the 2x1 solar panel part, when extended, says its receiving direct sun when the panels are pointed away from the sun... =(

Awesome! Very cool update.

Property of version 1.47, not with custom scaling. 1.47 is "special" for the moment, and it does some autoscaling stuff, you can try earlier versions instead.

Those look great! I can't wait for the next version to land... EDIT: Also, agree with what Climberfx says above, that's easy enough.

Edited to remove spam... Huh. don't know why that posted twice...

1.44 is the last really stable release - 1.45 and on introduced some features that interfere with other features (far as I can tell) in the presence of certain mods. 1.47's auto-scaling deal is also more or less broken for the moment - it works, but odd things seem to happen on spawns & reloads, masses go to infinity, stuff like that. Could be wrong, but I'm pretty sure lots of people have had issues even with 1.47 on stock... Anyhoo, so here's what I'm thinking for that code -I'm going to make a bunch of guesses, so I'm sure half of what I'm about to say will be wrong, but: As the MODULE{} is written now, I am going to assume that TweakScaleCorrector is only modifying the other variables that I can see in the code there. If it's being applied to stuff that's not in the MODULE{}, then this will be REALLY wrong, but you should be able to just write a TWEAKSCALEEXPONENTS{} fairly straightforwardly to deal with all of those MODULE{}s: TWEAKSCALEEXPONENTS { name = KFWheel raycastError = 1 // (scale linearly, I assume this has some relationship to model size?) springRate = 1 // (also linear, assuming the "rate" is a physical measurement and not a percent or fraction despite "Rate") damperRate = 1 // (also assuming linear with scaled size) smoothSpeed = 1 // (also assuming this value should increase/decrease with scaled size - but if this is the maximum speed of the wheel, maybe not) brakingTorque = 1 // (if this should scale in proportion to the mass of the wheels, then change to 3) rollingResistance = 2 // (I am assuming this variable should scale with the surface area of the part) } That SHOULD make all of those values do what I've said in parentheses without any jiggery-pokery with TweakScaleCorrector and whanot. But again, that's assuming that your module is only using the variables I see in front of me to make the wheels work, and not using some other variable (not written here) that would need to change as a part gets bigger or smaller. So this stuff: ... I don't know how to deal with, but if those are multipliers rather than numerical values applied to the steering and braking etc. under certain conditions, then you don't need to deal with it (in theory) if they're just multiplying the same value that TS is going change around (like "brakingTorque" or whatever) when scaling. What I don't see in there is a variable for the strength of suspension (which ought to scale probably cubically because it needs to match the mass of the part, which also scales cubically by default), unless that's what springRate does... I am assuming too that the Torque values are the only ones controlling the overall amoung of "oomph" the track has. So in short, I don't see what TweakScaleCorrector is doing that you can't just do with a normal TWEAKSCALEEXPONENTS{} definition, but it's obviously 99% likely that I'm missing something.. EDIT: ACtually TweakScale does seem to be able to handle lists of things, it does so with USI's resource converters by doing this, so maybe it could work with the various Curves too. If not, you could probably just make one variable that the module multiplies the curves by (like TweakScaleCorrector, but not applied to everything; just to each value of key = x x x x or something): TWEAKSCALEEXPONENTS { name = USI_ResourceConverter inputList { rate = 3 } outputList { rate = 3 } inputResources { rate = 3 } }

Anyone else still getting the thing where if you retract gear while you're sitting on the runway, then try to re-extend, they don't push the plane back up (go right through the ground)?

I'm getting a bunch of this in me logs: NullReferenceException: Object reference not set to an instance of an object at SpriteText.UpdateMesh () [0x00000] in <filename unknown>:0 at SpriteText.set_Text (System.String value) [0x00000] in <filename unknown>:0 at ferram4.FARControlSys.ChangeSurfVelocity (SurfaceVelMode velMode) [0x00000] in <filename unknown>:0 at ferram4.FARControlSys.LateUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) By a bunch, I mean thousands of instances. Does it mean anything? I really couldn't say what the circumstances were, it was just thousands of that NRE spamming before a crash that I *thought* was due to being out of memory (and probably was...?). Here's the log just in case: https://dl.dropboxusercontent.com/u/59567837/output_logFARstuff.txt FAR 14.4 and a bunch of other mods.

OK, I think I understand - that makes sense, and if indeed TweakScale is messing up stuff when you have 8 wheel MODULE{} in one part (or whatever), then having it chew on only that one variable might address that, too. I just can't think of a part I've seen that has two identical MODULE{} in it that would provide some kind of test case other than the wheels & tracks here. But maybe I'm not understanding - do you mean that there need to be multiple of the same MODULE{} in a given part to make the wheels/tracks work, or do you mean that the same variable gets mentioned X times in one MODULE{} (and therefore possibly borked by TS)? If it's the latter, I thought TS had a method of dealing with stuff like that so long as the same variable names are somehow nested (like different MaxThrust within a multi-mode engine MODULE{}, maybe?)... Are you using TS 1.44 to test all this? TS 1.47 produces some "creative" numbers when you scale stuff, just in case that's the version you're using.

Sadly I think Biotronic may have given up on TweakScale for real-life reasons (maybe he'll show up again in a month or two), I'm just trying to make any sense of it because I really want your parts to be tweakscaleable and work right because they're so cool =) Anyhoo, I obviously don't understand what's going on in your code - but why do you need a TweakScaleCorrector variable in the first place? What does it do? It seems to me the only real issue with the tracks in the past was that things like the suspension weren't changing with size (because the variable for suspension length, or however it works, wasn't defined in TWEAKSCALEEXPONENTS anywhere, and therefore not addressed by TS at all), but for the most part, when I tweakscale the currently-released tracks, they work. Their torque values are insanely high when scaled up, but they still work - no weird wheels going through the ground kind of stuff. Or, otherwise stated: what are the actual variables/values used by the MODULE{} at work in the wheels and tracks that need to change with the size of the part, and in what way(s) do they need to change when the part's larger or smaller?

I've had Kerbals spark, too, or perhaps they're making the pod spark when they come in contact with it and move it (can't remember, exactly) - version 2.0.