AccidentalDisassembly

I would say that for me personally, an updated, lightweight plugin combined with parts like you had in .07.1 would be perfectly functional and would cover all the bases: part costs something, adds mass, makes it so that you have to make a slightly larger craft in order to get the additional functionality, therefore gives a slightly greater challenge if you want to return experiments to Kerbin, etc. - and I also found the ASAS model and the others worked pretty well. If you really wanted to, you could fiddle with textures a bit or something, but no need to reinvent the wheel. If you want to limit capacity, I'd say just pick a number of experiments (doesn't matter how much data) each container can hold, vary that by part size, and then don't worry about moving science around: simply give a right-click option on the drives to "collect" and then, when collecting, you get to pick the experiments you put in the drive. Once they're in, they're in. Just options, I guess, but it sounds like you could at least apply your plugin to the parts you already had set up and make an "official 0.90 version" (with infinite storage - I mean, pods have infinite storage right now, don't they?) quickly while thinking over whether or not the other details are worth it.

Here's a log regarding the multiple stock toolbar icons: https://dl.dropboxusercontent.com/u/59567837/output_logPilotAssistIcons.txt One icon gets added per scene change, more or less. Here's a screenshot:

Quick bug report: ALT-clicking to duplicate a part that's been scaled results in incorrect node placement - the nodes are where they would be for the original part size, not the scaled size of what was duplicated. (1.49) Steps: 1. Place part, scale it up or down 2. Alt-click to duplicate: look at node positions

Having to put an extra part on the ship (extra mass) is a nice balancing effect too, though - more mass, but easier operation of a given vessel. But not strictly necessary, except that if you did the MM option for cores, that would mean probes could now collect tons of science results whereas only kerbals could before... Dunno if that's important. Maybe you could patch it in for pods, but require a part for unmanned stuff (so that probes would have to have a little more mass in exchange for the new functionality)? Just random thoughts.

Effing awesome. Thank you!

Cool, thanks. And also, just to check, does ATM double check every time KSP is started whether the textures in its cache are still needed? Meaning if I delete a part folder with a texture in it, ATM won't still load the texture from its cache?

Pretty sure right now the converter ignores any changes you make to the Minimal Res for Conversion fields...

Try going to a different body and then returning to the KSC, if you wouldn't mind...

It wouldn't be "realistic" (whatever that means) or nearly as good, probably, but if you want to avoid the problem of order, I guess you could ignore data size and instead just store a certain number of experiments per part (if that's even possible), assuming it's going to be horrible to try to figure out a complete storage solution where you can choose what goes in, take stuff out, rearrange, etc.

I'm getting 5 or 6 different icons in the Stock toolbar for Pilot Assistant - this limited to me, perhaps? EDIT: One is added every time I launch a mission.

Sorry if you did answer this somewhere, but I read for pages and couldn't find one: can you explain how the min_size variable in the ATM config works? I could see it working in either of two ways: 1) A texture's dimensions must be bigger than min_size in order to be scaled in any way, and then it is scaled according to the number defined above (scale = X). Example: Assuming 512x512 image, scale = 4, and min_size = 256, the image will become 128x128, because the original was over the threshold 2) The result of scaling a texture can't be smaller than min_size, and scale will be adjusted as necessary not to break this rule Example: Assuming 512x512 image, scale = 4, and min_size = 256, the image will become 256x256, and then I assume textures less than 256x256 aren't rescaled in any way. The reason I ask is that, given how long it takes to go through all the textures the first time, I'd really like to get it right on the first try, and these two understandings of min_size will produce rather different results, I think.

Haha... sort of, you start to... drift, I guess, when you start warping. It seems more like "hey, let's just change some numbers and also make time go faster" rather than multiplying stuff.

Hi Biotronic - or someone else who knows: I had a question about technology tree interaction with TweakScale. I know you can already write a SCALETYPE that defines particular tech nodes at which given scaleFactors are unlocked (or at least I think that's possible.. isn't it?). The question is this: is it possible to determine how much scaling either up or down (as opposed to which specific sizes) can be done according to unlocked tech nodes? I hope I can explain this decently - maybe an example or two will help, because I don't really know how to phrase this so it's not ambiguous what I'm talking about. Assume you have a SCALETYPE with "scaleFactors = 1.0, 2.0, 3.0, 4.0, 5.0" and a part whose defaultScale is 3. Right now, you could, for that scaletype, define tech nodes that unlock particular scaleFactors. Heavy Rocketry could be required in order to scale the part to size 4, for example. However, that also means that if you apply that SCALETYPE to another part, but one with defaultScale 2, it too can scale to size 4 when Heavy Rocketry is researched - in other words, unlocking that same tech node allows you to double the scale of the size 2 part, whereas you can only increase the size 3 part's scale by 33%. Is it instead possible to define a number of steps up and/or down a part with a given scaletype can be scaled, regardless of the size at which it starts - without having to write a custom scaletype for every original size of part? Example: unlocking Heavy Rocketry allows one step up in the scaletype you've defined, no matter what scale the part starts at. So a part of defaultSCale 1 may now be scaled to size 2, a part starting at defaultScale 3 can become 4, etc., but a part with defaultScale 1.0 can't be scaled to 4.0 anymore. Anyhow, I thought that'd be a really powerful way of limiting what kind of scaling you could do (and WAY easier than writing tons and tons of custom scaletypes) according to tech progression. Can this be done right now? Is it something you'd be interested in? Finally, I have rewritten SCALETYPES and configs and whatnot for tons and tons of mods with what for my own personal purposes I consider more versatile scales (mass = 2.5 or 2.6 rather than 3 for engines, 2.2 for really hollow parts, more increments for the surface scaletype, stuff like that). I'm happy to rewrite and share some configs and some SCALETYPES, but would you be interested in expanding how the default SCALETYPES you include right now work (stack, free, surface etc.)? I.e. is that something I should clean up and send to you - would you want to use stuff like that, or do you prefer it more how it is now?

If there's any way to address the physics warping - I mean, if it has anything to do with your modules rather than the game engine or whatever (maybe TimeControl, once that appears for 0.90?) - it's really useful for the otherwise very, very long rover missions where you're asked to visit multiple sites etc. Regular wheels go crazy on warp too (you can kind of drive sideways on them), I suppose, but you can still drive around real fast =)

If it doesn't, you could at least make an RCS part with a ludicrously high ISP that also takes EC to run as a stopgap, I think

JUST now stopped giving a 401 error for me - timing, I guess!

Sadly, there's no file at your link. Is KerbalStuff just not updated...?

Unless I'm mistaken, you're misreading: You still need EPL if you actually want to build stuff, it's just that MKS also has parts and a resource gathering and refining process that will allow you to do this, and therefore, if you choose, you can not use certain parts from EPL. But no EPL = no buildy.

Hmmm.. as for the efficiency, I think you'd still need a second part - unless you specifically wanted to simultaneously unlock a bigger part size and have the bigger size be more efficient, which is totally doable. You can (I think) define what tech levels allow you to scale to what sizes... though I'd have to look into that. That said, you could still have fewer parts - you could have one part with a certain efficiency ("V1"), and maybe a certain texture, unlock at tech node A, and have it be scalable up and down however you want. You could then have a second, more efficient part open up at tech node B, also scalable up and/or down, but then you'd just have two parts instead of 6, let's say - 0.625m V1, 1.25m V1, 2.5m V1, ... 0.625m V2, 1.25m V2, etc.

Not necessarily. It's also something you can do purely via MM config, no need to hard code anything - the mass of the part would also scale with its volume, and the same with electric consumption, so there'd be a downside to having a huge science hard drive too. If the 1.25m version was mass 1, held 10 science data, and consumed 1 EC per hour, the 2.5m part would be proportionally identical (mass 8, holds 80 data, consumes 8 EC per hour). But you could do whatever you wanted to those numbers, and you could even specify that the part must consume 98.3 EC/hour when it's 2.5m, but only 17.2 EC/hour when it's 3.75m. Then again, it really might create crazy imbalances that I am not thinking of. EDIT: Really though, to clarify, the benefit (if you do want to use TS) is that you could create one part, one texture, and have that same part work on any size craft and for any amount of data depending on how big the user wants to scale it.

Have you had the same issue I did where the repulsors didn't repulse any more at faster physics warp speeds? Bizarre...

Yeah, don't think it causes any problems - just the little popup that says "hey! you have an outdated version!" on startup. Just thought I'd mention in case you hadn't seen the KSPAPI update - turns out you had!

Thanks for updating this, it's so much better than the Elmer's glue that holds things together in stock.

Depending on how your rewrite works (how you define how much science can or can't be stored in a part), it's actually pretty easy to use TweakScale to make it so that a given value (let's call it ScienceCapacity) scales with part size. Assuming that your module's name is SirDargon'sModule, and that the variable you want to control within that MODULE{} is ScienceCapacity, you could write a config with this in it: TWEAKSCALEEXPONENTS { name = SirDargon'sModule ScienceCapacity = 3 } ^^^^^^ That code will tell TweakScale to modify a MODULE{} that looks like this: MODULE { name = SirDargon'sModule ScienceCapacity = 92830515.85 (or whatever value) } ... and the result would be that the amount of ScienceCapacity in the part will scale in proportion to its volume. Halve the size of the part = 1/8 the ScienceCapacity, double the size of the part = 8 times as muhc ScienceCapacity. The "3" is an exponent applied to the factor by which you are rescaling the part (factor of 1/2 and 2, respectively, in my example), then multiplied by whatever ScienceCapacity the part originally had. You could change that exponent too, though, or you could even define specific values for ScienceCapacity at a given part size. Depends on what you want to do.

Awesome, thank you! I can continue to be lazy =)