
[1.8.9] Render Conflict with ElecCore
Xiaminou opened this issue ยท 6 comments
Removing a conduit with a wrench causes a render conflict with ElecCore resulting in a crash.
Crash Report: http://pastebin.com/Z54Tdavw
Well I still get it: http://pastebin.com/wru9KuMt
also get this one: http://pastebin.com/3BYDBpsF
However removing conduits doesn't trigger it anymore, now it just happens randomly from time to time.
downloaded from git yesterday.
That's two new ones. :-(
Seems I will have to re-do the conduit rendering after all. I really hoped I had duct-taped it to hold until Crazypants is back...
well well the Damokles sword of "simple" lists and multithreading, maybe exchange them for concurrent safe versions in general?
oh boy ... I see the glitches ahead XD
It's a bit more complicated. Yes, a ConcurrentList is a good "duct-tape" fix, and if it was for TE rendering, it'd even be ok. TEs are re-rendered every frame, so a "wrong" rendering result is just a short flicker. However, this is for block rendering, which is not done that often. So a bad render will be visible to the user.
In addition I want to be able to cache the Conduit Render. When I look into log files I get together with those crash reports, I see that conduit bundles take about 15 times as long to compute their model as any other (cached) Ender IO block. And conduits are most numerous...
A problem with the caching is that collecting all the information for the cache key would take almost as long as computing the model. So what I'm aiming at is to have each component compute its model the moment it is created/changed. Then the rendering would only need to collect and combine those sub-models (QuadCollectors).
PS: Root cause of this madness is the fact that getExtendedState()---which should collect rendering-relevant data from the TE---is called in the rendering thread where you're not really allowed to access the TE.
Got a "tesselating block" crash today, first this week.
Crash Report: http://pastebin.com/p54YMHty