Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Smarter blueprint placer #646

Open
Nightenom opened this issue Jan 16, 2024 · 4 comments
Open

[RFC] Smarter blueprint placer #646

Nightenom opened this issue Jan 16, 2024 · 4 comments

Comments

@Nightenom
Copy link
Member

Nightenom commented Jan 16, 2024

State now: placer logic is generally dumb, the only reason it works for most of common blueprints is that it builds from bottom to top.

Potential upgrade:
a) iterate the structure unlimited times (unlike 4 block placement stages now)
b) every iteration place such blocks that BlockState#canSurvive(...) in target world, requires special attention for falling blocks (again...)

Solves:
Blocks requiring support without actually checking for support existence (but falling. blocks..) - dripstones, hanging chains
Removes the relatively new block solidness issue out of placer logic (we still need it elsewhere tho)

Doesn't solve:
Pistons and other blocks which may change size or anyhow change local context

Issues:

  1. need proper optimizations to fast skip blockPoses that are done already (without world blockstate check? skip fully built layers/rows?)
  2. moving redstone blocks (pistons only?) may actually become even worse - solution: special placement handler for powered pistons (mby do additional stage after blocks before entities to check that all redstone blocks incl. actuators are in requested state within one tick)
@someaddons
Copy link
Contributor

not to mention fluids that flow after placed and change the world state of multiple positions^^

@Nightenom
Copy link
Member Author

Nightenom commented Jan 16, 2024

Imho all fluids should get removed within single tick as first step, then normally placed after blocks before entities - handler should get count diff as result
Also need of temporary boxes for ocean placement.. or permanent boxes for caves

@someaddons
Copy link
Contributor

not that easy to seperate due to waterlogged blocks also flowing

@Raycoms
Copy link
Contributor

Raycoms commented Jan 17, 2024

Imho all fluids should get removed within single tick as first step, then normally placed after blocks before entities - handler should get count diff as result Also need of temporary boxes for ocean placement.. or permanent boxes for caves

Not at the first step, else they flow back in. Should be removed after the solids were placed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants