Problem in Builder:DoBuild(recname, pt, rotation):
local prod = SpawnPrefab(recipe.product) if prod then if prod and prod.components.moisturelistener and wetLevel then prod.components.moisturelistener.moisture = wetLevel prod.components.moisturelistener:DoUpdate() end
The moisture update comes BEFORE setting position/owner of the prefab.
Which means it defaults to position (0, 0, 0).
Inside MoistureListener:UpdateMoisture(dt), the following triggers:
if not (self.inst.components.inventoryitem and self.inst.components.inventoryitem.owner) then if self.inst.Transform then local x,y,z = self.inst.Transform:GetWorldPosition() if x and y and z then if GetWorld().Flooding ~= nil and GetWorld().Flooding:OnFlood(x, y, z) then self.moisture = math.max(self.moisture, TUNING.MOISTURE_FLOOD_WETNESS) end end end end
The item doesn't have an owner, but it has the defaulted (0, 0, 0).
If by any chance, that position is flooded, then the crafted item will be wet, no matter where you are.
Solution: delay the update to the next frame (after position/owner is setup) or insert the code after prod is built (but before the returns).
local function DelayedMoistureUpdate(prod, wetLevel) prod.components.moisturelistener.moisture = wetLevel or 0 prod.components.moisturelistener:DoUpdate() end function Builder:DoBuild(recname, pt, rotation) local recipe = GetRecipe(recname) local buffered = self:IsBuildBuffered(recname) if recipe and self:IsBuildBuffered(recname) or self:CanBuild(recname) then local wetLevel = 0 if self.buffered_builds[recname] then wetLevel = self.buffered_builds[recname].wetLevel self.buffered_builds[recname] = nil else local mats = self:GetIngredients(recname) wetLevel = self:GetIngredientWetness(mats) or 0 self:RemoveIngredients(mats) end local prod = SpawnPrefab(recipe.product) if prod then if prod and prod.components.moisturelistener and wetLevel then prod:DoTaskInTime(0, DelayedMoistureUpdate, wetLevel) end
Steps to Reproduce
Flood position (0, 0, 0) and craft stuff.
Flood position (0, 0, 0) and craft stuff.
- 3
A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.