You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Terrain jobs usually run on a thread different from the main thread, and it's allegedly dangerous to do object lookups from another thread.
The IET code could probably be modified to only lookup the DaggerfallUnity once on creation during gameplay, and use the cached result in those other threads. This also affects Monobelisk.Utility.GetOriginalTerrainHeight(), which also does a DaggerfallUnity object lookup from those dispatch jobs.
It could also be possible to compute properties such as the original terrain height and location rect on terrain promotion from the main thread, rather than during TerrainComputer.DispatchAndProcess
The text was updated successfully, but these errors were encountered:
Hmm. Altering monobolisk's math for terrain generation I've been able to handle, but when it comes to fixing the internal plumbing like this I'd be out of my depth.
I got this player crash
Player(34).log
The relevant part of the callstack is here:
This is similar to the known DFU crash here: Interkarma/daggerfall-unity#2355
Terrain jobs usually run on a thread different from the main thread, and it's allegedly dangerous to do object lookups from another thread.
The IET code could probably be modified to only lookup the DaggerfallUnity once on creation during gameplay, and use the cached result in those other threads. This also affects
Monobelisk.Utility.GetOriginalTerrainHeight()
, which also does aDaggerfallUnity
object lookup from those dispatch jobs.It could also be possible to compute properties such as the original terrain height and location rect on terrain promotion from the main thread, rather than during
TerrainComputer.DispatchAndProcess
The text was updated successfully, but these errors were encountered: