Obi Official Forum
Help Unity - UNKNOWN_OBJECT_TYPE declared as [WriteOnly] - Printable Version

+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Rope (https://obi.virtualmethodstudio.com/forum/forum-4.html)
+--- Thread: Help Unity - UNKNOWN_OBJECT_TYPE declared as [WriteOnly] (/thread-4277.html)

Unity - UNKNOWN_OBJECT_TYPE declared as [WriteOnly] - AlexisF - 02-07-2024

Hello
I am currently trying to update a project to Unity 2022.3.25 (from 2021.3.27). The current version of Obi Rope I'm using is the 6.3. 




Updating to Unity 2022 and keeping that version of Obi Rope leads to serious lags when increasing the number of ropes (already unplayable at less than 10). For this problem, I didn't really bother looking for a solution because updating to the latest (6.5.4 at the time I write this) solves it.


The problem is, thousands of errors pop up in the console after updating, and the rope behavior is clearly broken (at least visually).


Code:
System::InvalidOperationException: The UNKNOWN_OBJECT_TYPE has been declared as [WriteOnly] in the job, but you are reading from it.
This Exception was thrown from a job compiled with Burst, which has limited exception support.
#3 scripting_raise_exception(ScriptingExceptionPtr)
#4 AtomicSafetyHandle_CUSTOM_CheckWriteAndThrowNoEarlyOut_Injected(AtomicSafetyHandle const&)
#5 Unity.Jobs.IJobParallelForExtensions.ParallelForJobStruct`1<Obi.ApplyInertialForcesJob>.Execute(ref Obi.ApplyInertialForcesJob jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, ref Unity.Jobs.LowLevel.Unsafe.JobRanges ranges, int jobIndex) -> void_aaaff58bdce476e006d3a95c8933df9f from UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
#6 1a07ad49f6e8d1fe05692c844fae58d8
#7 ExecuteJob(ManagedJobData*, void (*)(void*, void*, void*, void*, int), int, unsigned char*)
#8 ExecuteJobCopyData(ManagedJobData*, void (*)(void*, void*, void*, void*, int), int)
#9 ForwardJobForEachToManaged(ManagedJobData*, unsigned int)
#10 ujob_execute_job(ujob_control_t*, ujob_lane_t*, ujob_job_t*, ujob_handle_t, unsigned int)
#11 ujob_wait_for(ujob_control_t*, ujob_handle_t, int)
#12 CompleteFenceInternal(JobFence&, WorkStealMode)
#13 ScheduleBatchedScriptingJobsAndComplete(JobFence&, ScriptingExceptionPtr*)
#14 JobHandle_CUSTOM_ScheduleBatchedJobsAndComplete(JobFence&)
#15  (Mono JIT Code) (wrapper managed-to-native) Unity.Jobs.JobHandle:ScheduleBatchedJobsAndComplete (Unity.Jobs.JobHandle&)
#16  (Mono JIT Code) [JobHandle.bindings.cs:27] Unity.Jobs.JobHandle:Complete ()
#17  (Mono JIT Code) [BurstSolverImpl.cs:274] Obi.BurstSolverImpl:ApplyFrame (single,single,single)
#18  (Mono JIT Code) [ObiSolver.cs:1505] Obi.ObiSolver:UpdateTransformFrame (single)
#19  (Mono JIT Code) [ObiSolver.cs:1553] Obi.ObiSolver:BeginStep (single)
#20  (Mono JIT Code) [ObiUpdater.cs:63] Obi.ObiUpdater:BeginStep (single)
#21  (Mono JIT Code) [ObiFixedUpdater.cs:48] Obi.ObiFixedUpdater:FixedUpdate ()
#22  (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
#23 mono_jit_runtime_invoke
#24 do_runtime_invoke
#25 mono_runtime_invoke
#26 scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)
#27 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
#28 MonoBehaviour::CallMethodIfAvailable(int)
#29 MonoBehaviour::CallUpdateMethod(int)
#30 void BaseBehaviourManager::CommonUpdate<FixedBehaviourManager>()
#31 FixedBehaviourManager::Update()
#32 InitPlayerLoopCallbacks()::FixedUpdateScriptRunBehaviourFixedUpdateRegistrator::Forward()
#33 ExecutePlayerLoop(NativePlayerLoopSystem*)
#34 ExecutePlayerLoop(NativePlayerLoopSystem*)
#35 PlayerLoop()
#36 EditorPlayerLoop::Execute()
#37 PlayerLoopController::InternalUpdateScene(bool, bool)
#38 PlayerLoopController::UpdateSceneIfNeededFromMainLoop()
#39 Application::TickTimer()
#40 -[EditorApplication TickTimer]
#41 __NSFireTimer
#42 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
#43 __CFRunLoopDoTimer
#44 __CFRunLoopDoTimers
#45 __CFRunLoopRun
#46 CFRunLoopRunSpecific
#47 RunCurrentEventLoopInMode
#48 ReceiveNextEventCommon
#49 _BlockUntilNextEventMatchingListInModeWithFilter
#50 _DPSNextEvent
#51 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
#52 -[NSApplication run]
#53 NSApplicationMain
#54 EditorMain(int, char const**)
#55 main
#56 start

Just to clarify, the expected result of the ropes is a perfectly straight line, with no bending at all. In the attached screenshot 1, you can see the rope is bending. And in the second attached screenshot, you can see the rendering of the rope is completely gone but the game still works as if the ropes were here. The flow of all this is, screenshot1 occurs when launching the game, but if I reload the level without quitting Unity, it's when the rendering disappears. This precision is what makes me think the problem is only on the rendering side because when playing in the first case scenario (with bent ropes) the physic behavior feels normal.
To add more "proofs" for that thought, if you play the game (links below), you will notice you can cut ropes. In the attached screenshot 3 you can see trying to cut the rope on the visual doesn't mark it red, while trying to cut between the hand and the head marks it red (screenshot4).

Now, the major points I need to mention are, I have little to no experience with Obi Rope, and this project isn't my own. The person who created this game isn't working with me anymore, quickly looked into this to see if anything was obvious but couldn't find a solution. They told me to make a post here to have a better chance.


The information worth mentioning :
- During my research, I ended up on this post which looks very similar but doesn't have any answer as the OP stopped responding (+ I don't know how to "Disable Burst to get a better stack trace")

- Unity version : 2022.3.25

- Obi Rope version : 6.5.4

- Android and iOS store links if you want to observe the pre-update (and wanted) behavior.


I'm sorry for the small amount of details, I truly don't know what to share to help explain my case and will gladly add more precision if needed.