nikokespprfan

Members
  • Content Count

    302
  • Joined

  • Last visited

Community Reputation

158 Excellent

About nikokespprfan

  • Rank
    lithobrake scheduler

Recent Profile Visitors

1,664 profile views
  1. for the sake of argument, I want to challenge a few complaints about implementing it (EDIT: And then proceed to trow it all away again.) 1) Long vessels need extra code to account for gradient effects. As long as the thing is built well, in the way the video suggested, a substantial simplification will work relatively well, and few of us will complain about lacking accuracies we don't really care for.... 2) We have trouble simulating the vessel at large distances because of physics bubbles. Again, as long as the thing is built well, few of us will complain about lacking accuracies we don't really care for.... But this is KSP we are talking about. We can and will bring the code to its knees, and when we do, that is when we need to resort to actually simulate the darn thing in minute detail. ... unless.... Unless building a skyhook is like building a colony. Once you have completed it, all the complex dynamics keeping the system operational will be neglected because you have succeded in your goal. From now on, it just works. It is, after all, a megastructure. The question is, will we be satisfied by that? 3) The tip is satationary at the ground. I was going to bring this up, but it's false upon closer inspection and so my point is moot
  2. For the sake of keeping the source of sources up to date with the latest sources. The discussion thread for this development is here.
  3. Could this be bad,... possibly, if yearly extension after yearly extension occured without us seeing anything. But we are not yet at this point, and it is not helpful to start feeling anxiety over it, even though we all badly want the game tomorrow. For now, this is a one-time delay that could amount to no more than a month, for a game we indicated they had a tight timeframe for. The info we have gives from a month to a year more time, which gives them the breathing space I personally expect them to need to make a good game. I could also see Take Two having wanted to release it in Fiscal year 2020 for economic statistics and reporting results and such, which they now have sacrificed for unspecified reasons. As for the careless speculation on my part; We've had the reveal last month and the team was taking in lots of feedback. What we hear now would be inline with the team processing that feedback (including possibly our cues that we have patience) and concluded (/convinced T2) that a delay was for the better. All in all, I don't see things here that couldn't plausibly be explained by a change for the better, and I also don't see things that are good indicators of impeding disaster. I will not be losing sleep over this. I have patience.
  4. Here are my two cents, first there seems to be the harsch statement: there doens't need to be a console version in principle, here on the thread. This is not something the OP wants to hear, but we could totally have lived in a world where the console market never had a KSP, or the expectation for one. And that would be, to an extent, completely fine. In fact, even after the KSP1 console versions, KSP2 could have been PC-only. Similar points can be made on similar statements. "I expect them to meet these expectations but I fear (/am convinced somehow) that they won't meet it"; Response: "well,what says that you can reasonably have those expectations." KSP is a pc game, not because I think it is for some arbitrary reasons of taste, but in the sense of above. KSP could have had no console version at all, and for a long time it didn't. It built its first playerbase during that time. It was developed during that time, with only PC in mind, adding what would become porting pitfalls to be unfixably discovered at a later date. One aspect I immediately think of is the fact that KSP makes use of many keys, as if your keyboard acts as a spacecraft control panel. That reveals some PC-focussedness, and I imagine this makes KSP difficult to port. (but then again ports exist, and I don't know how (well) they handled all the keys, so this particular example might well be void.) As soon as you can say the focus-platform is PC, that gives you reason to temper your demands of the "least expected quality/status/priority/whatever" when it comes to consoles. I just want to put this out there. _________________________________________ Having said all that harshness, I really don't want to fight about this. Of course I also want a KSP 2 console version just as much as the next guy, that is on par with the PC game, and bug-free, and released at the same time as the PC version. KSP would be able to reach more players if it has a good console version, which in the end all of us want. But consider this: Star theory announced the KSP 2 console version at the same time when they announced the KSP 2 PC version. Contrast this with KSP 1, where there was no such promise from the beginning. The difference this makes is that star.theory probabily have the console version in mind from the start (while doing a complete rewrite of the game!, mind you). They can know the pitfalls of porting in advance (hopefully freshly learned from KSP 1's ports to console) and that will allow them to avoid these pitfalls. In a sense, that the assurances exist is already a reason to believe that the finished product will be more easily ported, and that the port will have better quality. (even though it ironically allows players to have higher expectations about it). Is that what is actually happening, is that what star.theory is actually doing? Will the port be better than the ports of KSP 1. Who knows??? ¯\_(ツ)_/¯ Don't ask me.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.