Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    Crew Dragon will have a streamlined cover over the docking port. Which either jettisons or opens/closes. (I've seen it depicted both ways; not sure what the real final version will do)
  2. Starwaster
    I don't know why considering that is what is being used as your control reference.
  3. Starwaster
    Finally fixed the damned overheating gauge on Kerbals. I was using a very precisely calculated value for the threshold multiplier which was predicated on the gauge threshold being a static value of 0.7 but it is overridden in the Physics Globals to 0.625 So I bumped the threshold multiplier up accordingly. Download DeadlyReentry-KerbalEVA.cfg and copy it to your DeadlyReentry folder, overwriting the existing file. https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-KerbalEVA.cfg This will keep the gauge from showing up until your Kerbal's body temperature exceeds ~314K which is little below the temperature at which tissue damage begins to occur (317K). (intermediate levels of heating corresponding to fever temperatures are ignored)
  4. Starwaster
    variable not found in part warnings are harmless. That's why it's a warning and not an error. (unless of course it was meant to be a CoMOffset.... then of course you would want to track down and correct it)
  5. Starwaster
    @Gordon Dry Your configs are lacking necessary data. Look at the log: It starts when you added SR.Nosecone.35 (config part name is SR_Nosecone_35) Part SR_Nosecone_35 is lacking a textureLibrary field for ProceduralChute That is the cause of your errors (it's also lacking a currentCanopies field but I'm not sure that would cause issues or not. Missing texureLibrary WILL for sure. Guaranteed)
  6. Starwaster
    @damonvv Are the fins actually integrated into the model or are they separate parts? I would think making it all one part would make it impossible for the fins to be independently controlled...
  7. Starwaster
    If you're up for it, you could edit the craft in the save file and change the port diameter there. If you're comfortable doing such a thing...
  8. Starwaster
    @Cratzz What is the navball issue exactly? The fact that it is over to the left or that it is skewed to 45 degrees? The latter is because of the MechJeb control part being mounted at 45 degrees. Or if it's that it is sitting off to the left then that is because you changed it under KSP settings. (you can move the navball left or right) The plume always on is a configuration issue for that engine part. What are you using for an engine pack? (RF doesn't include engine configs anymore; you need a separate engine pack such as RO or the stockalike pack)
  9. Starwaster
    @drhay53 I resized the welding ports to 1m and successfully achieved docking. One caveat there is that the ports are recessed so far into the station part that you have to shift the camera inside to be able to access the port for welding after docking. Not a big deal though IMO Also, I had to test under KSP 1.3.1 with the corresponding version of SSTU but that shouldn't really matter since it was just a collision issue. It should work exactly the same for 1.4.5
  10. Starwaster
    The welding ports can be resized, even lower than their default. I'm working on reproducing this AND solving it via resizing. I think that should work. Going to try 1m instead of 1.25m
  11. Starwaster
    They're not making proper physical contact. What it LOOKS like (I could be wrong, it's hard to see) is that the other four ports are in the way. Either way though, it looks like there is a significant gap.
  12. Starwaster
    They HAVE to be retracted before they dock. Either because you retract them after they have been magnetically pulled together or because you keep them retracted while docking. (I prefer to just leave them retracted)
  13. Starwaster
    They definitely will NOT actually dock if either of them are extended. Extended is the equivalent of 'soft' docking as opposed to a hard dock (or latch). Extended means the only thing holding them together is magnetic attraction. They BOTH need to be retracted before they will actually dock. Other than that I dunno why they wouldn't be docking when retracted.
  14. Starwaster
    There's a lot of odd things Elon says and sometimes I think it's nervousness or anxiety on his part and sometimes I think he doesn't really know what he's talking about. He's knowledgeable for sure but he's not an engineer. I know he thinks of himself as one but he's not. Case in point: When he says that dorsal fin isn't really functional? Don't take that very seriously. Maybe most of the time it's not really needed, but if BFR needs stabilizing in a hurry and they tuck both of the actuated wings in, trust me, that dorsal fin is going to be very aerodynamically significant.
  15. Starwaster
    Looks like I'm in luck! With my very own 'Toothless' dragon to protect me, those zombies don't have a prayer! Or... was it Timber Wolves that I last googled? Well that's ok too I guess... if nothing else I'd rather be eaten by wolves than eaten by the undead...
  16. Starwaster
    @JadeOfMaar, @Gargamel is largely correct. Apollo did not reenter in several passes though it did perform what is referred to as a 'skip' reentry where it would fly back out of the atmosphere very briefly and then plunge back in. This was controlled by rolling the pod to direct lift. G-forces for lunar return missions ranged from 5G-7G. The Genesis probe sample return pod performed a ballistic reentry that exceeded 30 G's. (it also returned direct without multiple passes into the atmosphere)
  17. Starwaster
    Pfffff how about 52+?
  18. Starwaster
    he said aTtitude not aLtitude
  19. Starwaster
    A watched rover never roves...
  20. Starwaster
    Updated DeadlyReentry-OPT.cfg file. Missing part configs by @pr4ger It can be downloaded directly from https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-OPT.cfg and copied over the existing file in your DeadlyReentry folder. (operational temps in ModuleAeroReentry may change before the next update) Also I'm still mulling over the engine and and other parts that were given a max temp of 1500 - I may still reduce that but for now I settled for assigning it a maxOperationalTemp of 698K which is about the point at which steel begins to weaken. (i.e. the part will begin to accumulate damage proportional to the amount by which it is over its operational temp). That SHOULDN'T be a problem as those parts probably won't even reach those temperatures just from being run full power. (just referring to the engines there, not all of those parts were engines)
  21. Starwaster
    Want some help testing it?
  22. Starwaster
    He wasn't trying to; his problem is that the game sees it as having the same surface area as inflated even when it is not.
  23. Starwaster
    Sounds like its drag cubes aren't being properly calculated for both the inflated and deflated states ... a short investigation later and... The problem is that SSPX uses a proprietary animator which does NOT implement IMultipleDragCube The solution is either use the stock animator class as a base for ModuleDeployableHabitat or implement IMultipleDragCube in the ModuleDeployableHabitat class. Either way involves a rewrite to one extent or another... Hard to say which would involve more work. Could be a case of being six of one and half a dozen of the other.
  24. Starwaster
    When they act up, it's usually when you reload the craft
  25. Starwaster
    Sounds like autostruts again.... Or not....
×
×
  • Create New...