Missing Acid Rain Visual in Sanctum

Changed Status to Fixed

The issue is related to clients not having the world topology data that the server has for this area, resulting in a mismatch with the server.

Easily checked with the areaaware component or printing TheWorld.Map:CanPointHaveAcidRain(x, y, z), with the coordinates based on the player position or a point on the screen on vault floor, both on the server and the local client. The client will show "no current node" for area aware, and return false for the acid rain map function (which results in not spawning the acid rain VFX).

Also, acid rain can happen in the vault in the first place because it's not marked with a "nocavein" tag (which is strange, given that it has a newly added "noquaker" tag..), and either that one or "lunacyarea" are the ones that block acid rain.

 

A temporary fix would be to give the vault the "nocavein" tag, or include "noquaker" in the acid rain check (although you might want to do the former anyway to keep it consistent with the archives). Clients will still have no topology data, but at least it'll match in terms of gameplay.

Ideally, this would need to be addressed to have clients have matching topology data for these layouts that change on the fly.

 

There's also an issue I reported a few times that, even if this gets fully addressed, will still persist, where non-player entities will be affected by acid rain even in areas where there can't be acid rain (this would include dropping items on the vault floor). See here.

 

EDIT: oh, forgot to answer this.

Quote

Potentially both forms of rain have this problem.

Normal rain is unaffected by this issue, as it has no restriction mechanics related to world topology, unlike acid rain.

 

EDIT 2: oh oops, the page wasn't refreshed when I was investigating and typing this, and there's no notification for new comments unlike in forum posts, so I didn't see it being marked as fixed.

Edited September 16, 2025 by hoxi

Well, hotfix 690194 claims to have fixed it but after both looking at the code and checking in-game, nothing seems to have changed..? Acid rain should still happen there, and it will not show for clients (until they restart the server, as they'll receive topology data, then acid rain will show).

 

I looked into the code a bit more and further debug checked things, and noticed something, both the Vault_Lobby and Vault_Vault layouts aren't getting any of their intended tags, they have none.

I mentioned that the vault was lacking the "nocavein" tag, so acid rain wasn't exempted, but no, it is actually there in the layout definition, along with "noquaker" and a few others, it's just that they're not actually being set when placing the layout, and it feels like an oversight that currently it's just sending an empty table for the tags parameter, when the data is available there.

 

So the issues seem to be:

• The layouts placed by vaultroommanager aren't setting the tags from their definitions.
• Clients don't receive any of the new topology data added during runtime (expected, vaultroommanager is a server-only component and there's nothing on it syncing this stuff).

 

I was able to solve the first one by changing this bit in maputil.lua:

local topology_node_index = StaticLayoutPlacer.AddTopologyData(topology, tx2*TILE_SCALE - (map_width * 0.5 * TILE_SCALE), ty2*TILE_SCALE - (map_height * 0.5 * TILE_SCALE), size*TILE_SCALE, size*TILE_SCALE, "Vault:0:" .. layout.name, {})

To:

local topology_node_index = StaticLayoutPlacer.AddTopologyData(topology, tx2*TILE_SCALE - (map_width * 0.5 * TILE_SCALE), ty2*TILE_SCALE - (map_height * 0.5 * TILE_SCALE), size*TILE_SCALE, size*TILE_SCALE, "Vault:0:" .. layout.name, layout.add_topology ~= nil and layout.add_topology.tags or {})

(scroll to the right, sorry but it's a single line there too..)

 

Both layouts will have all their tags as expected, the tags will be stored when saving, and clients will get them after a server restart (leaving this as the only thing that would need to be addressed).

 

You might still want to add a check like this for CanPointHaveAcidRain:

function Map:CanPointHaveQuaker(x, y, z)
    if self:IsPointInAnyVault(x, y, z) then
        return false
    end

But if it's deemed unnecessary with the tags working properly for both of these, you could get rid of it in that function instead.

Edited September 17, 2025 by hoxi
Didn't realize I put some text with a black background

@hoxi

Looks like this missed hotfix 690194. It is fixed in-dev with the Vault check in CanPointHaveAcidRain.

50 minutes ago, omar_klei said:

 

Looks like this missed hotfix 690194. It is fixed in-dev with the Vault check in CanPointHaveAcidRain.

Oh, good! What about the missing topology tags though? Feels like that should be addressed as well.

And the fact that clients don't get the topology data until a restart, you don't have to do it for this release necessarily, especially with the change you mentioned, but I think it's worth looking into.

3 hours ago, hoxi said:

Oh, good! What about the missing topology tags though? Feels like that should be addressed as well.

And the fact that clients don't get the topology data until a restart, you don't have to do it for this release necessarily, especially with the change you mentioned, but I think it's worth looking into.

Adding the tags in the function and fixing the task prefix so it is not always "Vault:0" for this helper function. The topology data not being present initially will need to be fixed.