Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Kerbas_ad_astra

  1. Instead of trying to find the exact offset, I just duplicated the model and flipped one. It looks a little weird in the editor due to z-fighting, but at least it's now perfectly balanced...as all things should be. MODEL { model = SquiggsySpaceResearch/Parts/MicroSat/MicroLqdFuelEngine/MicroSatLqdFuelEngine } MODEL { model = SquiggsySpaceResearch/Parts/MicroSat/MicroLqdFuelEngine/MicroSatLqdFuelEngine rotation = 0, 180, 0 }
  2. As a stop-gap* measure, you can nudge the model a little so that the total thrust vector is brought under the centerline: // Replace the existing model definition line: // mesh = model.mu MODEL { model = SquiggsySpaceResearch/Parts/MicroSat/MicroLqdFuelEngine/MicroSatLqdFuelEngine position = 0.002, 0.0, 0.011 } * I call it 'stop-gap', but it actually causes a visual gap/offset with the fuel tank above...I did this with one of the Ven's Stock Revamp engines, but since that was a 2.5m engine, the offset of a few millimeters wasn't as obvious.
  3. You should be able to delete the Squad sub-folder and go from there. It's also possible to take advantage of the part variant system so you can have your cake and eat it, too, but that's more work. (I've done that for the fuel tanks, for example.)
  4. From some testing, 10500 kPa should be good enough for Venus landing. Miiiight still recommend 12000 kPa to be a nice round number (3x stock pressure limit, also matches high-pressure submarine parts from USI), but it wouldn't be necessary. Galileo's entry probe made it to a depth of 2200 kPa, less than the stock pressure limit, so no worries there. Unlike my PR, I would recommend also applying that increased pressure limit to the Fomalhaut heat shield and parachute (and not just the probe and its solar panels), or else add some +Y CoPoffset for the probe body -- I found that if I ditched the heat shield and parachute, the probe tended to want to flip over. As for gTolerance, I was able to get greater than 50 G's (stock limit) by smashing the probe into Venus on a very steep entry angle, but a more conventional entry kept max G-loading below that. However, for Jupiter entry, I got a peak load of something like 70 G's with what was intended to be a nice easy entry, and Galileo IRL had a peak load of 228 G's, so 450 is a fine number to use. Obviously Galileo and Venera were different missions, but it probably makes sense to give both values to both sets of parts (it's the same design principles for dealing with high stresses), so that players can choose to run both sets of experiments in multiple environments. Even with a high-speed entry to Titan, I found there was no need to enhance the durability of your Huygens parts -- in fact, I forgot to pack a parachute and still landed intact.
  5. I haven't used it myself, but SMURFF has a check at the end to make sure nothing gets a negative mass, so at a minimum nothing should 'break', and OhioBob says he used the Kickback SRB as a performance baseline, which is also the one that I used when setting SMURFF's balance factors, so I expect things should work out well.
  6. It's true that supporting every planet pack (RSS or others) would involve a lot of writing, but science experiments will use the 'Default' definition if the planet is not defined, so there's no functional problem. (I did notice that the new Argo camera calls for a ca_filmCamera experiment which is not defined, which is a functional problem...I've patched it on my install to use ca_orbitalScope instead.) Most of the other functional elements of a spacecraft are handled either by RSS itself (antennas) or SMURFF and/or RO (fuel tanks, engines, reaction wheels, heat shields, etc.), but maximum pressure tolerance is a new system, so it's kind of left out. It's not an issue for me to patch it in SMURFF myself, but if you're going to say "It is designed to survive rough landings in extreme environments" in the part description, you might as well give it the numbers to live up to the hype.
  7. I made the PR to your repo because not everyone uses Realism Overhaul (I don't, and evidently Gordon Dry doesn't), and because I didn't think that was something that should depend on the solar system (there may be other systems that have extra thick atmospheres). I guess I could as well make a patch for it in SMURFF, which I guess is the other major alternative for adjusting parts for large solar systems. (Now that I think about it, 10500 kPa might not be quite enough, since Venus's config defines sea-level pressure as 10905.2 kPa...probably should just kick it up to 12000 like the USI submarine parts.)
  8. It's not temperature, it's air pressure. The default max pressure is 4000 kPa, or close to 40 atmospheres, but surface pressure on Venus is over 9200 kPa (96 atm). I have made a pull request to beef up the Fomalhaut probe in the same manner as the Venera probes were, but it has not been accepted.
  9. I've been working on this for the last couple of days (I'm using -force-d3d11 to get moar mods in, went to take a screenshot and found a black rectangle)...I figured it would be as easy as compiling another shader bundle for DirectX 11, but sadly that hasn't worked. In fact, I just dusted off an old 1.0.4 install, before the shaders were loaded from compiled (platform-dependent) bundles, and found that it didn't work with DirectX 11 back then, either. Interestingly, the failure mode back then was different: the window could show a black rectangle, a blue rectangle with part of the staging interface, or the flattened texture of the root part, depending on where the mouse is (I think, I didn't test this thoroughly). None of the shaders currently used (ColorAdjust and FXAA) seem to have any code that is dependent on the renderer (or whatever the appropriate term is), so I'm pretty much out of ideas besides switching to OpenGL. About the only good to come of this (besides me learning just enough about Unity package management and shader languages to be dangerous) is I've added a couple more shaders to the bundles so there will be no more (evidently harmless but annoying to me) "No replacement for KSP/Alpha/Translucent" logspam, when I get around to making that PR.
  10. It seems like it’s somehow halfway-deployed. It still collects solar power and the antenna still transmits, so it’s just a visual issue. This is probably something that I’m missing on my install, but it seems every time I have this mod I’ve always seen it happen. Does anyone know of a quick fix for this? It doesn’t really affect gameplay, it’s just annoying. Thanks I’m advance. Love the mod btw. I use the Soy Juice parts all the time I confirm that the issue exists, but unfortunately there are no exceptions in the log. I'm guessing the issue is related to the same part holding both an antenna and a solar panel. I tried changing the names of reference transforms in the part config, but the animation bug kept happening and some combinations prevented power generation, so I'm inclined to leave things as is. Something that is not staying as-is: the Lima pod's appearance! It now matches the Garlic pod...I'd be happier if I could take the hatches clean off, but that requires model work in Blender which I don't yet have figured out.
  11. I've figured it out! The issue is that the TE_F9_S1_Tank part has a patch (Extra_B9Tanks.cfg) which adds a B9 fuel-switching module, but then CryoTanks adds another fuel-switching module because the TE_F9_S1_Tank has standalone LiquidFuel and Oxidizer resources (lines 39-50). The fuel-switching module from CryoTanks has an addedMass variable defined, so the check in SMURFF.cfg line 1020 passes, but when SMURFF tries to grab that variable in line 1022, it looks in Tundra's fuel-switching patch (since it was added first), which does not have addedMass defined, and so the error occurs. Since none of the other TE fuel tanks have RESOURCE blocks like TE_F9_S1_Tank does, I think that's an error on the part of tygoo7 and/or damonvv. If they remove those RESOURCE blocks, the issue is resolved.
  12. The direct issue is that Tundra Exploration's B9 tank switching patch is not using the 'addedMass' variable, but line 1020 should be checking that the addedMass variable is used, so the patch shouldn't be acting on that part. I'll have to test if that check is actually working as intended.
  13. That log doesn't reach the part where ModuleManager does its thing, and to help you, I need to see what part it was patching when the error occurred.
  14. But I would have to deal with it, because it's my name in the 'author' field and my thread and repository that people will go to for support (and understandably so). I'm not interested.
  15. Several parts now use the stock part variant system, which is new in KSP 1.4. I should update the parts so that e.g. the truss variants of engines support the new cost and mass feature, but everything should still be functional.
  16. Or use larger parts, such as from SpaceY Expanded or Near Future Launch Vehicles, which include 7.5/10 meter parts (the size of Saturn V and SLS).
  17. Now I remember why the scale factor was there -- the stock Mystery Goo experiment used to be bigger (the current config has rescaleFactor = 0.6, it used to be at 1.0). Squad shrank the Goo Container for 1.0, and I guess VSR never updated.
  18. I can't speak for Ven, but I don't think it should be bigger than stock. I'll take a look.
  19. Many thanks! That TR-2L model works at 30 degrees positive camber, and the M1 works at 15 but not 30...I'm not sure if that's "not far enough" or fine as-is, but that's what I found in testing. Speaking of colliders, could I also trouble you to look at this one? I've just confirmed the issue in testing. (The model in question is VenStockRevamp\Squad\Parts\Structural\LargeHub.mu.)
  20. In the log provided, @-MadMan- was using a previous version of Ven's Stock Revamp (version 1.9.8, from the version file), and CryoTanks had changed since that version's "release" (it didn't really get a proper release). The patch on my dev branch has been updated to work with the last release of CryoTanks. Yes, I confirm that issue. @EmbersArc, could you take a look at this? The TR-2L wheels are also affected, but the S2 and XL3 are not.
  21. That's not a part from Ven's Stock Revamp -- some other mod is cloning Squad's model, which is getting replaced by Ven's model, which uses a different animation name than Squad's, which makes the animation module stop working. For my next trick, I'll guess that you're using KerBalloons. (If you're not, please let me know what mod gives you the 0.625m service bay -- I'm working on a patch for KerBalloons, but if there's another mod I need to know so I can write a patch for it, too.)
  22. Unfortunately, that's actually not a "light" per se -- it's just an animation, there's no illumination to have a color.
  • Create New...