Jump to content

Fraktal

Members
  • Posts

    588
  • Joined

  • Last visited

Posts posted by Fraktal

  1. Forgot to mention. When I was flying the aforementioned plane, at one point I wasn't paying attention to my altitude and the landing gear ended up making ground contact for a split second.

    Vertical contact at 5 m/s destroyed the landing gear.

    Horizontal contact at slightly over 250 m/s didn't - but when I was previously taking off at around 100 m/s, the landing gear exploded at the end of the runway when I nosed up.

    I'm curious. Are landing gear coded to automatically self-destruct if the wheel gets fully depressed, regardless of actual impact velocity?

  2. More flying today, more failing.

    This time, a plane descending on parachutes at 6 m/s completely disintegrated on contact with water. Plane touches water, game freezes for 0.2 seconds and both wings, both tailfins, all engines, all fuel tanks and all landing gear detonate with such force that the cockpit was sent flying for several dozen meters. Does having an insufficiently strong CPU cause krakens or something?

  3. I think it's intended, as the orbital parameter readouts added to the UI a few major versions back don't show apoapsis height either until the Tracking Station is upgraded.

    Also note that it's not specific to the career mode itself. If you start a science game and edit the save file to downgrade the Tracking Station to level 1, it still happens.

  4. Found my first ever Mun Stone by complete accident. Happened to land in visual range of it (few hundred meters away) inside the Southwest Crater, noticed that it looked different when I looked around to check if there were any anomalies nearby (haven't found any so far) so I jetpack'd over and when it turned out to be solid, I knew it wasn't terrain scatter, so I had Bob bag it. +12 science.

  5. On 8/9/2021 at 2:48 PM, MR L A said:

    Also, and someone else will need to confirm this, but you’re missing relay strength. For example, 4% connection direct to KSC is still stronger than relays because of how unbelievably powerful the KSC dishes are at level 3. 

    Relay strength is irrelevant to science transmissions. All the game cares about is the 4%, regardless of whether it's 4% via Communotron or 4% via RA-15.

  6. I wasn't looking for random failures (and consider the idea to be BS). I was thinking more along the lines of parts gradually losing functionality in response to damage sustained.

     

    Thoughts I had in mind about how it would work:

    • Every part has a structural integrity stat calculated at part load based on volume and empty weight (since assigning values manually would make it a nightmare to maintain compatibility with other mods). This is a hidden value not normally shown on the UI but whenever a part is currently taking damage, remaining structural integrity is shown on the part itself similarly to the overheating overlay. The exact value might also be shown in the PAW while in EVA construction mode.
    • Structural integrity decreases in response to the following, with the mod's code hooking into where part destruction would normally happen:
      • Impact exceeding the part's maximum tolerance. How much structural integrity is lost depends on both the part's maximum tolerance and how much the impact exceeded said tolerance. Impact tolerance is now "upper threshold for no damage", rather than "lower threshold for instant destruction".
      • Core or skin temperature exceeding the part's maximum tolerance. Similarly to impacts, overheating now causes constant damage over time while the heat is sustained, rather than instant destruction. How fast damage is accumulated depends on both how far above maximum tolerance the part is heated and how long the part is subjected to that temperature (eg. overheating once for five seconds will do more damage to a thermometer than overheating five times for one second each).
      • Ambient pressure exceeding the part's maximum tolerance. Handled the same as overheating.
    • Every time a part's structural integrity drops below an even multiple of 10%, there's a cumulative chance of the part losing partial functionality without physically being destroyed. What can go wrong dynamically depends on what functionality the part has (ie. when you look at it via Module Manager, what modules the part has).
      • Parts containing resources can spring a leak (slowly at first but it can stack), clog up (contents cannot be used or even transferred anymore, turning it into dead weight unless you had the foresight to bring a Drain Valve, but even that won't work if it's a battery that broke) or both. Crossfeed might also malfunction.
      • Solar panels and antennas can stop working without being broken. Same with science parts.
      • Docking ports can become unable to attach, unable to detach once attached, suddenly detach if currently attached, or all of the above. Shielded ports are more resistant to damage, but can additionally jam open/closed.
      • Decouplers and stack separators might end up releasing their contents and fairings can fall off as well.
      • Engines can lose thrust (and can stack for eventual total shutdown), lose gimbal, jam gimbal in a random angle and direction (and has a non-zero chance of ignoring the currently set gimbal limit in the process, even if you locked gimbal ahead of time which does help your chances a bit) or even get stuck burning with no way to shut them off.
      • Probe cores and command modules can lose not just reaction wheels and built-in antennas and batteries, but SAS functionality as well, unless you have a second command module or probe core that isn't damaged yet.
      • Aero surfaces can gradually lose lift or cause drag due to physical deformation. Maneuvering surfaces can either stop articulating or get stuck on a random deflection angle.
      • Very low structural integrity also starts acting as a negative multiplier to how much G-forces a part can take before being snapped off.
    • If structural integrity drops to 0%, the vanilla part destruction code is called. Again, part malfunctions never kick in randomly, only in response to damage.
    • Stock repair kits can restore either functionality plus a small amount of structural integrity, or a larger amount of structural integrity and no functionality, but the amount of structural integrity restored per kit is inversely proportional to the current level of damage and additional diminishing returns are applied for each subsequent kit being used without docking to another vessel.
  7. There's a difficulty option whether all probes should have all SAS modes or not. Without this, HECS cores only have stability assist and prograde/retrograde. So, you probably got this turned off at game start. I'm not sure if it's one of the options that can be changed mid-game, but take a look in the Settings / Difficulty Options menu, just in case.

    Also, regarding your inability to steer. There's another difficulty option about how probe cores behave without a live radio link to Kerbin. If you have partial control enabled, you can't manually steer without a connection, but SAS controls will still work. Is this what you're experiencing?

  8. Is there any mod out there that models part damage gradually, rather than the "if(current_impact/heat/pressure_tolerance > maximum) violently_detonate_part-immediately();" model used in the stock game?

    I don't mean breakable solar panels/wheels/antennae, I meant all parts. I thought of an idea in that regard today, but don't know if there would be interest in it or if someone else had already done it.

  9. I tried to develop a standardized series of rockets, but very often encountered situations where I couldn't find any design for launching a specific payload because everything was either underpowered or overkill. Usually happens with probes or station parts in fairings: Terrier isn't strong enough to reach orbit before apoapse, Poodle is overkill for this payload weight, and there's no middle ground with acceptable vacuum Isp available at that point.

  10. First design uses:

    • One FL-T400 fuel tank and a single Terrier on the lander. There are three landing legs, one on each materials bay radially mounted onto the lander.
    • The service bay under the command pod contains one experiment storage unit, one thermometer, one barometer, three goo containers and four Z-100 batteries.
    • Two FL-T400 tanks and a Terrier on the transfer stage.
    • Four FL-T400 tanks and a Swivel on the launcher's core stack.
    • Four FL-T400 tanks and a Reliant on each of the launcher's two side boosters.
    • Two Thumper SRBs.

    Second design uses:

    • Command pod is a Mk1 Lander Can. There are two radial parachutes on the nosecone, along with OX-STAT solar panels.
    • The service bay above the command pod contains two experiment storage units, one thermometer, one barometer, one goo container, one Z-200 battery and an OKTO probe core so that you can bring a scientist instead of a pilot to repeat your single-use experiments for maximum science gain.
    • Two Sparks with three Oscar-B tanks each on the lander. There are four landing legs, two on each Oscar-B stack.
    • Same transfer stage as the first design.
    • Same launcher core stack as the first design.
    • Three FL-T400 tanks and a Reliant on each of the launcher's four side boosters.

    Third design uses:

    • Command pod is a KV-2 Pea. This part and the one used in the design below has a built-in heat shield that WILL survive reentry from the Mun, which saves some weight.
    • The service bay above the command pod contains the same as the first design, plus a Small Inline Reaction Wheel clipped under the nosecone (the command pod doesn't have a built-in one).
    • Two radial FL-T200 tanks and a single Terrier on the lander. There are four landing legs, two on each fuel tank.
    • Three FL-TX220 and two FL-A151S tanks and a single Terrier on the transfer stage.
    • Fourteen FL-TX220 and two FL-A151S tanks, one Reliant and two Thuds on the launcher's core stack. Feel free to use bigger tanks, I used these so that this particular rocket is available earlier in the tech tree.
    • Same side boosters as the second design.

    Fourth design uses:

    • Command pod is a KV-3 Pomegranate. Same nosecone kit as the second design.
    • The service bay above the command pod contains the same as the second design, plus a Small Inline Reaction Wheel.
    • Two Sparks with four Oscar-B tanks each, plus one FL-T100 tank on the lander. There are four landing legs, two on each Oscar-B stack. The extra fuel compared to the second design is needed because the Pomegranate is very heavy (nearly four times the weight of a Mk1 Lander Can).
    • Four FL-TX220 and two FL-A151S tanks and a single Terrier on the transfer stage.
    • Twenty FL-TX220 and one FL-A151S tanks plus one Bobcat on the launcher's core stack.
    • Two Kickback SRBs.

    All of these except for the Pomegranate, Kickback and Bobcat are early-game parts. Those three are on the same tech level as the Spark, which you mentioned you're already familiar with.

  11. 8 hours ago, Spengler said:

    And I just can't seem to get more than 3,000 dV out of it, which is not enough to transfer, orbit, land, and return.

    Whoa buddy, you are overengineering that lander a tiny bit. If I may, I'd recommend that you use your rocket's final pre-lander stage for the transfer, munar circularization and deorbiting and have the lander's own engine take over only during the actual descent towards the Mun's surface.

    Examples with and without Making History parts:

    BnCc0kV.png

    LCerCcW.png

    9Q6dbAz.png

    TyAArHe.png

    All of these are capable of landing near-equatorially on the Mun and returning to Kerbin with about 200 m/s to spare. On the stage readout, Stage 1 is the lander, Stage 2 is the transfer stage immediately below the lander.

×
×
  • Create New...