AccidentalDisassembly

I'll see what happens if I do size 0 and/or arbitrarily large parts (via part copying) with pitifully small nodes. Hope that's not it, since that would make for some really weak connections on larger parts (unless there's some way to make a given part's node very strong even though it's not large size...?). EDIT: Size 0 nodes and changing the scaleexponent for node connection strength stuff did nothing. Blech. It made the stackable extendatrons move upward from their base (viewed from launchpad), though they also move out. Doesn't fix larger parts. Likewise, specifically defining maxTranslate, keyTranslateSpeed, and masses using TweakScale does not make parts beyond a certain size work. I don't think it has entirely to do with node scaling, here's why: Right-angle extendatrons have node size 1, so do stackable ones. But at the same scale (2x), the right-angle part works as expected, stackable doesn't... EDIT AGAIN: May or may not be anything, but no foldatrons will work at 2x, some other rework parts (actually, most) will - using same TS definitions etc. Also, normal gantry rail is basically impossible to right-click in flight. And finally, creating gigantic versions by changing rescaleFactor, mass, maxTranslate, etc. to appropriate values appears to work. Node size 4 also appears to create no problems. Though these embiggened parts seem a little wobbly for their size.

Question - I have been playing around with tweakscale values for IR parts (mostly rework), and I have noticed some very bizarre behavior. I completely rewrote the tweakscale stuff, so this isn't based on having only three mass values in a part's TS module while having four scale factors in my scaletype, for example - I removed all of those and created an MM patch to add the TS modules back in so that it was easier to work with. However, the parts will not behave correctly when scaled by certain factors. 0.25x, 0.5x, 1x, and 2x are all acceptable - things work as they should, or at least they seem to, parts scale up, movement ranges (like with extendatrons) is correct, blah blah blah. However, NOTHING works correctly (non-extending parts don't work at all, mesh doesn't rotate but moves slightly) when I ask it to scale to 3.0x or 4.0x, and a few parts also fail on 2.0x (such as stackable extendatrons). What gives? Is there some problem with uneven numbers or numbers greater than 2 when scaling IR stuff?

I saw a couple references to new cargo bay parts in those configs, did those get released at some point?

Huh, I also had a problem a few pages back where a couple NovaPunch parts wouldn't tweakscale, but most other things would. I never figured it out either... - - - Updated - - - To make this work, just put "TWEAKSCALEEXPONENTS { mass = 2 }" inside the TweakScale module in your config, I think.

Hate to bring this up again, but I'm not sure that the log spam of "Input is null" that occurs with Virgin Kalactic (still in 5.1) node-switcher-on/off stuff is benign. I counted the instances in my output_log and it stands at 146,940 right now. The slowdowns I am experiencing are definitely not fundamentally related to the node-switching DLL, since the same thing happens without it, but they occur much sooner and more frequently with it installed. I know it's very vague, but there used to be a problem with RasterPropMonitor and the MK2 cockpit in Spaceplane Plus that produced a very similar effect to the one I'm experiencing now, though more pronounced. Same thing as I mentioned before: When you start building in the SPH, it's fine. Some time later, there are brief freezes every 10 seconds or so. Another 10 minutes after that, freezes occur every 2 seconds, and so on. Eventually KSP runs out of memory (I believe...) and crashes. With Spaceplane Plus, the problem was somehow related to RPM cameras (or something), blue cones for which were visible in the SPH when they shouldn't be. The crash with SPP occurred much sooner, but with the same M.O. EDIT: On second thought, maybe that doesn't even make sense, since this happens with zero command modules present... I think. I give up.

Sadly TweakScale also has issues with MFT (I believe), most notably with parts placed in symmetry. Masses & tank capacities can go crazy when you scale something, often to the tune of thousands of tons of dry mass (if you multiply size a few times), having twice the fuel in a tank as its capacity ought to be, etc.

Based on what I've seen (could be horribly wrong!), TweakScale works fine in terms of changing the size of parts in B9. It doesn't work very well in terms of scaling the mass or tanks of switchable-mesh/switchable mas/switchable tanks parts, however. So it can be used, but it will not produce what you are expecting in many cases. Essentially, the mass and tank capacity of switchable parts reverts to whatever its non-scaled state is every time you do anything to a part you've scaled. So if you scale up a fuel tank, for example, it will appear at first to have scaled its mass/capacity correctly. If you pick up the part and set it down again, it will revert to whatever its mass/capacity is at 100% scale. I'm not sure, but I think that saving/reloading ships can sometimes correct certain parts of that problem temporarily. I left a message in the TS thread about Firespitter switchy parts, but I assume Biotronic is busy with real life at the moment since he hasn't been as present in the TS thread recently as he has been in the past. If you don't want B9 parts to change scale at all, you can do one of two things: 1. Just don't change their scale in the VAB/SPH - if you don't, they will work fine and TweakScale won't break them or anything. 2. Delete the .cfg that applies to B9 parts - probably B9_TweakScale.cfg in the TweakScale directory. Then you won't have the option of scaling the parts. Question for the authors: for those of us who love tweakscale, is there a way to hack together non-tank-switching parts based on the different meshes available without generating a whole bunch of work for you? E.g. a non-switchable RCS tank with the corresponding 2x1 or 1x1 part mesh so that we can tweakscale like crazy people? Stopgap until TS is updated, maybe...

Any thoughts on compatibility with Firespitter tank switching? Would be awesome for the new B9. Suspect you are very busy with real life, however.

Nothing other than "Input is null". Taverius said earlier that these errors may be benign, though they seemed to contribute very slightly to the occasional pauses my game experienced after extended VABbing - brief freezes that occur closer and closer together the longer you play until things crash. No clue where they're from, nothing else in the logs (as far as my limited knowledge tells me).

Well.. I don't know for sure that it was causing the gradual slowdowns I was experiencing (looks like it was maybe one small factor among others), but it spawned thousands (possibly tens of thousands) of those errors over the course of building one ship! My logs became ... very large. Good to know though, I can add the DLL back! Huzzah.

Well, one thing to report at least. I am not positive, but I believe the errors I've been getting have to do specifically with parts whose nodes may be toggled on or off. Here's how I have been able to replicate the problem so far: 1. Place any part in the VAB or SPH whose nodes can be toggled on or off. Can be the root part of a craft or not, same things happen. 2. Upon placement, no errors are thrown. 3. Pick the part up, and do one of two things: 3.a. If it's the root, simply click to put the part back down, anywhere. Many "Input is null" errors thrown. 3.b. If it's not the root, place the part successfully in any configuration attached to another part - if it's set down and shaded red, meaning not placed successfully (or however you call it), errors won't occur. Each time 3.a. or 3.b. happens, "Input is null" errors occur. The number of errors is equal to 2x the number of nodes that can be turned off or on. Hope that's vaguely helpful. EDIT: Also seems to occur when another part - possibly any part - is attached to one of the node-switching parts. Happened when I stuck a mechjeb box onto one of the 2x1 bays... Also, I should clarify before, TweakScale does not correctly judge the mass of mesh-switching/mass-switching parts in real-time, but it may do that on reload, not sure. My ships seemed roughly as ludicrously massive as they ought to be, but that doesn't mean the masses were correct after reloading. In real-time, it does the same thing it does for tank-swapping parts: if you put the tank in or swap the mesh, THEN scale, the scaled values will appear correct. If you scale, THEN swap, it will revert to whatever the non-scaled mass or tank capacity is for whatever you just switched to. EDIT AGAIN: This particular problem is not related to TweakScale; removed it and nothing changed. But it may be any of my other 9385492835 mods. Sigh.

I can only imagine. I'd probably be having nightmares about NullReferenceExceptions if I were you. I will do my best to figure something out and report back if there's anything to report.

Bah, I hate doing that, even with the 50% at a time bit. Too bad the logs don't read "THISDLL.DLL DID A BAD THING: Input is null (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)"

Do you have any pointers for figuring out exactly which mod is causing the problems I'm having? I've looked through the (very many hundreds of pages long) log, but don't always know what I'm reading...

Tweakscale works to some extent already, but it has trouble with any part that you place a tank in, and may or may not have other issues. I have been using it, but have had a very gradual slowdown/memory hogging logspamming somethinorother occurring - it might have absolutely nothing to do with TS, posted about it a few pages back, don't know that it was seen. Sadly I lack the knowledge to decipher exactly what's going on. EDIT: It does understand the mesh switching part (I think, though it may cause issues that aren't blatantly obvious), in that you can scale up and down a part that you've switched the mesh for without crashing or parts reverting their meshes or something like that. But tanks won't work correctly.

I don't know that this has ANYTHING to do with B9, but I can't figure out what's wrong - when I'm playing around with B9 stuff in the hangar (not a clean install), I get huge logspam of: Input is null (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) The game briefly pauses every now and then, and the frequency of the pauses increases over time until the whole thing crashes. I have no idea what's going on. Is it the tweakscale + B9 issues someoneorother mentioned? Output_Log here: https://dl.dropboxusercontent.com/u/59567837/output_log_Maybeb9ornot.txt

Very cool, thanks for the info!

Question - do the B9 landing legs (or any landing legs, actually) have any springiness to them? I am attempting to make a truly gigantic ship use those legs to set itself down, but it seems right now like they kind of just smack into the terrain. Is it possible to give landing legs suspension to absorb landing impacts?

Play with the tweakables, you will see that the divider can be removed with the 3rd or 4th tweak-menu item down, I believe.

Had a question about KAS - please correct me if I'm wrong (usually am), but right now you have to be controlling a craft with a winch on it in order to use the winch, right? Is it possible to make it so that a Kerbal outside the craft could operate winches and such without re-entering the ship, or some other method of operating winches and whatnot? I am guessing it's impossible based on how other stuff in the game works when you are or aren't focused on/controlling something, but thought I'd ask...

Reason I ask is because I was hoping to scale the parts up bigger without rewriting too much stuff. I'll try rewriting the TS stuff in the cfgs and see what happens.

Yes. 10char

That would be pretty usefull too for reducing the part counts of a ship - but yeah, at the price of more parts in the mod and more work for the authors =( Since I seem to be full of ideas tonight... Another part that would be neat would be a version of the HX1-A-SA Structural Module in 2x1 dimensions.

I had a question about tweakscale - I was wondering why many parts contain individual tweakscaleexponents definitions for mass, maxtranslate, whatever. All of these relationships seem linear: doubling size doubles mass, or doubles maxTranslate or whatever, like in the right angle extendatron part: Why not just define mass = 1 in TWEAKSCALEEXPONENTS as an actual exponent, which would then double the mass of the part when you double its size, of halve when you halve? This is how it's done normally for non-IR-related tweakscale, if I've understood things right. This would avoid the problem of having to edit every part in order to make new and ludicrously large tweakscaled robotic stuff, wouldn't it? Or is there something that doesn't work right if you apply an exponent rather than individual values per defined scale?

Sounds reasonable not to do it then. The HX4 without the pillars will be cool though! Another very minor thing I noticed with the hollow parts, and one that may only be apparent when they're scaled very large - I don't really know the right terms, but here goes: because of that frame at the ends (I think), and because the space on the interior between the frames is sunken slightly with respect to them (on the biggest inner face of the part), attaching things like docking ports on the inside results in them being visually not connected to the "floor." Very easy to work around by just putting a big flat panel on the floor, but might be visually nice to have a continuous flat surface for a runway/hangar bay/whatever effect. Not sure it's really important enough even to think about though. Speaking of big flat panels, only other suggestion I can think of off the top of my head - it's handy for building various floor-like surfaces or whatnot to have rectangular versions of the structural panel, e.g. cut the 8x8m panel in half to make an 8x4 and make two versions - one that surface attaches on long edge, one that surface attaches on short edge. I made a quick & dirty pure-white version of the B9 panels for my own personal use if it would interest you example-wise. I did similar things with the various triangular panels.