Jump to content

Fraktal

Members
  • Posts

    532
  • Joined

  • Last visited

Reputation

363 Excellent

3 Followers

Recent Profile Visitors

1,793 profile views
  1. Oh yeah, now that's more like what I had in mind.
  2. 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.
  3. 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?
  4. 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.
  5. Not necessarily. Even if no more major updates are coming, what's stopping people from making threads about what they would've liked to see in a 1.13 update?
  6. It's very minimal. Couple months ago I tested it to see if it was the reason why my station had low FPS and the performance impact of 14 open docking ports was something like 2-3 FPS on a low-end PC, way less than merely having a 40+ part station.
  7. I don't use exploits other than the "get out and push" one when I run out of fuel.
  8. 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.
  9. ...okay, I'm beginning to approach what territory again. Do open nodes cause drag or not? Because I keep seeing opposing answers every couple of months rotating between "yes, they do" and "not since 1.0".
  10. FYI, the [X] Science mod allows you to mute the music in a certain scene without affecting the rest of the game by right-clicking the mod's button.
  11. On the other hand, is it just me or does the video indicate docking ports have a very limited rotational range?
  12. GET. THE. *bleep*. OUT. There goes the DockRotate mod from my mod list. Awesome!
  13. If you've got Making History, the KV-3 works just fine as a lander. It's just a bit heavy.
  14. 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.
  15. 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: 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...