Kerbas_ad_astra

Unfortunately, while it would be straightforward to make Ven's Mk1-2 model either a variant of the Mk1-3 or its own (accessible) part, neither solution is quite satisfactory. VSR doesn't come with an IVA model for the Mk1-2 pod, as it relies on the stock IVA, but presumably that will be removed with a future release of KSP, and redistributing it would be legally challenging. On the other hand, making Ven's model a variant of the Mk1-3 would cause the IVA to mismatch compared to Ven's model, and the RCS wouldn't work because the thruster transforms have different names on the two models. I miiiiight be able to change that latter issue without having to use Blender, just with taniwha's io_object_mu python library. That will wait, though.

I took a break from VSRchaeology for a moment when I noticed that the S2x8 soft tank was physically larger than the Jumbo-64 fuel tank but held less than 2/3 the fuel capacity. The soft tanks will get their capacities increased to correlate with their actual volume (up to the typical stock volume fraction of ~85-87%), while the CryoX nose tank will have its capacity reduced (its fuel capacity was about 50% greater than its physical displacement). Fuel mass fractions will remain the same (1 ton tank per 9 tons fuel for the CryoX tanks, 1 ton tank per 10.5 tons fuel for the soft tanks -- both lighter than stock tanks, 1 ton tank per 8 tons fuel, corresponding to their reduced impact tolerance).

The boiloff rate is 0.05% per hour, so you shouldn't bother refrigerating for a span of minutes, or even days (small number of days). Save it for fuel depots and interplanetary transit stages.

If you have those files readily to hand, sure. It's difficult to track down the 'best' aerospike model in the repo, given the number of reorganizations that it's been through.

Part of the issue there is that the mixed-tank definition of 6 units of LH2 and 0.2 units of Oxidizer per liter only adds up to 0.8 L, so the mixed tanks are only 80% utilized. Increasing the per-liter contents by 25% (7.5 U LH2, 0.25 U Ox) would make the two setups hold identical amounts of fuel. (Normally I'd also increase the dry mass per unit by the same amount, but that would exacerbate the gap in dry masses, so some other tinkering may be required -- possibly an issue with the math in the tank-switcher patch, since keeping a consistent 20% LH2 and 12.5% Ox mass fraction should work out the same for four mixed tanks or four pure tanks.) It would also let people get away with rockets 20% shorter than they currently fly.

It's not released yet, because I'm still fixing things, and because it depends on Module Manager having some features that will be coming in a future release.

I don't have that issue myself (testing on 1.4.2 + Making History) with the version I'm developing for 1.4.2. It's possible that my changes have fixed the issue. Hang in there!

I've nudged the model eeeeever so slightly to take out the majority of the offset (~3 orders of magnitude). I believe it's based on the Argus As 014 engine, best known for powering the V-1 "buzz bomb" in World War II.

It's good from the perspective of not depending on language settings. It does have the brittleness with respect to the particular format of the atmosphereCurve, but that would be easily solved by moving that function into the DLL; it could evaluate the engine's atmosphereCurve at 0 atmospheres and 1 atmosphere directly, and get the right answer for all engines, regardless of how the atmosphereCurve is actually defined in the config file. More broadly, I guess I object on the philosophical grounds that, while it may 'work', the two phenomena of the Isp gap and deep throttling are not physically connected. It's true that, generally speaking, vacuum-optimized engines (with poor atmospheric performance) tend to be pressure-fed and therefore theoretically more able to deeply throttle, but that large Isp gap is not caused by the quality of deep throttling (or vice-versa); it's caused by the high expansion ratio from the engine throat to the end of the nozzle. For example, the J-2 engine had an Isp gap of 48% (421 sec vac, 200 sec SL), but only had a throttle range of 78% (see this NASA fact sheet, last page), while the Space Shuttle Main Engine had an Isp gap of 81% but could throttle from 109% to 60% thrust (total ratio of ~55%). (Maybe it could be argued that these are outliers from their respective classes of engines -- the J-2 was a vacuum engine but was fed by turbopumps, while the SSME was specifically developed with deep throttling capability.)

Huh, seems it doesn't work. I'll break them out into individual patches. (That will work for players using the en-us localization, anyway.)

It will happen when it happens, and there may be trouble loading ships which have parts attached to the "top2" node that VSR added. They won't be eaten on game load, but opening them in the editor or flight may cause the vehicle to be 'cut off' at the engine in question. (Stock vessels or vessels which use the 'normal' node shouldn't be affected.) The best way to deal with this is to look in the craft and save files for 'top2' and edit it into just being 'top'. It's a little painful once, but this should be a more-or-less permanent solution, since it's going to be using a completely stock method in its intended use (as opposed to the current method, which is a 'hack' built on abusing the auto-shroud module). Also, before I commit this change, I need to make sure that it doesn't have weird effects on drag cubes -- the last time I tried a stock solution, it turned out that the 'phantom' adapter was still considered to be present for drag purposes.

SMURFF and VSR lean on CryoTanks for some of their patches, but VSR has other things that need resolving before a 1.4 update is published, and since RSS hasn't been updated for 1.4 yet, I doubt anyone's using SMURFF with KSP 1.4 right now, so the 'pain' of adapting to a new tank balance is minimal at this time. Do what you gotta do, I'll adapt.

When Module Manager updates, Ven's models and textures will be added as variants to the 2.5m tanks. (No urgency on releasing the update -- I still need to convert the engines with switchable attachment nodes to the new variant system.)

This update adds stock texture-switching to the fairing, so it is not compatible with KSP 1.3.

I've been working on a setup like this for the Rockomax fuel tanks, and I've run into the same issue -- even if I call out the full 'VenStockRevamp/Squad/Parts/Propulsion/X200-64(Clone) = [true/false]' in each GAMEOBJECTS block, ModuleManager's cache only reads 'VenStockRevamp/Squad/Parts/Propulsion/X200-64 = [true/false]'. As a result, Ven's model never goes away.

To be more precise about the problem, Ven's wheels look fine in the editor, but when they load into the game, the 'wheel' end rotates ninety degrees, so that the steering axis becomes a camber axis. (The XL3 wheels are not affected, presumably because they don't have a steering axis.) I think this might somehow be related to the orientation of SteeringPivot. It may be as simple as rotating the SteeringPivot transform to have the green axis up (per the cheat sheet, wheels "should" steer with their y-axis, which Ven's wheels do not). There may be more to it than that, as when I dug into the 'guts' of the parts with DebugStuff, the stock M1 wheel doesn't have the same orientation as the others but works just fine, but I think that's a good place for @EmbersArc to start tinkering. Which panel(s)? I just tried a few and had no trouble.

The balloon models haven't changed at all since the last MIT-licensed version, so it's fine to use them under that license, but the code base has changed considerably. We'd have to get @dunclaw's OK to put the code back into an open license (I'd advice GPL v3 for reasons explained in the long-winded post linked in my signature), or else 'roll back' to the older code from the last MIT-licensed version and lose his improvements (e.g. switching between stock and blizzy's toolbar, improved stabilization).

Releasing HGR Community Fixes v1.6.0 "Glasnost"! Updated for KSP 1.4: Parts now support KSP's internationalization/localization system. (Thanks to @IgorZ for the automatic localization software!) Fairing incorporates auto-trusses and color switching. G4-LK supply module now has a more proper texture. (Based on the Onions.) Heat shield fixed to actually protect the descent capsule. Small inline parachute deployment speed slowed. Thanks to @Pand5461 for a few suggestions. Those I accepted include: Increased battery capacity of Daikon service module. Several capsule masses reduced (especially Soy-Juice). Thanks to @Miharafor a couple of suggestions: Slightly more inventory volume in the Garlic pod (so you can fit a container in a container). Onion capsules now include life support recycler and habitation functionality (USI-LS). Tank balance pass (including service modules) -- tanks no longer contain more fuel than their physical volumes. With this release, it is now possible for a Soy-Juice stack to support a mission to either of Kerbin's moons, using only on-board life support, just like the Soyuz 7K-LOK. (With USI-LS, anyway -- and I welcome patches from folks who use other life support systems!)

The Lima has a lower-res texture than the other pods, and more importantly (for the lack of shininess) no normal map, unlike the 'proper' Soy-Juice models. I suppose I could do the same for it as I did for the 'Garlic' pod, taking the white Soy-Juice model and texture and 'staining' it, but it really wouldn't feel right to have the door and window on it (the upper module of the Progress spacecraft doesn't have hatches or windows, either, but at least it is crew-accessible). Maybe in the distant future, I'll work out how to edit its model and apply the normal map, so it will at least be lit properly.

Thanks for the heads-up! I might still make the python script to have an 'offline' option that doesn't require opening KSP, but I won't block HGR's release on it.

When I internationalized XT Landertrons, I crawled through the config files and internationalized everything by hand. No big deal, since there's just five parts and a handful of notification strings. I'd like to internationalize HGR, though, which has dozens of parts, so I'm a lot more interested in an automated solution. I'm envisioning a script that operates on a folder and goes through each part and pulls out the title, manufacturer, description, and tags into an en-us.cfg file. Meanwhile, each autoloc tag gets generated automatically, in a format like "#autoLOC_[short_name_or_abbr_for_mod]_[partname]_title" (and "_desc", "_mfg", and "_tags"). If nobody's made a script like this, I'll make one in Python and submit it to @taniwha's cfgnode library, but I figured I'd ask around first. (@linuxgurugamer, have you made something like this?)

I'm wrapping up some changes still, but here's a little teaser for my loyal fans: the Garlic pod, before and after!

I don't use RealChute, so I don't know what it's 'sensitive' to...the patch seems to use the same animations as the stock parachute module, which come out 'right-side-up' in stock, so I don't know what I can do to help you.

I realize that major solar system mods are not yet released for KSP 1.4, but I've got a little spare time right now, so I'll pre-emptively release SMURFF version 1.8.0 "Kerbal Equinox"! Updated xenon patches to new balance of stock tanks. Because those changes were made in KSP 1.4.0, this version and later versions are not compatible with KSP 1.3.1.

Thanks for the heads-up. Next week or the week after, I plan to dig into that and also the heat shield, in addition to localizing everything.