Jump to content

poopslayer78

Members
  • Posts

    62
  • Joined

  • Last visited

Reputation

117 Excellent

About poopslayer78

Recent Profile Visitors

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

  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
×
×
  • Create New...