Boomerang

The Mk1, M16XL, and M25, if you could. Either the original stock models or anything more like the original, rather than looking like the RealChute models. It's more difficult to attach decouplers and such above the parachutes via a cubic strut or something when the parachutes are so tall and pointy. But really, these skins and models are just great.

I don't know if you'd be at all interested in this, but my kingdom for your deployed parachutes with the old parachute models. I've tried fiddling with the model and texture files, but I haven't yet found a combination that gives me the original lower-profile parachute case and your awesome-looking canopy textures. Also, you deserve a knighthood or something for fixing the Mk 1-2 capsule. Both the odd positioning of the hatch and the limited number of attachment faces on the original made it such a pain to work with.

KER or PreciseNode would be nice. Or EditorExtentions, though that seems less likely.

What are things my girlfriend asks when a new KSP release results in neglect, Alex? But nah, not that I've noticed, anyway. Everything seems appropriately rigid. Maybe you've used KJR previously and forgot to add it to your new save?

Glorious mud!111!!11!!mmmm mud...

Also, I started .25 with NEAR and ended up deleting it. In both cases, I would occasionally have the glitch of things clipping entirely too easily through the runway or launchpad upon loading. If I had to guess, I'd say that the glitch lies with a buggy new collision mesh for those two areas with the advent of destructible infrastructure, not FAR/NEAR. And the FAR thread would be packed with angry people if this was in fact a FAR bug.

Or, make everyone who's watched Armageddon play an asteroid-redirect mission and show them how easy it would be to deflect a 'roid into a safe orbit as long as you have reasonable forewarning.

Cool idea. I've given up trying to play with FAR/NEAR, but it's cool that someone's working on this sort of project.

Eh... I wish I would have seen that poll. I much prefer having as few folders within Gamedata as possible and there wasn't anything difficult about keeping Self Destruct in the ThunderAerospace folder. Anyway, it's done now and thanks for the update, it'll be nice turning off the countdown.

I'm sure this sort of reversion isn't the sort of thing you really want to see as a request, but would there be any chance of getting an option to display the older white text overlay in the lower left of the editors, rather than the newer boxes? They aren't bad-looking, but they seem to like to pop up whenever they like, or the one featuring dV/TWR/etc isn't there at all. And for someone who's stuck with a less than generous screen resolution, the boxes take up more room than I'd really like.

There was a minor bug regarding parachutes with DRE and the inital release for .25. There was a patched released very shortly after that. So make sure you have the most recent DRE. That being said, why is deploying your chutes at 8km a problem?

Didn't know if this was a bug caused by something or if it was just left out of the .25 release, but it is very strange-looking.

Yup. IIRC, they have additional drag given by the intake area and when you close them, that extra drag goes away. If you want to test it, get a plane flying at a moderate altitude at a decent clip with symmetrical intakes. Close them on one side only and you should notice that your plane wants to yaw towards the side with the open intakes.

Sticking with somewhat realistic expectations (we're not getting life support functions in .26, etc), I'd really, really like to see finished IVAs for all the parts that need them. I realize that we're in a pre-release, but if they're going to take the time and care between versions to release them as cleanly as possible (rather than throwing out things as soon as they're finished, pre-testing), then the parts they're releasing really ought to be finished. It's one thing for a part-pack to have unfinished IVAs that the author gets around to eventually, but it feels a bit sloppy for the stock game to be run that way. To my mind, anyway. If they could suss out the bees regarding EVA'ing onto ladders, that'd be great too.

Can we take it down a notch? With so many mods depending on Firespitter, I'm sure that Snjo has plenty of double-checking and trouble shooting to do in whatever amount of free time he/she has to work on the mod. If it's working fine with your particular suite of mods, great. There's really no reason to complain so much about the version checker. It's not stopping you from using anything. Just click 'ok' and move on. It's a useful tool to make people aware that there may be problems stemming from whichever mods it's warning you about.

One nice thing about EVE is that the Github archive for the versions of it goes way back. If you are running a slower rig, try finding one of the versions right before the release of volumetric clouds. Won't look as nice as the more advanced versions, but it still looks better than stock.

Because this isn't how game dev works? SQUAD might be a bit slow and inefficient, but that's due to inexperience and a very small staff size. They've got a road map for what they want to do with the game and that'll dictate what gets added. Many of those mods are outside the scope of what they're aiming to include in a 1.0 release and at least the resource extraction is something that is entirely off the table for the stock game unless they come up with a novel way of implementing it. Besides that, good luck getting everyone to agree with what they want added to the game. For every person who wants better aerodynamics, there's going to be a person who's used to stock soup-atmo and is going to hate seeing it changed. Ditto for just about everything else on your list. The great thing about mods is that they allow us all to customize the game to what we enjoy. The question you ought to be asking is whether SQUAD would agree to your proposal. And I would strongly suspect that the answer is no. They've got enough on their plates without fickle customers being in charge of what they work on.

Do the control surfaces have any effect in flight? ie: is the animation of them moving perhaps broken, but they're still providing roll/pitch/yaw authority in flight? If it were me, I'd try removing NEAR and reloading the game to determine if the problem is stemming from that.

Looks like there might be an inline aerospike below and between the turbojets.

I've had that bug on other parts. Lately on a crew module that was copied from my last save with TAC resources in the cfg even though I didn't yet have the mod. Removing the resources fixed that zoom problem. I recall it happening with someone's experimental greenhouse part in an older version. So it seems to be somewhat related to TACLS, but I dunno if anyone knows what the exact problem is. In totally unrelated issues, does anyone know how to phrase a MM patch (or edit the pre-packaged MM patch with TACLS) to prevent that patch from adding resources to specific command pods? I've been trying to figure out the MM syntax, but without seeing an example of how FINAL: is used, I can't quite figure it out...

Hey, now that's a fine piece of writing. A very accurate and entertaining and I imagine effective review.

To your latter point, if you're having difficulty attaching things to the nodes within the cargo bays, hold down the your modifier key until you attach the part where you want. That allows attachment only at nodes and you won't have your payload trying to surface-attach to everything. If you're trying to eject things from the cargo bay, you might try using one of the slim radial decouplers on the bottom of the cargo bay.

I'm really struggling to sort out this syntax from the Github wiki and from looking at the MM examples I've got for my game. I can't find any other patches that actually use the :FINAL. All I can figure is something like: @PART[HERP_Pod]:FINAL !RESOURCE[FOOD], !RESOURCE[WATER] Which I know isn't right and doesn't work in the game. Are there any examples out there?

Can anyone point out to me how one would write a MM patch to prevent the actions of another patch? Specifically, I've just gotten the .25 version of TAC LS and I'd like to prevent the standard 3 days worth of supplies being added to two very small single seat command pods added by some of RoverDude's part packs. Since the TAC LS MM patch adds those supplies to any crewed parts with the ModuleCommand module, how do I tell it to not add supplies to two specific parts? Thanks for any help!

Just checking in quick - I was able to reproduce the IVA bugs I listed above on a clean save with only the mods related to the AES pack installed.