AccidentalDisassembly

Just trying out the new version - there's something going on where MCM parts are really affecting frame rate in the VAB, at least. No exceptions popping up, but seems like something is calculating quite a bit...

Have to say - that looks pretty cool!

Was any headway made on the issue with TweakScale where parts can't be scaled up past a certain size (possibly the scaleFactor at which the nodes on a part change to the next one up?), but can be scaled down? Would be great to be able to create massive IR parts (which I do right now via config copying/rescaling, but that's a bummer!).

I use this mod, and many other mods, and have exactly zero of the problems you do - and the mod plainly does ​work - so perhaps the problem is with your installation of the mod, your version of KSP, or some other thing and not the mod itself.

I don't know why, but I get this feeling that all of these parts are bigger on the inside than on the outside - when compared to a Kerbal standing next to a ship, for instance...

It's your choice, really - MKS' way of building stuff has more/different steps than EPL, so if you prefer EPL's "normal" route of Ore-->Metal-->RocketParts, you can just delete the hide-the-EPL-stuff config from the MKS folder.

I can't speak to a lot of what you're asking about, but I can at least speak to these - 1. Definitely not - they can all be named whatever you want if you're starting from scratch. The name of the part's cfg file especially doesn't matter - you can verify this be renaming any old "part.cfg" you find to "2390850_BoRPanerojADN.cfg" and it will still load. I am pretty sure that the texture names just have to correspond to whatever is set by the model (referenced in the .mu) - so if you're making your own model, if you have your model refer to "ThisTexture.png", then your texture file ought to be named the same unless you use placeholder textures, I think, though I'm not entirely sure how they work yet. Even then, I believe you still need to have textures somewhere that are named the same as the .mu requests. Lots of mods use placeholder textures, SXT is one that uses lots of placeholders (just for example). So if you're copying the .mu/cfg of an already-existing part, you should keep its textures' names the same (or use placeholders to point to the original's textures, if you want to do it that way). Just change the name of the part in the cfg so it doesn't conflict with the original, of course. 2. If I've understood your question (might not have on this one) : Right now, anyway, resources from Regolith's system don't deplete, they're just more or less concentrated at this or that spot. Hope that helps!

Speaking of carriable containers... Maybe this would not even be possible, but just to throw something out there: one way to keep a vague sense of "realism" with carriable containers that are much larger than Kerbals themselves might be to make them attach to Kerbals via a cable that would get stuck to a Kerbal's back. Kind of an automated sort of plug-in-to-a-port-with-KAS-stuff process, and then the Kerbals could tow/drag containers around rather than have them stuck to their backs. Then they could move larger containers around. Obviously I have no idea if this would work or whether it could be coded, but maybe...? Just a random thought.

Just FYI - I think I saw over on the Mobile Frame System thread that the author is working on container parts of a similar shape to the ones I proposed earlier - so, after all, it might not be worth any effort to go out of your way to make container-like parts designed for the MFS.

Dunno if this is helpful, but I also had very little reduction in the heat shield on reentry - but then I "tried" (oops!) dropping a capsule nearly straight down at 2000ish m/s (I think). Lots more (but still not a whole lot) burned off then - Purely a guess, but maybe temps just don't get as high with this newer version, but the ablative shielding still burns off at the same rate given a particular temperature...? Dunno. I didn't fiddle with any numbers, just a straight install.

Conversion to DDS (and resizing) via DDS4KSP produces a whole lot more RAM savings than ATM for me (with similar parameters for each). Plus it's at least (not exaggerating, I mean this literally) 10 or 20 times faster than ATM at converting textures.

Fix the memory leaks! New features are great, especially the aero, but there are bugs that need to be fixed before this goes "official 1.0 ready for the world etc. etc. etc."

Looking at your mission statement, you might be able to do several things with one part. Let's say (just for the sake of argument) that you made a piece that looks basically identical (same textures, shape, width etc.) to the one you've made already, but 1/3 the length (and lacking doors). Using FireSpitter's FSFuelSwitch module (or Modular Fuel Tanks, too), you can swap out the fuel/electric charge/whatever contents of your single part so that you only need to make one model for both the monoprop tank, the multi-flex fuel tank, the life support tank, the battery power unit. I think FSFuelSwitch (or maybe FSTextureSwitch only) also makes it possible for you to change the part's texture too - so you could build in a square panel somewhere on your model (for example) and use different textures on that panel that correspond to different tank contents. Sorry if you already know about this, I'm just making assumptions based on your question about FS switching. You could even use FireSpitter's mesh switching (see the Mobile Frame System mod) to have one part, like your open frame, that has many different possible configurations. Not necessary, but helps with part clutter. Depends on what you want to do - but the FS texture switching at least seems not terribly complicated, and fuel switching is done via config only (I think). Mesh switching I have no clue. Just more random thoughts.

I think it looks good, myself! I wonder - it might be neat to just reuse the same model with more or less the same textures (maybe some part of it could have a texture-swapping colored patch, or something) and make a container that would fit on top of the Mobile Frame System stuff: http://forum.kerbalspaceprogram.com/threads/107791-0-90-Mobile-Frame-System-MFS-%28v0-1-0%29. They look like they might go together well - the cabin you've made looks like it would be perfect on them. Then again, I guess the FTT containers (apparently) fit pretty well on there too, so maybe it's not worth the effort. And/or maybe a very large KIS container (comparatively)? Just random thoughts.

I can appreciate that, but RAM pressure is real - again, though, maybe it all will be a moot point with 1.0 if they actually fix various memory leaks. That would allow (in actual usage, as opposed to on paper) more textures/mods/whatever... who knows. It does make it harder to retexture parts individually, yes, but it also makes it easier to replicate a particular "look" across multiple parts at once Pluses and minuses, I guess.

Unfortunately, it can actually cripple the game experience. This is not because of your mod alone, and not because your mod is any more inefficient than Squad (though the takeaway is that Squad is also very inefficient with its textures) but because I play with more than just a couple mods. Two things happen: either the combination of those mods without alteration sends me directly to the RAM limit (even with ATM and/or DDSloader and/or reducing texture sizes to 1/4 their original value, which is insane), or I manage to keep everything under the RAM cap (by deleting parts), but KSP's memory leaks (present in stock too, just take longer) bring me up there anyway. A very secondary concern is that, in general, it is preferable to be able to take what one wants from a mod and ditch the rest - for less parts in the part list, faster load times, faster scene switching, whatever. This is obviously mostly Squad's problem, since they haven't deigned to bugfix in a long time, nor to release patches before 1.0, but I'm responding to how the game is right now, since that's what I can play. Who knows, maybe this will all be a moot point for 1.0. Starting out at lower RAM usage allows me to play longer without the inevitable memory leak crash, and/or lower RAM usage allows me to enjoy more mods. It really does make a difference. ~50 textures at 1024x1024 is maybe (says Google, but I don't know for sure) 200MB of RAM - when you consider the RAM cap is realistically about 3100 MB, and Squad's parts & the game make it start at maybe 1700 MB, a 200MB mod represents a very significant chunk of the "actual" RAM you have to play with, which is in reality only about 1300-1400 MB. Add just ONE mod like B9, and you can imagine what happens. I would love to help with the texturing, but unfortunately know nothing about 3D modeling. I've started learning the basics of Blender, but it's slow going! In the meantime, I can try to rearrange some parts/.mus/textures into separate folders at least, and send you a ZIP of it, if you'd like.

Welp, the answer to my question is a definite "no" - if you take a vessel to another SOI, then hit escape and return to the KSC, there's still a slight bug whereby the KSC and Kerbin and everything else vanish. Here's hoping for the update!

Okie doke. I mean, I think the shared texture route is the way to go, if possible - so what I'm saying is just in reference to how thing are now, if you don't intend on really optimizing the textures in the near term. There are certainly many opportunities for this: for example, asteroid-hatch.png and asteroid-hatch-port.png use essentially identical textures, just laid out differently in the file. By way of comparison, Hangar uses the equivalent of roughly 44 textures of 1024x1024 size. EDIT: I take that back. Actually, all told, Hangar uses about 49 1024x1024 textures (equivalent). Meaning about 1/4 of what all of stock uses. All of stock uses ~ 208 (equivalent) or so.

Hmmm. I wonder if TweakScale could work with this. I'm not sure, but I'm looking at this: If the hangar_space variable were simply defined in the config (if it looked like "hangar_space = 3.83449" or whatever), then TweakScale could definitely change that variable with part size. If HangarSpace = hangar_space produces a number, then TweakScale might also be able to change HangarSpace with the size of the part: TWEAKSCALEEXPONENTS { name = HangarStorage HangarSpace = 3 } ^^^^ That might actually work right now. Beats me. EDIT: Also, if I may make a request: very few of your textures are shared. It would be helpful to people like me who like to delete parts if you were to place all parts that have no shared textures in their own directories with their associated textures. That way I don't have to go fishing in the textures/models directory to figure out what goes with what.

You could make science experiments tweakable, but there's no point - nothing in the science experiment will change with size, I don't think.

Shrapnel when his craft explodes? =)

FWIW, I regularly get an NRE with RMM. Believe it happens on scene changes, like launching a craft, but also happens I think on first load when you end up at the KSP screen. It looks like this: Could this possibly cause problems for any other mods downstream? I'm pretty ignorant of whether or not any particular error is important, but I'd read that NRE's from one mod can theoretically mess up others. Thought you might want to know in case it actually is a meaningful error.

Possibly, Dwight. The stuff inside the mod's GameData folder should go inside the game's GameData folder - the directory structures should be parallel. Example: Mod's zip file: GameData\ModFolderName\Parts\SomeStuff <-- put this stuff inside KSP's GameData folder, as the directory structure suggests How your KSP GameData folder should look: KSP_Win\GameData\ModFolderName\Parts\SomeStuff How it should NOT look: KSP_Win\GameData\GameData\ModFolderName\Parts\SomeStuff

Dunno if this has been brought up before, sorry if it has - one of the variable names is misspelled in the grappling hook config: Is the variable spelled like that in the code too? Just wondering if it's a typo or not.

Had a very strange sort of trajectory occur when I lately sent a science probe to do a flyby of Eve. Using lots (50ish) of mods, and AVC thinks they're all up to date. As far as I know, I installed them correctly. Sent the probe up, things worked as expected, it arrived at Eve, did some science on the flyby. On the escape trajectory out of Eve, however, when I crossed the SOI boundary (I think that's when it happened), the craft did not end up in a normal orbit of the sun where the game thought it would end up (the orange result-of-maneuver line in the picture). Instead, the craft is now moving in one direction in space relative to the solar system. Let's call it "east". Though the craft is apparently always moving in that direction, it also orbits the sun as if it were "stuck" to Eve, but still moving at a fixed speed in the same direction relative to the whole solar system. Here's a picture: And here's an output_log: https://dl.dropboxusercontent.com/u/59567837/output_log_weirdorbit.txt Any ideas what the devil is going on? Recently updated RealChute and DRE, but... just bizarre.