GTNewHorizons / GT-New-Horizons-Modpack

New Modpack with Gregtech, Thaumcraft and Witchery
https://www.gtnewhorizons.com/
Other
966 stars 298 forks source link

[RFC] Dyson Swarm Ground Unit Balance & Recipes #8577

Closed glowredman closed 2 years ago

glowredman commented 3 years ago

Your GTNH Discord Username

glowredman#1337

Your Pack Version

2.1.1.0 with updated BW, Forestry, GC, GT, GT++, TT and StructureLib

Your Proposal

This PR adds the "Dyson Swarm Ground Unit", an energy-generating multiblock designed for the endgame (post plasma-gen / T3 fusion). You can find the newest build on Jenkins

Functionality:

Example setup with LSC: grafik grafik

Ingame Description: grafik grafik

Scanning Result: grafik

TODO:

Your Goal

Currently, the last endgame power solution is T3 Fusion with Plasma Gens. If you need more energy, you have to build more of them. This gets very tedious very fast and is not TPS-friendly at all. This multi tries to solve this while being not as boring as a Octuple Compressed Solar Panel.

Your Vision

Final Checklist

Houstonruss commented 3 years ago

How many modules can one of these use?

glowredman commented 3 years ago

11264 (up to 11 Input Busses with up to 16 slots each)

Houstonruss commented 3 years ago

6bill eu/t is kinda ridiculous. That's about 3k infinity tin plasma turbines and ~400 Mk3 reactors worth of energy. All in a tiny multi...

How can this be more performance friendly if you're still gonna be autocrafting the components and mining all the materials?

For plasma, you only need infinity catalyst, cosmic, stars, and diamond, and Helium3. All pumped from the ground with not much processing.

This is still a solar panel at heart, and I'm not sure anyone can make solar 'work'.

GlodBlock commented 3 years ago

it seems that every model's expectation eu output is 1048576000eu. it is a bit low tbh

glowredman commented 3 years ago

The energy per module is not decided yet, that is one of this RFC's goals

Houstonruss commented 3 years ago

it seems that every model's expectation eu output is 1048576000eu. it is a bit low tbh

Yeah this makes it a pita because you can't just let people spam low tier machines to save energy.

GlodBlock commented 3 years ago

a tin plasma cell contains 304496000eu iirc, at least the whole eu output should be more than 100 or even 1k tin plasma cells. change the break possibility to 0.1% or 0.01% will be more reasonable

Alexdoru commented 3 years ago

what's the recipes for the modules ? should it cost rocket fuel to launch a new module into orbit ? does it work at night time ? (it shouldn't)

Currently, the last endgame power solution is T3 Fusion with Plasma Gens.

there is the naquadah reactor thing now

This multi tries to solve this while being not as boring as a Octuple Compressed Solar Panel.

instead of crafting solar panels we consume modules now?

Houstonruss commented 3 years ago

Bot is suggesting atttrition: more in the swarm, more collisions, more loss

glowredman commented 3 years ago

what's the recipes for the modules ?

Not decided yet. You can help comming up with recipes though if you want.

should it cost rocket fuel to launch a new module into orbit ?

No but a constant supply of coolant is needed (within the lore of this multi, the modules are launched into space via magnet acceleration)

does it work at night time ? (it shouldn't)

It does (it should, daycycles only exist on a planetary level, not on a system level)

there is the naquadah reactor thing now

That is true and must be taken into consideration when discussing about this. I personally have not informed myself about it yet though.

instead of crafting solar panels we consume modules now?

You can still craft Solar Panels if you want.

Bot is suggesting atttrition: more in the swarm, more collisions, more loss

If the general consensus agrees, it is probably quite easy to change

Alexdoru commented 3 years ago

No but a constant supply of coolant is needed (within the lore of this multi, the modules are launched into space via magnet acceleration)

From my understanding of a dyson sphere, there are lots of modules into space orbiting around a star. The modules are basically big mirrors and they reflect light towards a single point on earth, so if it's night time you can't see the star = no power

Houstonruss commented 3 years ago

No but a constant supply of coolant is needed (within the lore of this multi, the modules are launched into space via magnet acceleration)

From my understanding of a dyson sphere, there are lots of modules into space orbiting around a star. The modules are basically big mirrors and they reflect light towards a single point on earth, so if it's night time you can't see the star = no power

You absolute buffoon! It is always daytime on the official servers :D

Maybe you need a second swarm in orbit for night power.

Alexdoru commented 3 years ago

the modules are launched into space via magnet acceleration

what's the energy cost of doing such a thing ? is there a magnetic canon multi that does the launching ? (is it what's on the pic but you didn't explain it in your post description ?)

GlodBlock commented 3 years ago

i believe it is some kind of compromise of technical limitations in code.

glowredman commented 3 years ago

the modules are launched into space via magnet acceleration

what's the energy cost of doing such a thing ? is there a magnetic canon multi that does the launching ? (is it what's on the pic but you didn't explain it in your post description ?)

I did not implement any detection of "an item has been inserted, output x EU less on the next tick", as such there is no cost attached to inserting modules. On the second picture, the bottom left structure is designed for this.

glowredman commented 3 years ago

i believe it is some kind of compromise of technical limitations in code.

Not directly, it would be possible for sure but at the expense of tick time

Alexdoru commented 3 years ago

does it work at night time ? (it shouldn't)

It does (it should, daycycles only exist on a planetary level, not on a system level)

How does the energy gets back to earth when it is night then, according to my master level calculations it doesn't work image

GTNH-Afx237v7 commented 3 years ago

I bet a civilization smart enough to design and build a working dison sphere has multiple receivers on their homeplanet so regardless of day/night cycle they can harvest the energy

Methes commented 3 years ago

Or in the orbit...

Pxx500 commented 3 years ago

Or in the orbit...

There shoud be a multiblock for that, until you craft it no energy at night

Phineasor commented 3 years ago

Or in the orbit...

There shoud be a multiblock for that, until you craft it no energy at night

A dyson swarm works (hopefully this is how this one is implemented), by reflecting light from the sun on mirrors. The mirrors would be a thin reflective foil of some cheap, easy to mass produce material, which you would make into satellites about a square kilometer in area, then fold them up to launch them into the sun's orbit. These satellites would use some type of ion thruster to keep it pointed in the correct orientation, in order to reflect the light from low solar orbits towards other satellites in solar orbit. This way, you can deploy a small amount of larger "focal point" or "collector" satellites, which collect the power from about 1-2 million of our small foil satellites (or however much power you can pump into it), which will merge the collected power into a beam that is sent to your receiver.

A common problem brought up is the case where the receiver is not in the direct view of a collector satellite (such as when it is nighttime), which can disrupt the energy transmission. However, there is a way you can get around this. By using these same larger satellites, which, in this case, are repurposed to redirect the energy transmitted towards another direction (sort of like an active transformer + TT lasers combo). These satellites will operate at a low orbit on whatever planet your receiver is located, which, when used correctly, will allow you to "bend" the light around the planet, therefore allowing a connection between your collector(s) and receiver. Unfortunately, one side effect of this is that transmitting the energy from the Dyson swarm through the atmosphere will potentially be dense enough to turn the atmosphere into a plasma (not good), so you would have to either tweak this method, or use another means of delivering power to the destination planet.

Note: An actual Dyson swarm like this would require MILLIONS of satellites deployed, which is far beyond the maximum 11,264 that the multiblock can use. One solution would be to have the multiblock actually consume the satellites instead of storing them in buses directly, and to have it keep track of however many it has used.

You also need to be careful to not melt the foil.

basdxz commented 3 years ago

Or in the orbit...

There shoud be a multiblock for that, until you craft it no energy at night

A dyson swarm works (hopefully this is how this one is implemented), by reflecting light from the sun on mirrors. The mirrors would be a thin reflective foil of some cheap, easy to mass produce material, which you would make into satellites about a square kilometer in area, then fold them up to launch them into the sun's orbit. These satellites would use some type of ion thruster to keep it pointed in the correct orientation, in order to reflect the light from low solar orbits towards other satellites in solar orbit. This way, you can deploy a small amount of larger "focal point" or "collector" satellites, which collect the power from about 1-2 million of our small foil satellites (or however much power you can pump into it), which will merge the collected power into a beam that is sent to your receiver.

A common problem brought up is the case where the receiver is not in the direct view of a collector satellite (such as when it is nighttime), which can disrupt the energy transmission. However, there is a way you can get around this. By using these same larger satellites, which, in this case, are repurposed to redirect the energy transmitted towards another direction (sort of like an active transformer + TT lasers combo). These satellites will operate at a low orbit on whatever planet your receiver is located, which, when used correctly, will allow you to "bend" the light around the planet, therefore allowing a connection between your collector(s) and receiver. Unfortunately, one side effect of this is that transmitting the energy from the Dyson swarm through the atmosphere will potentially be dense enough to turn the atmosphere into a plasma (not good), so you would have to either tweak this method, or use another means of delivering power to the destination planet.

Note: An actual Dyson swarm like this would require MILLIONS of satellites deployed, which is far beyond the maximum 11,264 that the multiblock can use. One solution would be to have the multiblock actually consume the satellites instead of storing them in buses directly, and to have it keep track of however many it has used.

You also need to be careful to not melt the foil.

Oh if the reciver is on the ground, there is no way you wouldn't have a solid columbn of plasma shooting across the sky. Which would be incredibly hot, bright and loud.

Phineasor commented 3 years ago

Or in the orbit...

There shoud be a multiblock for that, until you craft it no energy at night

A dyson swarm works (hopefully this is how this one is implemented), by reflecting light from the sun on mirrors. The mirrors would be a thin reflective foil of some cheap, easy to mass produce material, which you would make into satellites about a square kilometer in area, then fold them up to launch them into the sun's orbit. These satellites would use some type of ion thruster to keep it pointed in the correct orientation, in order to reflect the light from low solar orbits towards other satellites in solar orbit. This way, you can deploy a small amount of larger "focal point" or "collector" satellites, which collect the power from about 1-2 million of our small foil satellites (or however much power you can pump into it), which will merge the collected power into a beam that is sent to your receiver. A common problem brought up is the case where the receiver is not in the direct view of a collector satellite (such as when it is nighttime), which can disrupt the energy transmission. However, there is a way you can get around this. By using these same larger satellites, which, in this case, are repurposed to redirect the energy transmitted towards another direction (sort of like an active transformer + TT lasers combo). These satellites will operate at a low orbit on whatever planet your receiver is located, which, when used correctly, will allow you to "bend" the light around the planet, therefore allowing a connection between your collector(s) and receiver. Unfortunately, one side effect of this is that transmitting the energy from the Dyson swarm through the atmosphere will potentially be dense enough to turn the atmosphere into a plasma (not good), so you would have to either tweak this method, or use another means of delivering power to the destination planet. Note: An actual Dyson swarm like this would require MILLIONS of satellites deployed, which is far beyond the maximum 11,264 that the multiblock can use. One solution would be to have the multiblock actually consume the satellites instead of storing them in buses directly, and to have it keep track of however many it has used. You also need to be careful to not melt the foil.

Oh if the reciver is on the ground, there is no way you wouldn't have a solid columbn of plasma shooting across the sky. Which would be incredibly hot, bright and loud.

yes, the power of a Dyson swarm will make anything a plasma. hence why I said that you prob would want a space elevator to get it back to the ground, you can at this point move the power with some CHONKY cables

Or rather, convert the photons into a specific microwave frequency that would not interact with the atmosphere and be collected on the planet.

glowredman commented 2 years ago

A summary of what has been posted so far and what I think is important:

The other points I mentioned in my original comment still have to be commented on, so pleas do so.

Steelux8 commented 2 years ago

Would it be feasible to implement a section of the "Ground Unit" that would need to be Y=150 or even higher, and directly above the structure at ground level, and then connect the two with a column that would also bring the power down from the sky?

glowredman commented 2 years ago

Probably, though I think it would limit the creative (building) choices of the player less, if they can decide themselves how/if at all they want to transfer the energy down. For example players with a sky base may not want to have to transfer the energy down only to transfer it up again

Savallator commented 2 years ago

I would suggest having the swarm satellites stored inside the Unit. They don't need to be retrievable anyways. For sky bases, it could work like this: Upper part (Dyson energy focus) needs to be very high (maybe >200), and then the other part (dysan swarm controller) can be anywere below that. That can be y=150 for a skybase, or y=60 for a normal base. Both parts could maybe be connected by fiber cables for data transfer. Then, just make it have an energy hatch and let it consume energy for the launching (to make it easier, maybe just an average eu/t). the launch energy could depend on the number of satellites present, because at some point they would need to be launched to higher orbits, thus needing more energy to launch. Also, to make it more interesting, maybe have it so that it can only launch a (low) number of satellites by itself, and to controll any more it needs a Quantum computer connected to it with increasing computation depending on number of satellites. Would make a lot of sense for trajectory calculation (which is actually very complex in real life as well), and give the QC another use (the research station has limited uses anyways - at one point everything is done there).

For visuals, at first it could just show a beam like the beacon does (ir like the MFR void drills used to do), and if there is someone bored who has graphic skills, it could even show some kind of large, visually fluctuating beam.

0lafe commented 2 years ago

this seems like complexity better suited towards an Ev-LuV solar option, no? seems hard to balance the cost of the modules being lost.

craft items in -> lots of power out?

could do something like large fluctuations in power output, with a very noticeable power cost needed to transfer that power. like outputs 1A UV - 1A OpV, but needs to be given at least 1/3 the power to keep running. would make players adjust power sent based on power received, or risk the machine shutting off (voiding modules with not enough power or blowing up receiver) or loosing power (sending the max needed all the time)

would be easier to have the modules at a decent cost while still making the multi complex to use

Steelux8 commented 2 years ago

It would be very hard to code a realistic Dyson Sphere, but, the way I see it, it should function as the most advanced kind of solar panel, and the modules should be very expensive and only pay off after some time, but then they keep working after that, save for the occasional destruction from something crashing onto them.

I do agree that computation power should be needed to build a tight grid and take the full advantage of the Dyson Swarm. Since the new naquadah line is pretty stable in the latest dev version, I think the "cost" of making this setup should be similar, but done differently. Building several multis to bring the power down, inputting materials to build the modules, and computation power to calculate the grid and launches.

glowredman commented 2 years ago

Agree. I already implemented the internal storage of modules (should benefit performance too). I'm currently implementing the computation cost and have the formula computationCost = moduleCount * computationPerModule. What would be an appropriate computationPerModule value or do you think it should be calculated differently?

Also, I changed the destruction formula to tile.moduleCount -= (int) (getRandom() * GSConfigCore.destroyModuleChance * Math.pow(tile.moduleCount, 1.05));. Thoughts?

I don't want to change the structure at this point nor implement some sort of launch cost.

Savallator commented 2 years ago

this seems like complexity better suited towards an Ev-LuV solar option, no? seems hard to balance the cost of the modules being lost.

craft items in -> lots of power out?

could do something like large fluctuations in power output, with a very noticeable power cost needed to transfer that power. like outputs 1A UV - 1A OpV, but needs to be given at least 1/3 the power to keep running. would make players adjust power sent based on power received, or risk the machine shutting off (voiding modules with not enough power or blowing up receiver) or loosing power (sending the max needed all the time)

would be easier to have the modules at a decent cost while still making the multi complex to use

We really don't need more EV-LuV power options... there are so many already. What we need is competetive endgame power that is not just spamming solars, and this could be a nice alternative to the Nq Reactor.

Agree. I already implemented the internal storage of modules (should benefit performance too). I'm currently implementing the computation cost and have the formula computationCost = moduleCount * computationPerModule. What would be an appropriate computationPerModule value or do you think it should be calculated differently?

Also, I changed the destruction formula to tile.moduleCount -= (int) (getRandom() * GSConfigCore.destroyModuleChance * Math.pow(tile.moduleCount, 1.05));. Thoughts?

I don't want to change the structure at this point nor implement some sort of launch cost.

The computation question should boil down to the scaling of Computation vs generated EU. I have lost track of the EU formula, but imho it should not scale linear. Also, i would consider to have a base computation so that the multi can be used without QC attached, just with low energy output. Another point would be to have a way to keep it from exploding when new modules are added automatically. With the proposed Sstate, people would need like an OC script to keep track of the modules and stop inserting before it will generate too much power for the hatches. Maybe make it so that it won't add new modules when the dynamo hatch is at full capacity, or computation is missing, but instead voids them? That way it would not leave a giant crater if you don't, but you would still want to automate it.

Steelux8 commented 2 years ago

Also, i would consider to have a base computation so that the multi can be used without QC attached, just with low energy output.

Instead of this, either setup should be able to send out the same amount of modules, but the amount of computation reduces the speed at which modules are lost, since being unable to calculate perfect orbits for all new modules would mean some crash into others. More computation would mean less losses, down to a minimum loss rate caused by unrelated objects hitting the modules. I don't know how the formula would be for this, and I'm nowhere near endgame so I can't make balance suggestions.

glowredman commented 2 years ago

I like that idea, but I can't come up with a formula either

Savallator commented 2 years ago

How much computation does a reasonable endgame QC setup put out?

Steelux8 commented 2 years ago

This needs feedback from endgame players to bring forth actual values for balance. One of the ideas I have is to make the computation cost jump up at specific amounts of modules, to represent different orbit distances to the sun, and also as a way to limit the amount of modules lategame players can have based on their computation capacity. As an example, it could start with 1000 modules scaling linearly in cost per new module and then jump to 10x that per module up to 10000 modules, and so on. This way, there's a progression to this powergen while also pushing away the need to add more laggy infrastructure: all the additional resources are put into the same multi and generate more power once the computation requirements are met.

GDCloudstrike commented 2 years ago

How much computation does a reasonable endgame QC setup put out?

My 24 Rack stable QCs use 25 Amps of UV while running and produce 2160 Computation per, but it might be possible to get more out of them

yukieiji commented 2 years ago

The color of UHV Super Conductor Frame has changed(v2.1.2.0Pre3), so the appearance has changed, but is there a problem?

glowredman commented 2 years ago

I toyed a bit around in GeoGebra and this is what I came up with (green function, blue one is linear growth for reference): grafik x is amount of modules, y is computation required. a, b, c will be configurable of course.

glowredman commented 2 years ago

The PR is now finished, you can get the jar on Jenkins.

What has to be done now:

  1. Review the PR
  2. Balancing
  3. Recipes

It may be required to discuss the targeted tier before working on points 2 and 3.

The color of UHV Super Conductor Frame has changed(v2.1.2.0Pre3), so the appearance has changed, but is there a problem?

I looked at it ingame and decided it looks good enough for me to not care about. If someone wants to change it, I would appreciate it though.

github-actions[bot] commented 2 years ago

This issue has been FixedInDev for quite a while and nobody commented in 7 days. Remove FixedInDev label or comment or this will be closed in 1 days