Jump to content

Recommended Posts

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:

  1. 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.
  2. 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):

  1. 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.
  2. 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).
  3. 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.
Link to comment
Share on other sites

One simple solution each solar system runs like clockwork. Each supply run only happens when conditions are identical. for more complex the route the longer it will be for route to turn up again. 

As bigger engines come online the more routes open up that can occur more regularly. also as colony come online the need for the complex routes drops out of usefulness.

the only problem with 2 can be solved with a UI that asks if you want to repeat it every x days. with options to spawn new ship if one hasn't returned to load up new cargo.

 

Edited by mattinoz
Link to comment
Share on other sites

Nice assessment. Me expectation is the ‘Abstract Network’ solution is the most likely, but I agree it would be cool to see the vessels leave and arrive. Perhaps the recording method could play a part just in physics range and its purely aesthetic? As in even if it failed for some reason the resource would still transfer? 
 

I think a great solution to problem 1 would be to employ UI similar to a mission planner, where the game could automatically schedule repeat deliveries along each leg when windows appear that are similar in dV costs to the original run. Players could also tweak these if they liked by picking points on a porkchop. I wouldn’t even mind if the game gave a 5% tolerance here to make things easier. 

Edited by Pthigrivi
Link to comment
Share on other sites

On 11/18/2022 at 5:23 PM, poopslayer78 said:

Will automated vessels be under control of the Physics Engine

in ksp 1 all ships far away arent affected by the physics engines so i guess it will be the same in ksp2 especially for delivery routes

Link to comment
Share on other sites

I was just wondering about this the other day. I also think the "Abstract Network" is the most likely solution and the way to go, even if it is a bit gamey, particularly since it's so robust. 

On 11/18/2022 at 11:23 AM, poopslayer78 said:

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.

I totally agree with this. Setting up low-consumption flight paths is hard and time consuming and players should be rewarded for pulling it off. It's pro-problem-solving and anti-grind game design. Might not be absolutely realistic, but it's an acceptable abstraction. 

____

Some hiccups with the Abstract Network though:

Let's say you have a colony Alpha producing 100 widgets/launch window. You want to ship these widgets to colony Bravo, but Alpha doesn't have the best shipbuilding infrastructure yet and can only build and launch a small ship carrying 10 widgets. So you do that, and save it as a delivery route: 10 widgets, Alpha -> Bravo. Cool...
But once you've established that as a delivery route, in principle there's no reason why you couldn't multiply it. "Hey, Alpha, just send ten of those same ships per launch window, okay?" 10 widgets, Alpha -> Bravo, x10. Now you have all 100 widgets going from Alpha to Bravo per launch window, despite Alpha's low state of development. 

This is how things might work in real life, with Starships colonizing Mars for example. Hundreds or thousands of Starships could be loaded and staged in LEO, then depart all at once in flotillas every two years. But is that fair in the game? Should there be a button in the Delivery UI to duplicate export shipments up to the maximum a colony could support? Maybe, but it would obviate the need to launch bigger delivery ships, which would eliminate that as a design challenge for the player. I'm sure bigger ships could be more efficient and replace the smaller ones later, but still...

Okay, so let's say you don't include a multiplier button. Well now you've just incentivized the player to manually launch 10 identical low-tech transport ships, stash them in orbit, then have them all burn for their destination in one launch window. That's the same as doing the first delivery route x10, just grindier. Might as well give the player their route multiplier button back and save them the trouble. 

Mining missions have this issue too. If a colony sends out a rover to dig up and return 100 ore from a nearby deposit, can the player just... do it again and make 200 ore? Then 300 and so on until their colony has an unreasonable income due to grind? What's the launch window for a mining mission? Nearby craters don't have synodic periods. 

One option is to simply restrict the number of abstract delivery routes from any colony A to any colony B to 1 ship per window. This is quite unrealistic of course, but now all of the trade from Alpha to Bravo depends on one ship design and one flight plan, which seems in the spirit of the game as a rocket design and astrogation challenge. The amount of resources transferrable from Alpha to Bravo depends on the player's design of one ship for that purpose, and larger more ambitious designs are incentivized to maximize payload. It simplifies things a bit further too, in that there's now only one route to be replaced if the player launches a new mission to update it; there won't be a mess of different ship designs going from A to B to keep track of. Resource locations could also function as "colonies" for this purpose, so players will need to make their mining missions count. 

Of course, this creates the problem of having to constantly design new ships to update your delivery routes as your colonies grow, which is its own brand of grind. Maybe the delivery multiplier button is the best option and only the prospect of better ship design or flight path efficiency creates the incentive to update delivery routes. 

TL,DR: I'm confused and I hope the developers aren't.

Link to comment
Share on other sites

18 minutes ago, Timmon26 said:
On 11/18/2022 at 11:23 AM, poopslayer78 said:

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.

I totally agree with this. Setting up low-consumption flight paths is hard and time consuming and players should be rewarded for pulling it off. It's pro-problem-solving and anti-grind game design. Might not be absolutely realistic, but it's an acceptable abstraction. 

In this situation, it wouldn't impact the gameplay that much since the same gravity assist sequences come about far less often than regular transfer windows, and if your route repeats every time the conditions are the same, that optimized route would only repeat when similarly optimal conditions are met. 

19 minutes ago, Timmon26 said:

in principle there's no reason why you couldn't multiply it

20 minutes ago, Timmon26 said:

but now all of the trade from Alpha to Bravo depends on one ship design and one flight plan, which seems in the spirit of the game as a rocket design and astrogation challenge.

For context for those reading my post, these two quotes are opposite, the second one is not talking about a consequence of multiplying routes, rather the opposite. To respond to this, I had the same issue in a discussion about the inclusion of trains and space elevators to transport a lot of resources. To me, increasing resource rates by a factor of a hundred should mean designing a bigger and better mission instead of maximizing the rate of a less well-designed mission. It gives an incentive to go back and think about old routes, design craft with newfound skills and technology, and improve on old missions. However, this runs into problems, and there are a few reasons I think it won't happen. 

28 minutes ago, Timmon26 said:

Well now you've just incentivized the player to manually launch 10 identical low-tech transport ships

29 minutes ago, Timmon26 said:

Of course, this creates the problem of having to constantly design new ships to update your delivery routes as your colonies grow

These two are the biggest thing; it takes a lot of time to update and expand your delivery route, as you are building and flying (potentially identical) craft instead of just tweaking a slider. I want to do that as I think that building and flying is better than tweaking sliders or inputting a number, but there is an arbitrary point where I agree that it would be better to just have more missions go, rather than launch and grind new ones. The only consistent way of doing it that doesn't rely on an arbitrary limit on repeating things is to have it repeat as much as possible, which means as many times as the colony can afford to launch the ship. 

This does luckily still give a bit of restraint, as colonies will have to mine up enough resources to support a fleet of ships (and I'm still hoping that storage space for those ships is a consideration), so there won't be ludicrous amounts of ships flying in the early game. It also still incentivizes more efficient production, as better ships consume less resources per unit of cargo, enabling the same colony to transport more materials. It ends up with the best of both worlds; very little to no grind, with incentives for ship building and flying for those who enjoy that. Also, since we have no central resource conversion, colonies that shift their purposes in the late game (like going from a mining station to a resource deposit) will need to have the option to drastically shift their route production, and flying a hundred missions for dozens of colonies just to rebalance the network falls beyond my personal line. 

Link to comment
Share on other sites

I'll say a thought that's already been said here. I believe that the player should record the route by manually navigating the ship. I do not think that the game will add an autopilot, which will very accurately fly the route from takeoff to landing, which you have built on the map of the system (unless there will be a similar mod). The route you flew manually, of course, must be repeated under certain conditions, such as a certain relative position of the planets, the orbital parameters of the target and the availability of a certain amount of necessary resources. The concern is that the computer may not be able to follow your route exactly because of its machine precision, but you can build a route with a little dV in case the course is off course. I remember the developers promised to add a maneuver planner, why not automatically include it so it will make a little self-correcting for example Hohmann's transfer on some part of route using the dV reserve if it suddenly missed the target while building the transfer. And this function will of course be turned on, if the player flies past the ship performing the route or somehow interacts with it, because you don't need to spend extra resources on unnecessary additional calculations

Link to comment
Share on other sites

20 hours ago, Timmon26 said:

Okay, so let's say you don't include a multiplier button. Well now you've just incentivized the player to manually launch 10 identical low-tech transport ships, stash them in orbit, then have them all burn for their destination in one launch window. That's the same as doing the first delivery route x10, just grindier. Might as well give the player their route multiplier button back and save them the trouble. 

Im wondering... ""realistically"" simply launching more vessels isn't always a good solution. After all, we dont send out a thousand cheap boats instead of one large expensive cargo ship, A mining company uses giant dump trucks instead of a thousand people with wheelbarrows; the limitation resides in not only the infrastructure of shipbuilding but also ports and the amount of operators. A tiny colony wont support 1000 mining rovers if the only drop-off is a dumpster taped to a ore converter and the vehicle bay can only hold a single car, or there's <1000 kerbals in the colony (ignoring automation), or even just the resource inefficiency of building 1000 low-payload rovers as opposed to just expanding the VAB and building fewer bigger rovers may put the notion off (something something the container's mass squared, the volume contained cubed).
I think it is definitely possible that there may be a cap on the amount of supply routes per colony, maybe dictated by population or infrastructure or both. This would encourage larger or more space-efficient vessels and prevent your lander turned moonbase from filling up with 1000Gt of rover ore deliveries before you've ended the 2nd kerbin week of the play-through.

I also do not think the possibility to send 10 of the same delivery route is encouragement of grind. Maybe a second or a third(?), but not to the point where it saps the fun out of the game. I would personally very much prioritize the construction of infrastructure for larger vessels before subjecting myself to any such grind, as time warp is always an option for the impatient.

Edited by Xelo
Link to comment
Share on other sites

This could all be somewhat mitigated by requiring players to pay the converted build cost of the original delivery vehicle in order to set up a second, simultaneous route. So off the bat you could put 1000 resource harvesters together but only if you could afford to build 1000 of them. As t_v points out this would still encourage updating with larger vessels over time because of the square-cube law, but without too much grind you could easily expand production by duplicating existing routes. I do also like the idea that there would be a larger cap on how many supply routes a given hub could support--possibly a set of command-and-control modules that need to be staffed and can be upgraded as your colony grows?

Link to comment
Share on other sites

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:

  1. As @Pthigrivimentioned, having to pay resources to add each new freighter to a delivery route
  2. Use docking ports (or some part) to limit the number of ships per route.  Possibly limit each port to 1 delivery per 10 minutes.
  3. 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
  4. 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.
  5. Production bottlenecks (aka throughput for transforming basic products like ice into advanced products like fuel) are not helped by higher throughput routes
  6. Low ore concentrations could create bottlenecks that aren't helped by high throughput routes
  7. Late-game freighters economically replace entire groups of early-game freighters.  There are multiple reasons for this:
    1. Larger parts available
    2. Better parts available
    3. The player will be more experienced as the game progresses and can create more optimized designs
Link to comment
Share on other sites

On 11/18/2022 at 5:23 PM, poopslayer78 said:

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:

  1. 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.
  2. 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):

  1. 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.
  2. 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).
  3. 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.

For trucks I kind of imagine its an kind of replicate route however that the AI does the drive often based on its own tracking, might ignore surface shatter.
The AI truck might also be more careful and slower. 

For AI ships, Mechjeb launch autopilot+ mechjeb porkshops to  find earliest arrival date+ mechjeb landing autopilot, gives decent dV requirements and time and can set up an flight plan using the allocated fuel. If an tanker you will need to separate out the cargo fuel from the fuel the ship can use, probably also specify if ship can refuel at target.  
You might not see the ship land, But I assume liftoff and burn from orbit is visible. 

Ship will burn then dV requirement is less than its dV budget with say an 10% margin. 
Ship is still an real ship under AI control so you can take them over, probably except under trust as the game might fake a bit. 

Side note in Elder Scroll Oblivion you had multiple moving NPC who could be quest targets and you could see them moving on the map and could even follow them at foot. 
Same with traders in Fallout and the Khajiit caravans in Skyrim. But they was rarely visible on map but the idea is old and had some issues like the npc getting killed by monsters if near. 

Rigid body physic will not be active on remote ships or ships under warp in any way I assume.
I assume you will need to run the ship for some time before you can warp. 

Link to comment
Share on other sites

4 hours ago, poopslayer78 said:

As @Pthigrivimentioned, having to pay resources to add each new freighter to a delivery route

This could have some really cool implications. Later in the game you’re probably gonna want to save up on resources so that you can go interstellar. Something really interesting that the devs can do is make two engines/parts for more advanced stuff. One of them is expensive and inefficient but has very good performance. The other is cheap and efficient but it’s performance is poopoo.  This could vary up ship designs and make resources more important, especially in an environment like multiplayer.

Link to comment
Share on other sites

2 hours ago, BowlerHatGuy3 said:

This could have some really cool implications. Later in the game you’re probably gonna want to save up on resources so that you can go interstellar. Something really interesting that the devs can do is make two engines/parts for more advanced stuff. One of them is expensive and inefficient but has very good performance. The other is cheap and efficient but it’s performance is poopoo.  This could vary up ship designs and make resources more important, especially in an environment like multiplayer.

On the other hand you have more advanced tech, on the gripping hand do you want to use expensive to run orion pulse nuclear engines to  move uranium from Moho to Jool. 
Grabs tail but Moho is low on water outside the poles
Obviously  becoming an dyson swarm solves most energy problems. 
 

Link to comment
Share on other sites

7 hours ago, Xelo said:

Im wondering... ""realistically"" simply launching more vessels isn't always a good solution. After all, we dont send out a thousand cheap boats instead of one large expensive cargo ship, A mining company uses giant dump trucks instead of a thousand people with wheelbarrows; the limitation resides in not only the infrastructure of shipbuilding but also ports and the amount of operators. A tiny colony wont support 1000 mining rovers if the only drop-off is a dumpster taped to a ore converter and the vehicle bay can only hold a single car, or there's <1000 kerbals in the colony (ignoring automation), or even just the resource inefficiency of building 1000 low-payload rovers as opposed to just expanding the VAB and building fewer bigger rovers may put the notion off (something something the container's mass squared, the volume contained cubed).
I think it is definitely possible that there may be a cap on the amount of supply routes per colony, maybe dictated by population or infrastructure or both. This would encourage larger or more space-efficient vessels and prevent your lander turned moonbase from filling up with 1000Gt of rover ore deliveries before you've ended the 2nd kerbin week of the play-through.

I also do not think the possibility to send 10 of the same delivery route is encouragement of grind. Maybe a second or a third(?), but not to the point where it saps the fun out of the game. I would personally very much prioritize the construction of infrastructure for larger vessels before subjecting myself to any such grind, as time warp is always an option for the impatient.

While it good to discuss until there has been a bit of play through it's hard to know if potential problems will be real barriers. Still, Once you have flown a route the orbital mechanics of that route are known minimum spec's or a spec window for the route would be known. 2 factors seem critical thrust to weight and dV. I'd think they could if it proves to be an issue allow ship upgrades for a route. 

I'd think over time many would establish new infrastructure in the game that would make old routes redundant before they need distinct upgrades. ie an orbital parts workshop pulling some material from the surface of the body it orbits and some from the body your initial supply route was coming from. 

Link to comment
Share on other sites

I feel like it'll get pretty easily bottlenecked by limiting the number of supply routes, limiting the number of active freighters with your DSN reach, etc, and have it all be unlockable, so that late game there's no limit. But it does raise an interesting thought: if a shipping lane requires resource consumption to build the ships, and the planet doesn't contain that resource, will a supply network be limited by the supply network feeding it?

Alternatively, if the supply route is recorded...maybe they have to be reusable ships? so only fuel cost? So the only way to have a huge fleet is by repeatedly doing the route, or just doing it with bigger and bigger ships? Gives the option to cheese by grindiness, or progress and replace as new tech is available. But that wouldn't make much sense for getting out of atmospheres, since losing stages would immediately invalidate a supply run recording.

 

Link to comment
Share on other sites

17 hours ago, mattinoz said:

While it good to discuss until there has been a bit of play through it's hard to know if potential problems will be real barriers. Still, Once you have flown a route the orbital mechanics of that route are known minimum spec's or a spec window for the route would be known. 2 factors seem critical thrust to weight and dV. I'd think they could if it proves to be an issue allow ship upgrades for a route. 

I'd think over time many would establish new infrastructure in the game that would make old routes redundant before they need distinct upgrades. ie an orbital parts workshop pulling some material from the surface of the body it orbits and some from the body your initial supply route was coming from. 

Of course! But looking to realism does help for balance, as physical limitations already are 'balanced' in a sense? So having artifical limits (like supply route limits) inspired off of physical ones seems like a good place to start. I believe the original argument was along the lines of whats stopping you from just making a basic colony and clicking duplicate supply route indefinitely with a wheel attached to a mining drill and a chair.  Since we know population is based off some kind of milestone, it can be a way to limit supply routes based off progression. Another way would be the facilities to support supply routes like ports and storage and fuel production, forcing you to improve your colony and thus making tiny supply ships redundant in the process. The barriers don't have to be from emergent gameplay, otherwise the only real limitation would be cpu power:D 

Link to comment
Share on other sites

It will probably be an autopilot where the ship makes it’s own path that is the fastest, least dangerous, and least fuel consuming; the rocket will pop up on the map and when it is in a close enough proximity, and it will land/dock at it’s location.

Link to comment
Share on other sites

I think setting up deliveries on rails would be fine. Transport ships would leave when the launch windows come around. They would just have to get it to adjust its mid course correction to be correct as the inclinations change.

 

But whatever they do to set up the system, I really hope we will be able to see all our rovers and transports coming and going from our colonies and stations.

Link to comment
Share on other sites

3 hours ago, zeekzeek22 said:

I feel like it'll get pretty easily bottlenecked by limiting the number of supply routes, limiting the number of active freighters with your DSN reach, etc, and have it all be unlockable, so that late game there's no limit. But it does raise an interesting thought: if a shipping lane requires resource consumption to build the ships, and the planet doesn't contain that resource, will a supply network be limited by the supply network feeding it?

Alternatively, if the supply route is recorded...maybe they have to be reusable ships? so only fuel cost? So the only way to have a huge fleet is by repeatedly doing the route, or just doing it with bigger and bigger ships? Gives the option to cheese by grindiness, or progress and replace as new tech is available. But that wouldn't make much sense for getting out of atmospheres, since losing stages would immediately invalidate a supply run recording.

 

I say its pretty sure its has to be reusable ships.  And you will either has to refuel at target or have the dV to get back. 
Have an serious feeling resources in KSP will be pretty spread out. Fusion require helium 3 who can only be found in large quantities in Jool's atmosphere as an example. 

Link to comment
Share on other sites

4 hours ago, zeekzeek22 said:

I feel like it'll get pretty easily bottlenecked by limiting the number of supply routes, limiting the number of active freighters with your DSN reach, etc, and have it all be unlockable, so that late game there's no limit. But it does raise an interesting thought: if a shipping lane requires resource consumption to build the ships, and the planet doesn't contain that resource, will a supply network be limited by the supply network feeding it?

Alternatively, if the supply route is recorded...maybe they have to be reusable ships? so only fuel cost? So the only way to have a huge fleet is by repeatedly doing the route, or just doing it with bigger and bigger ships? Gives the option to cheese by grindiness, or progress and replace as new tech is available. But that wouldn't make much sense for getting out of atmospheres, since losing stages would immediately invalidate a supply run recording.

I think if it's a round trip you'd only have to pay to build the transport vessel once, but if it was one way you'd be assuming the vessel was built at the port of origin and recycled at its destination (probably at some loss). So in the latter case the resources that went into building the vessel would be part of the transfer, which might even be useful if what you're transporting is steel/metals. The same could be said for runs that spend stages along the way. So for instance if you had a uranium freighter that took off from Tylo, dropped a stage, delivered its cargo to a station above Laythe, refueled, then returned to the uranium outpost on Tylo you'd only pay for the vessel once, but the starting fuel, uranium, return fuel, and build-cost of the booster would be repeated each time. 

Edited by Pthigrivi
Link to comment
Share on other sites

With currency being out I think another important question is what stops the player from just shipping almost everything from Kerbin, where it is likely in unlimited quantity (excluding really rare materials). It doesn't seem like there would be a natural cap on expendable chemical rockets being produced Kerbin side.

Link to comment
Share on other sites

3 hours ago, MarcAbaddon said:

With currency being out I think another important question is what stops the player from just shipping almost everything from Kerbin, where it is likely in unlimited quantity (excluding really rare materials). It doesn't seem like there would be a natural cap on expendable chemical rockets being produced Kerbin side.

One limit would be the maximum size of the rocket you can build. It has already been confirmed that there will be hard limits on the rocket size build in the VAB. (Orbital VAB won't have size limits.) Another would be the amount of resources required. Building colonies will take massive amounts or resources. (They will be built on location, not landed.) Another could be a limited rate of resource production from the KSC. It may take a long time to get enough of a resource to even consider a launch. Another is just gravity. You can launch larger payloads from the Mun or Minmus than you can from Kerbin as they weigh less. Before I forget, interstellar travel is another reason not to send everything from Kerbin. It will take decades for it to arrive.

So there are plenty of reasons to build up colonies and not to launch everything from Kerbin.

Edited by shdwlrd
Typo
Link to comment
Share on other sites

22 hours ago, shdwlrd said:

One limit would be the maximum size of the rocket you can build. It has already been confirmed that there will be hard limits on the rocket size build in the VAB. (Orbital VAB won't have size limits.) Another would be the amount of resources required. Building colonies will take massive amounts or resources. (They will be built on location, not landed.) Another could be a limited rate of resource production from the KSC. It may take a long time to get enough of a resource to even consider a launch. Another is just gravity. You can launch larger payloads from the Mun or Minmus than you can from Kerbin as they weigh less. Before I forget, interstellar travel is another reason not to send everything from Kerbin. It will take decades for it to arrive.

So there are plenty of reasons to build up colonies and not to launch everything from Kerbin.

Remember that colonies comes before resources, so in the start everything has to be sent from Kerbin. 
I assume the best way in that phase is to build an colony in LKO have one or more space planes who transfer resources to it by the station and then have spaceship who bring it outward to other colonies under construction. 

Have an feeling that after we get resources colonies will have different levels, first level is just an place to stay, next level is mining and creating fuel and oxidizer.  Next level is to mine and create basic colony parts. 
Then you expand so you can produce rockets and more advanced stuff like more advanced fuels. 
Parts also have resource cost so you need the resources to build them, reactors require uranium.  I have an feeling we also get manufactured part something like colony building materials you skip to the colony to start building it.  Another question is if you can move an orbital colony simply by adding fuel tanks and engines to it. 
 

Link to comment
Share on other sites

5 minutes ago, magnemoe said:

Remember that colonies comes before resources, so in the start everything has to be sent from Kerbin. 
I assume the best way in that phase is to build an colony in LKO have one or more space planes who transfer resources to it by the station and then have spaceship who bring it outward to other colonies under construction.

It's easy to assume that the everything has to come from Kerbin, but what if there's just a mechanism that generates required resources magically over time? Once the Resource Update is there, that mechanism is removed. Kinda like how you have all tech at hand in sandbox but not in career.

Link to comment
Share on other sites

20 hours ago, Kerbart said:

It's easy to assume that the everything has to come from Kerbin, but what if there's just a mechanism that generates required resources magically over time? Once the Resource Update is there, that mechanism is removed. Kinda like how you have all tech at hand in sandbox but not in career.

Or that resources has to be moved from Kerbin.  Hover resources milestone is resources replaces money.
Now I'm not sure how we transport stuff to build colonies. I suspect colony modules can be flat packed, or is it an construction part resource?

Link to comment
Share on other sites

×
×
  • Create New...