Starman4308

Members
  • Content Count

    1,697
  • Joined

  • Last visited

Community Reputation

1,790 Excellent

3 Followers

About Starman4308

  • Rank
    Blind Astronomer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The primary limitation to multipurpose industrial robots isn't the form factor. It's the programming, and to a lesser extent, some types of sensor like smell and fine touch. Humanoid robots without the programming for multiple tasks is just a waste of money... and once you have the money to write the software for a new task, you may as well build a bespoke robot (not to mention fewer things can go wrong with single purpose equipment). A humanoid or other general purpose form factor (e.g. spiderbot) really needs strong AI to kick off.
  2. Mostly YouTube or other web surfing on a second monitor. RO means large dV requirements, and it's cheaper to skimp out on probe thrusters, so 4-20 minute burns are not atypical.
  3. What I've heard about Take Two: An boilerplate EULA whose more plausibly threatening terms were never enforced. They briefly shut down a mod for GTA that did break EULA and permit breaking DRM. None of us know for certain what went down, but given the kneejerk reactions many have to anything Take Two does and the sensationalism that surrounds it, I'm inclined to give them the benefit of the doubt. I'd give Star Theory the benefit of the doubt as well, but Star Theory is no longer in existence. I can't not-boycott a company that folded. Overall, I'm glad for this thread, because I did have a very negative reaction based on that Bloomberg article, and some of the comments here made me remember "oh yeah, media coverage is frequently sensationalist and there may be much more to the story".
  4. Short version: insufficient data. Long version: I've found most of the flak leveled at Take Two laughable, with this being the first real concern. What reassures me somewhat is that job offers were extended to nearly the entire team. This likely was not a cost cutting measure: you don't offer incompetents a job or needlessly disrupt an effective team. It's entirely possible that one too many insults was passed at the negotiation table and Private Division went for the nuclear option. Never discount ego: businesses are made of people, and people occasionally do irrational things. A bit of time will help clarify things: if this was a one off event, or if Private Division will make a habit of hostile takeovers.
  5. For this to work: there is a hard constraint that exhaust velocity must at least match your velocity relative to atmosphere. It's actually a bit of a thorn in the side of any sci fi writer who wants spaceships refueling by dipping into the atmosphere of a gas giant: for that to provide net propellant, you need something like a fusion torch as your engine.
  6. My understanding is that floating origin/Krakensbane solved the most problematic issues. While there's minor inaccuracies caused by 32-bit floating point, it's definitely playable. Most RSS issues are caused by a patchwork of multiple mods, rarely still maintained by their original authors, on top of the kludgy mess that KSP itself is. As to the thread topic: I'd maybe prefer some scale up, but a smaller system does ease the learning curve. RSS, scaled or not, also conflicts with the core interstellar aspects of KSP 2; it's intended to feature additional solar systems. With RSS, many are the lightyears to "nearby" exoplanetary systems.
  7. Weeks at best, quite possibly months to complete a realistic ion engine maneuver at 4x timewarp.
  8. Unrealistic does not mean unplayable. In this case, the Dawn engine would be unplayable without either unrealistic stats or on-rails thrust calculations Persistent Thrust style.
  9. First, that's a hair cheaty. Second, unless you're trying to use vacuum engines, 100 m/s is likely a huge overestimate. It gives you an almost negligible amount of velocity and gravitational potential energy. You do have less back pressure from atmo, bringing Isp closer to vacuum levels, but you're not going to get enough to justify switching to vacuum engines without either mods or craft file editing.
  10. There are several misconceptions in your post. 1) Just because a AAA publisher is backing the title doesn't mean they give AAA resources to the game. It's being made by a small team on a tiny fraction of the budget Take Two allocates to their AAA titles. 2) A better game engine will not help. Nobody in game design is possessed of a rigid-body physics engine meaningfully better than the one in Unity, and that is the bottleneck. 3) Unless I miss my guess, the KSP 2 team is doing something far smarter than trying to parallelize the monstrous problem that is rigid-body physics. They're probably going to do some sort of static or dynamic parts welding, treating groups of parts as a single part where the rigid-body physics engine is concerned. That scales up magnificently without requiring them to write a high-performance rigid-body physics engine from scratch. 4) Writing a better rigid-body physics engine won't help much, because the problem is inherently difficult to parallelize due to the self-consistent nature of trying to solve a large set of rigid-body constraints.
  11. I think there was at least one point where KAC stored settings in GameData, and there's some mod in my current RP-1 install that occasionally triggers an MM cache rebuild.
  12. For moddability, portability, and ease of sharing save files, flat text continues to be a good choice. Something that would add a bit of complexity would be to essentially bake MM into KSP 2, such that you can have "source" flat-text files in GameData with a cache that can be rapidly loaded if it hasn't changed. Hopefully, modders this time around remember to store settings and other mutable data outside GameData. For save files, they may consider bundling a save file converter which would let the player extract binary save files into flat text and back again This would have the effect of making life a bit more difficult for people who frequently manually edit or view save games, but is at least a compromise between speed and viewability/moddability.
  13. With RP-1, this becomes a much more substantial question due to tooling costs. Due to that, I tend to go for a low-thrust sustainer core that can just barely get off the pad, then slap on boosters as needed for heavier payloads. This results in OLV families with 0-8 boosters, occasionally including 1-booster designs, and sometimes with alternate booster selections. For example, if I need just a little extra thrust, I may slap on 2-4 Castor 1 SRBs, whereas more demanding payloads may call for a pair of LRBs.
  14. A good bet would be to park the return vessel at a Lagrange point, Eyes Turned Skyward style. It's a little bit more dV-intensive, and means a longer trip back to the return vehicle, but you can get to a Lagrange point from any point on the surface for roughly the same cost, letting you pick landing sites at will. I would rule out the high mountains unless a specialized lander is developed, as beyond the roughness of the terrain, you also need to deal with how thin the Martian atmosphere is up there. Seismic activity is likely a non-issue. Mars isn't 100% seismically dead, but it's not exactly prone to massive quakes. Radiation protection is likely a matter of mission duration. Short-duration, you can get away with minimal shielding. Long-duration, and you're probably going to want to set up your base underground... which incidentally solves some dust-related problems. Power: for a short-term mission, you can probably do solar panels + batteries (or regenerative fuel cells). Long-term, you can do either solar cells + wind turbines w/ storage, or go for a buried fission reactor. The latter also has the advantage of providing all the heat you could ever need. Heating: insulate the floor, and with how thin the Martian atmosphere is, you're probably not going to need much heating. This will be less of a concern if a fission reactor is used for power. A lot of choices depend on mission scope (30 day flags-and-footprints or multi-year base) and whether the local terrain is amenable to underground bases. I believe there's at least lunar proposals to use lava tubes to put the base in, though I don't know offhand if there are similar features on Mars one could exploit. Digging out your own cave is all fine and dandy until you try to figure out just how much Marsmoving equipment you're going to need for the job.
  15. I'm given to understand it's generally been the expectation that pilots be allowed to parachute down safely, even if it's over their own territory where they will undoubtedly be back in action the next day. It's been a while since I read about it, so I'm fuzzy on it, but I'm given to understand at least one WW 2 ace pilot was vilified for shooting pilots under their parachutes if they were over their own territory (though he did refrain from shooting pilots down over his territory under the assumption they would be captured). It does not hurt matters that there are frequently more pilots than aircraft available: the loss of just the aircraft is still a substantial blow to the enemy's capacity to wage war in the air. Now, as to whether this is morally consistent with how soldiers of other services are treated, I'm less certain, but so long as both sides agree to fight by the same rules, that's OK by me. These escape systems are probably bending the rules, and I could see countries saying "nope, you're not going to do this with us", but these systems would basically amount to a roughly ~100 mile extension of "we still won't shoot you under your parachute if you're over your own territory."