Jump to content

poopslayer78

Members
  • Posts

    62
  • Joined

  • Last visited

Everything posted by poopslayer78

  1. There is some amazing discussion around the "spamming multiple freighters on the same route issue". Luckily there are many knobs the devs can adjust to make this a fun and balanced experience. Here are some of these knobs: As @Pthigrivimentioned, having to pay resources to add each new freighter to a delivery route Use docking ports (or some part) to limit the number of ships per route. Possibly limit each port to 1 delivery per 10 minutes. To prevent spamming docking ports in #2, perhaps the command module or some sort of new "logistics module" could be upgradable in-place with maybe 4-8 levels for route throughput support Cargo storage space at the source and destination will naturally limit the useful volume of cargo in freighters if cargo is delivered in discreet bursts. Production bottlenecks (aka throughput for transforming basic products like ice into advanced products like fuel) are not helped by higher throughput routes Low ore concentrations could create bottlenecks that aren't helped by high throughput routes Late-game freighters economically replace entire groups of early-game freighters. There are multiple reasons for this: Larger parts available Better parts available The player will be more experienced as the game progresses and can create more optimized designs
  2. There's some in-game footage suggesting that Debdeb may be a red star, no word yet on it's size. I'm guessing it's a young star though based on Gurdama's development and the large ring around the entire star.
  3. Ah, I never read this I simply assumed it... and assumed incorrectly it would appear. Oh well, my dreams of real asparagus staging will need to be fulfilled elsewhere.
  4. Based on the description from Wikipedia, it sounds like the big brown tank contains liquid Hydrogen and Oxygen, which is fed into the space shuttle's engines. When the tank is depleted, it is detached and the shuttle operates off of the Hydrogen and Oxygen contained in the (full) shuttle. The shuttle's hydrogen engines run from the beginning of the launch combined with the SRBs. This sounds like real life asparagus staging to me, which is awesome. My impression was that asparagus staging isn't ever done in real life since pumping fuel around with turbopumps is really difficult, but I guess it works here.
  5. Asparagus Is Good For You - Feed an engine though a tank not in that engine's stack Don't Look At The Light - Directly view a synthetic nuclear fusion event without dying Smells Funny - Have a Kerbal remove their helmet on a non-Kerbin body that contains a thick oxygenated atmosphere I Wish I Had This Before - Build a launch site within 10% (height) of the highest peak on Eve Introverted - Have a Kerbal in interstellar space at least 10kM away from any other vessel Roid Rage - Tow an asteroid into a sub-orbital trajectory of Kerbin The Local Economy - Produce <some complex product> using only resources mined from that celestial body Rings Of Destruction - Collect an EVA sample from a planetary ring Return To Sender - Walk on the surface of Duna while carrying Duna ejecta collected from Ike Cassini Royal - Discover organic compounds on Merbel
  6. I'm very excited to hear that automated delivery routes are confirmed and can't wait to over-engineer a logistics network. Positivity First: It sounds like resource routes will be established by performing a delivery with a truck or rocket manually first. Once a single successful loop is completed, a new delivery route will be unlocked. This is an excellent design choice because it requires a player to achieve sufficient mastery for each route, and since some routes will be harder than others, the available wealth for a player will grow in proportion to their skill. Even better, the tedium of repeated manual hauling missions is eliminated (I've certainly done this in KSP1). There are two aspects of delivery routes that could cause problems if not implemented well: #1 - Variable dV requirements for routes that cross multiple SOIs If you want to get from Kerbin to Eeloo, the dV required will depend on the relative positions of those planets and the order you perform your maneuvers. This gets even less repeatable when gravity assists are considered. One potential exploit could be a player manually running a delivery route at the optimal time with very favorable gravity assists, and then getting future deliveries for less dV than they really should cost. Personally, I wouldn't mind this, and if a player is smart enough to exploit this... maybe they should be rewarded for it? This is one of those cases where I believe satisfying gameplay is better than realism. That said, I think there should at least be some sort of in game acknowledgement of this issue. Another possibility could be imposing some sort of handicap on a player while proving a delivery route... such as 10% greater fuel consumption. #2 - Will automated vessels be under control of the Physics Engine Please don't do this for the following reasons: It will cause delivery routes to spontaneously fail off-screen at no fault of the player due to kraken like bugs. Even if KSP2 has far more robust physics than KSP1, delivery routes would also greatly expand the number of failure modes. It wastes CPU - The rigid body physics calculations are computationally intensive and may be fundamentally limited in how much they can be parallelized. This cost is worth it for craft the player is actively looking at and piloting, but not for stuff off screen. Even if different vehicles far away were give their own physics threads, it would wouldn't take long to saturate even a high-end CPU. One possible exception - It may acceptable to physically simulate delivery vessels while they are close to a player. For example, if a player is piloting a space station and an automated freighter comes in to dock, this could be a reasonable because it only needs to scale with the number of players and if a kraken occurs, the player will witness the failure and learn something immediately. Discussion of possible deliver route implementations Since it hasn't been explicitly confirmed is exactly how the automated resource routes will behave. Let's consider 3 possibilities (there are many others): Exact Record/Playback This implementation would be like trucks in Satisfactory. You press "record", pilot your craft manually along a delivery route, then "stop" the recording when you close the loop. The craft would replicate your actions exactly. Tradeoffs: [-] Please don't implement this [-] Would only work for land-based routes. Orbital targets would change relative positions between iterations of the delivery route, so rigidly executing the same maneuvers at a different time would not work. [-] Not robust - It is not realistic to expect a vehicle to perfectly execute recorded instructions each time. If the player barely grazed the edge of some scatter while recording, it may cause a collision during a random playback. Ghost Ships on Rails - After recording a resource route, your craft will repeat that same route, but will be non-collidable and on rails [+] Robust - Players still have to prove route viability but don't have to worry about spontaneous failures due to FP rounding errors or kraken-like bugs. [+] Moderate CPU - This should be little more than viewing a bunch of craft in the tracking station, or rendering a few ghost ships docking at a resource depot. [+] Provides visual feedback/beauty to the player to appreciate as they build up their industrial infrastructure. [-] Still has the problem of different maneuvers required depending on relative celestial body position. Since these are ghost ships, some cheese is allowable here, for example "draw a curved path from Kerbin to Jool that looks reasonable". These automated ghost ships should achieve these paths "magically" without burning their engines (except maybe for visual purposes). Abstract Network - Delivery routes would behave like the KSP1 relay network. After manually executing a loop, the UI could draw a line between the source and sink and you could utilize this link in some sort of logistics/production management UI. [+] Very robust - No moving vehicles means no spontaneous failures [+] Very Low CPU - All you need are some new UI elements but no actual craft to render or track [-] Not as cool - It may be hard for some players to suspend their disbelief if a stack of ore magically appears every 6 hours in their station without seeing anything dock.
  7. I like the idea of this too, even if it's very simple. For example climbing and internal ladder for a laboratory module. This sound like a great idea for the extended roadmap so it doesn't lead to scope creep during the current roadmap. I think a feature like this would work best if the kerbals and internal furnishings weren't fully under the physics system... basically the equivalent of "No same vessel interaction" option in KSP 1. Maybe bouncing around in zero-g would be cool, but I could see it tempting the kraken.
  8. I agree with you Ember12, having standardized/modular sub-assemblies is something I want as well. When you say "git tree" it seems like you're actually talking about a "directory hierarchy" where you can have folders and sub folders with different variations of your design. When I used the term "git tree" I meant the directed flow graph that gets generated when you do forks & merges on a single file/craft over time... which now that I think of it isn't really a "tree" it's more of a DFG but I digress. Anyway, just wanted to make sure we're talking about the same thing. I love the idea of building flexible boosters and modules that can be easily imported for various payloads.
  9. For single player, I think a git tree would be overkill and version numbers would be preferable. For multiplayer, having the ability to "merge" and "branch" craft could be useful, as long as it's simple enough for non-git users to learn comfortably. I'm using the term "merge" very loosely, it would probably be as simple as a full craft replacement or adding a sub assembly to a workspace. To clarify, I'm not saying single/multi player should have different versioning systems, I'm saying that single player may get some extra features that are motivated by multiplayer. GoldForest has a point here, once you successfully optimize a craft there's usually no reason to go back. There are a few use cases where multiple version are still useful: You make a design change but won't know if the new craft is better or worse until after flying a (potentially long) mission, so being able to roll-back versions after testing is useful. Occasionally, you may want to look back on the evolutionary path of a complicated spacecraft and reflect on what you've learned between versions. Agreed
  10. For KSP1, I copied my .craft files between the save game folder and a git repo. This is one reason why I'm hoping a native Linux version of the game is eventually released. That said, I think you have some great suggestions here. Most people won't be using git and even if they know how it's still quite tedious, so having good in-game organization for craft and sub-assemblies would be nice.
  11. There's already some pretty good KSP1 machinima out there (Mirror for example). I'm sure there will be plenty of creative fan-films like this made using KSP2 as well.
  12. A couple additional thoughts on the UI that haven't been discussed as much: First, I'd like to explicitly state that I prefer the navball in the corner of the screen. This is because space in the vertical 1/3 and horizontal 1/3 of the screen is prime real-estate that's best used to view the craft in space. I don't mind if there's an option to move the navball to the center, it's great to give players a choice to play how they want. I also like the fact that the navball area is very compact, with multiple indicators (AP/PE levels, vertical speed, atmosphere, tapes, etc) in the same area. This means the player's eyes don't need to jump rapidly across the screen. Second, it would be nice if a kerbal's class (pilot, engineer, scientist) is displayed as a small icon over their portrait. In KSP1 it was very tedious finding which kerbal was the engineer and selecting them for EVA construction, or finding the scientist to reset an experiment via EVA. Of course, this assumes kerbal classes are a mechanic in KSP2, if there are significant differences here then this idea may need tweaking or become invalid. Here's a mock-up that I made with small class icons overlaid over the portraits. Using icons that simultaneously use different colors and have very distinct shapes make identification at a glance easier. Finally, points #1 and #2 can potentially be combined by shifting the portrait view to the left so it's in the top-left corner of the screen. Again, the idea here is that the middle areas are often necessary to comfortably view your craft in space without zooming out too much. It would be great to have center/corner as an option so players can choose what works for them.
  13. So I really like Enceladus and recently realized that Merbel is an icy moon around Glumo... really excited to see what surprises the devs hide on Merbel after interstellar/DebDeb are released.
  14. This is one thing I'm also worried about. I don't see much value in simulating colonies as rigid body arrays. I can see colonies spontaneously exploding or excessive landing-leg-skating when trying to land a rocket on a landing pad if the physics model isn't extremely robust. Not to mention all the CPU intensive computations for simulating all of this... In my mind it would have been better to impose some sort of approximate static building constraints in a base assembly editor and as long as your base was within those constraints, you could build it and it would behave like the KSC... infinitely rigid but still destructible. But whatever... having physically simulated bases could work just fine, it just seems like a lot of extra effort and risk for not a lot fun added. I'm also hoping that automated resource routes and mining operations are on rails as much as possible, at least if you're not in immediate proximity to those operations. Keep the background stuff abstract, reliable, low-CPU, and multi-threaded. Save the heavy physics for what the player's eyes are focused on.
  15. I like it. Based on the green nebula, This must mean the Kerbol system is in Gallente Space but not yet connected via stargate within the Eve Online universe
  16. I noticed on the equivalent roadmap post on reddit has slightly different information. This appears to be an official post but who knows... Anyway, I noticed that telescopes will be part of the interstellar milestone! Does this mean that the interstellar planets will initially be hidden from map view and require some sort of precursory missions to slowly build up the map?!? This sounds awesome! When I first played through KSP1, having the full map available from the start took some of the fun of exploration away. I love it when game content is unlocked slowly over time and requires mastery of previous mechanics first.
  17. I personally liked this aspect of the UI, in fact I think the dithered atmosphere indicator makes it very easy to distinguish the atmospheric layers at a glance. ...But I see your point, not everyone may see it as charming like I do. Now that I zoom into it... the rocket is very tall compared to each atmosphere layer indicator, which makes it ambiguous where layer you're in. At first I thought the red triangle at the bottom was a plume but maybe it's meant to be an arrow? Perhaps it would be better if the red arrow/plume was made horizontal to make it very clear what layer you're in. Maybe it doesn't matter since the actual atmosphere is continuous but since the UI breaks it into distinct regions, the ambiguity bothers me. Current Actual UI Deep Fake Suggested UI That I Made Also, maybe add some sort of "LED" at the top of the atmosphere indicator that turns on when you're in a vacuum.
  18. Is anyone else wondering why the lander is burning prograde (or maybe surface-radial-out) during this landing? ...or am I just an idiot.
  19. Dres has rings now! Does this mean we will get to test collidable rings and all the extra orbital maneuvering considerations that come with it in the Feb 24 release? This is a great new activity that can be done within the Kerbol system.
  20. Make sure you have a solid bug reporting / feedback system in place during early access I've played a few successful early access games and try to submit bug reports whenever I encounter something. I'm a verification engineer in real life so I'm already in the habit of simplifying bugs down to an easy-to-replicate base case and capturing useful details. There's nothing worse than putting in this extra effort (as a player) and feel like you're just dropping your feedback into a void. Here are some suggestions specifically around bug reporting when the early access period begins. Use a ticket-based system (similar to jira) and not a forum-based system. Separate each bug report into multiple fields rather than dumping everything into a single text field. For example... - Title - Category (Graphics, Physics, UI, Crashes, VAB, etc). There should also be a category for "Suggestions" or things that aren't strictly bugs but may be grindy or cumbersome. - Bug Description - Replication steps Each ticket should have a status field that is visible to the player submitting it. Even if my feedback won't be incorporated into the game, I want to know that it was read by someone and given a minute or two of thought. Here are some possible states for a ticket: - Pending Review - Accepted - Assigned (As in, there is now a specific human who is responsible for this task, even if they aren't working on it right now) - Rejected (Please include the reason: Duplicate, Cannot Replicate, Not In Scope, Missing Information) - Resolved The list of bug reports should be publicly viewable and searchable to avoid duplicate reports. Building on #4, players should be able to upvote and add comments on existing bugs if they encounter the same issue or know a workaround Allow reasonable attachments to be uploaded, such as save files, craft files, and images.
  21. Some initial thoughts after watching the video... I think early access is the correct move, but this should have happened earlier. I was a little surprised that colonies won't be part of of early access and really surprised that interstellar won't be as well. I'm going to give Intercept the benefit of the doubt here and assume that interstellar is mostly done but is being held back mostly so that the EA feedback is only on the core game mechanics and therefore more manageable. I saw quite a bit of footage with rover wheels and landing legs, so hopefully this means that the physics is improved from KSP1. This will be a great area to get feedback on for this first round of EA features but hopefully the baseline is good. How is continued development going to be financially supported? Investors will need some motivation to keep paying the developers' salaries through the EA period and hopefully this is done in a way that is financially sustainable without compromising the game itself. Overall I'm not gonna lie, I was a little disappointing (mostly around the lack of interstellar) but also a bit relieved. I had a feeling the game wasn't really done but now at least a lot of uncertainty is gone and after EA development won't be done in a silo anymore.
  22. I've been thinking how "The Efficient Market Hypothesis" or the quote "With many eyes, all bugs are shallow" apply to this forum. Every time the KSP2 team posts something small on some random platform that they haven't used recently, it gets instantly posted to the forums and analyzed in detail against every single previous communication over the past 3 years. It's also kindof funny when a KSP2 community manager officially posts the content to these forums a day or two later after it's already been discussed at great length.
  23. Maybe it's Schrodinger's folder. Until you open the folder, the release date is in a fuzzy quantum state defined by the wavefunction: Jan 01 2023 <= x <= Mar 31 2023. Also, I bet whatever's inside tastes like Minimus which is why the Kerbal wants it so bad...
  24. I really like this suggestion. There's another reason why this could be helpful: motivation to send smaller missions. I really like the idea of building small, lightweight craft that only perform flybys or suicide dives into an atmosphere. Unfortunately, KSP1 doesn't motivate me to send smaller missions and instead I tend to build large general-purpose SSTO hoppers with ISRU. There's nothing wrong with ISRU hoppers, but I wish there was a compelling reason to send a wider variety of missions. Exploring planets in increments over multiple missions is also a bit closer to reality and makes role play easier.
×
×
  • Create New...