AccidentalDisassembly

I'd actually be curious to know whether that's possible too - can stack attachment, snapping etc. be done using KAS, outside the VAB/SPH? That'd be pretty cool.

If I could request one thing (you may already be doing it this way), it would be that if you're doing anything more than hiding the parts that let you use EPL's chains, do it via an MM config or something, so that those of us who haven't quite figured out MKS's whole chain yet can use it AND use the EPL Ore->Metal->Parts chain while we're learning! If you're only doing what you say (hiding some of those parts via config), then no problem - I can just remove that part of the MM config and it'll all be gravy.

There's a new version of KSPAPIExtensions - one in your download is the previous version, just FYI.

If you want, you can change all of that in ScaleExponents.cfg, or you can write your own custom scaletypes to apply to parts. Right now, mass scales such that a part weighs 8 times as much when it's twice as big, or 1/8th as much when half as big. Thrust, on the other hand, is 4 times as much when a part is twice as big, and 1/4 when it's half. So yes, you can get crazy TWRs, or you can do what I did and define a different exponent that you then go apply to all the engine parts you think ought to have it.

Any word on an MFT update? Gave it a whirl in 0.90 and it didn't seem to work - no crashy, but also no right click options in the VAB/SPH.

Welp, I'm a blind idiot. Hah. I was just so pleased to have found the source of my dead KSC without having gone through EVERY mod in the folder. Anyway, with regard to the altimeter, it was an issue specifically for Pilot Assistant - which has (apparently) since changed to using vectors rather than the altimeter to control planes and such, so it may be a completely moot point - but at least that mod would basically send your plane into a death spiral as soon as TimeControl borked the altimeter. But, too, it might have just been PilotAssistant causing those problems.

Welp, there's me being wrong again, but wrong in the best of ways . That sucks, sorry to hear about that.

Based on recent experience, I'm guessing there's about a 0% chance Biotronic will update this in the near future - he seems occupied with his own life, which is fine. I think his license permits others to make new versions, though, if there are any coders out there yearning for some TweakScale action.

I'm using 1.7something from the main post - is there another one? Wait.. is there one with MORE GOODIES?!

PartCatalog's sorting is still better than the new flavor of sorting - hope that Squad either starts thinking about how people actually look for parts, or that PC stays alive!

No joke - let me just echo what the others are saying - PLELEEEEEELELELELEEEAASE don't let this die. The stock editor, even with the gizmos and whatnot, really feels crippled without Editor Extensions.

The tracks & repulsors SEEM to work (only tested medium alpha, and surface repulsor) - but everything also seems to fall apart if a gust of wind comes along. KJR, where have you gone... =( Hmm, hold the phone... dunno if this happened before (don't think so...), but now physics warp at least makes the repulsors essentially turn off - higher the warp, lower to the ground you go, though 4x seems really "special"in that the alignment of the repulsors visually flips out and you hit the ground, whereas you just get real low at 3x.

Indeed... at the least, though, allowing to sort the list (once you've displayed all parts from a given mod, say) by the existing categories (fuel tank, engine, etc.) would be a step up...

While most of the new interface in the VAB & SPH regarding sorting parts is great, some of the logic behind it is not. Here are a few suggestions: 1. Advanced mode filters Sorting by manufacturer is, for the moment, the best way to sort by mod (except via custom categories). However, manufacturer is meaningless except where mods are concerned. I note that there is some logical connection between Squad parts from the same manufacturer. However, there are so many manufacturers, many with only one part, and overlap between one manufacturer's "domain" and others' that sorting Squad parts in this way is effectively pointless and counterproductive. The number of manufacturers also makes the list of subcategories extremely long. Suggestion: either change all Squad parts to the same manufacturer, or allow an additional option of sorting by mod (by folder within GameData) without asking users to set up a custom category for every mod (excruciatingly tedious, as noted below), àla part catalog, because the only function of sorting by manufacturer right now is to show all of one mod's parts on the same page(s) at the same time. 2. Sorting of parts once you've chosen something from the advanced menu If there's no easy way to sort by mod, and assuming every mod maker lists the same manufacturer on all their parts, listing by manufacturer alone is not quite enough - in addition to Name, Mass, Cost, and Size, allow sorting of visible parts (as opposed to categorization) by function of the part. This way, a player can see all the parts from a given mod at once, but sorted by what they are rather than their name. Sorting by name is useless for a very large number of parts named something like XMRQ923854P-2041B Thingamajig. Unless the user wants to memorize a very long list of part names, sorting by function (EDIT: by that I mean sorting according to classes that exist already, like fuel tanks, control, utility) is superior. Mass, Cost, Size are all great, though. 3. Allow drag & drop multiple part selection in order to put stuff into custom categories Parts in the VAB/SPH are represented by what are, for interface purposes, essentially icons like you would find on your desktop. They should follow the conventions of icons: click & drag over many of them selects them all, dragging them into a "folder" (such as a custom category or sub-category in advanced mode) should copy them there. It's extremely - EXTREMELY - tedious to create custom categories by click on the plus in the upper right of the part icon and going through the whole selection & clicking process for every. single. part. you want to categorize. Another edit: There needs to be a way to scroll through category & subcategory lists. I have more manufacturers with just a few mods going than there is vertical space for manufacturer icons in the list.

That's just bizarre. Well, maybe I had something conflicting or out of date that will get sorted after the present GameData apocalypse...

Makes sense to look at the textures first. I'll see what happens when I try to make a hangar extender out of some B9 stuff, haha... explosions, most likely! Actually, just thought of something - with your code as it is currently, can ANY stack nodes on a part be defined as the passage nodes, and can multiple ones fill that role? If that's the case, in theory, you could do what I'm thinking about by simply adding a stack node to the side of a part, and radial attachment stuff wouldn't be necessary. In that case, simply having a somewhat shallower normal hangar part would do the same thing I'm thinking of, I think. EDIT: Or, in short, you could create simple parts that are just big, textured boxes or what have you, put a bunch of stack nodes on them, and then you could attach the hangar mouth (the hangar part, in other words, that's just a bit smaller so it doesn't stick out of the side of the ship so far) to whichever node you want.

Also - sorry I didn't post this sooner, wanted to update on my previous comment about black screens/input locks when returning to KSC. I have NO idea why removing your mod made it work the one time that it did, but after extensive testing I found it was TimeControl and not your DLLs that was causing the problem - at least, I hope!

Sorry if you already responded to this - I posted this a long while back, and it's a bit of a crazy idea. Don't know enough about how the game works to know if this is even possible, but: Don't joints get stronger the higher the mass of the parts? If that's true, then secondly, is it possible to create a resource that has negative mass? If both of those are true, would it THEN be possible to create IR parts that weigh 100,000 tons, but contain 99,999 of a resource with negative mass so that the overall mass you add to your vessel is only 1 ton? Would this somehow work through dark magic to fool the engine into treating the part as having an incredibly rigid joint without making the vessel actually weigh 100,000 tons? Also, any thoughts on the TweakScale issue - specifically, the reason why IR parts can't be scaled up when new definitions (with appropriate values for part extension, mass, whatever) are written?

Makes sense, going to try that fix (can't believe I didn't remember someone posted that...) and see what happens. I did once have a tipped-over vessel where one half of its wheels, on one side, were sunk into the ground when I lowered the gear - but the other gear on the other side, when lowered, were above ground. When I tried to rotate the vessel around, the gear that had ended up above ground did strike the ground, if I remember right, anyway...

All image files have to be loaded into memory, so every one of those counts in RAM - doesn't matter if it's a normal map or emissive, it still has pixels to read. That's why the load on demand mod exists, because that's what KSP DOESN'T do, unfortunately. I use the equivalent of ATM, 1/4 size textures, and still max out RAM - like I said, yours is one of a large number of good & really useful mods out there . I count 125 .png files in the Hangar folder I just unzipped... The ones in Spaces count too. Yes, I removed the old installation. Also, I am comparing the number and size of png files per part - sure, other parts packs like B9 have a crazy number of textures too, but they also have a crazy number of parts. Do you think it's possible to make the hangar extender work with radially attached parts at all? Maybe PASSAGE_NODE = node_attach, or something? Or somehow looking at parent part rather than node? The reason I wonder about that is just because then you as the modder could allow the user to create basically any shape & flavor of hangar, and put a hangar door facing any direction, too - including on a stack node like it is now, of course. If you had a variable size & aspect ratio entrance that looked like a somewhat deeper combination of the asteroid hatch + docking port doors, that would make it totally customizable. Actually, if I put that module from the small extender (just looked at it) in the config for a B9 HX part, let's say, would it work if it was stack attached to the rectangular hangars? Do the rectangular hangars then just need to have a PASSAGE_NODE added that corresponds to their bottom stack node to make that work?

Well, the issue for me is not that the gear just up and fall through stuff (apparently like others) - and they do extend and retract. The issue is that, if you are already landed on the runway or any other surface, THEN you retract gear, the ship will settle onto the ground like normal. But when you re-extend the gear, the gear do not push the ship upward like they should. On the other hand, if you take off, raise the gear, then lower the gear and land, they work as advertized. Try raising them and re-lowering them while you're standing still on the runway.

So... wee bit of a bug to report. On a clean (except for DDSLoader and PartCatalog) install of KSP (0.25, x32, on Windows 8.1 x64), TimeControl will result in either 1) mouse input lock - can't click on any KSP buildings, but can click on other stuff, or 2) a black screen, or 3) a weird half-black, half-horizon looking screen when returning (not reverting) to the KSC after visiting another body, like the Mun for example. It may be the case that you actually have to USE TimeControl - not sure on that one, I tended to do so to speed things up for testing. Reliably reproducible by moving TimeControl in and out of the GameData directory. Steps: 1) Install TimeControl 2) Make ship 3) Fly ship to moon, then fly it in to moon 4) Return to the space center after Jeb's inglorious death 5) Be sad Log: https://dl.dropboxusercontent.com/u/59567837/output_logTimeControl.txt Log of exact same install, almost identical procedure (same ship, same parts, same deadly crash), only difference being having removed TimeControl directory: https://dl.dropboxusercontent.com/u/59567837/output_logWITHOUTtimecontrol.txt

Welp, wasn't the science containers, still got the no-clicky after uninstalling that. Time for some really annoying tests... EDIT: It was TimeControl. So sad! Because so useful...

I'm also getting this effect - kind of annoying. Everything grinds to a halt for about 1-1.5 seconds every time you hit store/transmit on an experiment. Sad times! EDIT: I take it back, it actually happens every time anything science-related happens: even going on EVA (presumably in a place where an EVA report or surface sample might be possible). Experiment finishes? Big pause. Take data from something like the barometer? Big pause. Sigh =(

A few notes of stuff I've encountered so far: - Asteroid hangars: flipping awesome. - On a mostly clean install of KSP 0.25 32-bit, many hangar parts (like hangar extenders) can't be "set down" in the VAB/SPH unless it's to attach them to another part - don't know why. - There's no evidence in the VAB/SPH that the hangar extenders extend the space available in the hanger - I'm not saying it doesn't happen, just that there is no representation of this in the shipbuilding process. Is it possible to update the space value (Volume: x m3) in the right click menu in the VAB when an extender is added? - I *think* I understand the visual indicators used to tell me how to align the various docking port stuff, but it would be clearer if the mark you use on the corner of each part, the green patches already there, were also arrows that all ought to point in the same direction. ---- Depending on the angle at which you view the part, EVERY side of the asteroid hatch can be bathed in both red and green light, or one color primarily, so if orientation in relation to this part is important, it's not going to be clear. It would be really clear with a green square like the other parts have. I think it looks pretty clear in space, but in the VAB it's not terribly. ---- The Roll-Sensitive Docking Port - pretty clear, but: there are two green markers on this part, and it's easy to see that the one on the side of one corner is meant to be aligned with the very similar one on the corner of the Roll-Sensitive Docking Port Adapter. But there's a second green mark on the FACE of the docking port too, which looks like it ought to align with a similar one on the Adapter, but can't. Slightly confusing, or perhaps I am just slow in the spatial perception department, hah! Very possible. - Any plans for rectangular extenders for the ground hangars? Additionally... any plans for a radially-attachable hangar entrance like we discussed long ago (kind of like the asteroid hangar entrance, but adjustable in size and aspect ratio, and perhaps a little deeper)? This could be stuck on the side of any hangar extension part, thereby allowing greater control over where the entrance to the hangar points - would be pretty cool if it's possible. If there's some sort of simple MODULE{} that you can add to parts that allows them to be hangar extenders, one could quite easily create dedicated hangar-space parts for different mods - take a non-hollow HX part from B9, for example, empty out the fuel and put in the MODULE{} that gives hangar space, then radially attach a hangar entrance and boom: hangar time. EDIT: Also, if I may make a request, I understand putting all the models and textures in the same folder - however, many of us delete parts that we don't want (to save RAM). It's much harder to do this when everything is thrown in one folder. Since many textures don't seem to be shared between very many parts, putting all of the adapters' configs in the same folder with their .mu and .png files - in short, organizing things more clearly when textures aren't shared - would be very helpful. I ask this because Hangar uses some absurd number of texture files (100+), 32 of which are 1024x1024 or so, another 49 of which are 512x512, and the rest are 256x256 or smaller. That means that Hangar probably takes up ~ 80-100MB of RAM (unless I'm calculating wrong - I don't know, actually the 1024x1024 textures alone might take up 120MB) - for a small number of parts. RAM is at a premium even if using OpenGL [no shadows! ] considering how many good mods like yours are out there that people want to use. In theory, considering how many parts look somewhat similar in this mod (which is a good thing), you could probably get away with using one 1024x1024 or 1024x2048 texture file if you're going to go down the texture sharing path. If not, please make it very easy for the rest of us to delete stuff.