AccidentalDisassembly

Oops, maybe something changed in a recent version? Assuming only stock & tweakscale are installed, then, the base mass of everything goes up at 2.5 exponent, while mass of resources contributes appropriately? It used to be 3 for mass, anyway...

I think you mentioned something like this before, but if you want to change it so that all of the parts have a freescale-ish way of scaling, I'd personally much, much prefer something like this: SCALETYPE { name = thenewscaletype majorScales = 0.625, 1.25, 1.875, 2.5, etc. minorIncrements = free / 0.25 /whatever maxScale minScale otherstuff } It could operate with two sliders, kind of like Infernal Robotics does for speed control (or something, can't remember) - one slider for major changes (i.e. stack size changing), a second slider for minor increments. Just an example - I'm sure there's a better way, and actually B9 procedural wings have a pretty good interface right now. My thinking here is that I would really like to be able to increment the part to standard stack sizes or to any size I define, like I can do now with normal, not-free scaling (I changed the "stack" scaletype to include lots of different sizes). Then, depending on the part, it could theoretically be useful to fine-tune the scale (especially for parts that aren't REALLY 2.5m or 3.75m scale, or whatever, to make them match up with stock or other parts). But here's the rub: the reason free/surface vs. stack scaling exist as two separate things right now is that scaling many surface-attached parts according to "1.25m, 2.5m, 3.75m" or any other sizes with discrete measurements makes no sense. Sure, some surface-mount parts have discernible 1.25m bits on them, or whatever, but think about radially-mounted engines: let's say they default to 1.25m in the SCALETYPE - well, they may or may not actually be 1.25m in size to begin with, so scaling them to 2.5m might make zero sense and not be intuitive at all. I don't think it's possible to eliminate the difference between stack-style, discrete-step scaling and surface/free scaling and still have things make sense. But: I do think it's possible to combine all surface scaling into the free-scaled regime, so long as you leave major size-increment options that are appropriate for surface-mounted parts that actually are 1.25m or 2.5m or whatever in size: in which case 1x, 1.5x, 2x, 3x, 4x, 5x, 6x sizes would be apporpriate, or however big or small you want to go, with a second slider allowing for fine-tuning if you want (or something). Another thing to think about: one of the major limitations of current TweakScale configs and SCALETYPEs is that scaling engines up produces useless monstrosities, while scaling them down produces ridiculous TWR. Thrust increases as a square, mass increases as a cube - or decreases as a cube, where thrust only decreases as a square. I would propose: 1. Create new SCALETYPE(S) with different mass scaling for engines - probably TWEAKSCALEEXPONENTS { mass = 2.2 or 2.5 or something} 2. Create an MM config that runs last in the order, searches out every engine part that has a TweakScale module, and applies this scaletype to them (maintains all the default scaling and whatever) Or something along those lines. I bet I can cook up a glitchy version of each right now: MM Patch that probably will break everything: Or this might possibly be better, it would catch surface-scaling engines too, maybe? Thought it would override any custom scaletype's mass scaling, if that's a factor. Yet another option would be to do what I've done personally, which is edit every single TweakScale config so that engines have the stack_mid scaletype (and some other parts too)/ - - - Updated - - - That's the problem with scaling up IR parts? Holy crap! I think you could define a custom SCALETYPE that makes the node sizes stay identical, maybe... not sure on that one. I think node size is determined the same way mass is, so it maybe should be possible... Would that mean that joints on large IR parts are really, really flimsy? EDIT: I take it back, nodes do this: attachNodes { breakingForce = 2 breakingTorque = 2 } So breaking forces are controlled by TWEAKSCALEEXPONENTS, but I don't know how node size actually ends up getting done.

Uh... There's a big red word "Download" and right under that a link to the file on dropbox.

Yep! Pretty efficient. But you do end up saving a little bit of memory if you do the MCM - I'm guessing it's almost entirely precisely because there aren't two different sets of parts with it. Compared to Squad, both are unbelievably efficient.

Thank you, that's helpful as well - I always feel dumb when I jump to the conclusion that some part / mod isn't working correctly only to discover it's my lack of knowledge that's the problem. =( Didn't even know it was possible to (apparently) stall the tail completely, so that cranking the control surfaces wouldn't have any effect! But apparently this is quite possible.

OK - but what happens is that it does bounce around, and eventually sort of "settles" at a very low angle of attack (relative to the velocity vector on the navball) - so that makes perfect sense. But what doesn't make sense is, when I am still holding down W/S, now, nothing happens. The whole plane is pointed just a few degrees up from the VV, and visually the elevators are cranked to the max, and the nose does not rise. AFTER it's done bouncing around... But maybe this is what tail stall is, and I just haven't understood that. That's good to know, and tells me it's at least partly (maybe mostly) the fact that I was using huge elevators, but I just don't get why with stock elevons, it also bounces, suggesting too much control area (I used 4 total elevons on similarly-sized non-moving elevators), but it "bounces around in a full circle", so to speak, whereas with the B9 all-moving pieces, it jerks hard, bounces back, then just stops. Roughly the same amount of initial over-steering with each set of surfaces, but the stock ones still provide force when I'm holding W/S once the craft has come back to a state where it's pointing more or less forward again instead of at a terrible AOA.... I even put the stock elevons at the same height on the tail in case that had something to do with it, but they still worked where the procedural ones ceased. I know, and if you'll notice in my post, I tried with smaller control surfaces (maybe 1/6 the area). But I'll try with even smaller surfaces and see if that was the issue. I guess what makes me suspicious, too, is the weird behavior with spoilers - another control surface deflecting vertically that ceases working if you hold down B (like holding down W/S) - unless no one else has issues with the spoilers either... EDIT: Thanks to everyone who responded, with your help I am able to determine (with reasonable certainty) that all of this is just a question of me not designing things well. Thank you! Spoilers are still a mystery, though.

OK - there's definitely something strange going on with these procedural (all-moving) control surfaces, but I am not sure whether it's a product of me not understanding aerodynamics, or something actually wrong - I'd appreciate some feedback. It's specifically a problem when the control surface is held at maximum deflection, I think, or at least most apparent then - like I described earlier for the spoilers that cease working if you hold down B, but work fine if you pulse it. I get that this is probably a FAR issue on some level - but is it possible that these procedural parts are not delivering the right "shape" to FAR, or something? Sorry, I just don't know enough about how it works to know whether that question even makes sense. I thought at first it was a lack of control surface area, but I don't think that's it. Here's the plane, for reference - I mean, I think the elevators are definitely (apparently) big enough to force pitch enough for a loop with the plane, right? : But in fact doing a loop is impossible. Here are the symptoms: 1. When I at first press W or S to engage the elevators, the plane jerks sharply up or down. I figure this is normal - those elevators are huge. 2. If I HOLD W or S, however, the apparent force pushing up/down on the tail seems to decay rapidly to zero. It's like the only thing that's actually then rotating the plane is the reaction wheels in the cockpit. 3. I thought maybe my design was just crappy, so I repeated this with stock elevons. Problem does not happen - still a crappy pitch-wobbling design, but it wobbles all the way over in a loop at a relatively constant overall rate of pitch. 4. This does not apply to procedural control (not all-moving) surfaces used as ailerons - I can roll constantly, just fine. 5. The problem doesn't seem to apply to the all-moving procedural control surface used for yaw, either - only pitch, but a little hard to tell with the yaw. 6. Thinking the problem might be that the elevators were just too huge, I tried a different (smaller) size of procedural all-moving surface. The result was REALLY weird pitch behavior - hard to describe. Relatively normal speeds here (100-250m/s, tried at different speeds). You'd think that holding W or S would cause the plane to continue pitching up or down, but it doesn't. It *feels* (yeah, yeah) like there's some weird response curve or something associated with holding down the key (or with reaching maximum deflection, or something) that just makes them stop working. As if the shape FAR is seeing on the elevator is maximally deflected at first when you press the key, rather than after holding it down for just a moment. Anyhoo - I can take this over to the FAR thread, too, or post over there, but thought I'd ask again since I don't see the same behavior with other control surfaces (but still with FAR). Maybe another mod is interfering too - I use a lot. Am I the only one who has this experience with all-moving control surfaces used for pitch, and other control surfaces used as spoilers?

For those curious exactly how much texture area you can save using MCM if you delete all the textures (EXCEPT the optional ones) in the second post of the first page, here's the answer: Total pixels of textures used by MCM (full res, no ATM compression, etc.) = 15.89248 Mpix Total pixels of textures you can delete from MKS/OKS (NOT including optional) = 30.67904 Mpix So apparently MCM provides the same functionality of MKS/OKS parts using 50% fewer texture pixels (ish). If you're even more curious, MKS/OKS uses, grand total, this many textures of the given dimensions:[TABLE=width: 400] [TR] [TD]64x64[/TD] [TD]8[/TD] [/TR] [TR] [TD]128x128[/TD] [TD]2[/TD] [/TR] [TR] [TD]256x256[/TD] [TD]21.5[/TD] [/TR] [TR] [TD]512x512[/TD] [TD]49.5[/TD] [/TR] [TR] [TD]1024x1024[/TD] [TD]10[/TD] [/TR] [/TABLE] The 0.5 textures correspond to ones where one dimension is half (256x128, 512x256). MKS/OKS grand total: The equivalent of about 24 textures of 1024x1024 size, or (maybe?) ~96MB of RAM. I have no idea how much RAM a texture takes up, though, but the Google told me maybe 4 bytes per pixel. EDIT: Another fun comparison: Squad's folder (and I didn't even count ALL the textures) has the equivalent of about ~218 textures of 1024x1024 size. My personal conclusion based on an incredibly superficial knowledge of texturing? Squad's texturing is ludicrously inefficient.

Aha! I have had this same problem, and am glad you've figured out what the mod combination seems to be that causes the problem! I couldn't figure out why some KAS stuff would give me 100,000+ entries in the log, others wouldn't.

Fair enough, but wouldn't there only be one adapter required? a Mk4 to Mk4 adapter? Cockpit -> Mk4 normal to Mk4 1.5 adapter -> all the other parts are just scaled up? I'm probably just not remembering a few parts here that wouldn't fit anymore.

Another thing possibly to look at - don't know if it's TweakScale's doing or TweakableEverything, but funny things happen to things like decouplers' ejection force when things are scaled and you're using TE.

But this all assumes that every maker of parts will use size 1 nodes specifically for 1.25m parts, size 2 for 2.5m parts, etc. etc. What about intermediate sizes? I don't recall intermediate node sizes even existing (is there even such thing as a size 1.58 node?), so what happens with something like a 1.5m or 1.875m part? Granted, there are fewer of those. What if I just want a strong connection on a 0.625m part and give it a size 4 node? Etc. etc. I dunno. Maybe it's not a lot of work - and obviously you can do whatever you want, I'm not the one putting time into this! I do think the chain scaling has more possible uses, though, since you could just totally resize an entire craft with it (in theory), or an entire subassembly, or something like that.

To be honest, if it were me working on this (and thank goodness it's not, because I can't code), I would completely abandon the very idea ofautoscaling. Needless complexity, and it takes time you could dedicate to other things. There are so very few use cases for it - and in every single one of those cases, the drawback is just having to click on a part you just attached and scale it to whatever value it's supposed to be. Then, you can just duplicate that part if you need a bunch of them. It is a clever idea for the sake of a clever idea and not one that is really necessary or useful for the function of the mod in *almost all* cases. Stack nodes are a terrible way of determining the size to which a part should autoscale, too - they do not necessarily correspond to the part's size, and especially not the size at the location of the particular stack node in question. That further reduces the number of cases in which autoscaling scaling actually make sense. Really, you would need to add a value to every single part in the game such as "actualsizeofthispartatnode_1 = 1.28985m" to implement autoscaling in a meaningful way. My two cents, others may disagree. UPDATED the post because I included chainscaling without thinking about it. Really, I mean autoscaling.

If you're interested in stuff to put on "the list" for TweakScale's future... I have two things I can think of off the top of my head: 1) Infernal Robotics *full* support. Yes, it sort of works right now - but very weird things happen when you scale IR parts up. Scaling them down (like their default configs allow) works, but even if you write a correctconfig for scaling them up, weird things happen after 1.5x or 2x size. 2) Updates to scale exponents for the new way Regolith does resource harvesters and converters - fully compatible scaling for drills and distillers and whatnot. For drills, the amount of resources extracted currently can be made to scale easily, but don't know about the other stuff (like electricity consumption - the recipe inputs). For converters, I just couldn't figure out how to correctly write a scale exponent thingamajig because of the lists of values Regolith uses in its configs. Thanks for working on this! It would have been immensely sad to see TweakScale founder and die.

I like the look of the new parts. Can I make a suggestion, though? When you finalize your designs, can you include an adapter part that would allow seamless(ish) tweakscaling? For example, let's say you make an adapter for the Mk3 cross-section to Mk4 - if at the same time it would somehow be relatively easy to extend the adapter so it goes from Mk3 to 1.5x-scaled Mk4, then you'd essentially have a 2.5m and 3.75m spaceplane system in one. There would probably have to be a Mk4 cockpit to larger-Mk4-fuselage adapter too, etc. etc. Having just a few Mk4-Mk4 adapters to allow tweakscaling would (just IMO) very greatly increase versatility. May not be many people who feel that way, though, and since I know nothing about 3d modeling, I don't know how easy or difficult it actually would be to fiddle with adapter cross-sections to produce appropriate pieces... Nor do I exactly know what that would look like an whether it would look funky in the end. Just two cents to consider. One possibly crazy idea would be to somehow replicate what was done with a couple of the MRS/SpaceY adapters, where one part can serve for multiple sizes/ratios.

Aha, my fault, you're right - I didn't even notice the first couple times I looked! Not identical.

FYI - many tanks are incorrectly labeled as 2.25m - 2.5m is the standard size. EDIT: Also, the three parts in the FuelTank/Radial_Adapt_LG directory are all still identical.

I've had 100,000+ instances of that error (I think) when messing around with KAS stuff, but couldn't pin down the exact circumstances...

Okie doke. Weird that it would work just up until it hits max deflection... ah, the magic that is KSP, sometimes =) I can confirm though that if the control surface is not currently being used as a spoiler (you're not holding , it will work just fine as an aileron. Though weird yaw-ish forces do seem to occur if you hold down B for long enough as well, hard to say whether that's anything to do with the spoilers though.

Hi Bac9, I have no idea if this even relates to your mod, of if it's a FireSpitter thing or whatever - so sorry if this has nothing to do with your wings. Noticed an odd behavior with spoilers. Here's how to replicate: 1. Create craft (whatever you like) using your wings & your control surfaces. I used your control surfaces on wings specifically. 2. Allow spoiler behavior on ailerons, and set to maximum deflection. (I don't know that max deflect matters, but it's what I did) 3. Launch craft, get in air, activate spoilers. 4. Watch how quickly airspeed decreases at different deflections. You'll notice that if you hold B for max deflect, the spoiler effect seems to stop working, but if you pulse it so that the control surface remains at something like a 65 degree angle (or less), the spoilers do work. Short version: spoilers don't work if you hold B and keep them at max deflect. Does this have anything to do with your particular control surfaces, or is it something else?

My god, that was it... Bah. I'm so used to buying everything as soon as it's researched that I forgot I was doing a little experiment on this save where I would buy parts as I use them to see which ones I never actually touch! Thanks!

Had a question - I'm having a problem where certain parts, which do have the correct modules in them to be grabbable and storable in KAS (like the EL survey stake), don't appear in the list of available parts when editing a KAS container. I.e. when I right click on a KAS container to edit it, there's a list of parts there I can add, but many parts are absent from it. Any ideas on what might cause this, so that I can go figure out what's wrong? Could a bad config (or something) cause a whole bunch of parts not to populate that list...? Don't want to reinstall all my mods one by one and whatnot =(

Sorry if this has been reported before (and/or is not meaningful), but PlanetShine consistently produces an exception every time I load KSP. It looks like this (a little before & after provided):

Yeah, yeah, it's nitpicky, but FYI - for the extendable RCS "boon" part, unless there's some inside joke going on - it should be "boom."

Awesome. Another FYI - I really like these parts! Very well done.