AccidentalDisassembly

I don't understand. KSP 1.1.3 (for linux) is available at the store on kerbalspaceprogram.com to DL, at least. Or did you purchase it a different way? Is it not available via Steam or something?

FYI - with latest versions of RealPlume and RealPlume Stock (I hope), some engines no longer have sounds - the LV-909, for instance, and SXT prop engines have their sounds removed (I'm guessing by one of RP's patches?).

Hi @ferram4, The latest dev version of FAR (the build from 4 days ago I think) does not seem to enjoy fairings being placed in the editor. Log: https://dl.dropboxusercontent.com/u/59567837/output_log_FARDevFairings.txt Reproduction: 1. Start sandbox 2. Enter VAB 3. Place something, then place fairing part, then begin to build fairing: exceptions

This might already be among the changes you're making, but if not: it would be very nice for window states and positions to depend on what scene you're in - e.g. window open (automatically) in flight (and positioned wherever), but closed or in a different, remembered position when I return to space center view.

FYI - three of the prop engines will throw NREs in the editor and in flight under circumstances I can't figure out (they won't do it if only SXT is installed on otherwise Stock game). Here's a patch that solves whatever the incompatibility is with another of the 78 mods I'm using - don't know exactly why (went and looked at other props that worked, they had these elements and SXT ones didn't):

This may work, but it would be an awful lot slicker just to make WASD change the values - then you can also do fine adjustments on the fly, as needed, without mousing, clicking, typing every time. Pilot Assistant does this very well, and I think replicating the functionality of that part of PA for AAP would be really useful. If that happens, nothing says that you must use WASD (or whatever, but WASD is the most intuitive) to change values in the boxes - you could type them, still, and the delay you propose would still be valuable for that scenario, I think. Creating this feature doesn't change anything, it only adds something which (via WASD) is intuitive for two reasons: 1. The course autopilot (as opposed to fly-by-wire) is controlling pitch/yaw/roll while it's active, so WASD (in that mode) should be telling the autopilot what the user wants rather than manipulating control surfaces. 2. The plane would still end up doing what it ought to do if WASD were acting like normal: pressing W would indeed make the plane pitch down, S would make its heading "yaw" left, etc. My $0.02.

With the latest version of DMagic, I'm not seeing ASS automatically collect OR transfer DMagic experiments any longer - same for EVA reports. Is this only me?

That seems plausible, turning it off didn't make them magically pop back into action, but they did wake up on reentry to Kerbin. Unfortunately, that was mere moments before their fiery deaths.

I don't think I modified any settings (other than turning off hab effects) from default, but the kerbals nevertheless won't de-tourist. How would I even find out whether everything is set to wear out? I can see wear numbers on things like the science lab, but nothing else, and since the spare parts are invisible, I can't know if they've run out. I'm not sure I see the logic of making them invisible, come to think of it... also did not find anything in the wikis about turning that feature on or off, only reducing the rate of deterioration. EDIT: Should note that the wear on the science lab etc. is something like 0.4%

Rover, is there something I'm not understanding with LS behavior? My understanding is that the only things kerbals need are 1) electricity 2) supplies 3) hab stuff. I have hab time's effects turned off, my kerbals have access to supplies and power via a supply ship I just docked (and transferred supplies from), but they will not stop being tourists. The only thing I can figure is that running out of replacement parts is somehow affecting the kerbals, but I thought replacement parts were non-functional? They appear in parts' resources lists in VAB mouseovers (I think), but are invisible in flight. What gives? Very modded install, I acknowledge it could be a conflict but wonder what that conflict might be if that's the case... Imagine it is probable *I* am missing something, though. Replicate problem: 1. Send kerbals to a station, leave them a very long time (oops). Hab effects are turned on, so are supply effects. They all get grouchy; they're tourists now. 2. Turn off hab effects in settings from space center screen. 3. Send ship with supplies/fertilizer to RDV with station, transfer fertilizer and supplies into the station (in my case, into the insufficient greenhouse that was pitifully attempting to prevent them from starving). 4. Shouldn't they spring back to life? Nothing happens now that they have access to supplies, though the control panel says they're up to 23 days' worth and hab became "indefinite" after turning that off. Log: https://dl.dropboxusercontent.com/u/59567837/output_logUSILS.txt

I see your point, but it's not for aesthetic reasons - it's so people can do things like delete parts they don't want and know what they're deleting, for one example. Here is an archive (https://dl.dropboxusercontent.com/u/59567837/OPT_AccidentalDisassemblyFixes.zip) with updated part configs that fix a number of issues, mostly revolving around: 1. Mismatched or misplaced brackets {} that were causing part compilation errors (I don't think I caught them all) 2. Typos 3. Part descriptions that didn't follow the scheme (didn't change actual part names). Now all descriptions begin with OPT and are organized by profile letter (J, K, 2.5m, whatever). 4. Improved the formatting of a couple of the more egregiously-formatted part configs, then gave up in despair. The rest could use some love on that front. 5. Fixed the duplicate part names of the two ISP cockpit variants, which are nearly identical, one is just a slightly updated model of the other. One could be deleted, but I didn't delete anything, so there you go. 6. Reorganized a few folders that made no sense - left the rest (the majority) alone. 7. Eliminated the duplicate AVC dlls and errata from the archive. 8. Removed the MM Patch from the k-TAV cockpit's config and put it in OPT_FS.cfg where it belongs. There is still something borking the Mk3 shuttle nose part - it's showing in the editor as a copy of the mk3 cockpit. My guess is someone copied and renamed the cockpit model, thinking it was the nose model. Also, both ISP 2.5m cockpits need fixes eventually for the crew hatches - kerbals don't grip on exit. No clue how to do that myself. Apart from that, I do truly doubt I caught everything - probably not even close. But it's better.

A couple of (hopefully useful) remarks on the newest pack: 1. If the rest of the K parts aren't legacy, then the K-TAV cockpit shouldn't be either; it should be moved into an appropriate folder under Parts. If not, it needs its model path corrected (uppercase letter needed) for it to show up in-game. 2. All part titles need a double check for consistency so that parts are both placed together and in the same order by cross section, within and across tabs. 3. The A-series of parts is pretty much useless and could be entirely eliminated and instead offered in some sort of legacy compatibility pack separate from finalized OPT versions - K parts are basically the same thing with a slightly different cross-section, and the K-TAV cockpit is (ish) an analogue of the old A cockpit. 4. The L cargo tail needs a ModuleCargoBay, and its animation module can have a deploy limit placed on it to make it more customizable (like the K cargo tails have). Is there a repo for pull requests or whatever?

Far as I can tell it's fixed! I'll post if something isn't, but I didn't see the same exception spam again. Thanks!

Same log (NOT new download of release, same game session), after sending to orbit the craft that spammed those NREs. After getting it to orbit, went into VAB, placed MK1 command pod with extendatron basic (rework part) on top, launched, no NREs: https://dl.dropboxusercontent.com/u/59567837/output_log_IRNRE_2.txt. Will try the release download again here. EDIT: But if you're referring to the GitHub 2.0.3 Core files, that's what I've got in my GameData right now (I hope) and I don't see any new changes to it in the last 4 hours...

With 2.0.3, I'm getting some NRE spam when launching stuff - funny things is I don't think I even have any IR parts on the craft: https://dl.dropboxusercontent.com/u/59567837/output_log_IRNRE.txt

I was going to say something similar about heading and altitude - when in cruise mode, it would be nice if the WASD controls somehow gradually increased or decreased heading/altitude fields in the GUI (as it does in Pilot Assistant) rather than having to type in values. Typing in "2000" rather than "3000" in altitude at first makes AAP think that you want 2 meters and it tries to correct sharply for this.

Indeed, part spam sucks... I wonder, because I don't know how the mesh / texture switching works, if it wouldn't be possible to create one part that mesh switches to become X adapters - like an adapter that is 1.25m on the top, and mesh switches so the bottom becomes either 1.5, 1.875, 2.5, 3.75, whatever... Can node size change on mesh switchery? That could result in having very few parts in the list, maybe...

Hah, yeah, that would do it! I forgot about all the possibilities of MM patches with # and $ and ^= and such, but tried to re-learn a few things in creating these preliminary configs: https://dl.dropboxusercontent.com/u/59567837/FTP_Create09375mTanks.cfg https://dl.dropboxusercontent.com/u/59567837/FTP_Create1875mTanks.cfg The first copies FTP's and Squad's 0.625m parts (tanks and decouplers) and rescales them to 0.9375m with (hopefully) appropriate masses. No tags though, didn't think about that. The second one down-scales FTP and Squad Rockomax parts (including Squad tanks and decoupler) to 1.875m. The configs are completely redundant if you have Tweakscale, but hey! Doing this made me think of something that I put together a while back when attempting to learn how to make parts for KSP (because rescaling of adapters doesn't produce something desirable under many circumstances). It's a set of adapters meant to cover uncommon tank-to-tank ratios with both long and short fuel tanks - If you're looking for random things to add to FTP, a set of adapters covering many eventualities could be useful (though for a pretty limited audience, admittedly). It works best with tweakscale, but could be used via MM configs similar to the ones I'm doing to produce adapter parts that cover just about every mod's unusual sizes. The parts include short and long versions of: 1. Tank with 1:2 ratio (1.25 - 2.5) 2. Tank with 2:3 ratio (2.5 - 3.75) --- also covers 3. Tank with 3:4 ratio (3.75 - 5) --- also covers 0.9375m-1.25m / 1.875m-2.5m, 7.5m-10m 4. Tank with 4:5 ratio (5-6.25) --- also covers 1m(Kosmos)-1.25m, With a 5:6 ratio adapter (6.25 to 7.5, also 1.25 to 1.5, 3.125 to 3.75) and a 3:5 ratio adapter, I think you could (with tweakscale) cover almost any needed adapter. Anyhoo, thought that could be an interesting addition to FTP that would make for a kind of universal mod-to-stock adapter compatibility. I have some crappily-textured models I can send you if you DO find that idea interesting. They cover the four ratios listed, but not 5:6 or 3:5. Probably have the blender files somewhere too.

Awesome, thanks! I'll give it a whirl and see if I can come up with some interesting configs for 0.9375, 1.5, 1.875. EDIT: Works quite well. Very easy to make new sizes. I took it one step further and tried to play with the default texture given to the new size of tank (start it with Juno instead of Oscar) by reconfiguring your patch. It works fine when PLACED in the editor - starts on right texture, switches fine, no graphical errors - but the parts list, on the other hand, shows no texture on the sides: I am guessing that that's not something that can be solved because the model itself is pointing to the red/gray textures to begin with (?), is that accurate? Just curious, not a real issue.

If it's a complicated change, I can also just add the appropriate sizes to TweakScale and be done with it, that would work too! The reasoning behind all of this in my mind was (optional) size compatibility with things like 0.9325/1.875 engines from HGR or BlueDog or whatnot, I'd rather have nifty texture-switching tanks of all sizes than 92385902852 new tanks from every mod I install. But, of course, TweakScale is basically built for that, heh.

Necro, I'm attempting to create a set of ModuleManager patches for myself that copy your parts and create intermediate sizes (like 1.875m) without the use of TweakScale (although that would be an equally good solution, really). However, I'm running into a problem. Here's an example of a patch I use - FTP, B9 Part Switch, and Interstellar Fuel Switch are installed. The first config duplicates the Oscar dome tank, the second duplicates a longer Oscar tank. New parts have correct sizes/node placement/whatever, but there's some sort of crazy texture-switchy issue as you can see in this picture. Two things happening: 1. The funny overlapping/Z-fighting-whatever you call that on the upper tank 2. The dome tank at the bottom should have (maybe?) been the same gray color as the normal Oscar dome, but it started white. However, when moused over, it becomes gray again as seen in the picture. Picture: Do you happen to know what I'm doing wrong here? If you'd like, once these actually work, you'd be welcome to include my completed configs as optional extras or something (if that interests you).

Couple slight fixes for the next version: 1. The CLEAVER engine's attach node needs a size: @node_stack_top = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 3 (?) 2. The 2.5m Elephant engine also needs a node size.

Shoot, this might have been fixed with 0.9.21, so sorry if it has been. Exception happens on load related to drag cube and the wagon. Don't know if that's meaningful or not, just thought I'd throw it here. No full log at moment, sorry! EDIT: Oops. Should note that this is with FAR installed, so may or may not even have anything to do with you (?). Possibly useless information... =( EDIT 2: Unimportant issue: The JetWing parachute is miscategorized as a fuel tank.

Came here to report an exception produced by planting a flag while on EVA, but I looked on GitHub and (not a programmer!) it looked like there was a change that might already address this. Worth coughing up log etc., or was I seeing what I thought I was seeing?

Well that does indeed make sense!