Immersive Intelligence

Immersive Intelligence

Mods
2M Downloads

[BUG] any emplacement with high range (probably radar too) causes heavy lags

IVsniper opened this issue ยท 3 comments

commented

Describe the bug
When there's a lot of mobs in the emplacement's view (IR observer or any other), this causes heavy lags with fps drops up to 0 and freezes forever. This probably caused by how mod handles getting mobs positions. However, when emplacement gets a target, lags stops.
Using Spark profiler, "pl.pabilo8.immersiveintelligence.common.util.MultipleRayTracer.volumetricTrace()" causes all the lags (Spark link and Spark file in archive (in case link is not working) are attached)
I've also checked that with increasing CPDS distance up to 56 blocks through config, same result

To Reproduce
Steps to reproduce the behavior:
1 - Buld IR observer
2 - Wait for mobs to spawn in your world
3 - FPS drops heavly, disabling the emplacement causes fps to return to normal
3.1 - Spawning mobs in range causes fps to return to normal

Expected behavior
A game not to lag

Screenshots or GIFs
~

Logs
latest.log
https://spark.lucko.me/kncqKExtL
kncqKmExtL.zip

Environment

  • OS: Win10 Pro 22H2
  • Minecraft version: 1.12.2
  • Forge version: 1.12.2-forge-14.23.5.2860
  • Immersive Intelligence version: latest 0.3.0 from github, yet problem was existing on earlier versions
  • Immersive Engineering version: 0.12-98
    If you have other mods installed, it would be nice if you send a list of them too (maybe it's not II's fault after all) ^^.
    -Immersive petroleum (without it is the same result)
    P.s. My pc isn't a potato, so probably it's really on mod side
commented

Part of the changes in #251 might be related to this, emplacement targeting was checking if entities were visible and then checking if the visible entities matched the targeting filter. I swapped the order, which should result in fewer visibility checks.

commented

Might be, but it looks like it wasn't after all, because few days earlier was released "Improved MultipleRayTracer performance" fix, wich makes me think it wasn't related to this, and also, this bug was presistent even earlier (in 0.2.1/0.2.2b)

commented

Both are applicable, I improved the performance of the raytracing function itself in e3e3158, while the #251 PR changes the checking order to be more efficient.