🐞 [Bug] Spell visuals are currently bugged

[Wall-core]

I've spent the last day crawling through the debugger and haven't been able to find what is causing this. It started happening at least a year ago.

Spell visuals for channeled abilities get stuck. I assumed it had something to do with the last update to fix Tranquility but reverting that commit didn't resolve it.

If anyone can find the cause and help get this fixed, it would be awesome. Likely, there is some sort of cleanup packet that the client is expecting but is not receiving.

[Wall-core]

Upon further testing, it seems that this issue is exclusive to AMD GPUs. This issue is occurring on my RX6600 with updated drivers. Tested on Nvidia with Windows and Linux clients and no issue. Will test further and attempt to fix via drivers.

[Wall-core]

Tested on 750ti, no issues there. Will test OpenGL drivers for AMD

[Daribon]

Are you using DXVK on Windows with an AMD GPU?

If not then you really should. Even modern retail had issues with AMD GPUs on Windows for over a year, but everything ran fine when using DXVK.

[Wall-core]

I tried DXVK for d3d9 with my AMD RX6600, but no dice. Still the same issues persist. Tried modifying the client as well to clean particle buffers unconditionally and no luck either. It seems like the visual is stuck in the GPU framebuffer or something. Gonna try an older driver version next

[Wall-core]

I'm back to square one. Tried dgVoodoo2, tried DXVK, tried disabling GPU entirely. The issue still persists. Maybe it's CPU related, doubtful though. I'm gonna keep searching for an answer.

[Wall-core]

found someone discussing the issue on Nost forum, same problems described but no solution found.
https://nostalrius.org/viewtopic.php?f=76&t=30228

[Wall-core]

After too many days of rigorous testing, I've come to conclude:
This is an inherent flaw in some spellvisual and spellvisualkit designs. This problem affects all clients, but is masked due to specific hardware and software configurations.

This is a low-level problem stemming from how visuals are applied. In the case of Tranquility, there is an ImpactEffect visual which calls a persistent area aura visual while another one is called in the ChannelEffect event for the same dynamic object, which is invalid but blizzlike behavior. Either microsoft/nvidia gpu/amd cpu is masking this bug by handling it differently - either through some garbage collection procedure or handling of buffer data.

I can't narrow it down to anything specific without diving into it at a hardware level. As stated, I've tested this with a Win10/Intel i5-5500k/AMD RX6600 system on multiple clean clients and vmangos builds. It persists with DXVK and dgVoodoo2 wrappers. It persists with GPU disabled and running on Software Rendering.

It does not appear on my Win7/AMD A10/750ti rig. So likely it's one or a combination of these. I can manually fix this with a client patch to correct the invalid spellvisual data but that's obviously not a valid solution for vmangos.

[Wall-core]

Something I noticed as well: The issue resolved here is not present on my system, whereas this other bug is. Disabling this commit changes nothing, namely there is no issue with the channeling of starshards animations. This video is without the above commit applied:

2026-02-19.13-56-31.mp4

[GoonBoiBarry]

Something I noticed as well: The issue resolved here is not present on my system, whereas this other bug is. Disabling this commit changes nothing, namely there is no issue with the channeling of starshards animations. This video is without the above commit applied:
2026-02-19.13-56-31.mp4

Yeah I remember giving the report that commit was addressing. It was 'bugged' at one point where the channel hand visual and sound would end early, which ended up actually being accurate to vanilla according to video evidence of the channel spell 'blizzard' submitted by ratskorb #2216. But the commit was never reverted. It did 'fix' the visual at the time, but messed up the channel sound. I reverted it on my own core a couple years ago and noticed it works almost perfectly on it's own now. Not sure what changed between when it was committed and now, but there you go

[Wall-core]

all the spells with bugged visuals have a few things in common: they have Kit IDs that were added much later after their creation (ids of 300-400 range and one that is 5000+) and they all have cast and impact kits which conflict with their channel kits.

[Wall-core]

After two days of crawling through IDA, I've managed to decompile the spell visual AreaModel creation/rendering/destruction pipeline within the client and have exposed a dangling pointer that nvidia's stringent DX9 fixed-function pipeline cleans up automatically, whereas Intel/AMD rely on an explicit texture nulling which the client does not send. I am working on a solution, perhaps in dxvoodoo2, to resolve this problem without any client mods required. I will also release any fixes into a binary patch for those who wish to mod their client to fix it. Afterwards I'll see if it's possible to get AMD or Intel to apply a patch for it in their drivers.

[Wall-core]

I have made further progress in diagnosing and fixing this. I have referenced Balake's IDA database for the client SMSG_SPELL_GO function. After having disabled SMSG_SPELL_GO, the spell is partially fixed. This isn't a valid solution but it points to a packet ordering issue. The client may expect a better order for MSG_CHANNEL_START before processing SMSG_SPELL_GO. I will continue researching this issue over the coming week.