AccidentalDisassembly

Huh, actually I did have MechJeb installed - but maybe a different version? I was using the dev version 429 (or something like that). EDIT: guess you beat me to the punch on that one by a few seconds!

Last night I tried making a TweakScale config for BDArmory bombs - it didn't work particularly well (exceptions, can't attach parts in editor, bad stuff). I was wondering if you thought it ever might be possible to scale up bombs, mostly because I think it would be very entertaining to drop an absurdly large bomb on the KSC and see what happens. The variables I tried to get TweakScale to modify (in the MissileLauncher module) are: blastRadius blastPower explosionSize thrust cruiseThrust I asked Pellinor about BDArmory + TweakScale over in the TweakScale thread, and he said this: Do you think BDArmory could ever end up working with TS? I am just assuming that right now it does not like having its variables manipulated without notice. Would be cool!

Just out of curiosity - what is it that makes IR parts not function if node sizes are changed? Could that phenomenon be fixed to address the cause rather than the symptom, so to speak? On the other hand, if the node size isn't terribly important for joint strength, then that wouldn't really matter and might not be worth it. Does node size make a particularly important difference, or is it just a visual thing?

Uh, I guess if you consider forevermore having Kerbal run at 3 frames per second "without problems"... For me this happens every single time. New saves too.

Pellinor, have you ever tried TweakScale with BDArmory? I wrote a config for it with appropriate exponents for various values and everything, but it resulted in a glitchy nightmare (parts wouldn't attach in editor, exceptions thrown, stuff like that). Just curious if anyone has had it work - could be cool to scale up one of the BDArmory bombs to make a megabomb.

Although this contract pack seems awesome, I believe I am having a small problem with it. Whenever I accept the first kill-the-drone contract, then launch a craft with weapons, another craft spawns in the runway next to it and the game slows to a horrible crawl (~3 fps). The craft doesn't explode or anything, it just sticks there half out of the runway. The drone target also spawns off to the side of the runway near the space center, and it can be killed. Here's an output log: https://dl.dropboxusercontent.com/u/59567837/BDArmoryContractOddities.txt The first couple of times I tried this, I had RealChute installed, and it produced thousands of exceptions in RealChute. The log above doesn't have that - I thought it might be a RealChute conflict and uninstalled it to test. It isn't. EDIT: Accepting the "Training" contract makes this happen:

I think the one over here is IR-based..

If there isn't a necessary correlation between stack node size and joint strength, then maybe there's a way to override TweakScale's treatment of stack nodes just for IR parts - then maybe they could be scaled up indefinitely without breaking? Assuming the joint strength would still be reasonable. I am suspicious that IR parts start malfunctioning when scaled up specifically when the size of the stack nodes goes up an increment from 1 - so if it starts at stack node size 1, then they'd start breaking when scaled beyond about 1.41x (1.41^2 = ~2, increments to stack node size 2 because of TweakScale using exponent 2 for managing stack node sizes... maybe). I am not sure how to write a TWEAKSCALEEXPONENTS{} that would make stack node size increase with an exponent of 0.4 (rather than 2). I tried this, but it didn't work: Downside would be visual burial of the attach node within the larger parts, but not a terribly big deal. EDIT: Changing the ScaleExponents.cfg to have values of 0.4 for all the breakingForce/breakingTorque stuff also did nothing. Is there some other way to control TS' interaction with stack nodes maybe?

Welp, it was indeed the node sizes, or so it seems. How much do they matter, really? I didn't find a definitive answer to the question of whether stack node size affects joint strength, but I thought it did... Parts alone can work with larger stack nodes (at least when surface attached to something), but robotic part on robotic part = disaster. =(

Hard to describe the not cooperating bit, and unfortunately I don't have a picture. Essentially the patch breaks the telescopic parts - they will extend, but when they extend, they shift upward/sideways as well as outward, ones at the base don't extend fully, etc. I don't understand it either, since I also couldn't figure out how those parts could conceivably be different than the others... all I was doing was changing the exact same variables as for the other parts, didn't change the SCALETYPE or anything else. I also couldn't figure out why some legacy parts (like gantries) broke in a vaguely similar way when doing this... It's possible it was just some error/typo when I was making the MM config too, I just left it out because it was still broken. Yeah, the @rescaleFactor *= 4 definitely wrecks stuff, but until TS and IR play together nicely for upscaling, it's at least one way of having larger IR parts without duplicating everything (a method I've also tried) and therefore cluttering your part list. Is there a way to do this without breaking things? Duplication was the only thing I could think of. EDIT: Added the telescopic parts back to the patch. New behavior I haven't seen - now they explode when you extend them. This is the starting point: When you press the control to extend them, they do begin moving outward. If you just press it for a moment and extend them a tiny bit, the craft will begin rotating (constantly) counterclockwise. If you extend them farther, they explode. Beats me... Totally guessing, but could there be an issue with these parts specifically and the new nodes sizes I apply? Works OK for the other parts, but they aren't usually in robotic-on-robotic-part chains. EDIT AGAIN: Aha! That's got something to do with it - when I place other IR parts (rescaled) end to end - one robotic part on another, oriented correctly - they also cause weird forces in the ship and explode if moved too far. Huh. So much for the patch as is. =( I seem to remember this phenomenon with the stacked telescopic parts being less pronounced when in an original iteration I tried using stack nodes of size 2... not sure about that though.

Numero uno: the new plugin, the new interfaces, the new (I think?) amount of control you have over the speed of parts, presets, all of that are awesome. I love it all. Secondly: If, like me, you are irrationally frustrated with the limits on the maximum size of robotic parts, I've got a workaround-ish solution until TweakScale interaction is improved (if it will be). Here is a ModuleManager patch that does the following things for Rework parts specifically - not for Legacy: Things: All robotic parts can now be scaled at relatively fine increments from 0.25x their original (normal) size to 5x. HUGE! Wooooo! Trusses and wheels can also be scaled at these fine increments, though I didn't allow for wheels to become huge since I just don't know if they behave correctly when enormous. You can easily change this if you want. The mass of robotic parts except at the smallest scale is increased somewhat (most Rework parts originally: 0.1t, my changes: 0.3t); this gives them slightly stronger joints. Smallest-scale parts now weigh ~ 0.02 instead of 0.025ish. Much simplified TweakScale stuff - fewer SCALETYPES to edit if you want to fiddle with scaleFactors or what have you. Hides the three pointless (I think? I just couldn't figure these out) half-size Athlete trusses. Downsides: Biggest downside: when placing parts, they start out huge and you'll have to scale them down for normal-sized ships. This is currently unavoidable if you want parts more than 1.5X (or so) the size of the originals. Telescopic pistons didn't get upscaled - they don't cooperate and I don't know why. Maybe someone else can figure this out. You can still make trusses match their size (or pretty close) since they're made to freescale. Heavier robotic parts could be a downside too. The original SCALETYPES for reworked parts had a cool system of matching names of scales to absolute sizes of parts - this is somewhat broken with my system, but only for half-size bits like RoboTruss Lite and RoboTube parts, wheels too, I think, and maybe some others. I.e. a RoboTruss Lite part at "2x" scale will no longer exactly match every other part scaled to "2x". I think the bonuses outweigh this. No Legacy part support. They break like the telescopic pistons. Also don't know why. Didn't mess with electric charge required, so that will be way off - maybe in another version. With some fiddling, this same thing could be done to allow 8x or 150x (or whatever) size robotic parts too, though they would be really annoying to place in the editor. FYI: I'm totally guessing on reasonable masses for the scaled-up robotic parts, so tweaking is probably needed; maybe some stuff is totally broken. Feedback welcome!

For future renditions of LLL - on page 220 of this thread, MrWizerd gave a link to some extra parts, some of which are included in the LLL download, some not - the ones that aren't are pretty useful though, like the 3-stack of 2x1 tanks and the various adapters (4x1 to 3x1 and such). Would be great to re-include a couple of those!

Sorry if I'm just dense and missed it somewhere, but I was wondering - let's say you make a craft that's basically round and you want to attach 4 or 6 wheels to it radially, like in the following picture (seen from the top or bottom, either way). Imagine an MKS module or something that you drop onto a planet, I guess. The red lines in the left-hand diagram represent the directions (I think, right?) the wheels would face when placed with radial symmetry. Is there an easy way, or - since they rotate through the magic of IR - is there some neat command that would make all the wheels line up and face the same way, like on the right in the picture? And then you could just rotate like normal with IR and have the thing translate really easily. Might be a neat feature for the wheels if it's not in there already and I just missed it. Also, though it's unrelated to the wheels, a really handy part (for me, anyway) for the rework pack might be an angled piece for the rework trusses (a short bit of truss bent at 15 or 45 or something degrees) and/or a hub for them too, though it is certainly possible to use the stock node thing if you scale it up.

Just playing around with the newly redone parts packs and whatnot - I think there's something strange going on with the stackable extendatrons, though I don't see why, they look awfully similar to the ones I'm used to and I'm pretty sure they have the same max extension in the config... They keep moving past the visual limits of their models when fully extended: Non-stackable versions don't have the same behavior < Oops, that's not accurate. EDIT: After playing around with it a little more, I think *maybe* it has something to do with sticking duplicated IR parts on other IR parts (or something). Take a look at this next image: Steps to reproduce what's happening in the red-circled parts: 1. Make craft, put stackable extendatron on craft. 2. Scale that extendatron up one to the maximum. 3. Duplicate that extendatron, scale down one, then repeat this step until you have a complete stack. Strangely, the base (largest one that was duplicated to produce the others) doesn't extend out very far... EDIT AGAIN: Actually, if you follow those same steps for the green-circled non-stackable extendatrons (place, scale up, duplicate, scale down, duplicate that one, scale that one down, etc.), they will also have the same problem. Otherwise stated - if you stick another duplicated smaller extendatron on the end of the one circled in green, problem happens. I am going to take a wild guess that something is happening with TweakScale + the extension range of the part + duplication, maybe? Dunno...

That's fine if you don't want to, your work, so your call, obviously. Though I would argue it would be a shame to only half support TweakScale. Sadly, I wouldn't know what to request you pull, but I can at least do teensy bits of feedback re: exceptions and the like. New version on a (relatively) clean copy of KSP throws an exception when placing the first IR part after loading the VAB scene. Steps: 1. Load VAB scene, place a part or two, then place first IR part onto those. Exception thrown. 2. Doesn't throw more exceptions when you place additional parts, remove and re-place. 3. Re-loading VAB scene (exit and re-enter to same craft or doing a new craft) resets whatever is going on, and placing first IR part will again throw exception. Log: https://dl.dropboxusercontent.com/u/59567837/output_logNewIR2.txt

I am loving the changes in IR, but it's pointless to have a tweakscale config that allows sizes above 199% or so if the bug with scaling IR parts up that large hasn't been resolved... Again, it is extremely easy to replicate. Just scale a part up past 1.5x or so, then go try to use it. For example, scale a powered hinge to 400% in the vab, launch, attempt to move it.

Huh, that's just bizarre. You would think that the amount of resources in a part (logically, but since when has that been a hallmark of KSP's programming?) wouldn't affect the rigidity of the connection. Part mass independently of resources, sure... Sounds like something Squad ought to but never will address =( I guess maybe a workaround could be something like adding negative mass in a non-connected part of the ship? Though that would be equally bizarre.

A question I asked some time ago, but might be interesting still.. I am pretty sure that the joint stiffness of IR parts is affected by their mass. I am fairly sure of this because I've made scaled-up versions of the parts with much higher mass (multiple tons), and they seem subjectively to be much, much stronger than normal-sized IR parts (can support lots more weight before wobbling like crazy, for instance). Would KSP die a fiery death if you introduced a resource with negative mass? Here's what I was thinking: Make IR joint parts really massive so that they're very rigid (or just more rigid), then introduce some kind of negative-mass resource to cancel out some of that mass to make the overall system a reasonable weight. Or make the parts have high mass, but some kind of magical anti-gravity effect less than their mass, or something. Possible? Ridiculous?

Will it function as a shock absorber too? looks pretty awesome - a big version for gigantic planes would be cool as well. You mentioned before that a long, thin hinge (one you could drive over, attaches a ramp to another flat bit, for example) was on your to-do list, is that something you happen to be looking at for the next release?

I'm obviously pretty fixated on the tweakscale stuff, haven't really seen much else. Fixing TS interaction (if it's even IR's fault!) would be pretty awesome, though!

Yeah, everything is updated. I don't know what was going on, but I'm not sure *I* can reproduce the issue either. If I somehow can, I'll try to provide more info, but right now I'm going to assume it was some fluke or one-off issue with my computer or something like that. Sorry!

It's the very long-standing issue IR has with tweakscale - you can easily reproduce it, too. IR parts can be scaled down without any problems (that I've seen, anyway!), but they can't be scaled up past a certain point (something like 1.999x size, but it doesn't seem absolutely consistent). To reproduce, just go to a clean copy of KSP with only TS and the new IR release, then try to scale up a hinge to 4x size. Go into flight mode, attempt to move it, you'll see what I mean. It doesn't produce exceptions, I don't think, it simply doesn't function like it should. Sometimes, you can see slight movement in the parts (or really bizarre, off-axis, wrong-direction movement, specifically with extending parts - I think). Somewhere else, someone mentioned (speculated? I don't know) that it might have to do with changing node sizes on an IR part via tweakscale. If that's true, it would be a TS-specific issue, since it is very possible to re-scale IR parts manually via config editing and give them gigantic stack nodes with no problem. Maybe it's the attach node? Just guessing wildly. When rescaled via config editing, IR parts do ​work at much larger than normal sizes. Also - if I could make one request, it would be to remove TweakScale from the part configs themselves and apply ALL TweakScale stuff via MM config. It is much, much easier for an end user like me to work with that way.

Hmm, I think I must have posted the wrong log, because the copy of KSP I was using to test the new MechJeb doesn't have Clouds/Realchutes/EPL... Was it not this log I posted before? : https://dl.dropboxusercontent.com/u/59567837/output_logNewIRException.txt Also, what about the long-standing TweakScale issue? Possibly the relevant bits:

Awesome! The one piece of feedback I have so far is that the problem with scaling IR parts up with TweakScale does not seem to be solved. That would be a really, really nice feature to have for absurdly large robotic contraptions. Otherwise... the new interface is much improved, and the whole presets idea is great, I can see that being very useful (toggling between "stowed" and "deployed", or things like that). EDIT: Second bit: when I made a preset (fully open) on a hinge while in flight, then activated that preset (hit the next preset button), IR threw an exception. Log: https://dl.dropboxusercontent.com/u/59567837/output_log_EPLexceptionsMissionManager.txt

Log: https://dl.dropboxusercontent.com/u/59567837/output_logMCMVABLag.txt Other mods: Toolbar CommunityResourcePack CrossFeedEnabler DDSLoader ExceptionDetecter Firespitter (dll) RasterProp bits Regolith ToadicusTools TweakableEverything (maybe this is the culprit?) Nothing in USI except Kolonization I dunno - maybe MCM models are just more complex than ones I'm used to? That could be it, too... beats me. EDIT: Also, quick note about texture savings steps on your second post: if users still want the Radial Tank to work, they need to keep DECAL.png, Tank_N_NRM.png, and TankBase.png in the assets folder - since RadialTank.mu and its corresponding cfg weren't mentioned in your delete list