• Content Count

  • Joined

  • Last visited

Community Reputation

156 Excellent

About nikokespprfan

  • Rank
    lithobrake scheduler

Recent Profile Visitors

1,575 profile views
  1. they are large trusses right. we could look at it in a different way. Your orbital colony is the shipyard for spacecraft, or a craftyard, then, if it is 'the norm' that you have multiple trusses on one craftyard, then these trusses can be called CYTs, or CraftYard Trusses . Although, it is ambiguous whether it is a K-sound or a See-sound. Me tworings stuff at the wall to see if it sticks Semi-good results: CYT: Craftyard Truss VAC'D = Vehicle Assembly Construction Dock, it is also a vacuumed facility. SCAD: Space Craft Assembly Truss O-CRAP:Orbital - Craft Resource Assembly Platform CRAFT: Craft Resource Assembly Facility Truss OOF, for Orbital Operation Facility, or for "OOF, thats heavy, we can't launch that from Kerbin." -- this one is not mine, it just wasn't mentioned here yet. OAL: Orbital Assembly Location or maybe we should just call them a Vacuum Assembly Beam and be done with it.
  2. exactly, under the hood, the kerbals aren't idiots. (I mean, they ditched the space-suit-mitts policies, which is the biggest technological improvement in mission succes of the decade.). However on the other hand, the purpose of Kerbals being derpy is to make them relatable by derpy players. Lolsplosions exist in trailers to tell players that everyone mucks up pretty often, and that they should not feel bad for mucking up. WE are why kerbals "are" derpy, and the kerbals have nothing to do with that. Say, for the sake of argument, you are a new player (not a minute played) attracted by the improved tutorials. What fun would it be for a trailer that is entirely triumphant, only to get a game where you will fail for sure the first time you play. Also, even a serious company like space-X has a lot of lolsplosions, and they accieve success as well. No I very much understand why the explosions are there.
  3. oof, that is a difficult choice. Both are a little odd. Both already are pretty good, in all seriousness. If we don't want to say "orbital" because the thing can be outside planetary SOI's, then use off-world instead of orbital.
  4. It depends on how big the change is, I'd say. Learning new systems is probably fine, and learning small changes to systems is too, but relearning major systems is where stuff gets annoying.
  5. Astronomers keep tables and databases of positions of stars in the milky way galaxy. These databases get updates every 50 years to account for all kinds of phenomena, from changes in the earth's rotation to the stars moving around. I don't know the average change that these tables have, what I can say is that that is the change in position you notice in between a trip of 4 lightyears on a craft at 10% speed of light. That can give you an idea as to how much the stars really move. What I'm trying to say is, in the KSP universe we are used to bodies further out moving larger distances over time, but my gut says that this just isn't the case for stars, everything is very static on human lifetimes, although admittedly you might not completely be bounded by human lifetimes in KSP 2.
  6. There are many little things I have to say about this. Regarding the need of supply missions, there are things you can do, for instance automated control (principles currently in game), or just letting the base keep mining even when in hibernation. Since you mention the definition of hibernation, you might be referring to my Hibernating Stable-State LS design earlier in the thread, where indeed all operations will be cut in hibernation, but that plan had automated recurring resupply missions (that you only fly once) built in. So I guess that could mean that stable-state =/= self sufficiency, and you could get a colony stable at any size by automatically shipping in goods (as opposed to making it all yourself, which would be self-sufficiency). Also, the HSS plan only works for craft that are big enough, so small bases ala KSP1 could still be made, exactly what you want, but I digress.... Also, from what we know about bases, they will not grow past a hard cap. You need to enable it to grow to a new cap by meeting requirements, otherwise the kerbals have no reason to celebrate, and the devs have said there will be no new kerbals without reasons to celebrate. So that is one worry less, as the requirements can be build to fit any model necessary.
  7. Aha, Eureka! The walls of the metallic hydrogen tanks are made of frozen Mystery Goo, the only unobtainium in known to be in game. _____ In all seriousness, when talking in principles, saying speculative engineering not speculative science is kinda already rooted in the goal of KSP: a game in which you fly absurd creations under realistic physics. This makes it pretty convincing as a good judgement for any nearfuture drives/tech. I also feel kinda convinced by @Dragon01s' argument that KSP should avoid spreading misconceptions. However I'm at that nasty stage where I don't want to let go of my ambivalence towards metallic hydrogen rockets just yet. (That is, you won, but I feel resistant). Mainly this is because there is the principle of this criterion, and then there is the theory of game development (in which gateway tech might be necessary), and the then there is the practice of actually experiencing the tech progression as a player. So really what would be a constructive thing here is: are there other "speculative engineering but sound science"-drives that we can think of that could take its place. Given all the reasons why a metH-drive might be convenient for the dev's, what would be the more scientifically-sound, better researched alternative. It is a running theme of KSP to find the balance between teaching science and keeping the ultra-complexities out of it. I don't fundamentally think that it's wrong to take some liberties on either side of that tightrope sometimes..... although the above principle is a very useful one. ______ Now that the rammifications of this assumption are well understood, I'm going to do the very mathematical leap of trowing away this assumption, and changing perspective/context of the discussion. My preferred design of life support (no played experience though) thinks about the player not in terms of periodic imputs that the player has to do to every craft with kerbals, which indeed becomes a logistic nightmare that no-one wants to play when you even think about it. But rather it sees it as a part of the game loop, a part of the challenge of getting something done. So what tends to be the game loop for a given mission: build a rocket, test the rocket, fly the rocket, accomplish your goal. You could make it so that part of the game loop of establishing a colony is to make it self sufficient, and then once it is it never needs player input anymore. The player has now completed its objective to establish a colony, and it can go about it's business. An analogy is this. Say, in KSP2, you could have airship colonies or bases on gas giants, or on venus/eve-like planets. While you are setting up the base, you would require the player to make the base floatable. If the player cannot do that, he will fail, that's just part of the challenge. However, if the player succeeds, would you want to simulate the floating stability of that colony for the rest of game time, and require the player to keep fixing any issues that might pop up? NO, just NO. You'd want to accept it was stable, flag something in the code, and tell the player he was ready to move on. Anytime the player comes back, the colony will be there, unadorned, hanging in the sky. No periodic input, but useful as part of the game loop of establishing an air colony. Another anology could potentially be made to leaving space stations be when they are in a suborbital trajectory. I mean, that will fail, you have to get it into a stable orbit before you can look away, that is just part of the challenge. But once you do, the game will not simulate all the microforces that real spacecraft experience, that tug them out of orbit (n-body rammifications, atmo-drag well "out" of the atmosphere, etc.). Those phenomena are approximated away. You space station will now be in a stable orbit forever. (Now, all that's barring the obvious differences that orbital mechanics is more important to the essence of KSP than LS, and that this way of stabilising craft forever was not intentionally for this but instead a result of just using simplified orbital mechanics, however the way the gameplay works out is what I want to demonstrate here) Now I know your opinion on colonies when it comes to self-sufficiently (which is vital to the difference between our assumptions), but colonies have much lower burden of being utterly realistic when compared to, say, near-future engines. You have some liberty, especially after the 3D printing part of the discussion. Besides, when it comes to the "you never have all things you need", I would be very much in favor of the kind automation you mention. Have the player fly a transport mission from a colony to another once, and have the ability to setup automated repetitions of that mission. That would be a very factorio-style automation that makes you (have the ability to) play on a very different scale once you get to a certain point. These transport missions could then be a part of your goal as player to stabilise a colony before absolutely neglecting them for gameplay reasons.
  8. Poeple think they are plants because the kerbals are green. Now that anything green we asociate with plants is our thing, but there is no reson why (green ==> plants) must be true. In other atmospheres, plants might have diffent colors (although the atmosphere and plantlife of kerbin is very similar to earth) and biospheres might have evelved differently. Life support doesn't imply this per se. It could only matter for colonies, it could put kerbals in hibernation when deprived of stuff, you could have it so that colonies become "magically" self-sufficient if you reach a certain point. It doens't have to be punishing.
  9. 1) Can the sources of science/data/etc be modded, and to what extent. I assume this will fall under the category of the science question already in your list. I'm mentioning this related to something you might remember... 2) Will ships be trees, or will they be something more sophisticated. I.e. is multidocking a thing? 3) Will we have bigger asteroids.
  10. We didn't discuss this specifically, but we did touch on the idea sort of tangentially, and it sounds like the answer is "not a lot". Specifically, they said they want this game mainly to be about building and flying rockets-- the phrase they used was "We're not trying to build Kerbal Cities: Skylines". They don't want to take emphasis away from that and make the player worry too much about logistics. Why do I mention this. I mention this because it means the devs have another consideration.This will be useful for any speculative or fantasy LS system designs we make in this thread. Not only does one need to heed micromanagement and the severety of failure, you also need to keep track of the fact that the game keeps being about flying rockets, not logistics. You should be doing restocking missions constantly.
  11. Scott mentioned that he would put a backup up at youtube or something? Most twitch streams get deleted after 14 days I believe, so if there is a backup, we should post that backup.
  12. I meant this as a jokey comment, just a little jab, that's all.