Jump to content

Sea Weed's will attack nearby players when ignited even if said ignition was NOT caused by a player.


Hornete
  • Closed

1784971136_GIF11-29-20216-29-10PM.thumb.gif.78fb473f80491264b13a78ddff847809.gif

Sea Weeds that are caught on fire(any fire) will attack the player, even if it was just a wildfire.

local function on_ignited(inst, data)
    -- Would be nice to use data.doer, but very few places seem to pass it!
    -- So just set the closest player as a target and assume they lit us up.
    find_and_attack_nearby_player(inst)

    inst.components.harvestable:Disable()
end

I noticed there were these comments, and it is understandable to assume a player may have lit up a Sea Weed, considering most of the time a spittlefish will likely be there to stop any smoldering, the smoldering can still happen even if it was not caused by player interference. So it's a bit of a dangerous assumption to assume the closest player lit up the Sea Weed, perhaps it would be best to just go ahead and pass data.doer in all "onignite" events rather then dancing around the issue and assuming a nearby player lit the Sea Weed up?


Steps to Reproduce

1. Let a sea weed be caught on fire by a wildfire/smoldering(c_select().components.burnable:StartWildfire())
2. Notice it just aggroes onto the nearest player.

  • Like 2
  • Sad Dupe 2



User Feedback


This should stop Sea Weeds from becoming aggresive when being ignited from smoldering:

  • Make so Burnable's SmolderUpdate uses self.inst as source for Ignite: 
    local function SmolderUpdate(inst, self)
    	< ... >
    
    	self.smoldertimeremaining = self.smoldertimeremaining - SMOLDER_TICK_TIME * heatmod
    	if self.smoldertimeremaining <= 0 then
    		self:StopSmoldering() --JUST in case ignite fails...
    		self:Ignite(nil, self.inst) --smoke is invalid at this point, so use self.inst as source
    
    	< ... >
    end
  • Don't forget to pass source to "onignite" event: 

    function Burnable:Ignite(immediate, source, doer)
    	if not (self.burning or self.inst:HasTag("fireimmune")) then
    		self:StopSmoldering()
    
    		self.burning = true
    		self.inst:ListenForEvent("death", OnKilled)
    		self:SpawnFX(immediate)
    
    		self.inst:PushEvent("onignite", { source = source, doer = doer })
    		
    		< ... >
    	end
    end
  • And finally, make use of these changes in waterplant prefab: 
    local function on_ignited(inst, data)
    	-- Would be nice to use data.doer, but very few places seem to pass it!
    	-- So just set the closest player as a target and assume they lit us up.
    	if data ~= nil and data.source ~= inst then
    		find_and_attack_nearby_player(inst)
    	end
    
    	inst.components.harvestable:Disable()
    end

     

Edited by Tykvesh
  • Like 1
  • Thanks 1

Share this comment


Link to comment
Share on other sites

I understand that the on_ignited comment, as it exists in the script, gives a certain impression of why the script is written as it is. The mistake here was that comment not being re-written before the update's release. I can assure you that the burning behaviour was a discussed piece of design feedback at the time.

I cannot promise that we will make the changes in the above comment, or change the design of the Sea Weed catching on fire, but I will take this bug report as design feedback, and rewrite the on_ignited comment for a future change.

Thank you for the report!

  • Like 2
  • Thanks 2
  • Big Ups 1

Share this comment


Link to comment
Share on other sites

9 minutes ago, StevenM said:

I understand that the on_ignited comment, as it exists in the script, gives a certain impression of why the script is written as it is. The mistake here was that comment not being re-written before the update's release. I can assure you that the burning behaviour was a discussed piece of design feedback at the time.

I cannot promise that we will make the changes in the above comment, or change the design of the Sea Weed catching on fire, but I will take this bug report as design feedback, and rewrite the on_ignited comment for a future change.

Thank you for the report!

I appreciate your response a lot, thank you for your work!

Share this comment


Link to comment
Share on other sites



Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...