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

Builder causes massive lag #90

Open
khaskelbergTAU opened this issue May 6, 2022 · 5 comments
Open

Builder causes massive lag #90

khaskelbergTAU opened this issue May 6, 2022 · 5 comments

Comments

@khaskelbergTAU
Copy link

essentially the title - not sure if this was ever addressed. using latest rftoolsbuilder builder causes massive framedrops when building.

@McJty
Copy link
Collaborator

McJty commented May 7, 2022

What version? The answer is probably going to be that this is unavoidable though. Placing blocks is expensive in Minecraft. There is not much I can do about that

@Vanqy9316
Copy link

let me abuse this issue to prove a point on my side. the builder is actually not causing that much lag during normal operation, if its either pump, quarry or builder. we are talking about a ryzen 5950 server here, so please listen carefully:
the BIGGEST lag at all comes from using the preview mode. this has multiple reasons:

  • the preview mode is not client side only. i highly suggest to take a look at mekanism or create to see how preview clientsided works
  • since the preview mode is serversided, there are dummy blocks being placed... in a click of a single button and depending on the shape card a few millions at once. let me calculate out the amount ive tested on the server ... 512 x 512 with full height... so the roof alone is a quarter million.. in one button press
  • any server that does not have a ridiculous high server watchdog timer will crash at this point. instantly. we are talking about 5 minutes where the server is not responding, not even to chat

@McJty
Copy link
Collaborator

McJty commented May 24, 2022

There is a reason that the preview mode is like this. It was initially added to be able to safely build structures while the support blocks made sure that liquids didnt' flow away during building. For the quarry it's less useful to do this though. I have to think about this

@James103
Copy link

From my experience, the support blocks that the builder places when preview mode is enabled are not transparent, despite their render material. Since these blocks are not fully transparent to the lighting engine, the server has to spend a lot of additional CPU time recalculating lighting, especially if many thousands of these blocks need to be placed. In other words, the root cause is the same as the root cause of much of the server lag that occurs when a player runs the following command: /fill ~-80 255 ~-80 ~80 255 ~80 stone, where stone is an opaque block.

If this is confirmed, then to save on server lag, the preview blocks placed by RFToolsBuilder should be fully transparent (to the lighting engine).

Steps to confirm the additional lag is due to lighting updates (click to expand)
  1. Create a new world with cheats enabled (can be in a vanilla instance if desired, but the Spark mod allows additional profiling).
  2. If spark mod is installed, start its profiler. Otherwise, press F3+L.
  3. Immediately after, run this command: /fill ~-80 255 ~-80 ~80 255 ~80 stone
  4. Time how long the command takes to execute.
  5. Stop the profiler if it is still running when the command (and corresponding queued lighting updates) completes.
  6. Run this command: /fill ~-80 255 ~-80 ~80 255 ~80 air
  7. Wait for the above command (and corresponding queued lighting updates) to complete.
  8. Repeat steps 2-5, but with the command /fill ~-80 255 ~-80 ~80 255 ~80 glass.
  9. Notice that in most cases, a stone roof takes more CPU time to construct than a glass roof due to lighting updates.

@McJty
Copy link
Collaborator

McJty commented Sep 5, 2022

I will check this out now

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

No branches or pull requests

4 participants