Jump to content

Haustvindr

Members
  • Posts

    61
  • Joined

  • Last visited

Reputation

77 Excellent

Recent Profile Visitors

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

  1. My 2 cents: I think the problem with radiation is something else. Sure, we can put radiation shields, we can even launch lead habitats with a bit of effort and whatnot. The issue about "protecting" our kerbals from radiation is the easy one. But... what should happen when we don't? Since the game aims to be non-punitive, there's no way a system that can wipe your entire crew is going to feel right. Sure, we could turn them in space tourists instead of killing them, but then how will you be able to fix it in-flight? Reducing their efficiency seems like a no-go as well, for all we know there's no concept of efficiency even. And if we aim for even a little bit or realism, it's not like it could be solved by something like transferring the crew to a protected module either. And it's not all about the design phase either. You could have an accident and lose your radiation shields, or be exposed to the radiation generated from another vessel. There's even the possibility of your colonies being exposed to radiation coming from rockets. Radiation is not something that can be 100% solved in design, and therefore there's an actual need to make kerbals react to radiation. My guess it's that's a little more complex than people think, and the complex part is in the "what should happen to kerbals" and not in the "how will our kerbals be protected". If a compromise can be found, I expect it to come sooner or later, but to be fair I can not find a balanced compromise for this one. Or course, if a mod turn the game in a punitive one, there's no reason to not kill kerbals with radiation.
  2. I think the bug I reported and your "Changed between two undocked vehicles causes one to fall apart" may be related to each other, or maybe even the same. In your scenario, and if I'm not mistaken, one of your vessels would have a docking port as root upon separation. I tested the jr. (will try more of them on the weekend when I have more free time), but if does the same on any docking port... And now that you mention the phantom forces related to orbital decay, it may be very well all related since the craft would load with displaced and/or unattached parts if this bug is universal.
  3. I can confirm that the parts tree gets messed even if the reroot occurs later. Say, you attach the vessel to a launcher as-is, get to orbit and then separate. Upon separation nothing seems wrong even if now the new root is the docking port, but if you save and reload at that point some parts become displaced or disconnected. I'll try to get some time in the weekend to test with different root parts, maybe it is related to a part family instead of a unique one (e.g. all docking ports instead of just the jr. one).
  4. The game tells me around 6200m/s, but dV gets a little wonky with the external tanks so I'm not really sure, it may be probably less. It's made heavier than other coffins I made though, so the TWR is probably enough to land only in the smaller moons. There's 2 RTGs in there (to keep our kerbonaut warm, of course), landing gear (in KSP1 bay I just landed on its doors), and so on.
  5. Today, I redesigned my fun long range coffin vessel. Those panels can't bring enough juice though, might redesign later, again.
  6. Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 (latest) | CPU: Intel Core i7 7700k | GPU: Asus Strix 4080 | RAM: 32gb DDR4 3600mhz I was fiddling around with an ion "coffin" type of micro vessel. It has some amount of rotated and displaced parts. Everything is fine on its own in the editor, and can load fine from its save. But, when changing the root part to a clamp-o-tron jr. docking port, it becomes disjointed in several subassemblies on load. This happens either on loading the vessel in the editor or loading the vessel for launch. When loading in the editor, the parts appear in the ground. It seems that the code path for saving or loading destroys the tree, but only if the root part is said docking port. It can save and load correctly if the root part is not changed. I can reproduce this bug every time with this micro vessel, it's not a one-off random one. Attached: a zip with the micro vessel with the root elsewhere, and a zip with the micro vessel rerooted to the clamp-o-tron jr. Included Attachments: Strollerminitest.zip
  7. Today, I re-explored an old concept of mine. Yes, both parts will glide back home, though they need some tweaking.
  8. My 2 cents: "Time" as a resource in KSP is useless, no matter what concept of "time" you want, and this carries in KSP2. It has zero relevance since it is infinite and we can just fast forward at will. Of course, there are game loops that can/should be attached to "time", and game loops where it's just silly. The vessel flight is coupled to "time" because it is you -the player- who flies it, and the player lives in a world with a very strict time concept, you cannot fast forward the player "time". EC consumption is coupled to "time", because an orbit necessarily takes time and therefore the vessel needs a little time to go around a planet shadow, where solar panels don't work and you should actually be able to deplete the batteries. Science transmission, even if it is realistic, it's a little silly to couple it to "time" and would be much better (gameplay-wise, not realistic) to couple it to a physical antenna restriction (i.e. not being able to send a giant data pack with an underpowered antenna). Planetary scan is a little more complicated since it is tied to something in orbit. KSP1 version of science labs and ISRU is completely silly. Generally speaking, almost everything that only needs "time" to complete is probably a bogus loop, because you can just fast forward and skip the loop entirely. Therefore, when the colony grows, it should be due to something uncoupled to "time", because if it were you could simply fast forward to grow your colony and forget about the game loops that are in there. Having the colony grow when some milestone is reached is much more logical and sound. As for kerbal mortality, "lore" wise they would be almost immortal, or at least have a lifespan in hundreds -if not thousands- of years. We've send our pilots in missions measured in decades (and more) so there's no way their lifespans are even close to ours. But let's say they have a much more finite lifespan and that kerbals in our vessels are immortal because it is a "needed evil" and an exception. In that case, we can simply think that colonies can support up to a maximum number of kerbals, and that they have a strict conception policy allowing enough births to replace deaths and thus keeping the same number of kerbals over time. If you build the required facilities, that number can be raised and more conceptions are allowed, and since they would be allowed as soon as the facilities are available, that ultimately gives us the "boom events".
  9. I'm down for this. There was a mod that added this engine to the game and it was a complete blast, so much that I MM'ed over and over in my PC through KSP versions. Super fun engine.
  10. If you review a little the forum, you'll find that most KSP1 veterans are just chilling around. Generally speaking, they will prefer to spend their energy on important things like playing or catching bugs (and in RealLife(tm) of course) than participating on useless flame wars. Also most of them know what an EA program is about. When the salt trolls eventually die down, they will start thawing from their hibernation and become more noticeable. I'd say that the most angry ones are those that are accostumed to see "EA" tags used as marketing strats. There's an endless stream of mostly finished games with the "EA" tag, and they're using it for the little oompf in initial (full-release) sales due to the mouth-to-mouth effect (or should I say finger-to-eye in social media). Even if it is not a lot of push, it is basically cost-free to do, and in small to mid size games it can be absolutely noticeable, and it could be the difference between being known or not... and nobody buys unknown things. It is becoming the modern equivalent of telling the world "hey, look here, we're making a game". When a real EA program appears, one that really want to involve people sending feedbak and helping to shape the game, those people are forced to face a reality check. And generally speaking, people don't really like that.
  11. As someone who tried the game in a nowadays-uber-potato GPU, I think I can help you somewhat: the art style for the UI doesn't look fine out of native resolution. Meaning, it goes from "bad" to "borderline illegible" out of 1:1 scale, depending on the UI widget drawn and the resolution chosen. If you are playing full screen, even if it tanks your performance you may want to try playing at native resolution. If you want to play in a window, I suggest you to configure the game resolution to something manageable as a window (1280x720?) and let it run 1:1. It will look and read much better. I've raised this point in a suggestion post, but it is actually hard to actually "fix" it. It is not exactly a problem in the game itself, but a side effect of image/texture rescaling combined with the chosen art style. They might get it better with different rescaling algorithms, which I'm not even sure if they can actually configure somehow. Time will tell, but for now playing at native resolution is the way to go if you want everything to be readable.
  12. Intruding for a bit just to let you all know a maybe relevant little piece of trivia. I've had a GTX 560ti, indeed I still have it. Due to several things that are not really important, I've played on it until very recently. And yes, I've tried KSP2 on it. It was... surprising... There are a number of things that this GPU doesn't like in modern games. There's specially the triplanar thing on terrain, which makes it go into crawl mode. The way they are introducing the video at the start is particularly hard on it al well. What does it mean? 1.- I had to deactivate the guided start to prevent the video from coming up. 2.- I had a whooping 0-2 fps while looking at the ground (KSP1 vibes? Yeah, but much stronger). Therefore my launches where looking at the sky to get around and be able to work the input. 3.- And once in space... It was surprisingly playable in the range of 10-20 fps. Mostly aroung 15. The faults in my system were just the GPU. I have a 7700k which is more than enough for anything modern, and for anything new incoming for a number of years. I also built this one forward thinking with 32gb RAM so no issue in there as well. Just the 560ti weighting it down until I could finally replace it (only a veeeery liiiitle generational jump!). The VAB was... workable. It was not great because you could feel the time lag in your mouse movements, but even if annoying at least you could build things. The launches were a little on the side of unplayable, and space was actually kind of enjoyable. The biggest annoyance was actually the UI, but not because the UI itself, but the UI graphical style due to not playing at native resolution. These kind of pixelated UIs are very poorly translated to non-native resolutions. Also, keep in mind that I could not play at all until 1.0.2, because I was a victim of the "pumping sim" issue, so I have no input on performance prior to that second patch. With that said, I'd venture that a 1650 can indeed move the game in it's current iteration to a "playable" state (of course, depending on each player definition of "playable"). BUT, we all know about the requeriments of these games, so I don't really know what the combination of a 1650 and a weaker CPU can reach. A little grain of salt is needed over my experience before applying it to anyone else.
  13. I'm hijacking a bit, and I'm not really good at physics but... as far as I've understood: I think it's safe to assume that the acceleration will be fixed for the duration of the physics tick. In the next tick, it will take the new mass and TWR and calculate the new acceleration. Even in big time warps where you could "advance" a lot of space after your fuel runs off, it still does make sense, since in space there's nothing to slow you down once you accelerate to speed and therefore the difference would be probably acceptable. Even then, you could handle this as a special condition (engine without thrust) and make a second calculation to fix that difference or something along those lines. And in celestial bodies the maximum warp is much smaller on purpose, which means forces such as atmospheric drag and tighter gravity are updated more frequently, making it much more accurate. As I've said, I'm not really good at physics, but I think the collision probability area is just a bubble with the center in the vessel current position and with a radius of the maximum distance the ship can do in the physics tick. Meaning, it doesn't matter the direction nor if it is not moving in a straight line, the ship can only end the tick whithin that bubble. And if I'm getting it right, that means it is not a "perfect" solution because there are also some weird edge cases where there are wasted cycles due to not having the direction in the formula, but I guess it's fine since they would be discarded in the second pass. E.g. if a ship is coasting perfectly parallel to another, at the same speed, then in high time warps = their bubbles will always intersect but they will never have a collision. Not perfect, but still very good since those cases in space are typically very rare or made on purpose (i.e. while docking). If it is not like that and I'm completely misunderstanding, the please disregard everything I've said and kick me away to a math class.
  14. I think I'm leaving the pumping room! I can now create a campaign and build something. I don't have much time these days due to IRL work so I didn't test to fly, save/load... but it looks good so far! Keep your hopes up! It's obvious that they are indeed making changes under the hood and bit by bit they are expelling us from this little corner. I'm sure your turn will eventually come!
  15. Project name: KSP 2 Project version: 0.1 and beyond Project name and version are independent of each other, always has been. There's nothing to debate over, really. And the poll results reflect it perfectly. --- Exercise for your mind: what if it was like this? Project name: KSP: Beyond Project version: 0.1 and beyond
×
×
  • Create New...