My vote is for that rotor method, just for the ease of alignment. I'm curious if when you complete the space elevator, what would happen to the grids if you use merge blocks to join all 3 20-km sections into one grid? Will something like a coordinate precision error mess with the game b/c the engine can't reliably calculate the location of the blocks on the ends of the grid? (I assume this is why the 20-km grid dimension limit exists in the first place) Another question: Are all PCU created equally? i.e. Are 125 armor blocks equal to 1 connector, or 100 armor equal to 1 rotor, in actual CPU/RAM resource usage? What about 1 light armor vs 1 heavy armor vs 1 interior wall? We already know for sure that static grids/stations are more performance friendly than free-floating grids. And I've seen someone mentioned ages ago that interior blocks and unfinished armor blocks use more resources b/c they have higher polygon count or details (emissive lights on the interior walls) than plain finished armor blocks. My guess is that SE PCU are just a simplified estimate of resource usage. I was thinking of ways to "Wal-Mart" the space elevator, cutting corners down to a minimum of PCU per layer, while still keeping it robust enough to not disintegrate just b/c of drunk engineer flying. Maybe a 1x3 layout of 1 armored conveyor between two heavy armor blocks, as a minimum? Or for enough angle to provide some inherent elevator platform stabilization, add a 3rd heavy armor block on the back side of the armored conveyor, creating a T-shape. That would be 13 PCU per layer, instead of the current 34 PCU. At 12,000 layers for 60 km height, that's a difference of 252k PCU (156k vs 408k). We know the SE engine can handle 156k PCU, esp as a static grid. I suspect 408k PCU may be ... challenging. :D (Obviously a single conveyor tower (for potential connector construction and access on the way up) or single armor block tower (for absolute cheapest PCU) would be the logically cheapest extreme, but highly vulnerable to accidents. Second runner up for cheapest PCU would be a single (heavy) armor block with (armored) conveyor attached to one side, but any piloting mistake would have a 50% chance of destroying the conveyor line and probably disrupt the elevator platform's stability.) For survival resource consumption, heavy armor uses 6x more steel plates plus metal grids, but has about 6.5x integrity of light armor. The metal grids are optional, and can be left out to save on cobalt for only a minor loss in integrity (something like 10%?). Overall, a heavy armor T-shape would save about 25% in steel plates versus your current PP 3-tower design. Kind of curious whether a ship could time-efficiently prefab 100m or even 1km sections of the tower, then lift them into place and merge them? Applying the same cost-cutting process to the elevator platform and construction rig, I'm sure you had to really experiment with multiple redundant landing gears and wheels in order to achieve enough stability for the platform and rig to consistently maintain alignment. My T-shape elevator shaft has a much smaller length and width, providing less leverage for the rig/platform to stabilize themselves horizontally compared to your setup. I'd have to try a more vertically stabilized build with outriggers above/below the main mass of the rig/platform. There physically isn't enough room to use the same number of landing gears and wheels as you did, for a single layer rig/platform, but I'd have to maybe double it at least if using one or more vertical outriggers to stabilize the grid's alignment to the tower. If total platform mass could be kept low, back-up H2 thrusters might not be necessary. On this point, I think Andrew Man Gaming tried out some wheel-only elevator platforms, and found that their friction quickly failed when he put a full sized large grid spaceship on the platform. It'd be interesting to see how much mass can be lifted per 100% friction 3x3 or 5x5 large grid wheel, how badly suspension strength and wheels phasing into the elevator shaft will incur Clang's wrath, etc. Landing gears would be the most reliable anchor, but your point about landing gear and piston inchworm drive is quite clear -- that would take FOREVER to ascend the space elevator. Plus lifting a large spaceship using pistons feels risky due to off-axis forces, unless the load can be centered very close to the elevator shaft. I'm guessing a payload of a few hundred tons will be easy for most sensible platform designs. Maybe even 1k to 2k tons. But 10k to 20k ton ships are going to be a challenge. Kinda makes sense, the way sci-fi often depicts larger ships as being 0g-bound and requiring smaller shuttlecraft (or space elevators) to ferry cargo and supplies in and out of the gravity well. In SE game economy terms, I wonder how many trips on a space elevator would be needed to break even on the initial player time cost spent building it? :D As compared to building/collecting the H2 or battery power infrastructure to pay for normal large grid ships to fly from surface to 0g. For this reason, I'm looking forward to your future experiments with maximum payload mass with the space elevator platform! I know people played around with space elevators years ago when planets were first introduced, but the engine has changed a lot since then. It's cool to see you revisiting the idea at this point in the SE engine's development. So many questions from watching your videos. I've taken a break from SE for a while. This is giving me the itch to get back to it and try to answer my own questions, using your tips!
Great piece of engineering 👏 I would like to see a construction-machine automatically building the rotors-connection every one kilometer of height. This construction-machinery should also automatically fill it's build-resources, means, it should connect at every stop of the lower crawling part at a connector to be able to suck resources from ground base unattended (no need to manually fly or atach resources to the welders).
Hi, the rotor/piston/hinge/connector/merge block are very good solution to solve this problem, landing gear solution can't pass through any energy to other grids. For my part I prefer the solution of fusion blocks, to keep away "Clang", which can be used once the project is finished. I also think the fastest and Clangless solution will be to use connectors. Anyway very nice job 😉.
*Edit: Posted this comment only halfway through the video Welp, buildlimit hit, this may impact you not only in space, but also in your base. have your tried building below the tower to see? Three methods i would personally apply: 1. instead of connectors, a hinge will give you a subgrid that is perfectly centered, just set its limits to 0 2. Have blocks facing into eachother that do not merge, you can make pretty nice inward shapes, this is in the event you end up merging a grid that is past its limits with another grid, i dont really know what would happen 3. Convert the second subgrid to a station in the K menu. (Also, using voxel hands to place a voxel piece that they can attach to be static would probably work well. you can see an example of this concept in any valheim build tutorial that builds towers far above build height, they spawn a floating rock that the grids will hang on to. As you are limited by the game engine, i wouldnt look at it as unfair to spawn a voxel as you are using the game engine to fix its limitations in the "safest" way possible
I would like to see a wheel-driven elevator rushing up and down the construction really fast. Not more than two minutes drive-time from bottom to top. Wheels on rotors do not have suspensions and therefore they hopefully do not wobble. I would use rotor-attached wheels to prevent wobble and suspension-attached wheels to gain speeds.
when merge blocks dont turn yellow or green, the grid needs an update, place a block and remove a block on one or both grids and it should work fine everytime. this is only an issue on static grids or grids that are perfectly still (locked via landing gear)
Is there an issue with clang when attaching two grids with the rotor-method. How bad would clang become when you try to build a rotor-method-connection every one kilometers?
Wait.... you can build a base 20km in any direction? Were building on the side of a mountain and I was worried about the fact the stairs were going 800 meters from the base lol Also I note the device you have appears to have made the blocks as it went up? is that right and if so how? (digging a tunnel I am using piston, piston drill... then grind it down and do it again further on, if i had it make a road as it moves it cold be a rover and keep level..? or the holo blocks a mod?
Pandemic Playground previously built a template tower of blocks, blueprinted it, and is now using a projector to project that tower blueprint. That's the holographic image you're seeing. You can look back in his previous episodes of this series to see details of the timer block welder rig. Basically, it's two frames, each of which uses multiple landing gears to lock onto all three towers. A piston connects the two frames. Timer blocks coordinate the locking and unlocking of the landing gear sets on each frame with the piston reversing, on each cycle. There is also a set of welders on the lower frame to build a projection of a conveyor pipe in the middle. Periodically, PP manually builds a connector on the conveyor, and lowers a connector on the frame to connect and refill the frames' cargo container with components for building the tower and conveyor pipe.
@@PandemicPlayground Ah yeah, of course, but i guess once its all finished, you should be able to, but then again, im not sure if SE would like you doing that, i can imagine it will probably lag for a long while or even crash
That was very instructive. Thank's for the Tipps! ☝😀
My vote is for that rotor method, just for the ease of alignment. I'm curious if when you complete the space elevator, what would happen to the grids if you use merge blocks to join all 3 20-km sections into one grid? Will something like a coordinate precision error mess with the game b/c the engine can't reliably calculate the location of the blocks on the ends of the grid? (I assume this is why the 20-km grid dimension limit exists in the first place)
Another question: Are all PCU created equally? i.e. Are 125 armor blocks equal to 1 connector, or 100 armor equal to 1 rotor, in actual CPU/RAM resource usage? What about 1 light armor vs 1 heavy armor vs 1 interior wall?
We already know for sure that static grids/stations are more performance friendly than free-floating grids. And I've seen someone mentioned ages ago that interior blocks and unfinished armor blocks use more resources b/c they have higher polygon count or details (emissive lights on the interior walls) than plain finished armor blocks. My guess is that SE PCU are just a simplified estimate of resource usage.
I was thinking of ways to "Wal-Mart" the space elevator, cutting corners down to a minimum of PCU per layer, while still keeping it robust enough to not disintegrate just b/c of drunk engineer flying.
Maybe a 1x3 layout of 1 armored conveyor between two heavy armor blocks, as a minimum? Or for enough angle to provide some inherent elevator platform stabilization, add a 3rd heavy armor block on the back side of the armored conveyor, creating a T-shape. That would be 13 PCU per layer, instead of the current 34 PCU. At 12,000 layers for 60 km height, that's a difference of 252k PCU (156k vs 408k). We know the SE engine can handle 156k PCU, esp as a static grid. I suspect 408k PCU may be ... challenging. :D
(Obviously a single conveyor tower (for potential connector construction and access on the way up) or single armor block tower (for absolute cheapest PCU) would be the logically cheapest extreme, but highly vulnerable to accidents. Second runner up for cheapest PCU would be a single (heavy) armor block with (armored) conveyor attached to one side, but any piloting mistake would have a 50% chance of destroying the conveyor line and probably disrupt the elevator platform's stability.)
For survival resource consumption, heavy armor uses 6x more steel plates plus metal grids, but has about 6.5x integrity of light armor. The metal grids are optional, and can be left out to save on cobalt for only a minor loss in integrity (something like 10%?). Overall, a heavy armor T-shape would save about 25% in steel plates versus your current PP 3-tower design.
Kind of curious whether a ship could time-efficiently prefab 100m or even 1km sections of the tower, then lift them into place and merge them?
Applying the same cost-cutting process to the elevator platform and construction rig, I'm sure you had to really experiment with multiple redundant landing gears and wheels in order to achieve enough stability for the platform and rig to consistently maintain alignment.
My T-shape elevator shaft has a much smaller length and width, providing less leverage for the rig/platform to stabilize themselves horizontally compared to your setup. I'd have to try a more vertically stabilized build with outriggers above/below the main mass of the rig/platform. There physically isn't enough room to use the same number of landing gears and wheels as you did, for a single layer rig/platform, but I'd have to maybe double it at least if using one or more vertical outriggers to stabilize the grid's alignment to the tower. If total platform mass could be kept low, back-up H2 thrusters might not be necessary. On this point, I think Andrew Man Gaming tried out some wheel-only elevator platforms, and found that their friction quickly failed when he put a full sized large grid spaceship on the platform. It'd be interesting to see how much mass can be lifted per 100% friction 3x3 or 5x5 large grid wheel, how badly suspension strength and wheels phasing into the elevator shaft will incur Clang's wrath, etc.
Landing gears would be the most reliable anchor, but your point about landing gear and piston inchworm drive is quite clear -- that would take FOREVER to ascend the space elevator. Plus lifting a large spaceship using pistons feels risky due to off-axis forces, unless the load can be centered very close to the elevator shaft.
I'm guessing a payload of a few hundred tons will be easy for most sensible platform designs. Maybe even 1k to 2k tons. But 10k to 20k ton ships are going to be a challenge. Kinda makes sense, the way sci-fi often depicts larger ships as being 0g-bound and requiring smaller shuttlecraft (or space elevators) to ferry cargo and supplies in and out of the gravity well. In SE game economy terms, I wonder how many trips on a space elevator would be needed to break even on the initial player time cost spent building it? :D As compared to building/collecting the H2 or battery power infrastructure to pay for normal large grid ships to fly from surface to 0g.
For this reason, I'm looking forward to your future experiments with maximum payload mass with the space elevator platform!
I know people played around with space elevators years ago when planets were first introduced, but the engine has changed a lot since then. It's cool to see you revisiting the idea at this point in the SE engine's development.
So many questions from watching your videos. I've taken a break from SE for a while. This is giving me the itch to get back to it and try to answer my own questions, using your tips!
Great piece of engineering 👏
I would like to see a construction-machine automatically building the rotors-connection every one kilometer of height. This construction-machinery should also automatically fill it's build-resources, means, it should connect at every stop of the lower crawling part at a connector to be able to suck resources from ground base unattended (no need to manually fly or atach resources to the welders).
Hi, the rotor/piston/hinge/connector/merge block are very good solution to solve this problem, landing gear solution can't pass through any energy to other grids.
For my part I prefer the solution of fusion blocks, to keep away "Clang", which can be used once the project is finished. I also think the fastest and Clangless solution will be to use connectors. Anyway very nice job 😉.
*Edit: Posted this comment only halfway through the video
Welp, buildlimit hit, this may impact you not only in space, but also in your base. have your tried building below the tower to see?
Three methods i would personally apply:
1. instead of connectors, a hinge will give you a subgrid that is perfectly centered, just set its limits to 0
2. Have blocks facing into eachother that do not merge, you can make pretty nice inward shapes, this is in the event you end up merging a grid that is past its limits with another grid, i dont really know what would happen
3. Convert the second subgrid to a station in the K menu. (Also, using voxel hands to place a voxel piece that they can attach to be static would probably work well. you can see an example of this concept in any valheim build tutorial that builds towers far above build height, they spawn a floating rock that the grids will hang on to.
As you are limited by the game engine, i wouldnt look at it as unfair to spawn a voxel as you are using the game engine to fix its limitations in the "safest" way possible
I would like to see a wheel-driven elevator rushing up and down the construction really fast. Not more than two minutes drive-time from bottom to top. Wheels on rotors do not have suspensions and therefore they hopefully do not wobble. I would use rotor-attached wheels to prevent wobble and suspension-attached wheels to gain speeds.
when merge blocks dont turn yellow or green, the grid needs an update, place a block and remove a block on one or both grids and it should work fine everytime. this is only an issue on static grids or grids that are perfectly still (locked via landing gear)
Is there an issue with clang when attaching two grids with the rotor-method.
How bad would clang become when you try to build a rotor-method-connection every one kilometers?
the rotor or the hinge are the way to go for aligning them up perfectly.
merge blocks
Nice one!
Wait.... you can build a base 20km in any direction?
Were building on the side of a mountain and I was worried about the fact the stairs were going 800 meters from the base lol
Also I note the device you have appears to have made the blocks as it went up? is that right and if so how?
(digging a tunnel I am using piston, piston drill... then grind it down and do it again further on, if i had it make a road as it moves it cold be a rover and keep level..? or the holo blocks a mod?
Pandemic Playground previously built a template tower of blocks, blueprinted it, and is now using a projector to project that tower blueprint. That's the holographic image you're seeing.
You can look back in his previous episodes of this series to see details of the timer block welder rig. Basically, it's two frames, each of which uses multiple landing gears to lock onto all three towers. A piston connects the two frames. Timer blocks coordinate the locking and unlocking of the landing gear sets on each frame with the piston reversing, on each cycle.
There is also a set of welders on the lower frame to build a projection of a conveyor pipe in the middle.
Periodically, PP manually builds a connector on the conveyor, and lowers a connector on the frame to connect and refill the frames' cargo container with components for building the tower and conveyor pipe.
advanced rotor offset -20cm is flush
Watched and 👍 Liked
Would you be able to to later attach it with a merge block?
I do believe so, but you will then create a new limit at the very top.
@@PandemicPlayground Ah yeah, of course, but i guess once its all finished, you should be able to, but then again, im not sure if SE would like you doing that, i can imagine it will probably lag for a long while or even crash
I can always give it a go once i hit about 43km.
Is there a blueprint in the work shop for your elevator?
I will put it in the workshop once I am done with the build.
How do you do the build limit
Ok. So a redesign into stackable, printable 15 km sections
Dave!
hmm, das sie da nach aus das, die Baugrenze bei 8192 Blöcke ist.
There is a height limit??? 😂
Edit: spelling