Jump to content

Wildfires can start on entities inside a sandstorm and can be prevented by having a single invalid/protected lureplant nearby


hoxi
  • Pending

It seems that wildfires only check if a target player is inside a sandstorm or not, without checking if the object is in a sandstorm. This can lead to things inside the sandstorm catching on fire, or even in the oasis, which kinda defeats the purpose of that biome being supposedly safe from wildfires. Something could be chosen just as you're leaving or while not exactly in view.

The interesting part is that canopies actually check if a target is below them, though with different methods as it's more simple. Making them actually reliable compared to the desert sandstorm.

Here's some context with code, in scripts/components/wildfires.lua, maybe the sandstorm check could be moved from LightFireForPlayer from just checking on the player, to CheckValidWildfireStarter, like this:

local function CheckValidWildfireStarter(obj)
    if not obj:IsValid() or
        obj:HasTag("fireimmune") or
        checkforcanopyshade(obj) or
        (obj.components.witherable ~= nil and obj.components.witherable:IsProtected()) or
		(_world.components.sandstorms ~= nil and _world.components.sandstorms:IsInSandstorm(obj)) then
        return false --Invalid, immune, temporarily protected, or inside a sandstorm

This would require the IsInSandstorm check in scripts/components/sandstorms.lua to be updated however, as it normally only works on entities with an areaaware component, which could be changed to look like this to work entities without said component:

function self:IsInSandstorm(ent)
	if _sandstormactive then
		if ent.components.areaaware ~= nil then
			return ent.components.areaaware:CurrentlyInTag("sandstorm")
		else
			local x, y, z = ent.Transform:GetWorldPosition()
			local node = TheWorld.Map:FindVisualNodeAtPoint(x, y, z, { "sandstorm" })

			if node then
				return true
			end
		end
	end

	return false
end

I'm aware that FindVisualNodeAtPoint is expensive, which might be a problem when there's many targets found, so maybe something different could be used, or a separate task could go through the potential targets with a very short delay. Maybe NodeAtPointHasTag, but I'm not familiar enough.

It would be nice either way to fix address this somehow as it can be frustrating, when wildfires can be annoying as is.

------------------------------------------------------------------------------------------------------------------------------------------------------

There's also an issue where, if any "high priority" targets for wildfires are found (currently only lureplants), even if none of them are valid or are protected, any other potential targets are ignored completely and no wildfire happens. Ideally, if the high priority targets are exhausted and no wildfire happened, the low priority list should be checked afterwards.

In code, also in the LightFireForPlayer in scripts/components/wildfires.lua, the following bit could be changed from:

            firestarters = #highprio > 0 and highprio or lowprio
            while #firestarters > 0 do
                local i = math.random(#firestarters)
                if CheckValidWildfireStarter(firestarters[i]) then
                    firestarters[i].components.burnable:StartWildfire()
                    break
                else
                    table.remove(firestarters, i)
                end
            end

To:

            firestarters = #highprio > 0 and highprio or lowprio
            while #firestarters > 0 do
                local i = math.random(#firestarters)
                if CheckValidWildfireStarter(firestarters[i]) then
                    firestarters[i].components.burnable:StartWildfire()
                    break
                else
                    table.remove(firestarters, i)

                    -- alternatively, can do  if #highprio == 0 and #lowprio > 0 then
                    if not next( firestarters ) and #lowprio > 0 then
                        firestarters = lowprio
                    end

                    -- could also be as simple as  firestarters = lowprio
                end

This would obviously have the side effect of removing a way of dealing with them, even if it's very specific and counterintuitive. The method to plant a lureplant with a flingomatic in range would still work, as the plant will catch on fire, but yeah, that's something to keep in mind. I'd rather see more ways to deal with them or a rework of the mechanic if possible.


Steps to Reproduce

For wildfires in sandstorms:

  1. Stand near the sandstorm desert while wildfires can happen, but not enough to count as inside the sandstorm. Make sure there are some potential targets nearby, you can drop grass or twigs or so inside the biome and step out. Alternatively, plant a lureplant inside the sandstorm and step out.
  2. Remove other potential targets near you to minimize the chances of those being chosen instead, unless you use a lureplant.
  3. Observe how wildfires can happen inside the sandstorm, when that shouldn't be the case.

For wildfires being negated by having an invalid/protected high priority target in range, with most consistent way I can think of, even if it's a bit specific:

  1. Set up a canopy tree near land, or go to a waterlogged biome.
  2. Plant a lureplant below the canopy, inside the protection range. Can be on a boat in either case, or on land as well if the canopy is near land.
  3. As long as that lureplant is in range for wildfires for a player, no wildfires will happen for that player.
  • Like 1



User Feedback


I'm also attempting to bump this one like I did with my other report, I know some people would appreciate if the first issue was addressed to not have things catch on fire inside a sandstorm if the player is right outside. Regarding the other issue, probably wouldn't be appreciated, but still worth looking into.

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...