Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by SciMan

  1. I usually try to explain things with an "in-universe" explanation first. But at the end of the day, "it's a game, let it be a game, games are supposed to be fun, XYZ new weird mechanic that nobody asked for isn't fun and shouldn't be in the game" is my fallback line of reasoning. And this time, "lightspeed communications delay for science transmission only and not probe control" is... very much not fun. Nobody likes having to wait to play with the new toys that the game told you "you unlocked this new thing" but you "can't actually play with them" because "the message hasn't gotten here yet" or something. I'm not playing KSP 2 to "wait for something in the mail", which is what lightspeed communications delay for science transmission and tech tree unlock synchronization does. I only put up with 2-day delivery on Amazon because it costs an absurd amount of money to get even faster shipping. It costs 0 dollars to not play KSP 2 because it has a mechanic that introduces too much grind or "I could be doing so many other things right now that would probably be more fun" type incentives. I don't do no hit runs. I don't do speed runs. If a game is too grindy, I'll cheat or just not play it. I generally don't play rogue-likes for a long time, even if I was really interested in them to start off. KSP 1 as it is is already too grindy, which is why instead of playing it continuously I play it in short bursts of like 2-3 months at a time. After a while I forget how grindy it is, and I start thinking it's a fun game again, so I come back, find out it's very grindy, and get turned off of it. And that cycle repeats. I don't want that happening with KSP 2. I don't even play KSP 1 career because locking things behind money just gets in the way of building and flying rockets. Same with the research requirements in Science mode, now that I think of it. All it does is get in the way. The tech tree isn't even organized in such a way that you get the truly useful and "really you should have these from the start" structural parts like beams and girders (the kinds of things that should be able to be taken directly from mundane architecture instead of having to unlock a "space rated" version), because parts of literal ground buildings shouldn't be locked behind needing to get research from the Mun. Same with the aerodynamics parts, there's no reason going to the Mun should unlock research about how to go faster thru the atmosphere with air-breathing propulsion.
  2. I can agree with that, I guess it's even better if it doesn't need a reason to explain it away, especially if that reason violates the known laws of physics. "Because it's a game, dangit" is a fine reason. Not all things need to have an in-universe "immersive" explanation. If you provide an in-universe explanation for everything, you do make a very immersive universe. But you also have to very carefully skirt around falling into the pit of making your "different" universe just be "Real life but almost not".
  3. Easy. All capsules probably still have small monopropellant tanks (they might have even increased the capacity of the monopropellant tanks because that reduces part count). If that's still the same-old Mk1-3 capsule that I think it is, then it should store 30 units of monopropellant. If you're really good at rendezvous and docking, that's way more than you technically "need" to dock probably 1 or 2 times. I generally don't put that much monopropellant on my craft. The RCS is only used for docking and OCCASIONALLY to prevent an extremely seriously sideways landing attitude from becoming a landing that flipped on its side. As for what happened to this particular lander, I can only imagine that since the terrain is relatively flat that they tried to contact the ground while still having some significant sideways velocity (my estimates are in the range of 3-5 m/s horizontal velocity at touchdown). This then caused the classic "flip over and oh crap shut off the engines" response, when they should have seen that they were tilting sideways when they touched, mashed "full throttle" while the craft still had the engines pointing "sort of down" engaged the RCS and corrected attitude to pointing up again, cut throttle, point retrograde, and tried for landing again. EDIT: This would have resulted in them likely having an "eventful but largely successful" landing EDIT 2: I know that this is the right thing to do because I've had a very similar situation happen to me on more than one occasion. It's a lot like landing on an aircraft carrier. If you miss the arresting cable, you don't cut throttle. You go to FULL AFTERBURNER as quickly as the engines can do that, because you're not gonna be able to stop, your only choice is to go around and try again.
  4. Did the forum just break somehow? Because all those "the parallax thread can be found here" links are coming up as a white box with a sad face saying "Sorry, this content is no longer available." But from what I saw on the OP, Parallax looks great, at least on Kerbin. I'll echo the thoughts of some others here when I say that maybe things that look like "life" shouldn't be found on other planets in the Kerbol system, not on Even and not on Laythe. The atmosphere has no oxygen on Eve, and there's far too much radiation on Laythe thanks to it orbiting Jool with Jool's theoretically immense Van Allen radiation belts that Laythe should be right in the middle of (tho I suppose some form of radiotrophic microbe that somehow puts out oxygen would make some sort of sense there)
  5. Small diameter "lifter grade" parts are something I'd love to see. But then that might also require smaller still payloads. I think a 0.625m rocket should be able to make it to orbit. But I don't know what I'd put on top of it other than a nosecone. I'd ideally like a 0.625m diameter payload fairing part, so I'd be able to put the payload in something to prevent it from having atmospheric drag on the way up, even if it doesn't need thermal protection. So, an 0.625m high-ish thrust sea level engine (maybe 40kn thrust at sea level, ISP of... maybe 250s at sea level and 275 in vacuum, and under half a ton dry mass), an 0.625m vacuum rated engine (Spark is fine for this, but I'd really prefer a little less thrust and a little more ISP in vacuum, say 10kn and 335s ISP in vacuum, with maybe 0.075t dry mass since it's "less engine" than the Spark), longer 0.625m fuel tanks that share the Oscar-B's strangely high fuel capacity for its small volume, and of course the payload fairing like I mentioned. Might need a smaller diameter decoupler to go with that payload fairing as well, payload fairings don't like to work with a decoupler that's the same diameter. But there's another category of "small rocket" parts that might be nice to have. Or maybe "not so small" rocket parts too. SRBs that are optimized for use in vacuum. IRL there have been many hundreds of satellites launched to geostationary transfer orbit that used a solid rocket motor to raise their periapsis most of the way to a circular geostationary orbit, with the satellite's own propulsion systems making up the rest of the velocity needed because these things need some real fine tuning to stay where they're supposed to be stationed and an SRB is ill-suited to that. So, something like a Star-37 or Star-48v would be nice. Yes, I mentioned the Star-48v instead of another star-48 variant for a reason. It has a nozzle that is capable of thrust vectoring. Additionally, perhaps some specific special variants of larger vacuum-rated SRBs could be complex enough to incorporate blow-out panels intended to be used as a thrust termination system? You still can't stop the SRB from firing, but you can stop it from providing meaningful thrust by opening the other end of the tube! Maybe also adjustable multi-pulse SRBs, for similar requirements where you want to precalculate where the burns start and end, but also useful for times where you don't want to use 2 or more SRBs with part loads of fuel in each one when you could save weight by using one larger SRB and dividing up the fuel by putting one or more high temperature burst disc(s) and additional ignition system(s) in the middle of it to split it into multiple smaller "segments" of SRB thrust. Both of those things exist IRL, tho in general they're only used on ICBMs. Plenty of places where you could use them in a space exploration mission tho. You could use a thrust termination capable SRB to get a moderately precise transfer burn done to encounter the Mun, and then a multi-segment SRB to do the Mun capture burn as well as the de-orbit burn and braking burn, with liquid fuel only taking over on final descent. We shouldn't be forcing players to learn that they need to spin-stabilize their small solid rocket motor stages or provide additional systems in the form of RCS for them, that seems like something that just adds more parts and reduces fun even tho it's realistic, and who's going to code in a "yo-weight de-spin system" into Kerbal when that's a thing that's hardly ever going to be used outside of some extremely specific situations anyways, realistic or not?
  6. IMO light speed communications lag just doesn't belong in KSP 2. The speed of light in KSP 2 could be said to be "observed to be as close to infinity as our instruments let us measure". This gets rid of the entire problem quite handily, with exactly ONE departure from the known laws of physics. Besides, it's just not a good gameplay mechanic (I'll explain below), and it would require a lot of complicated calculations to implement, because believe it or not you're opening a HUGE can of worms when you want to introduce speed of light delay (and I'll explain why it's such a huge can of worms further below). Why is it a bad gameplay mechanic? It's all stick, no carrot. There is only ever a punitive effect given to the player. Light speed communications lag as a game mechanic is a bad idea, because there is no situation where NOT knowing about some important advancement in technology or science is ever beneficial to any race of sentient beings, Kerbal, Human, or Other. So if knowledge is power, you want all the "power" all the time, as soon as possible, right? At least that's how IRL is going, humans have the ability to look up more knowledge more quickly now than at any other time in history, ever since the advent of smartphones with an internet connection and access to a search engine. It's the same reason why I think Life Support is a bad game mechanic, at least in the way pretty much all the KSP 1 mods for it implement it. What do you get if you design a ship with a good life support system? The crew gets to experience that greatest luxury known as "Not Dying". Aren't you happy the game didn't kill you? No? Why? Is it perhaps because "the game didn't kill me because I did something right" sounds like the start of an abusive relationship between you and the game? That's what it sounds like to me, or at least it's a very few steps removed from it. "Do right and don't get punished" without a "do right and get rewarded" isn't how you design a fun game. Maybe some people find that kind of game fun. I guess that's why Elden Ring is so popular these days. But I don't find Dark Souls type games to be fun at all, there might be "some" "carrot" type rewards you get, but it's not much, and it's buried under a MOUNTAIN of "stick" type punishments for not doing something EXACTLY right. I don't appreciate the games I paid money for treating me like I'm a misbehaving dog. And just like a misbehaving dog, I probably won't understand why the game's punishing me the first few times it happens, leading to a period of trial-and-error before I decide that the whole thing's just not worth it and I avoid the situation entirely by not playing the game anymore. Put another way, you don't train any living thing well if all you ever do is use the stick. Sometimes, you have to use the carrot. Besides, there's no communication delay in KSP 1. Why put it in KSP 2? Sure the distances are greater, but there's other problems with this. And here's where I explain the part where implementing lightspeed communications delay opens up a whole can of worms that I promise you you don't want to open If you implement ONE feature of "communications delay, or ships not being able to go faster than light", you have to implement BOTH of them, or your game will be inconsistent with respect to the laws of physics. If you fail to simulate EITHER ONE, you get SOME form of the possibility of FTL communications. If you simulate Relativity but not Lightspeed Communications Delay, you get "FTL radios". Plenty of games do this, but none of them have realistic orbital mechanics based spaceflight. But if you simulate Lightspeed Communications Delay but not Relativity, you get "FTL mail ships". Plenty of games do this too, but again, none of them have realistic orbital mechanics based spaceflight. Either way the message is allowed to travel at speeds greater than the speed of causality, with the resulting issues of time paradoxes arising naturally. What's an "FTL mail ship" you ask? Well, let's say you don't have relativity saying you can't accelerate a physical thing faster than the speed of light. But you do have light speed communications delay making messages take literal years to cross the gap between stars. That's fine. You can just design your fastest possible ship, and send messages on that ship, rather than on electromagnetic waves. A physical carrier for a message of data. A mail ship, that goes really fast. A mail ship that goes faster than light. Or you could skip right to the end and call it a FTL mail ship. Or an FTL Courier even. This brings up a problem, naturally. If you use such ships to carry parcels like we use airplanes to carry Amazon.com orders, causality gets weird. Not only does your package arrive instantly. Oh no that wouldn't cause a problem. What happens is that your package arrives before you even ordered it! Now I don't know about you, but that sounds like a universe-ending problem. Because the link between cause and effect would have been effectively broken. Besides, it is my personal opinion that methods to break causality, either with a physical thing or a simple electromagnetic wave somehow traveling faster than light, always result in the universe de-stabilizing and it only becomes stable again when the universe has eliminated all evidence of that method of breaking causality. Likely by containing them inside the event horizon of black holes. In other words the only stable universe is one where there is no possibility of backwards time travel or violating causality. That's why I think setting the speed of light to be "infinity as far as we can tell" is so smart. If the speed of light is infinite, then you can't go faster than light, no matter how fast you go. Of course the concept of measuring distances in light years also evaporates with that, so we'd have to switch back to physical standards for length, but that's a small price to pay IMO for doing away with the whole problem of not breaking causality, while also not unduly penalizing the player for "the universe being the way that it is".
  7. Life support on COLONIES makes a lot of sense to me, when you think about how it interacts with the other gameplay mechanics. Sure, it might not be a major drain on your resources, but it could be a key element in allowing the player to derive maximum benefit from these "Population Boom events" that the devs mentioned several times as being a large part of overall gameplay. I can think of two situations where life support on colonies comes into the picture. In one case, it's a negative thing, however in a way it's because you the player messed up or forgot something. In the other case, In either case, life support would play into the challenges faced. First off, the "negative thing" type of Life Support interaction with Population Boom events: If you have all your colonies sized "just right" for their population, and you have a population boom event happen, then you could suddenly have a bunch of Kerbals on your colonies that don't have a place to call home. To fix that, you might have to delay sending that next exploration mission or mining station out from the colony until you can solve the housing problem by expanding the habitation section of the colony, as well as maybe adding more life support equipment as well. Now for when the interaction can be a positive thing: If you planned for the population boom event BEFORE it happened, you could have the colony ready to accept a larger population before you make the boom event happen, and by doing this you might even be able to get a "bigger boom event bonus" out of the situation. For example, the life support systems might say they're "rated to support X Kerbals" but for short periods the life support systems can actually support let's say "X+5" kerbals, and with the habitat spaces there's only so much hot-bunking you can do. In both cases, you'll eventually hit a "hard capped maximum" population beyond which population will never increase no matter what, unless you expand the habitation spaces and add more life support equipment. In the negative case, that could be a reason why a colony doesn't see its population increase as much as expected during a boom event. However a smart player could think "hey, I'm about to try to do something new or set a new record, I should probably have a plan in the works for if that sets off a Boom event", and so they preemptively increase the size of their colonies hab section and life support equipment to handle the incoming EXPECTED Boom event. In this case of being prepared beforehand, the player could be positively rewarded for thinking ahead, by getting bigger population increases, as well as bigger bonuses to things other than population (doesn't matter if they're temporary or permanent, or if they're colony-wide or civilization-wide bonuses). As for life support on SHIPS, that I'm not sure of. To be honest, I'm of the opinion that it should only be a limiting factor on the smallest craft that aren't expected to be on their own for longer than say a month. On ships larger than that, a part should be available that enables fully (or almost fully) closing the resource loop of the life support system with the only true requirement being the ability to sustain an electrical draw for an extended period, and that is without regard to whatever those resources used by life support might end up being.
  8. That's nice and all, but it still doesn't stop Steam from "aggressively" updating the game when you just wanted to enjoy your save a few more months even tho a new version just came out and broke everyone's mods. Of course, it would also be nice if a save game from an older version could prompt the game to say... close itself, tell steam to revert to the same version as the save game, re-open, check to see if all the mods are compatible with the (now older) version of KSP, and only then continue to load the save (while telling the user what it wants to try to do as well as allowing the user to override whatever choices the game has made "for" the user.
  9. Well, wheels are "good enough" for movement tech, provided they ACTUALLY WORK (which takes far too much fiddling with the KSP 1 wheels, and even then you still flip over and crash and explode after 5 minutes of driving in any case, so I basically only ever use wheels to move around surface base parts when docking them together). But yes, having some tank tread type parts would be nice, as well as some sort of ground movement option that has HIGH SUSPENSION TRAVEL. I feel the need to put that in all-caps because while some of the wheels in KSP 1 do have high suspension travel compared to the size of the wheel when compared to typical automobiles seen here on the roads on Earth, it's still not enough. I'm an auto mechanic, and it's not just because there's good money to be made in this line of work. No, it's because I like cars, and I like working on cars. That means I probably have some knowledge about pretty much anything with wheels. And it just so happens that I know of a type of suspension that is suitable. The idea is to optimize for high suspension travel. Go look at a "Stadium truck" suspension, or the suspension on a "baja desert race" type truck. That's what I want out of a wheel. Not the giant "tank turning only" type wheel that is the largest one in the game right now. No, I want a wheel at least as big as that (physical size of the wheel itself minus everything else), with a tunable suspension, actual "pivoting wheel" based steering like the rest of the wheels in KSP 1, and a suspension travel of something like 1.5-2 meters from fully extended to fully depressed. Also needing to be addressed is the "binary" way that KSP 1 wheels lose their grip on the terrain, either they grip so well that you you flip, or they can't grip at all and you get the feeling that instead of being on another planet you might as well have stumbled into a banana peeling factory where the floor is both Teflon coated and you can't put your foot down anywhere without stepping on a banana peel, so you can't climb any slopes at all, and there seems to be not much of a range in between those two behaviors to me, so it seems you're stuck with one or the other, and no "happy middle ground". If KSP 2 wheels had a much more GRADUAL grip failure than that, then I think that we'd be able to build rovers that can navigate over the surface of pretty much any planet, at high speed, without worrying about the rover flipping over every 5 minutes or more often. And that's key if we want to use rovers to transfer resources between surface outposts on a given planet, which is what I would love to be able to do but can't even think about doing it in KSP 1 because the systems in place just aren't up to the task.
  10. Well if Minmus IS indeed made of ceramics, it would seem natural that materials found on minmus would be REFRACTORY ceramics, aka they're useful at very high temperatures as an insulating or shielding material (SiC is one of those). So, extracting minerals from Minmus might be the key in the Kerbin SOI that lets you produce aerospace parts rated for both atmospheric reentry AND not based on using ablative heat shields, aka one of the key pillars for building a truly rapidly reusable SSTO. As in a vessel capable of Airliner levels of "fast turnaround". Land, unload anything you brought back, check over the craft quickly, go to the payload loading building, get refueled, and then launch again (maybe swap out the crew?). Can't do that with an ablative heat shield, and lightweight, high temperature ceramics are one key to realizing a lightweight and indefinitely reusable heatshield for something like a spaceplane or rocket-powered VTOL SSTO.
  11. Well, tripropellant rockets "can" have better ISP than bipropellant rockets. Or you could do what the Russians did when they were trying to make a spaceplane. Make a rocket engine that is normally Hydrolox, but at launch you can inject extra LOX and Kerosene (RP-1 or RG-1 or even Syntin which isn't quite kerosene but it acts like it except for better ISP I think) to get more thrust out of the engines for when you really need to push up and out of the atmosphere with all that fuel that you haven't burnt yet. Enter the RD-701 Now, like you said, you can in theory use a tripropellant rocket engine to get improved performance. However, most of the studies that I have read were about using Hydrogen, Lox, and Lithium in combination. I don't know about you, but last I checked, Lithium is... problematic to handle, because you have to keep it hot enough to stay melted. That means the fuel tanks are gonna be heavy, and as every study I read found out (by doing the math), that is more than enough extra weight to chew right thru all that extra margin you got by "improving" the performance of the rocket engine. Gotta watch out for those kinds of things when you think you're on to something "better". It usually has a critical downside that might be getting overlooked. That's why the RD-701 is such an interesting engine. It's not trying to improve performance over a Hydrolox engine, it's trying to be what's basically a dual-mode engine. However, there are other means to improve the specific impulse of a hydrolox rocket without sacrificing so much performance by extra weight in the fuel tanks. It doesn't involve a third propellant tank tho, so technically it's still a bipropellant chemical rocket. The idea is that you add something more reactive than oxygen to the oxidizer. Most of the time this ended up being Fluorine, because that's the most reactive halogen (Oxygen is technically a halogen, but biology likes that one so most people think of it as it's own thing unrelated to the other halogen-type elements like iodine, chlorine, fluorine, bromine, oh and Fermium, but that one's so radioactive that it decays before it can react chemically most of the time, so that's another one considered to be its own thing). The oxidizer created is named "FLOX", for "fluorine-doped LOX". Studies showed that when you could stop the stuff from rapidly corroding literally anything made of metal to the point of nonfunctionality, it provided a specific impulse boost of I think 20-30s or more over the ideal ISP of straight hydrolox. However, like you might have caught on to, that's "when you can stop the stuff from eating the metal parts of your rocket". And that took some careful design and engineering work on protective coatings. Of course, the exhaust from such a rocket engine is also spectacularly toxic, seeing as it has a high proportion of anhydrous Hydrofluoric Acid in it, and if anyone here has experience with that stuff you know that the best reaction to seeing that stuff leak is a good pair of running shoes. Not because it'll eat you alive. No, the stuff is acutely toxic to life as we know it, AND it'll eat you alive in sufficient quantities. You'll get poisoned first tho.
  12. My personal bit of lore is... not about the Kerbals. Instead it's about Minmus. I think Minmus should still be an ice ball. To make this happen, I also think that Kerbol should be a red dwarf star. Now that brings up an obvious problem. Why does Kerbol when viewed from Kerbin in KSP still look like the Sun when viewed from Earth IRL? The answer is in the eyes of the Kerbals. They're aliens after all. They have different eyes. To see in color, all that is needed is for the eyes to have sensitivity to multiple different wavelengths of light. WHICH wavelengths of light tho? There's the key. If Kerbals eyes are sensitive to three LONGER (redder) wavelengths of light than the three wavelengths of light that Human eyes are sensitive to, then their brains might just put the pieces together in a way that makes what a Kerbal calls "white" a combination of overall longer wavelengths than what Humans call "white". And that little bit of "the brain's using the same name for something that's actually different" thinking is what allows the spectrum of Kerbol to be whatever the heck it needs to be (aka cool enough of a star) to allow Minmus to be a ball of ice at the distance from the star it is in the Kerbol solar system. EDIT: Oh and I did all of that without having to break a single law of physics. That's pretty impressive, if you ask me!
  13. But an offline mode for Steam isn't what I'm asking for. It helps, don't get me wrong, but it doesn't fully solve the problem. An offline mode for steam just stops EVERYTHING updating, and there's other games I play that update thru Steam. I can see a situation happening where I want those other games to update but I DON'T want my KSP 2 to update, because the KSP update just came out and it would break all my mods that haven't updated yet... That's why the ability to play the game (even in multiplayer) without it being forced to update to the latest version by Steam doing whatever it wants out of my control is so critically important. That and a way to tell steam to revert to an older version. What is really needed to fully solve the problem as it appears for KSP 2 is in fact two things: 1. A much finer level of detail over what games update when, along with the universal ability to revert without having to specify a reason you want to do so (critical for KSP and KSP 2 and pretty much every other game that is heavily dependent on mod support for core game sales). 2. A true offline mode that allows you to play the offline content (if any) of any game, in the absence of an internet connection: There would be multiple ways to enter/exit this offline mode. You could do it manually even if you DO have an internet connection, of course. However you would also be able set an option on Steam's connection settings to automatically switch into offline mode if you lose your internet connection. When your internet connection is re-established after such an automatic disconnection, you would be able to pick from a list of set actions to dictate what Steam does when a connection is re-established. Perhaps something like the following options: Automatically exit Offline mode. Prompt the user that Online mode is available, and that they should select if they wish to remain offline or not Remain offline until manually re-set to Online mode. Depending on the kind of game, or what the game's developer wishes, a game could of course be set so that Steam always feeds the client the update, no matter if they want it or not, I know that some kinds of games need this to maintain stability and game balance (mostly competitive multiplayer games, as well as some other kinds of software), but that's a decision that would be communicated by the game's developer or producer when figuring out what way they want to get Steam to distribute it. Steam Client updates (not steam game/software updates) would be downloaded (following the download bandwidth limits set in Steam) at any time that Steam has a valid internet connection, regardless of the user setting Offline mode or not, for security and stability reasons of course. I think that covers everything I want out of what Steam does regarding game updates.
  14. Like usual, my number 1 want for "vanilla mod support" is the functionality of ModuleManager to be implemented in the game without needing to install any mods, which would greatly ease me doing the thing I like doing the most, namely tweaking config files to my liking. It would also make mod inter-compatibility patches much easier to implement, since you wouldn't have to over-write any of a given mod's config files.
  15. I'm sincerely hoping that they allow multiple installs, but specifically with the caveat that any additional installs are NOT shackled to Steam updating them "whenever it feels like it". While that method is critical for a competitive multiplayer game that doesn't support mods, for any game that DOES support mods, it's a deal-breaker. Because at any moment, you could lose your entire save file simply because you can't find the updated mods that were in your save file doing critical things like supplying the data that represents modded parts for your vessels. I'm sure many of us have gone thru that problem with KSP 1, for me it's why I don't have Steam having the ability to track my play-time of KSP. I never play the steam version of KSP, instead I copy all the files from that install, move them "somewhere else" that Steam can't get its hands on them, and then play happily until I tire of that modded install, without fear of an update (that wasn't anticipated or planned for by me) ruining my install in who knows what way. Without the ability to choose when I myself (and nobody else) wants me to update my copy of KSP 2, I'm not so sure I'd be so happy playing it with a lot of mods, as I fully expect to be doing.
  16. Well, that answer gets into human psychology. I might not have a college degree in the subject, but I know how I myself would react. Those of us who desire to do so would be able to start planning out a "practicing for KSP 2" install of KSP 1, and honing my skills. Heck, we might even see a mod-pack show up that allows for such an experience. We'd be able to have far greater peace of mind knowing that certain things aren't in fact "holding the game up" as so many seem to have convinced themselves. We'd finally be able to stop arguing about what Multiplayer and potentially Life Support is/are going to look like. To be honest there would be a lot less overall "but what if it's like this"-type talk on this subforum, because we'd in fact know what the developers want it to be like. But honestly, I think that doing that would utterly kill off most of what passes for discussion on this subforum. Now I'm not sure if that would kill off discussion on this subforum entirely, or if we'd find new things to discuss, but I'm leaning towards the latter, at least for a little while. Ultimately, I think that if they revealed everything right now they'd also have to open up preorders at the same instant, otherwise they would lose out on sales. And yes, discussion on this subforum would take an ultimately downward turn. The tone of discussion would improve, but the overall AMOUNT of discussion would be decreased after a few weeks, just like what happens when any other amount of new info about KSP 2 is released. In summary, while from a selfish perspective I want all the info now, from a wider perspective of the health and continued existence of support for KSP 2 as a game, I don't think they are doing anything wrong right now. And since it's September 3rd as I write this, that puts the game's release (if it's in Q1 2023) at anywhere from just a little over 3 months to a maximum of 6 months away. I don't know about you, but I can wait that long. I have any number of other games I can be playing in the mean time. In fact, I think it's been roughly a week since I came back to the KSP forums, or at least the better part of a week. That's a pace I plan to keep up going forward, I simply don't see the need to look at the KSP forums daily anymore since new news is not released frequently and neither is there much overall new to discuss about KSP 2 every time I check back here.
  17. OK so I got my terms mixed up regarding how oxygen is affected by magnetic fields. Point was, you do NOT need to IONIZE oxygen to get it to respond to a magnetic field. And yes, I know that you'd have to have active cooling in place to keep the antimatter contained. But you know what? You don't have to explain all that to the player to be able to use antimatter. Just say "antimatter will always react with normal matter, so to keep it contained you need to supply power to the antimatter storage vessels". The key is to know when to stop explaining to avoid confusing the player, and also to avoid opening up any holes in your argument. In any case, I personally don't think that antimatter will be introduced into KSP 2. Fusion propulsion is more than capable, and if there is some form of "thrust generating means that doesn't use fuel" then that will also be useful. Of note, you don't need to invoke "warp drives" to get a way to produce motion without consuming reaction mass. You can always use a solar sail to do that. It works even better if you aim a lot of lasers at that sail, rather than depending on the star to provide all the energy. And it works best if you can direct a beam of particles at the sail (so-called mass-beam technology, because instead of a beam of light it's a beam of particles that have mass). With the mass-beam idea, you don't even need a physical sail anymore, you can use a magnetic field. That same magnetic field can be used to decellerate at the target star by using that star's own magnetic field and the charged particle radiation that star outputs as a source of momentum to impart on the interstellar vessel. There's also the potential to build a series of mass drivers in deep space in order to accelerate things to interstellar velocities in a much shorter time period than is tolerable by crewed vessels, this would obviously be useful for sending bulk commodities and specially braced or reinforced infrastructure equipment ahead of sending actual crew to potentially operate that equipment (so you could have the "base in boxes" sent to the other star at the same time as the crew, but the base would get there first because it was sent at a higher acceleration even if the cruising speed was the same).
  18. All I know is that I don't want nor do I think I need any form of faster-than-light drive in order to explore a few stars that are likely rather close to the home system (potentially only a few light years, maybe a maximum of 10-20LY to the furthest one). But at the same time, I do think that Kerbal lifetimes should be measured in centuries, not decades. Maybe only 2-300 years, but that's still both short enough that you can't get to another star using chemical or fission propulsion, and long enough that you don't have to get bogged down in micromanaging where all your crews are going to be when you expect them to expire (in order to prevent losing a crew while on a mission), all while having a life long enough that you don't have to replace them after only say 5 long-duration missions.
  19. Anti-oxygen would be a good candidate for storable antimatter, now that I think of it. Oxygen in its liquid and solid O2 forms is at least a little bit diamagnetic, meaning that a specially configured and/or modulated (time-varying on a static cycle, or actively controlled with something like pulse-width modulation) magnetic field can repel it. Surround a mass of solid anti-oxygen (so no boil-off) with such magnetic fields (to keep it away from the container walls) and you've made yourself a way to store antimatter quite densely, which is one of the chief problems with storing antimatter. To extract it from this storage, hit the mass with a high energy laser at a favorable point, and then use those same magnetic fields to direct the created anti-oxygen plasma where you need it to go. Simple in concept, but probably a nightmare to pull off in practice. But at the same time, if I can think of this and I'm just a college drop-out, either there's some real physicist waiting to tell me why this won't work, or the idea is at least feasible.
  20. I can totally understand wanting to be able to replace the 3d model of a Kerbal crew member with a human astronaut model. I intend to try out RSS/RO (or whatever it ends up being called in KSP 2), and that kind of feature would further put me into the world of such a modded game being maybe only a few conceptual leaps away from giving me the same kind of experience that I got when I played Orbiter Space Flight Simulator so many years ago (Hail Probe!) In fact, I didn't learn how to dock or precision land on a landing pad in KSP at all. Instead, I carried many of my space flight skills over from my many, many hours playing Orbiter pretty much every day after school after I had discovered it. Apparently, that software is still going, I think it got an update in 2016 which is recent enough that modern computers should be able to run it. No idea if any of the older mods are still out for download or even maintained anymore. I would also be utterly unsurprised if many of the well-known KSP mod authors had authored mods for Orbiter as well, despite them using different kinds of authoring tools (However, Blender and/or Maya are still in common between them I think, it's just a matter of what format do you choose to spit out the created 3d models). But KSP 2 with a RSS/RO type mod pack would be a truly incredible experience I think, and from what I've seen on YouTube regarding SOME creator's approach to playing KSP RSS/RO, it doesn't have to be any less silly than "normal" scale KSP. You can still make a rocket that is 5x taller than the VAB (or more!) and then launch it and see if it explodes on launch or not. Surprisingly, this is even possible without using too many parts, thanks to RSS/RO's inclusion of the procedural parts mod and Tweakscale. The only potential problem happens when the numbers representing the forces involved get too large and you start encountering floating-point errors once again (the old Kraken comes back on creations large enough, even without SAS, simply because of the nature of Unity joints). And to be honest, making rockets that are so large you have to build them in the Chesapeake Bay and then tow them out to sea (converting a large section of the causeway that crosses it into a pontoon bridge that can easily and quickly be moved out of the way of such a massive construction) for launch is the kind of thing I've been imagining when I imagine KSP 2, because how else are you going to use a sane number of launches to build something in orbit? EDIT: Of course, with such a KSP 2 RSS/RO mod pack, either the stock life support would have to be "good enough" or be easy to turn off entirely in favor of something added by a mod in the mod pack for KSP 2 RSS/RO.
  21. I'm quite certain that they're being very deliberate about what pieces of info they release when, and they might have even done small studies to figure out which things generate the most hype compared to other things. I know that the most recent Dev Diary (even in it's "oops the forum ate it but the community still managed to post some portion of it" state) is one of the things that has generated the most hype for me personally since the larger cinematic trailers were being released. I don't know for sure if that means they're already ramping up, or if it means that that particular dev diary just means more to me personally, and to be honest I'm betting it's that second one. In any case, the developers probably have at least some idea about how much buzz they want to generate about the game right now, and about how much buzz certain pieces of info will generate, pieces of info about what for all we know could be fully finished features of the game. And yes that includes multiplayer. To those who say that they'll have to cut multiplayer to make their deadline, first off they didn't make it a deadline they said "no earlier than" IIRC, and even then if you're not a member of the dev team you're speculating with no info, so it could be that multiplayer is ready to go RIGHT NOW but the rest of the game isnt. In reality, the question of "is multiplayer in KSP 2 what's holding things up" is in a quantum superposition of "all answers are valid and not valid at the same time". This is because the developers haven't "opened the box that the cat (or in this case, game known as KSP2) was put in", to reference the Schrodinger's Cat thought experiment. And until such time as they do, we'll just be talking in circles about it. Personally, I find speculating with no data to create a set of initial conditions to be a rather fruitless and unsatisfying endeavor because you might as well have an "i wish it was this way" machine except it doesn't work ever, but that's just my feelings on the matter.
  22. I see now, thank you for clarifying. Torch ships should be there to get a resource. But the resource should be "literally any resource". The sole advantage is that it doesn't take as long. That's it. That's all there is. Nothing else. If there was something else, that "something else" would break physics in some way. And that's because none of the elements that we're interested in have a half life shorter than 500 years. Not even uranium-235 or plutonium-239. Go look it up, they have surprisingly long half-lives, how else do you think the US has been able to get away with not making any new nuclear warheads for roughly 30-40 years now? Chemical fuels just plain don't react if stored properly. About the only thing that could possibly expire that quickly is fresh food. But there's 2 problems with that: 1. Because we humans need to eat pretty much every day from birth to death, we've invented TONS of technologies that allow us to preserve food for extremely long periods of time. So "Fresh food" is something you'd be getting from the greenhouses at a colony, not something you'd be packing for a 10-year journey. 2. Because KSP 2 is set in the near-future, I'm absolutely certain that if we do get life support as a gameplay mechanic, it will be with parts that allow the life support loop to be closed almost completely, without needing to keep track of 10 different resources that are only used for the life support systems and nothing else. So maybe you will be able to have fresh food on that 10 year journey after all. But the majority of that will be stuff you didn't have with you when you started, instead it will have been produced from the closed-cycle life support system. Everything else is about as inert as a cargo of rocks, in fact the important ores we'll be looking for and potentially shipping around are literally "just somewhat special rocks". Ok, maybe oil isn't a rock, you got me there. But here me out: Coal is just "rocks that can burn", Radioactive ores are just "rocks that emit invisible energy", metal ores are just "rocks that can be melted down to make shiny rocks", the list goes on. Even water can be a special kind of rock. What do you think Ice is? Ice is just "Rocks that you melt and then drink". Point is, there isn't any "unstable resource" that out-and-out REQUIRES transport by torch ship or you don't get hardly any of it because it decays in transit. EDIT: Having read @JadeOfMaar's reply that was posted before mine, I have something to add on the topic of Tritium: You won't be mining Tritium. Instead, you'll be creating it as you need it, if you need it at all and we're not just presented with fusion drives that solely use Deuterium and Helium-3 as fuels. How? Tritium is easy to create if you have a potent source of neutron radiation, and some Lithium. If you know how modern thermonuclear weapons work, you know what's coming next. Exposing Lithium to a high neutron flux does something useful. The neutrons smash apart the Lithium nucleus, for every Lithium nucleus split, one Tritium nucleus and one Helium-4 isotope are produced (with Lithium-6 the reaction is as indicated and slightly exothermic, with Lithium-7, you also get an extra low-energy neutron and the reaction is instead endothermic). Assuming you use a molten blanket of Lithium surrounding your fusion engine or reactor, you should be able to siphon off the produced tritium and helium. It shouldn't be hard to separate the tritium from the helium, you just need to introduce some Oxygen and ignite the mixture (or send it thru a fuel cell). Then harvest the tritium water from that reaction, and dump the helium either into the exhaust nozzle of the fusion engine or just vent it overboard without the intent to produce extra thrust, you don't need it anymore. Obviously the tritium is then stored and metered into the reaction chamber of the fusion reactor or engine, where it is fused with Deuterium. If tritium production is insufficient, or you're trying to get the thing started, you can use a fission reactor (obviously fueled by uranium or plutonium) to supply the neutrons. There will still be more than enough neutrons to go around to do the job, assuming a fission reactor that is depending on Fast neutrons to continue the chain reaction. And like I said, that's not even considering that these fusion reactors and engines might not even be using D-T fusion. They might be using D-He3 fusion instead. I know, D-He3 fusion doesn't output as much raw power. That's fine, what you lose in raw power you gain in "not needing to worry about Tritium" and "a heck of a lot less neutron radiation", both things that can reduce the dry mass of the propulsion system of your vessel (yes I'm lumping the radiation shielding in with the propulsion mass, maybe that's wrong, but since you always need the radiation shielding when you have both crew and a radioactive drive system I figured it made sense). Not only does D-He3 fusion produce a lot less neutrons (there's still a little bit of it, thanks to some unavoidable D-D fusion happening in side reactions), but the charged reaction products are more energetic as well, which means higher specific impulse, and therefore greater fuel efficiency overall. EDIT 2: Having now fully read Jade's reply, I agree that Kerbals should eventually get old and pass on (if they don't want to put the concept of death in the game, they could just say that they retired from spaceflight to go teach the next generation).
  23. Most of the time video games are basically required to use UDP to send data, simply because the video game has it's own ideas about what the data protocols should be. If there was a video game specific protocol out there, they would probably use that instead, but there's not. Setting a standard for video game communication would probably not help things in any case, as it's not like video game developers are looking to make their video games interact with each other (eg being able to start up Minecraft and log into a Roblox server), instead each game's networking protocols are intended for that game only. Even being able to connect to the same game on another platform is not commonly seen (this is known as cross-play when it happens, and it's not common at all because the console makers don't care if your game does well on the competition's console or PC or what have you, only on their own platform that they're making money off of). EDIT: In any case, what specific behind-the-scenes networking stuff they use doesn't matter that much to how enjoyable the multiplayer experience is, assuming it works and that the ping time between the players is both low and stable. To be honest, what you've said about the alternatives does sound like a good idea for many factory games, because of the need to keep everything synchronized. Otherwise it seems to me like you'd need to label your packets with what order they were sent in, or things would either catastrophically de-synchronize (in games where the order things happen in matters a great deal, like turn based games and factory games), or you'd get things like player avatars teleporting around erratically (in games that are less sensitive to order of operations, such as an FPS).
  24. You don't "NEED" antimatter to make a torch-ship drive, per se. The nuclear salt water rocket is VERY MUCH a torch drive, at least when you do the math using weapons-grade enriched uranium (typically enriched to 90% or greater). Pulse-fusion ICF drives (like Dadelus but using a magnetic nozzle and much faster pulse repetition rate) can also be Torch drives, it's just a matter of increasing the mass flow rate and power output to a high enough level. Something that can help with increasing that mass flow rate is operating these pulse type drives in "afterburning" mode (injecting extra hydrogen into the exhaust to "shift gears" by trading away some fraction of the total ISP of the drive to gain a lot more thrust output, the energy provided to the propellants remains the same because the rate of consumption of fusion fuel remains the same). With this, it's theoretically possible to build a drive that can accelerate a quite large ship at very close to 1 G for months on end or longer. And if that's not a torch drive, I don't know what is. Pretty much all drives "can" shift gears in this way. Oddly, even chemical engines can "shift gears" like this, at least to some extent. For a somewhat odd example the RS-25 SSME runs notably fuel-rich. I'll start off with why it's an odd example. Running fuel rich with hydrolox propellants means that the engine is actually able to "up-shift", trading thrust for ISP. That's unusual because most times when an engine is capable of "gear shifting" like this, it will be an extremely high ISP drive and you dump "something extra" into the exhaust to LOWER ISP and INCREASE thrust, but the exact opposite is happening with the RS-25 SSME. In any case, running fuel rich with hydrolox increases specific impulse because given a constant temperature and pressure in the combustion chamber, if the exhaust products are of a lighter molecular weight they will have a higher linear velocity out the exhaust nozzle, which is exactly the same thing as saying "higher average exhaust velocity" and that translates directly to an increase in ISP since ISP is directly correlated to exhaust velocity (no matter what system of units you're using). Even a lowly nuclear thermal rocket running on pure hydrogen propellant can "gear-shift" to the point that it becomes an engine with a high enough TWR to be able to launch directly to orbit, switching at altitude to hydrogen-only use. What does it inject into the exhaust to get all this extra thrust? Oxygen! Now it's true, that basically turns the NTR into a "hydrolox rocket with extra steps" in the lox-augmented mode, but that's fine, the performance advantages of the "NTR only" mode outweigh the disadvantages of the more complex plumbing that happen because of the LANTR mode addition. So too can electric propulsion systems like ion engines, hall effect thrusters, and others shift gears. Most of the time they do this by switching propellants, because any kind of electric propulsion system should in theory be able to use any noble gas as a propellant. Xenon is chosen because of its low ionization energy and high atomic mass, meaning it actually is the "lowest gear" for an electric thruster. SpaceX with their Starlink satellites quickly figured out that if they were to use Xenon they would consume more than the world's yearly production of the stuff, and so for logistical reasons they chose the next best candidate noble gas, Krypton. Krypton is still a very "heavy" gas as far as the noble gases go, but the electric thrusters on Starlink satellites did take a hit to the thrust output. This is part of the reason that SpaceX lost a batch of Starlink satellites a few months ago, the increased solar activity at this time of the roughly 12-year solar cycle made the earth's atmosphere extend to a higher altitude than normal, which increased atmospheric drag to the point that the electric propulsion systems couldn't even orient the sattelites correctly so that their solar panels faced the sun enough to generate enough power for the electric thrusters to raise the orbit, so they all reentered within a few days (with maybe one or two survivors out of around 60 satellites). Even the highest power electric thrusters we have, running on Xenon (so highest thrust possible) generate less thrust force than the gravitational force of a single sheet of letter/A4 paper resting on your hand. Electric thrusters literally only work because there's no real "opposing" drag force in space.
  25. "Same goes for any other exotic ground-to-orbit solutions" Well not quite. Some of them shouldn't have "just an orbital VAB that takes time instead of resources to build vessels at", which seems like the closest thing to what you're proposing. Most of them in fact should be visible from extremely long distances, or put some sort of visible mark on the surface of Kerbin where they're set up. Like the Lofstrom loop should have a "line hanging in the air" with a really weird looking support system since it's under tension not compression. Like the Space Elevator (on a small planet) should be an incredibly long line between the surface equator and some spot in orbit (the counterweight would actually have to be a little bit beyond geostationary orbit, in order to balance out the forces of gravity on the length of the tether and the centripital force of the counterweight being forced to rotate at geostationary speed when the circular orbit velocity at its altitude is in fact slower(resulting in a net outward force calculated to balance the mass of the tether hanging down in the gravity well)). And like a linear accelerator long enough to launch crew without lethal G-loads should perhaps show up as a long track on the surface of the celestial body it's installed at. It's hard to even know they're there if they don't show up as visible from low orbit because you "abstracted" their functionality away. Now at no point did I say you should be able to build any of these from parts. Oh no, I know the can of worms that opens, and I'm intentionally avoiding it. Instead, these should be monolithic creations more akin to the buildings at the KSC in KSP 1, in that "they exist, and they have physical collision layers on them so things don't just go straight thru, but they're not part of the physics simulation other than that because they're a static object", if that makes any sense. So, visible from space, and able to be physically interacted with, and perhaps, with great effort (gonna take a gigantic rocket to outright destroy it, unlike the KSP 1 VAB, etc.), destroyed by accident or on purpose, but purposefully NOT simulated as it's own "vessel-like" creation that has joint stresses and things of that like to worry about.
  • Create New...