The fix had two parts: the behavior fix, then the “actually load the new DLL” fix.
The workbench object script was still using the small gnome-style completion value: 100. That means the object sim reached “done” almost immediately. I changed the Crafting Gnome Workbench runtime patch in WorldObjectProvider.cs (line 165) so this specific workbench now uses an 8000 completion threshold instead.
That patch updates the BHAV logic for:
Add Progress: keep working while progress is below 8000
Are we done working?: only finish once progress is at least 8000
Finish Carving: same 8000 check before producing the item
Set Graphics: divide progress by 2666, so the model advances through visual stages across the longer craft duration
That logic starts around WorldObjectProvider.cs (line 2700).
I also added a progress reset for the crafting flow at WorldObjectProvider.cs (line 2784), so a previous completed gnome does not leave progress behind and cause the next one to instantly complete.
The sneaky part was that your IDE/test copy was still loading an old FSO.Content.dll. The new patch had compiled into TSOClient\tso.content\bin\Debug, but TSOClient\FSO.IDE\bin\Debug\FSO.Content.dll was locked by FSO.IDE / Visual Studio, so it never got updated. Once the rebuilt DLL actually made it into the runtime bin folder, the 8000 behavior took effect.
