bugfix(fxlist): Fix unreliable terrain layer selection of particles using CreateAtGroundHeight

[stephanmeesters]

When creating a particle system that uses the CreateAtGroundHeight option in the INI, the current terrain layer (for example GROUND, or BRIDGE) was not reliably determined because of an uninitialized variable.

This mostly affects toxin pools on a bridge which end up on the ground layer instead, see the images.

Before (note the particles on the ground):

After (most of the particles are now on the bridge, some are on the edge and float):

[greptile-apps]

Greptile Summary

This PR fixes an uninitialized variable bug in ParticleSystemFXNugget::reallyDoFX where newPos.z was not set before being passed to getLayerForDestination, causing unreliable terrain layer selection for particles using CreateAtGroundHeight.

• newPos.z is now initialized to primary->z + offset.z before the m_createAtGroundHeight branch, giving getLayerForDestination a meaningful z-coordinate to determine whether the spawn point is on a bridge or ground layer.
• The else branch is refactored from a full assignment (= primary->z + offset.z + m_height.getValue()) to an in-place add (+= m_height.getValue()), which is mathematically equivalent and preserves existing non-ground-height behavior.

Confidence Score: 5/5

Safe to merge — the change is a minimal, targeted fix for an uninitialized variable with no behavioral side effects on non-ground-height paths.

The fix correctly initializes newPos.z before it is read by getLayerForDestination, eliminating the undefined behavior. The else-branch rewrite is mathematically identical to the original. No other paths are affected.

No files require special attention.

Important Files Changed

Filename	Overview
Core/GameEngine/Source/GameClient/FXList.cpp	Initializes newPos.z before calling getLayerForDestination to fix uninitialized variable causing wrong terrain layer selection; else-branch refactored to equivalent += expression.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["reallyDoFX called"] --> B["Compute newPos.x, newPos.y via offset + radius * cos/sin"]
    B --> C["newPos.z = primary->z + offset.z\n(NEW: initialized here)"]
    C --> D{"m_createAtGroundHeight\n&& TheTerrainLogic?"}
    D -- Yes --> E["getLayerForDestination(&newPos)\n(now uses valid z for layer detection)"]
    E --> F["layer = GROUND or BRIDGE"]
    F --> G["newPos.z = getLayerHeight(x, y, layer)"]
    D -- No --> H["newPos.z += m_height.getValue()\n(equivalent to old assignment)"]
    G --> I["setPosition(&newPos)"]
    H --> I

Loading

_{Reviews (2): Last reviewed commit: "Process review comment" | Re-trigger Greptile}

[Mauller]

seems quite simple, does this also affect burn marks being applied to the bridge?

[stephanmeesters]

seems quite simple, does this also affect burn marks being applied to the bridge?

Scorch marks are different as they are not particles and have their own render path (because they persist the entire match, and you have a max number of scorches)

[Mauller]

Scorch marks are different as they are not particles and have their own render path (because they persist the entire match, and you have a max number of scorches)

Ah i see, that's cool. Does this also affect how particles are placed over uneven terrain? Or is that a different problem?

[bobtista]

Good find! Looks good to me

[bobtista]

LGTM 👍

[stephanmeesters]

Ah i see, that's cool. Does this also affect how particles are placed over uneven terrain? Or is that a different problem?

This change should not affect particle placement at locations where there is only one terrain layer because getLayerForDestination will return GROUND regardless of the Z value.

For particles on uneven terrain I'm working on terrain conforming particles, which instead of the regular method of drawing quads will make tiny meshes by sampling the terrain map, unless that particle is on a bridge in which case its probably best to just draw as a quad

[Mauller]

This change should not affect particle placement at locations where there is only one terrain layer because getLayerForDestination will return GROUND regardless of the Z value.

For particles on uneven terrain I'm working on terrain conforming particles, which instead of the regular method of drawing quads will make tiny meshes by sampling the terrain map, unless that particle is on a bridge in which case its probably best to just draw as a quad

That's cool, from your pictures showing the terrain conforming particles i thought this might have been part of it.

[Mauller]

Looks good to me.