Jump to content

SciMan

Members
  • Posts

    843
  • Joined

  • Last visited

Everything posted by SciMan

  1. @t_v Well to be honest, your argument about Windows being disqualified as an operating system to support doesn't quite hit its target, and I do think that Linux should be supported. The reason your argument misses the point is that I wasn't comparing versus the average example of a Windows/Linux PC, a console, or a Mac PC/Laptop. I can't do that, it would be apples and oranges. What I was getting at is this: With consoles, the hardware configuration is firmly established to be "exactly this configuration", and therefore by the very nature of doing that you can do quite a lot of code optimization because the hardware that is running the OS (and the games) is always the same. For a very CPU-demanding game like Kerbal Space Program (because of all the physics calculations and the tendency to have vessels have high part counts), a console's hardware (even tho it's the same architecture as some Windows/Linux PC's) is likely not quite up to the task, or will have significant limitations that must be kept in mind. I'm not saying that a console could not be made that WOULD be sufficiently powerful to run KSP on it at a similar level to many people that play it on PC, but I AM saying that the current consoles on the market are not good enough for it. Well, PS4/XBONE for sure aren't good enough, PS5/XBSX might be good enough to handle it with some settings related to the physics tweaked. Plus, because of the "gated community" approach to the software running on these consoles, mod support is almost impossible, and since mod support is one of the crucial pillars supporting Kerbal Space Program, that's another reason to not support initially releasing KSP 2 on consoles at all. These two reasons are why I don't think consoles are worth supporting. The version of KSP that we got for consoles is pretty bad compared to the PC/Linux version, you can't do much at all in it because the computing hardware in those consoles simply can't keep up. With Mac laptops and PC's, the situation is mostly the same as a console, except you have maybe a few hardware options you can select from when ordering it. However, unlike a Windows/Linux PC, and unlike ALL Laptops, field upgrading a Mac laptop or PC is largely impossible, or at least you MUST use parts ONLY from Apple, else the thing won't work or will have tons of bugs. And even if you DO want to upgrade it, and have the money to pay for it (which will cost more than you'd have to pay to do a similar upgrade on a Windows/Linux PC), the upgrades that are available for a Mac PC or Laptop aren't for the parts that are crucial to game performance (GPU and CPU), instead they're things like adding more of the same speed of RAM (which only matters if you don't have enough), or things like switching to an SSD (or larger/faster SSD if it already has one). Since games don't really care about those things beyond meeting the minimum requirements, these upgrades don't make much of any difference to performance in games (OK switching from an HDD to an SSD will likely significantly speed up loading times, but that's not a real performance increase that would allow you to build vessels with higher part count while maintaining a similar framerate). Unlike consoles, with Mac PC's and laptops you could probably get KSP running on a Mac to support mods, but again that depends on how locked down Apple wants the operating system to be (which could change with the new M1 chips coming out). The hardware constraints are why I think that KSP 2 should not release on Mac operating systems, at least not to start off with. Maybe later, but right now I'm trying to advocate for decisions that will lead to the minimum amount of "distractions" to finishing the core KSP 2 game itself, and supporting additional platforms on launch day is something that I would indeed consider to potentially be a distraction unless the market for it is large indeed (and I mean like fully 1/8 or more of total KSP 1 sales were from that platform, which I'm almost certain excludes Mac, and maybe even Linux). The reason that Linux and Windows are operating systems for which I DO fully support launch-day compatibility is quite simple. You're not "locked to one or a few hardware configurations" like you are with consoles or Mac PC's (and all laptops regardless of operating system). Therefore, you're not constrained by what the manufacturers of your computer considered to be "affordable by most people" which they do so they can sell a lot of them. You're free to spend as much money on your computer as you want, which lets you do something with a Linux/Windows desktop PC that you can't do with any other type of computer. You can BUY performance, without having to change the operating system radically to support it. Will most people that own a PC buy the performance needed to run KSP? Probably not, because like you said, most PC's out there have barely enough performance to run even a web browser competently. However, the stat that I'm interested isn't the "Average PC", instead it's the "Average 'high performance' PC". That's a whole different thing. Most "High performance PC's" built in the last 2-3 years should be more than able to run KSP 2 sufficiently. At least, that's what I expect the hardware requirements to reflect. With all consoles, you're stuck to a given level of hardware performance. You get what you get, you can't improve it or else it's no longer that console. With Mac's, it's similar. You're stuck to a given level of CPU/GPU performance. You get what you get, because the parts are electronically keyed to each other so that only a very specific part or small range of parts is compatible (which is done by Apple so that they can be the sole supplier of compatible parts, and therefore charge you an exorbitant rate for upgrades). With Windows and Linux, the only limiting factors are your personal financial situation, and the global availability of parts. Those two factors can also be leveraged against each other to make up for shortcomings in either one. If you're on a tight budget, you can choose a less capable but more available part. If you need as much performance as possible, you can spend more for better parts, even if those parts aren't as common. The thing to keep in mind is that Windows and Linux are FLEXIBLE in the hardware that they support. This gives people who want to play KSP 2 on those operating systems a wide leeway in deciding how well they want the game to run or look. EDIT: Oh and that "wide range of hardware support" is also why the drivers in Windows behave oddly from time to time. There's simply too many different potential hardware configurations, it results in a nearly infinite amount of edge cases where things work "almost the way they should, but not quite", so there's simply not enough time in the day for Microsoft to make exceptions for all of them, so some of them fall thru the cracks. If they did manage that gargantuan task, it would take them 20 years or more to make a new version of the operating system, and you'd have at least minor updates every week if not more frequently. You should be grateful that Microsoft allows third party hardware manufacturers to author drivers, at least that reduces the workload to a point where it can start to be tackled, but even then some things will still fall thru the cracks. END EDIT You just can't do that with consoles, or Mac PC's and laptops. And that's why I don't think they're worth supporting (at least at launch).
  2. This is the approach I'm taking with it, sort of. I've basically stopped playing KSP. Not because I don't like it tho. Quite the opposite. I did this so that when KSP 2 DOES release (and trust me, it's not like fusion power where for the past 50 years it's been "just 10 years away"), I'll be quite happy with my new game that hopefully gives me enough different things to do on planets that I don't get bored of a planet after landing in 8 biomes like often happens with KSP. Despite having thousands of hours in KSP, I have plenty of OTHER games I'm more than happy to be playing, so keeping myself occupied until KSP 2 comes out (while reminding myself that it's still coming by posting on the KSP 2 discussion subforum) seems to be the right play in my mind. That being said, I wouldn't at all mind it going into some form of "early access" period where most of the features are in but maybe not all the planets or star systems or even rocket parts are in the game yet or something like that. They would have to have the colonization and a few of the high tech engines and the automated resupply mission piloting thing in the game to get me interested tho. EDIT: Also, at least with AAA studios, these days the term "Beta" doesn't mean what it means in software development any more. What it really means is "Limited availability time game demo, with us also maybe collecting some sort of telemetry about the game so we can maybe tweak some things or fix some bugs 6 months after release even if they're game-breaking bugs". What I mean is that even if literally everyone that plays that beta reports the exact same bug, with steps for reproducing that bug, then you can probably expect that the game on release day will still have that bug 19 times out of 20. And that's why I stopped pre-ordering AAA games.
  3. Yeah to be honest I'm already leaning away from the i9-9900k route. And I prefer K to KF processors because even if I never use the IGPU, it existing will allow me to keep the computer running (at least to browse the web if not to game on) should something happen to my graphics card. Even tho I have 2 spare GPU's waiting to be slotted in if this one fails. Even tho I sincerely doubt that this GPU will fail. EDIT: Those two backup GPUs aren't anything special these days. They're the pair of GTX 970's that my previous computer used. The GPU in my current PC as of right now is a RTX 3070 Ti because that's what was available when my turn came up to get a GPU. If I could have had my choice, I would have gone with a plain old 3070, or stepped up to a 3080 (or more likely a 3080 ti). I take my hardware redundancy and backups seriously. The data doesn't matter as much to me, I can re-download everything I need again, but if the computer's not working then I'm denied my main source of entertainment (I don't watch TV, instead I use streaming services on my computer, for instance).
  4. This is an argument against Mac support, as it is my belief that the Mac that most people can actually afford (around the $2,000 USD price point) is not well suited for playing KSP, let alone KSP 2 which will naturally have higher system requirements than the older game. However, if you took it as a rant against Mac, it's that too I guess. Good luck fixing the thing when it breaks. Oh wait, they don't want you to do that either, and in fact they do quite a lot to make sure you have a really hard time getting the schematics for it so you can actually have an idea of what parts you even need to fix it. Oh and you better know how to do really fine detail soldering, because unlike a regular desktop computer there's probably next to nothing that's actually socketed, instead everything's soldered, and did I mention it takes special equipment to solder many of the packages that those chips come in? Designed to be thrown away. I really don't like that.
  5. Landing with an Orion drive seems like a fantastically bad idea unless you build a very very specific kind of landing pad that's basically "the Orion drive's pusher plate but upside down and firmly embedded in the ground" Said kind of landing pad would also be the only feasible way to LAUNCH an Orion drive craft directly, and not have to use some form of auxiliary propulsion method to get the vessel to a high enough altitude where it won't either obliterate the launch complex (if launched from a surface colony or KSC itself), or just kick up so much surface debris that it damages the vessel (if launched from bare ground). The main reason that we see rockets launched from launch pads is because that's just the shape of the thing that can fuel and drain the rocket, and also not cause the rocket to suffer damage when being launched (Even just regular chemical rocket engines can be so loud that when the sound from them reflects off the ground and back up, those reflected sound waves can be strong enough to physically damage the rocket! This is one of many reasons why they have "water spray sound suppression" systems on most launch pads). Of course, as far as sourcing the stuff, there's actually two kinds of Orion drives, and they have different fuel requirements. The basic "Just make it work as simply as you can" type of Orion drive (and the least efficient) is the Pure Fission Orion drive. This uses pulse units that aren't much different from the Fat Man bomb, as they're probably "fission pit implosion" type devices. The drive itself is pretty much just mundane materials, after all the most prominent part of it is the hydropneumatic shock absorber system used to couple the pusher plate to the rest of the vessel, and that's well known technology (just on a very very large scale) and the handling mechanisms for the pulse units are basically similar to that of a 5 inch anti-aircraft gun (rapid fire projectile dispensing mechanism). The pulse units themselves are where the problems start. They would obviously require Uranium or Plutonium, some form of high explosives (probably doable if you can make decouplers and stack separators), and some electronics to handle safing and arming, fusing, and the timing of all the detonators to make the thing actually go off with a significant nuclear yield and not just make an expanding cloud of plutonium atoms and whatever is left over of the fusing and trigger explosives (probably doable if you can make probe cores). After all, we're talking about nuclear explosives here, while a dud wouldn't be a GOOD thing by any means, it's much preferable to the alternative of the pulse unit going off when you don't want it to go off. The more advanced "Make it actually useful for doing things" type of Orion Drive is the Thermonuclear Fusion Orion drive. The drive itself is mostly similar to the Pure Fission Orion drive, but as you might guess, this uses pulse units that get most of their energy from Fusion, the fuel for which is Lithium Deuteride, and the trigger for which is a fission nuclear device similar to the pulse unit for the Pure Fission type Orion drive. The interesting thing here is that you can in fact make a "directional" thermonuclear device, which means that you can make a Thermonuclear Orion drive pretty efficient since with a well engineered pulse unit you can direct roughly 80% of the energy of the pulse unit in a direction where it will impact the pusher plate. If you want to look it up, this is called a "Casaba Howitzer" for some reason, but I'm pretty sure most of the "here's the math we did" kind of results for it are still highly classified, since we are talking about nuclear explosives after all. The drive itself would therefore have similar construction requirements to the Pure Fission Orion drive, but the pulse units are again where it gets interesting. For the sake of simplicity, we may as well say that all fusion fuel is the same. So it could be that the drive needs hydrogen isotopes, it could need Deuterium and He3, or it could need Lithium Deuteride, but the differences aren't really that large in the grand scheme of things because given enough research you could feasibly make any of the fusion drives use any of these combinations of fusion fuels. Granted, they already have the best fuel for the particular drive picked out, but the distinction isn't that relevant unless you're a nuclear physicist and not a rocket scientist. So the pulse units would need all the things that the Pure Fission Orion pulse units need, and then a large quantity of the "Fusion Fuel" resource, whatever they decide to call it. It is my belief that Orion drives of all types are not suitable for interstellar travel. They have a lot of thrust, but for a drive using nuclear physics to create thrust the specific impulse is not that great, especially if you use the Pure Fission Orion drive. Of course, that doesn't mean they're useless, in fact they're great (nearly ideal, the only downside is the difficulty of sourcing the pulse units) for interplanetary travel. Oh and one thing I forgot to mention, Orion drives actually work BETTER inside an atmosphere, because that means they have more reaction mass available to heat up and project at the pusher plate (the atmosphere itself that is between the pusher plate and the pulse unit will contribute to thrust, so in a way Orion drives are one of the few kinds of drives that have increasing ISP as atmospheric density increases). For interstellar travel, you need to step up to at least a Pure Fusion pulse drive, such as the Daedalus drive that we see in the very 1st KSP 2 trailer that was released. Even then, you have to be specific about which kind of pure fusion drive you are talking about. A magnetic confinement fusion drive that injects plain old Hydrogen into the exhaust to boost thrust won't work, the specific impulse is not high enough. Again, great for interplanetary travel tho, and a good bit easier to get the fuel for it than for an Orion drive (but the Orion drive can move more payload at a time because it has much higher thrust). Chemical propellants are really all about the CHON group of chemicals. Carbon, Hydrogen, Oxygen, Nitrogen. Same stuff that life as we know it is mostly made of. Hypergolics and Monopropellant need a source of some Nitrogen containing ice, liquid, gas, or mineral (because Hydrazine is H4N2, UDMH is C2H8N2, and the oxidizer for both of them is N2O4, so really there's quite a lot of nitrogen involved unless you're saying Monopropellant is in fact hydrogen peroxide in which case all you would need is Water ice). Hydrolox just needs Water ice (melt and electrolyze water to get H2 and O2 and then liquefy those gases to get LOX and LH2). Methalox needs CO2 and Water (or some other source of Hydrogen, but Water makes the Sabatier reaction's equations and the equations of methalox rocket fuel balance out nicely). Kerolox needs, well, pretty much it needs a planet that has crude oil and therefore likely abundant carbon-based plant life on it for millions of years. Alternatively with much more energy input you could create a synthetic longer-chain hydrocarbon from Methane feed-stock that acts like Kerosene/RP-1 as far as a rocket engine is concerned but is likely not quite the same when chemically analyzed. So the way I see it, if you want an ISRU converter, you're going to have to source it from either Dres (lots of easily accessible Platinum-group metals needed for catalysts and that sort of thing) or Kerbin. If you need a whole lot of metals for general building purposes, you're going to need to go to Moho (Mercury-like planet so small but highly metal-rich near the surface), or again maybe Dres or Ike or even Gilly. Since they now said Minmus is glassy, if you want ceramics you're gonna want to go to Minmus. Fusion fuels, you go to either a gas giant or a planet with a water ocean (IRL it's projected that there's enough deuterium in Earth's oceans to provide our energy needs for a couple thousand years (even factoring in growth in energy needs as time advances), but there's millions of times more in Jupiter's atmosphere, and Jupiter has Helium-3 and probably a little bit of Tritium as well). As far as Uranium and Plutonium and things like that, the Mun would be a good place to look, if you can't find enough on Kerbin. But really, that stuff should be around on any rocky planet.
  6. Boy I'm glad I left my i7-9700k at stock clocks and water cooling (custom loop not AIO), and that I have a beefy power supply, because that means I have plenty of overhead to be able to overclock should I have the need to do so to get adequate performance out of my now seemingly relatively old CPU. And even if that fails, I can still upgrade just the CPU to an i9-9900k without having to change the motherboard. But if it does come down to changing the motherboard, I'll probably go with Intel's 13th or better generation CPU, and windows 11, because by then hopefully all the bugs with both of those things will have been worked out (but I'm suspicious of Windows 11 because of the "every other version of Windows is crap" paradigm that they seem to have stuck to ever since windows Vista).
  7. My case against Mac is that for the price of a "capable" Mac laptop, you could have a MORE capable desktop PC. And Apple themself want you to entirely forget about any attempt of making their operating systems run on hardware you didn't buy from them. So, my question is, when buying a Mac, I'm paying a premium. What in the product is that premium being used for? Clearly it's not the performance of the product. And I'm not much interested in looks beyond what that means for the functionality. Thin power cords aren't stylish, they're failure-prone.
  8. Pointless how? They made concessions to realism in that Minmus is now glassy, why wouldn't they do the same with respect to things like the very much more important actual propellants they're telling you the engines use? I mean, I suppose "A rose by any other name", but at the same time these words have very specific meanings, and I thought I was suggesting a title that better fit what the propellant was actually being used for. IRL you don't often see a monopropellant thruster capable of a full 1000 Newtons of thrust, yet that's exactly what you get with most of the RCS thrusters in KSP. For reference, the hypergolic bipropellant Draco thrusters on Dragon 2 are only capable of 400 newtons each. That's a little less than half the thrust of a typical KSP RCS thruster. And yet it's plenty enough to give the Dragon 2 capsule full control in space. The SuperDraco thrusters (at 71 kN each, or 142 kN for a pair, with the Dragon 2 capsule having 4 pairs) are ONLY used during an Abort situation, and they too are still Hypergolic Bipropellant thrusters. I mean surely you must have more to say about it than just "pointless"? You gotta explain what you mean at the very least. And even if I think your explanation for why it's pointless is valid, I still think that there should be another type of fuel called "Hypergolics". Or maybe we just do it differently, say we say some engines use "Monopropellant plus Oxidizer" as a valid fuel combination, to represent hypergolic fuel combinations? My point is that just "monopropellant" doesn't explain the whole thing well enough. At best, it's the "Lies to children" version of the truth.
  9. Well like I said, those mods that include better aquatic propulsion options generally are of the form of "really high thrust and absurdly high specific impulse jet engines", which doesn't really address the problem. The problem is that the drag is way too dang high, not that the thrust is way too dang low. Adding these extremely high performance propulsion methods just makes it all the easier to make your ship (unrealistically) bend in half or have a Kraken attack from the thrust forces being so high. I've been putting my Goliath engines under the water line, because that's where the propellers on a boat (and therefore the center of thrust) goes on most boats. Even the idea of making a "planing" boat like a hydrofoil or speedboat doesn't work, because that just results in your boat flipping over nose-down into the water upside down. What I'm trying to say is that I want boats in KSP to act like Boats, not like "boat shaped objects".
  10. Been playing KSP on and off since 0.13.3 (they had just added Minmus, meaning that all there was was the Sun, Kerbin, Mun, and Minmus), and I can tell you this much about the robotics parts: They have always needed a better way to control them. KAL controllers aren't quite enough. What I meant when I said the robotics parts are too "fiddly" is that I don't want to have to spend an hour fiddling with every little slider of every single joint just to make it go where I wanted it to go without it wobbling all over the place (even just under Minmus gravity!) or causing a Kraken attack. It needs to be streamlined and simplified at least a little bit, because at the end of the day this is a video game not a training simulator for real NASA astronauts, and IMO the point of KSP is to "Mostly have fun but maybe accidentally learn something along the way". What I'm trying to say is that there's a bit of magic missing. That magic is called Inverse Kinematics. You see, I'm not talking about having problems with one robotics joint. I can handle that easily. What I have problems with is when I have say a combination of 5-10 joints and pistons on one thing that I'm calling a "remote manipulator arm" or "crane" and I can get the thing within say a foot of where it needs to be with just one minute's work, but to get it to actually do anything that's not good enough, you need much higher precision for things like making docking ports connect without using the magnets in the docking ports, and you can't use the magnets in the docking ports because if you do well the servos are holding the docking ports apart but the magnets are trying to force them together and the physics engine decides that that means you basically just made a Kraken drive so your whole base starts moving or flipping or just shakes itself so hard that it breaks itself against the ground. Does anyone really think that's fun? I sure don't. It might be a "unique" challenge, but that doesn't mean it's any fun to play the game like that. My point is that I'm not happy just "existing playing KSP", I want to be accomplishing things when I'm playing. And when I have to fiddle with a dang robotic arm for an hour just to get it to connect two pieces together on a base on the surface of a planet or moon, I don't feel like I accomplished anything, I feel like I was getting nothing done for an hour and it's all the game's fault. I know how to do these things IRL, so not being able to do them in a much simplified video game is intensely frustrating. At the very least, we should have a few more analog control axes that we can configure on a joystick and dedicate to JUST robotics parts. Then things like realistic construction equipment would be possible, and I'd be able to set them up so I can control them with a couple of joysticks like you do when you're in the cab of said construction equipment, instead of having to spend an hour messing about with sliders on robotics parts. It's absolutely infuriating, and that's why I avoid it at all costs. Plus, the game doesn't even properly save the state of those robotics parts when you quicksave, so if you switch to the tracking station and time warp some, and then come back to that vessel again, who knows what position those robotics parts are going to be in!?!? Again, this is infuriating, and needs to be addressed before I'll ever touch robotics parts.
  11. Was anyone else expecting this mod to also help with it being basically impossible to make large boats move thru the water at anything approaching a realistic speed? Even with 4 Goliath turbine engines at max throttle, moving even a small boat thru the water (without this mod installed) seems to have a maximum speed of say 5-7 meters per second. That seems totally out of line with the amount of thrust I am applying to the vessel, by that logic to move a small boat (like a pleasure craft for instance) at high speeds across the water I'd need not merely "a few hundred horsepower" as it is in real life but instead "several ten-thousand horsepower". I mean, it seems that having a name like "Rational Hydrodynamics" would imply some form of addressing of the issue of HORIZONTAL hydrodynamic drag being totally unrealistic in KSP, right? Am I missing something or is this not addressed by this mod? If it is, I'll probably consider installing it.
  12. @field_of_gazorpa I've been tinkering with configs to make my own parts (that I don't publish) for a very long time now. I think I started when KSP was at version 0.15 or something, so back before it was even on Steam. You shouldn't really need a new model or textures or anything of that sort for something so simple as "I want this or that part, but bigger or smaller". There's a line in the config file specifically for doing this, actually ( "RescaleFactor = [some number]" without quotes, where for Nertea's parts the number is just "1"). Since I don't know which curved solar panel you based your part config on, I'll give you numbers for re-scaling both the 2.5m and 3.75m curved solar panels to fit a 5m diameter cylinder. If you based your new 5m curved solar panel part's config on the 2.5m diameter curved solar panel's config, you should leave the model and texture definition stuff alone, and simply set "RescaleFactor" equal to 2 to get the part to be the size you want it. That's it, the part should show up the right size in-game. Of course, you'll need to adjust the other stats of the part to suit its new larger size, but you said you already took care of that. If you instead based your new solar panel's config on the 3.75m diameter curved solar panel, you should set "RescaleFactor" equal to 1.33333333 because 3.75m times 1.33333333 is 5 (or close enough to not worry about it). When setting RescaleFactor, the important thing to figure out is how much bigger (or smaller!) the new part is compared to the original model. If the original part's "RescaleFactor" is not set to exactly 1, you will need to do a bit of proportional algebra to figure out what to set the new part's RescaleFactor to. However, if you have a calculator this should not be a problem.
  13. So long as you get updated versions of all the dependencies, the B9 parts are just that, parts. With some exceptions, "simple rocket parts" like those found in all the B9 parts packs are not really broken very often by KSP getting updated. It's always the plugins that need to get updated. And fortunately, I'm almost certain that all the plugins that the various B9 parts use are in fact updated to work with 1.12.x, meaning that they should all work just fine right now! Assuming you are playing the latest version of KSP (1.12 at this time), all you need to do to use these parts is make sure (double sure) that you download and install the most up-to-date version of all the plugins mentioned in the first post, and then download whichever portions of the B9 parts packs that you want to use (could be just B9, could be also B9 legacy, could be just the HX parts, IDK for sure but I think any combination of those is valid).
  14. IMO KSP 1 "monopropellant" covers many engines where you'd be far more likely to be using Hypergolics, such as that "Puff" engine. High thrust monopropellant engines are simply not practical IRL because the larger the monopropellant thruster is, the harder it is to ensure both that all the propellant is decomposed by the catalyst bed AND simultaneously that the catalyst bed which decomposes the propellant does not itself melt under sustained operation due to the catalyst itself having to exist in what is essentially a rocket engine combustion chamber. This means that to me, even the O-10 "Puff" monopropellant engine at a whopping 20 kilonewtons is testing the limits of plausibility. IMO 5 kN is much more reasonable and likely to be achievable in the real world. EDIT: Put another way, assuming you don't think KSP 1 "Monopropellant" also covers hypergolic fuel mixtures, the O-10 Puff engine has too much thrust for a monopropellant engine, but if the same engine had only 5 kN of thrust (and 1/4 the mass to keep the TWR the same), it would be much more reasonable, because what happens when a spacecraft needs a lot of thrust out of just monopropellant in real life is that you see clusters of smaller thrusters being used, instead of one large one. However, if you assume it DOES cover hypergolic propellant mixtures, the O-10 Puff is right in the sweet-spot of small-to-medium scale hypergolic rocket engines such as used as the apogee kick motor of geostationary satellites and small upper stages of rockets such as Fregat and Briz-M. (edit ends) Naturally, these limits of Monopropellant technology limit both maximum thrust and maximum specific impulse to relatively low levels, whereas Hypergolic thrusters of similar thrust levels have no such issues, start reliably many many times just like Monopropellant engines if they don't have turbomachinery (some are capable of thousands of ignitions or more between needing to be inspected, let alone serviced or replaced), and offer growth options towards generally higher specific impulse and thrust (for example, the main engines of both the US Titan II "ICBM-turned-satellite launcher" and the Soviet/Russian UR-500 Proton "we built a mega ICBM but now we don't need it so we'll use it to launch big things into space" both use hypergolic fuels in their first and 2nd stages, which are both quite high thrust and far outside the realm of anything Monopropellant can do feasibly) I mean the only way I can think of to make a Monopropellant rocket engine that scales well to high thrust levels is to switch away from using solid catalyst beds and instead use liquid solutions of catalytic agents, at which point you've essentially made a hypergolic rocket engine with extra steps and worse performance because part of your propellants (the catalyst solution) doesn't provide any energy to the reaction. I mean there might be a way to arrange things so that the reaction is energetic enough that it self-sustains, in which case you would be able to drastically reduce the amount of catalytic solution you carry on the rocket, but at that point you're still leaving performance on the table compared to what you're almost doing, which is "RP-1+ LOX with TEA-TEB igniter fluid used to start it". In other words, if you're going to use a liquid propellant rocket, other than very very specific situations there's very little reason to not use some form of 2-component fuel combination. Not even RCS thrusters are immune to this. The Space Shuttle and the SpaceX Dragon capsule both use/used bipropellant hypergolic attitude control thrusters. Yes, the Shuttle's RCS was in fact hypergolic, not monopropellant. The reason is that the Shuttle Orbiter is BIG and quite MASSIVE, and because of that it needs the extra performance margin that hypergolic attitude control thrusters (and OMS engines) have over monopropellant ones. As a secondary matter, because they needed the OMS engines, they were already forced to have both components of hypergolic propellants on board, so the matter of making everything use the same propellants (instead of the RCS only using Hydrazine but the OMS using Hydrazine + N2O4) simplified the plumbing on that already massively complicated vehicle. With Dragon (and therefore Dragon 2 as well), the reasoning was basically down to the secondary concern on the Shuttle (it makes the plumbing simpler). They already had the SuperDraco thrusters using hypergolic fuels, so the question of what to use for the RCS was simple to answer because if the attitude control thrusters can use the same fuel combination that the SuperDraco ascent abort system thrusters use, then you don't have to carry around two sets of fuel tanks to make both work, instead you can simply make one (slightly larger) set of fuel tanks that will cover the needs of both systems in the worst-case scenario, plus a safety margin. Doesn't hurt that originally they also planned to use the SuperDraco thrusters to propulsively land the Dragon capsule if they didn't need to use them during an abort (which would help speed up turn-around time because they wouldn't have to re-pack the parachutes, something that takes a long time when you have to record and review every step of it to make sure it was done right so that you are absolutely sure that they'll work right when they have to work). OK so long story short, I don't see Monoprop being particularly valuable except around low gravity worlds, as I don't expect them to be making any larger engines that run on the stuff and the specific impulse is just horrible anyways. Whenever possible, I try to use the Vernor RCS thrusters, because it reduces the number of different resources I have to carry around on the vessel. I wouldn't be against the idea of re-naming Monopropellant to a single "Hypergolics" resource, and additionally I hope that we see RCS thrusters that run on all of the new (and old) fuel mixtures that rely on a chemical (not nuclear) reaction to produce thrust. So that would be both "Methalox" and "Hydrolox" RCS thrusters. Additionally, I hope that we're not limited to only the "single nozzle" Vernor-style bi-propellant RCS thrusters, and instead have both single and configurable multi-nozzle RCS block variants available. Perhaps MH or Xenon+Electricity RCS too, but that would be more about simplifying the plumbing than it would be about the much higher specific impulse (and thrust in the case of MH) that either would provide. EDIT 2: To expand on what others have been saying, I don't think that Monopropellant would have the "simplest to construct" rocket engines. Instead, that title goes to (you guessed it) Hypergolic engines. Hypergolic engines have no "special materials" required in their construction, however Monopropellant engines ALWAYS need a small amount of rare materials (usually platinum-group metals) for the catalyst bed. Of course, if you happen to wrangle a large enough example of the right kind of asteroid, you'd likely be able to mine it for all the platinum-group metals you could ever possibly need. Of course, since Dres is also basically an overgrown asteroid, it should also be rich in such materials. So Monopropellant vessels may in fact be common, but around Dres and asteroid bases, not so much around Minmus.
  15. To be honest, the only thing that beats the Orion drive for lack of subtlety in rocket propulsion is the Nuclear Salt Water Rocket. The fuel is simply a solution of something like Uranium Bromide in regular old Water. Of course, it's not just ordinary Uranium, it's enriched uranium, which is where the energy comes from. The water is just the reaction mass, I suppose you could use Ammonium or something else other than water assuming it has good nuclear properties (doesn't slow down Fast neutrons that much). It's like an Orion drive, but there are no "pulses". There's just one CONTINUOUS NUCLEAR DETONATION, and the rocket surfs the blast wave. It's like a series of firecrackers under a tin can (orion drive) versus an actual rocket motor (NSWR). Of course, we haven't yet figured out how to contain such an awesome level of power dissipation in a way that doesn't itself almost immediately vaporize from the fact that it's required to be mere inches from nuclear fire, but that hasn't stopped people from using them in science fiction. Nertea's "Far Future Technologies" mod has 2 examples of Nuclear Salt Water Rocket engines, one based on "low enriched" fuel, and one based on "high enriched" fuel (for simplification of game play and resources, they both run on the same fuel). The high-enriched one has a very high specific impulse, and a very high thrust, both at the same time. Somehow, I still find myself clustering multiple engines to get enough thrust to accelerate my interplanetary missions at several G's because I like fast transfers but I don't like having to wait an hour for a burn to finish (because I'm trying to minimize the amount of time I play the game "doing nothing" because I'm waiting for something to be finished, be that time-warping to the destination on a slow transfer or waiting for the burn to finish on a fast transfer). Trust me, even at several G's of acceleration, and spending more than 10km/s on both the ejection and injection burns for the transfers, those "High enriched" based NSWR engines have more than enough performance that I should be able to visit every planet in the stock Kerbal solar system without refueling a single time. But if that's not good enough, they ALSO include the infrastructure you need to make more fuel from just Ore (in multiple steps, first make Enriched Uranium from ore, then transfer that to the 2nd machine, that 2nd machine takes Ore and Enriched Uranium to make nuclear salt water rocket fuel).
  16. I agree for the most part, things like forklifts and cranes shouldn't need to be made of individual pistons and hinges, they should (like robotic arms for orbital work) be something where the player inputs are simplified down to something approachable by the layperson instead of having to spend 20 minutes just figuring out which angles to set what servos to in order to get the blasted thing into a configuration resembling something that lets you get work done, let alone actually get anything done with said contraption. That's why I personally haven't approached the robotics things. Too much set-up time. I guess I kinda want to skip the middle bit, in that I want to use the thing to set up my base, instead of spending 24 hours making the thing to set up my base. This is why I assemble my bases in orbit where I can use a small number of simple probes that have some RCS on them to get all the parts of the base assembled, and then use a large skycrane type thing to actually soft-land it on wherever I was going to put the base. The constraint is always getting the base modules into LKO, in a way that doesn't create all kinds of drag right at the front of the launching rocket, and you only have fairings so large so you must launch in multiple pieces. Nobody said you had to LAND it in multiple pieces, and robotics as it is in KSP 1 is so dang fiddly that I just get frustrated with it, so I land THE WHOLE BASE instead of doing it part-by-part, that way I can avoid using the robotics parts. Now this is probably too hard to code, but if I could build a robotic arm and the game would just "know" how to use it (make the end of it follow my mouse pointer for example), then I'd be much more likely to build cranes and the like to assemble my surface bases. That's why I think that cranes and forklifts and robotic arms should be "one part solutions" where the very most you have to do is figure out where to attach it to your vessel and what kind of thing you want to put on the end of the arm (be that a claw or a jr docking port). This would also make transferring fuel between surface vessels so much easier, because right now if you design a fuel tanker it will have a different ride height when full and when empty which makes docking it to a stationary surface base a real pain in the butt.
  17. I think procedural parts are a great idea, with some limitations. The primary limitation is that you shouldn't be able to enter a custom diameter, because that makes the logic that checks for a smooth aerodynamic transition between parts much more complex, and it could also make the player confused by "too many choices", a thing that already occasionally happens to me personally with all the mods I have installed. Because of this, I think it might be the case that we'll have LESS "parts" to choose from in the editor, but those fewer parts will cover more options, leading to an overall better experience. Semi-procedural cylindrical parts is a good thing, you'd select a diameter from a list, select a length from a list (or enter a custom one if it's within the range of lengths covered by the list), select what fuel combination, "Battery", or just "structural", there's your cylindrical part. If we have parts dedicated to being the "spine" of a gigantic ship assembled in orbit, those should be semi-procedural too, pick a diameter, pick a length (or enter one), but the difference between these and the regular cylindrical parts is that the limits on length would be something on the order of a full kilometer (having just one part that long is REALLY IMPORTANT when you're building a gigantic ship in orbit, as otherwise with so many joints in the stack you're bound to get a wobbly vessel unless the parts are literally non-physically attached to each other aka parented to each other instead of being connected via joints). Semi-procedural diameter adapters would be good too (select top diameter from list, select bottom diameter from list, select or type in a length (within a sane range), select fuel combination, battery, or structural, done. Fully procedural wings would be needed, and I'm pretty sure they're coming. SRBs should also be procedural, because right now we have way too many of them. There would be several preset configurations available that match up with the existing KSP1 SRBs, but if you wanted something "in-between" you could still choose from a list of diameters, enter a custom length, choose if it can gimbal or not, and finally choose if the engine bell is optimized for vacuum, sea level, or very high atmospheric pressures like Eve (or any similar Venus-like planets planets in KSP 2 that are in other solar systems). Engines might have to stay the way they are in KSP 1, however there should be an option for "clustering plates" where you stick a number of engines on it and it (for the sake of making the math easier) will turn both the plate and all the engines on it into something the game considers as "just one part" as far as both physics and the resource consumption logic are concerned. Also since we're going to be building gigantic vessels in orbit, it would be real nice if we had some feature like the old UbioZor Part Welding mod (such code could be used in part to implement the functionality of the clustering plates I mentioned above, but there might be more code needed to make it work besides that). Even if it only works on certain kinds of parts, that would be a massive improvement to the overall structural rigidity of the vessels we make in KSP 2. I don't care if it has to be an "advanced tweakables" option or something that's disabled by default, it's functionality I'm looking for.
  18. @eeemil This issue should also be fixed by installing SystemHeat along with all the MM patches (in SystemHeat's "extras" folder) that convert all of the things in the game that use the stock heat system (well, stock things and Nertea's things anyways) to use the SystemHeat system instead. I did that because I really hate the bugs in the stock heat system (sometimes your radiators get stuck at like 2000k for no good reason if in high time warp), and this fixes that quite nicely. Plus it gives you a bunch more radiator parts to use, which is always a good thing.
  19. What, launching this December, with the most recent delays being not the fault of JWST, but the Ariane 5 rocket contracted to launch it? Look, I get that JWST got delayed a lot, and that people like to use it as an example of bad program management because of that. Really I do. However, it's actually an example of excellent flexible program management, because instead of throwing up their hands and letting the program get canceled, they stuck with it and made the changes they needed to to keep making progress on it until it was (finally) ready to launch. However, comparing it to a game is like comparing apples and oranges for many reasons, not least of which that KSP 2 is being developed by a private enterprise that loves what they do, and that JWST was a wholly government-funded project and so expecting it to stick to its deadline is like expecting pigs to fly. On the other hand, considering the amount of budget over-run on JWST, some would say that pigs are in fact flying when JWST finally does launch (as many now consider it to be a pork project). Personally, I'm just glad that both JWST and KSP 2 are finally at a point in development where the point of culmination of all that effort is finally in sight. I'm a fan of space, and I think that more ways to get into space is always better, so long as the laws of physics say they can work. I'm also a fan of having a new game to play, and KSP 2 is one that I look forward to playing. I'm sure that it won't live up to some people's expectations, as there are always a few that expect the game to do things that just aren't practical to program given the time constraints, but I'm relatively certain it will live up to my own expectations, as I don't consider myself to be one of those people. Really, so long as KSP 2 doesn't require me to fly every logistics flight to its destination when I'm doing colonization things, I'll probably have a lot of fun playing it. And if the game doesn't live up to my expectations? Well, I guess I could start making mods for KSP 2 so that it becomes what I want it to be.
  20. Oh PC/Mac/Linux crossplay shouldn't be hard to do at all (but you'll be paying way too much for whatever Mac you play games on, like most things Apple). At least with PC and Linux the hardware's mostly the same. I'm not sure about what they're going to with the newest Macs tho, since those are (once again) going away from the X86 architecture (for who knows what reason, maybe to make it harder for people to "build their own Mac" probably, because apparently it's not in Apple's best interests to allow their customers the ability to choose to use anything non-Apple, and therefore intentionally make their stuff incompatible, despite their stuff likely not doing anything any better than a similar PC). Aside from my personal extreme dislike of Apple's business practices, I don't see any reason why crossplay wouldn't be possible, but like I said since they're moving away from the X86 architecture there would have to be a port of the whole Unity game engine over to handle that. So I guess I'm saying "PC/Linux crossplay highly likely, Mac maybe but that's not on the KSP developers to make it happen, and after that they might maybe who knows make Xbox also crossplay a little bit (or maybe even do like Fallout 4 did and make a miracle happen by allowing some kinds of mods on consoles too).
  21. Expanding off what @Axelord FTW said, since the line between gas giants and brown dwarfs is blurry, you could have a brown dwarf that's on the edge of being a gas giant (only being a brown dwarf by the core sustaining D-T fusion and not the triple-alpha process seen in all true stars) eventually find its way into the orbit of a white dwarf, where that white dwarf is undergoing periodic novas because of the siphoning of hydrogen off of the brown dwarf.
  22. Perhaps they can improve how they do the SoI checking, at least for vessels not under thrust orbiting around bodies where restricted-N-body is not being used? My first idea is that when you're orbiting a body that has no natural satellites (ie a moon, or something like Dres which is a planet that just doesn't have any moons) then you can just do SoI checking based solely on orbital eccentricity. If it's below 1.0 (maybe with a tiny fudge factor to handle potential integration errors), your orbital elements are gonna stay where they are forever, so you can cache that result until the player pays attention to that vessel in some way again. If the body you're orbiting DOES have natural satellites, all you need to do is cross reference the orbital elements of the vessel with the orbital elements of the natural satellites (plus or minus the SoI radius for those natural satellites), and then you can easily rule out any chance of the vessel ever encountering the SoI of those natural satellites, and (yet again) cache that result until the player interacts with that vessel in some way again (be that docking something else to it or just piloting). Seeing as (at least in my playing of KSP 1) the majority of vessels that I need to have in orbit are simple communication relay satellites that once I place where I want them I never pay attention to them again, it seems to me that this would simplify the math the game has to do by vastly reducing the number of sphere of influence checks the game needs to do (since it can pre-cache results for everything that's never going to be on an intercept trajectory). This would also allow for a lot more asteroids to be in the asteroid belt, since they have no gravity of their own and are counted by the game as a single-part "vessel", and often don't have a trajectory that intersects anything, while still allowing the player to go out and harvest them for resources and/or scientific results if they so desire.
  23. To be honest, Eve is a planet I've never really considered doing much of anything at as far as landing. If I did do something, it was just probes that had parachutes on them. This is because I have a personal limitation of never sending Kerbals anywhere without already having a plan to get them back, and making a spaceplane that can get out of Eve's atmosphere is just not an appealing prospect (I'd rather use a rocket, and with Eve being Eve, I'd need more than one stage anyways). Laythe on the other hand, I've landed on Laythe with a spaceplane before, and I've even made it back to Kerbin with that same spaceplane. However, that was before the aerodynamics overhaul (aka it was back when the "souposphere" was still a thing), so now I'm practically hopeless with spaceplanes in general. In general, I just have better luck with rockets anyways, because the type of spaceplane I like to build needs large radiators for its propulsion systems because of modded engines, and apparently according to KSP, radiators might as well be wings with the way they make such spaceplanes always flip out no matter what I do, tho now I do have B9 PWings installed so maybe I can avoid that. Additionally, now that we have the robotics parts, if I were to make a spaceplane for Eve usage, I'd be using the ducted fan parts to ensure that all I need is a steady supply of electricity to allow it to climb to an altitude sufficient to enable me to make efficient usage of the rocket engines I put on it, instead of having to spam Vectors and/or Mammoths (with their high mass) because those are the only engines that really work well at all down low in Eve's atmosphere.
  24. I have a feeling that a lot of this will be helped immensely by the fact that they're still largely using only patched conics for simulating orbits, and when it's not that, it's the "restricted N-body" problem where you fix the orbits of the planets and let the sole independent variables be linked to just the vessel itself. This (restricted N-body) is the method that Orbiter Space Flight Simulator used (Hail Probe!), and that was sophisticated enough to let you have many many vessels in orbit of any combination of the planets of the IRL solar system, and it had options to use the RK8 integration method, as well as accounting for non-spherical gravity sources and gravity-gradient torque (making orbital plane precession manifest itself naturally, as well as allowing passive gravity gradient stabilization of something like a space station). Really, it was quite amazing just how well it ran considering the complexity of the math it was doing regarding vessels traveling along their orbits. Time warp in Orbiter worked at up to 1 million or 10 million times faster than real time (been a long time since I played it), and back when I was playing it (around 2008) even on the computers of the time I was getting 600 FPS with absolutely no problem whatsoever, with the FPS only dropping slightly at the absolute highest time warp levels. Oh and there was no such thing as "on rails" or "physics" warp, you could fire your thrusters at any time (even during time warp) and even do things like adjusting what attitude you are in and what thrust level your engines are operating at, all while constantly changing the speed of time passing, and the game didn't so much as bat an eye at it. Really the only thing that would make the physics reliably mess up in Orbiter was flying too close to the sun, which would cause the physics to mess up because of floating point rollover and/or roll-under effects (apparently those variables weren't clamped to keep them at sane values, so you could "bounce" off the sun and get sent at like 500x the speed of light out of the solar system). Mind you, that was with a PC that had (I think) like a Core 2 Duo CPU in it, and Orbiter had NO facilities for optimization against multi-core CPUs. Graphics cards also weren't particularly capable either back then, yet like I said, it was managing 600FPS EASILY (I had VSync turned off). I guess what I'm trying to say is that if Intercept has problems implementing the physics and thrust-on-rails, they have a good example waiting for them in Orbiter. Heck back when I was playing it it even ran fantastically (maybe not 600fps which was apparently the fastest it could possibly run, but it wasn't bad at all) on a school laptop, which didn't even really have a dedicated GPU in it, and I think my current tablet has a better CPU and more RAM and a better GPU than those old 2005-6-7 era school laptops (Dell brand I think). What I'm trying to say is that these days it would run nicely on a potato computer, heck I don't doubt that it would have no issues running on a Surface Pro "tablet PC". Oh and I forgot to mention, since this is probably important. Orbiter was made by a college professor, and was released with as open source of a license as possible. It's so old that it even started out as a DX7 game (tho a DX9 rendering pipeline is available for it, which is what I always used). EDIT: On a totally unrelated note, I do hope that they'll have features available to allow "burn splitting" for things like Hohmann transfer ejection burns and when you want to save propellant doing a plane change by raising your Apoapsis at AN/DN first, basically instead of doing the whole burn right when you need to do it, you split it up into several burns so that only the last burn is the one that sets you on your interplanetary trajectory. This is a good thing because it lets you take more advantage of the Oberth effect, while still having a vessel with a somewhat low TWR (not as low as a craft with an ion engine, this would be best for things using vacuum-rated Hydrolox engines, or nuclear thermal rockets). The complex part of getting this to work is the math that works things out so that you still arrive at your orbital periapsis right when you had the maneuver scheduled originally (when you initially created the maneuver as a default "single-impulse" maneuver). I know there is at least one mod for KSP 1 that helps with this, and I did have that installed at one point, but I never really got around to using it so I'm not sure just how well that actually ended up working out. But the presence of that mod means that someone's already worked out the big problems of how to implement this before, so it shouldn't be too hard for Intercept to do that either.
  25. @Master39 My apologies, it seems I was in fact tagging the wrong person. Your objections to KSP as an "mmo-style" game are entirely valid. @PlutoISaPlanet 's idea that you could have KSP be an MMO-style game doesn't seem to make much sense to me, as it would be incredibly technically challenging to make the game run well enough given that literally every vessel needs its physics to be simulated instead of in most "play some form of humanoid character" MMOs where the most physics that needs to be considered is simple ground movement and maybe jumping and flying that's not at all based on physics so the calculation load per player is just TINY. Consider that the server would have to be calculating the physics of every single vessel that players are paying attention to in the universe, every frame, except when they're in time-warp, and the size of the problem should dawn on you, because boy oh boy is it a big problem. Standard systems, even something with a Threadripper in it that could dedicate one of its many cores to each vessel, simply wouldn't be enough processing power to handle all that. And then you go and add the load of all the other things that the vessels are doing, like tracking resource usage and therefore adjusting the mass of the vessel every frame (which impacts the physics again), as well as things like getting in range of another vessel where the physics needs to be EVEN MORE ACCURATE in order to handle close-proximity operations like docking (or just figuring out if the two or more vessels collided with each other at a velocity high enough to cause damage or not, and what that does to the structure of the vessels if something is damaged). Maybe we'd have enough processing power to do this once we have highly efficient quantum computers or after we figure out how to make processors that don't use silicon as their semiconductor (perhaps germanium or something, the advantage to be had is higher frequencies of operation with a manageable heat load).
×
×
  • Create New...