Fearless Son

Members
  • Content count

    605
  • Joined

  • Last visited

Community Reputation

494 Excellent

About Fearless Son

  • Rank
    Spacecraft Engineer
  1. That is actually something a patch last year handled pretty neatly, by spinning the physics calculations for separate ships out to separate threads. The total part limit per thread might still be an issue, but two three-hundred part ships in an rendezvous will calculate like two three-hundred part ships, as opposed to one six-hundred part ship which is what it was effectively doing before. So long as you have multiple core CPUs (as most computers these days do) you have to try a lot harder to drag down that physics performance now than you used to. Fun fact: middlewear physics packages like Havok and PhysX are already heavily code optimized, and I speak from the experience of someone who did professional performance testing on a game that used one of those regularly. So long as you keep the physics objects under a budget, they run incredibly quickly. Unfortunately, anything that allows users to arbitrarily add things to the simulation is going to go over its nominal CPU budget at some point. As being able to add objects in various configurations and quantities within the simulation is pretty core to the KSP experience, I cannot see this changing any time soon.
  2. I feel like the auto-strut feature has actually resolved this pretty handily. I mean, I think it is part of the intended gameplay design that rockets should be delicate in some ways, players should have to think about the balance of different forces on different parts of the rocket and weigh the benefits of strength/weight requirements of various pieces on various missions. That said, rockets should not be built out of matchsticks either, and a little forethought on the part of the player during the design phase should be able to overcome these issues. Manually placed struts are one of the ways this can be resolved, but the auto-struts are a more subtle way of doing it. They are there if a player needs to use them, but the point is that a player still has to think about how to use them if they do. I tend to think that kind of consideration is part of the fun, but as fun is subjective your mileage might very.
  3. I sense a few unspoken assumptions among some commentators in this thread that I would like to address. First, there seems to be an assumption that Unity is a crap engine. As @Alshain pointed out, this is not true. Unity is actually quite a capable engine. Unreal or Cry Engine might be a little better optimized for super-high end rendering, but the differences are not all that much. I think this perception comes from the fact that Unity is one of the most accessible engines, which is a big point in its favor. It is very easy to develop for, very inexpensive to license, and very easy to mod for as well. However, its low barrier to entry means that Sturgeon's Law applies more liberally: it means that the crap does not get filtered out if someone decides to make crap using it. That is not Unity's fault. Second, there seems to be an assumption people are making about how optimization works. First of all, it is never a matter of "just tighten up the graphics on level three." Performance optimization is like a kind of careful balancing act. A seemingly minor enhancement to graphics in one part could lead to a massive performance hit somewhere else, or taking a seemingly "little" item out of memory might result in a drastically smoother framerate. So if someone says "I want better graphics!" the developers have to balance that against everything else they have going on in the game, which might have an impact outside of what the person asking for it thinks it will. Likewise, if someone says, "I want better perf!" they have to understand that might mean giving up something else that might otherwise be important. Sometimes you can make a few code tweaks that, on balance, gain you more than you lose, but those are the low-hanging fruit, and the gain is not always big enough relative to the effort it would take to make them. And sometimes what is being traded away to get it is stability, and I doubt anyone wants less of that. Finally, a lot of these kinds of complaints are from people who tend to use a lot of mods. Everything I said above about Unity and performance? That goes double for mod-makers. Unity's ease of developing for means that mods are easy to make, but that can also mean a lot of neophytes can end up making mods, and they might not be cognizant of everything they are trading to add what they put in the mod. Someone who loads a bunch of high-resolution textures for example could have a drastic effect on performance, especially if combined with other mods that do more of the same. Squad knows what they put into KSP and they limit it to a budget for a reason, but mod-makers do not have to fit themselves into that. And further, you cannot hold Squad responsible for what other people do to their game. Any mods you install are done at your own risk (to performance/stability) and Squad can only do so much to facilitate them. Unfortunately, the more they do the more likely mod makers are going to try and push the envelope. This is true virtually every time a piece of underlying technology gets better. Having both worked in Unity and worked on performance optimization for a major multi-platform AAA release, I felt the need to frame these things appropriately.
  4. "RX-78 to White Base..."
  5. Automatic fuel-flow balancing across adjacent tanks. This made everything a lot simpler. Prior to that, I would have to set up fuel lines everywhere and selectively lock-down flow from certain tanks just to ensure that the craft retains proper balance during thrust. Now though, the game is much smarter about which tanks to drain first, and multiple tanks all joined together are considered one large "tank" as far as fuel-flow seems to be concerned. Makes VTOL aircraft and powered landers much less finicky.
  6. I would be okay if the Swivel had better gimbling for that cost, weight, and thrust. The Reliant is great as a LF/O booster engine (good TWR and inexpensive) but there are control advantages to having the main lifting engine be capable of vectored thrust to adjust for perturbations or slight aerodynamic imbalances during the lower ascent.
  7. How are they drinking through their helmets? I think I have an idea...
  8. I noticed you have a large monopropellant tank just behind your cockpit. That honestly probably contains much more monopropellant than you actually need. Especially if you are including vector RCS nozzles which fulfill the same purpose just with a different resource requirement (LF/O) and more thrust. I would recommend replacing the monopropellant tank with a similarly sized LF/O tank, and replacing the other RCS blocks with more vectors. Not only will this give you better RCS control, you will save on some of the excess monopropellant weight you are (probably) bringing along with you, give your vectors more fuel, and allow you to shift weight between the fuel tanks.
  9. I would recommend you add another fuel tank near the front. Not necessarily a large fuel tank, and not necessarily even a full one. But having fuel tanks at the front and back of a spaceplane will allow you to adjust the center of mass of the plane forward or backward by shifting the fuel from one tank to the other. I find this can help a lot for maintaining control during descent. Though it helps to have fewer total tanks with more capacity than lots of separate tanks with little capacity since you will need to adjust fuel flow quickly and while under external forces, and balancing the mass across many different tanks can be hard without mods for that purpose. I would recommend two tugs, but not necessarily one at the front and one at the back. The problem with that is then you need to get each tug perfectly aligned with the other tug. To do otherwise means that the wheels of one are not necessarily parallel with the wheels of the other, and that can lead to control problems, which you definitely do not want when lifting something heavy. But do consider adding docking port juniors to the front and back (or possibly the sides) of your rover. That way you can send multiple rovers, link them together, and have them all move a larger mass as one extended rover. Docking each rover to each other will ensure they keep their wheels aligned while spreading the weight of the object being carried across them.
  10. About the simplest version of this I know is the kind with drop-tanks. As long as it has enough air-breathing engine power to lift a little extra weight, you can use small external rocket fuel tanks to burn through while doing its trans-atmospheric burn. Once the tanks are spent and it has a trans-orbital trajectory, you can drop the tanks and save some weight for the orbital circularization burn.
  11. Aye. I find it especially useful for testing how easy it is to land a particular plane. The island airfield is a lot shorter than the airstrip at KSC while also being on a much steeper rise. It requires the pilot have better judgement about their altitude, and the plane needs to be able to get all its gear in contact with the runway very quickly and with minimal impact if it is to have any hope of landing.
  12. [Redacted]
  13. ... why do they need a boat at the bottom of the sea?
  14. The KSP forums do not host files of their own, but you can link to files from here. I see you already have a Google Drive for the .craft file. If you take any screenshots, you can upload them to an image sharing site (Imgur seems to be one of the most popular here) and embed the photo in the forum post using the "Insert other media" button below a new post and selecting "Insert image from URL".
  15. Aww, I know how you feel. Out house hold has a kitty named Pumpkin too! And just last November we lost one of our cats, Horatio, who was just a few months past his twentieth birthday. Years ago, I lost my childhood cat who lived to be twenty-two! Cats really do seem to get sweeter and more affectionate in their old age.