[Crash] DK bananza crashes on loading world on AMD 6000th gens

Before submitting

I searched existing issues and found no duplicate
I'm using the latest build
My game is legally dumped from my own console

Emulator build

all of them to build 206

Regression

This is a regression (it worked in an older build)

Last known working build

No response

Game

Donkey Kong Bananza

Graphics card

AMD RX 6000 series or older

Operating system

Windows 11

Steps to reproduce

boot the game
pick a save
wait for it to load
crash

this is a known problem on all RX 6000 series using windows. it only works on pokedinner fork and the rest just result in crashes.

Log / crash dump

eden_log.txt

Adding the faulting module and offset, since I hit the same wall on an RX 5700 (RDNA1, Windows 11, build-206) and the report above does not name it.

exit code        C0000409  (STATUS_STACK_BUFFER_OVERRUN, the driver's own fast-fail)
faulting module  amdvlk64.dll 32.0.21045.1000 +0x2ECD41D
repeatability    same module and same offset in five boots
WER dump         50 MB written each time

What happens right before, from the emulator log:

DefineEntryPoint: Geometry ...                    <- a pipeline with a geometry stage
26 to 27 graphics pipelines created in ~1.3 s    (1920x1080 and 960x540)
45 to 46 "Draw skipped (no pipeline)"             in the same burst
Native graphics shader rejected                  0 in every session

So the session reaches the first 3D scene, builds a couple of dozen pipelines in one burst, skips two dozen draws for having no pipeline, and the AMD driver takes the process down with a fast-fail. It is not an access violation the emulator could catch, and it is not a rejected shader.

Two things I checked that narrow it:

It reproduces with and without EDEN_NX2_EXPERIMENTAL_GEOMETRY=1. With it, the session parks on the adventure-hint screen until input and dies on the following burst at t=175.9 s; without it the load runs on its own and dies at t=84 s. The variable changes when it dies, not whether.
VkLayer_crash_diagnostic did not attach for me (zero output), so I do not yet have the Vulkan call. VkLayer_api_dump is next.

Your report says the PokeDinner fork works. That is consistent with a driver-triggering pipeline state rather than a title bug: PokeDinner is based on an older nx2 and builds different pipeline state for the same scene.

If anyone on RX 6000 has the same offset, it is worth saying so here, because a fast-fail at a fixed RVA across cards points at a specific invalid structure we hand to the driver rather than at a race.

I got the failing call with VK_LAYER_LUNARG_api_dump (the SDK layer is named VK_LAYER_LUNARG_api_dump, not after the file, and it has to be registered under HKLM\SOFTWARE\Khronos\Vulkan\ExplicitLayers before the loader will take it).

The dump ends exactly where the process dies:

Thread 15, Frame 1590:
vkCreateGraphicsPipelines(device, pipelineCache, createInfoCount, pCreateInfos, pAllocator, pPipelines)
    createInfoCount: 1
    stageCount:      2

and it never comes back. So the C0000409 fast-fail in amdvlk64.dll +0x2ECD41D happens inside vkCreateGraphicsPipelines, not on a draw and not in shader translation.

What the pipelines in that burst carry, by stage, counted from the dump right before the end:

VK_SHADER_STAGE_VERTEX_BIT                 79
VK_SHADER_STAGE_FRAGMENT_BIT               51
VK_SHADER_STAGE_GEOMETRY_BIT               40
VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT   36
VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT 36

So the state we hand the driver combines geometry with tessellation. That points at one thing I would check before anything else, and it is in our own code:

if (has_tess_stages) {
    // The Vulkan spec requires patch list IA topology be used with tessellation
    // shader stages. Forcing it fixes a crash on some drivers
    LOG_WARNING(Render_Vulkan, "Patch topology not used with tessellation, using patch list");
    input_assembly_topology = VK_PRIMITIVE_TOPOLOGY_PATCH_LIST;
}

We override the topology to PATCH_LIST whenever a tessellation stage exists. If the rest of the pipeline state is built from the game's original topology (the patch control points, the primitive restart flag, the tessellation state), the driver receives a VkPipelineTessellationStateCreateInfo that does not agree with the topology it was forced into. AMD's driver answers that with a fast-fail instead of a VkResult.

That is a hypothesis, not a conclusion, and it is testable cheaply: the same title with the override removed, or with the topology kept and tessellation rejected explicitly, and see whether the burst survives. I do not have a build environment here (my local MSVC build fails on __std_rotate against the shipped Qt), so I cannot hand in a patch, but the api_dump and the layer registration steps above should let someone reproduce this in one run.

I also want to be explicit about what this is not: Native graphics shader rejected is zero in every session, so the shader translation gaps in #437 and #492 are not what ends this process.

Adding the faulting module and offset, since I hit the same wall on an RX 5700 (RDNA1, Windows 11, build-206) and the report above does not name it.
exit code        C0000409  (STATUS_STACK_BUFFER_OVERRUN, the driver's own fast-fail)
faulting module  amdvlk64.dll 32.0.21045.1000 +0x2ECD41D
repeatability    same module and same offset in five boots
WER dump         50 MB written each time
What happens right before, from the emulator log:
DefineEntryPoint: Geometry ...                    <- a pipeline with a geometry stage
26 to 27 graphics pipelines created in ~1.3 s    (1920x1080 and 960x540)
45 to 46 "Draw skipped (no pipeline)"             in the same burst
Native graphics shader rejected                  0 in every session
So the session reaches the first 3D scene, builds a couple of dozen pipelines in one burst, skips two dozen draws for having no pipeline, and the AMD driver takes the process down with a fast-fail. It is not an access violation the emulator could catch, and it is not a rejected shader.

Two things I checked that narrow it:

It reproduces with and without EDEN_NX2_EXPERIMENTAL_GEOMETRY=1. With it, the session parks on the adventure-hint screen until input and dies on the following burst at t=175.9 s; without it the load runs on its own and dies at t=84 s. The variable changes when it dies, not whether.

VkLayer_crash_diagnostic did not attach for me (zero output), so I do not yet have the Vulkan call. VkLayer_api_dump is next.

Your report says the PokeDinner fork works. That is consistent with a driver-triggering pipeline state rather than a title bug: PokeDinner is based on an older nx2 and builds different pipeline state for the same scene.

If anyone on RX 6000 has the same offset, it is worth saying so here, because a fast-fail at a fixed RVA across cards points at a specific invalid structure we hand to the driver rather than at a race.

i...ii uhh. i dont understand all this, does this mean this can be fixed for main eglantine branch?

Short version, in plain words.

What is happening on your card

The game reaches the first 3D scene, the emulator asks the AMD driver to prepare a batch of drawing setups, and the driver gives up in the middle of that request. It does not return an error, it closes the program. That is why there is no error message for you to read and why every build crashes the same way: the crash is not in the emulator code, it is inside the driver file amdvlk64.dll, always at the same place.

Is it fixable

Yes, and probably on the emulator side, not on your machine. The setups in that batch contain geometry and tessellation stages, and we may be sending the driver a combination it does not accept. If that is the case, the fix is in the emulator code, one of the maintainers builds it, and your card stops crashing. Nothing you can change in settings will fix it, so do not spend time reinstalling drivers.

Why PokeDinner works for you

It is built from older emulator code, so it prepares those setups differently. That is consistent with the problem being on our side rather than a broken Radeon.

What would help

If you can run the emulator once with the dump layer on and it also dies at amdvlk64.dll +0x2ECD41D, say so here. Two different cards hitting the same address is strong evidence, and it turns this from "my machine" into a real bug report the maintainers can act on.

no its not just you theres like 4 others with 6000 and older gen AMD cards who crash on anything other than pokedinner, your theory is correct.

That is the useful data point, thank you. Four or more cards from the same generation crashing the same way, and only PokeDinner surviving, is no longer a machine specific problem, it is a bug with a population behind it.

Two things that would make it count:

Ask the others to post their card model and, if they can, the line from Windows Event Viewer showing the faulting module. If it is amdvlk64.dll with the same offset on every card, nobody can write it off as a driver install.
Anyone with the PokeDinner fork working: note which emulator build it is based on. That tells us roughly which change started it, and it is the fastest way to a fix.

I am also trying to get a local build going so I can test the tessellation pipeline change myself instead of only reporting it. If that works I will post the result here rather than asking someone else to build it.

yes all of them can use pokedinner fine. their cards if i recall correctly are all on the 6000th gen. one being 6800 xt another 6700 xt and a 6900 xt
the other one with a 6700 xt like mine can in fact load in other emulators using the LINUX OS they have. but using windows still results in a crash for them.
and as for your question. most of them are capable of running all pokedinner builds. from the first to the the latest one

if you need i'll ask them for their LOGS and post it

Yes please, send them. More data is worth more than a clean thread here.

What is most useful, in this order:

The emulator log of a crashing session (eden_log.txt), from boot until the crash, without trimming. The last 30 lines matter most, but I want the whole file because the pipeline burst starts well before that.
The Windows Event Viewer entry for the crash: Application log, Error, source Application Error. I need the faulting module and the offset. If it says amdvlk64.dll and an offset, that is the single most valuable line, because we can compare it across cards.
Card model and driver version, plus whether the crash happens on every AMD build or only some.
If any of the other four still has the PokeDinner fork, the emulator build it reports in its title bar. That gives a rough "last good" point, which is what turns this from a mystery into a bisect.

If the logs are big, attach them as files to the issue rather than pasting, that is fine.

One thing that is NOT needed: reinstalling drivers or Windows. Four cards failing identically is not a broken install, and I would rather have your logs than another clean driver install.

its definitely not a bad install. my windows is perfectly fine. this is a known issue on 6000 cards so its not a mystery. the fix is mystery though. this is a thing on AMD cards up to RDNA 2

think you can tell this to the main developers so eglantine itself can work?

The hypothesis holds. I have the A/B now, on an AMD RX 5700 (RDNA1) with the proprietary driver on Windows 11.

The change I tested is one line in vk_graphics_pipeline.cpp, behind a variable so nothing else moves:

// before
if (has_tess_stages) {
    LOG_WARNING(Render_Vulkan, "Patch topology not used with tessellation, using patch list");
    input_assembly_topology = VK_PRIMITIVE_TOPOLOGY_PATCH_LIST;
}

// after
if (has_tess_stages && !std::getenv("EDEN_NX2_NO_PATCH_FORCE")) {
    ...
}

Control, same title, same save, same settings, same machine

with the override       dies at 78 to 90 s      C0000409 amdvlk64.dll +0x2ECD41D
                        or 134.9 s on my own build of the same tree

With the override skipped

309 s and still running when I stopped measuring
332 presents, 5.7 GB working set
first 3D scene rendered, HUD active, "Explore the mining tunnel", Y Punch prompt on screen
no crash, no driver fault

So the fast-fail is caused by the forced PATCH_LIST topology, not by anything in shader translation. That also explains why PokeDinner survives: older code did not force it.

Two caveats so nobody over-reads this:

Skipping the override violates the Vulkan spec, which requires patch list topology with tessellation stages. It survives here, which suggests the tessellation stages involved in this title are not doing real tessellation work and the state we hand the driver was the inconsistent part. A proper fix probably needs either the tessellation state to be built consistently with the forced topology, or the pipeline to reject tessellation rather than fake the topology.
With the override skipped I see 35 Native graphics shader rejected lines that were not there before, so this is not free. Worth checking which stages those are before anyone calls it fixed.

I cannot hand in a PR for the real fix because I do not know which of the two directions the maintainers want, and picking wrong would change behaviour for titles that legitimately use tessellation. What I can say is that this is reproducible in five minutes with the dump layer and this env var, and that the population on RX 5000/6000 series would notice immediately.

A comparison that narrows this down, now that I have both binaries on the same card.

My build, stable. Base ddfea92df7 plus #443 (geometry), the Phi type mapping and a few build fixes:

396 s, presents climbing, no crash
0 shader rejections
3 draws skipped

Official builds 206 (c54bc228) and 212 (d6efc8e), same card, same title:

die at 78 to 100 s inside vkCreateGraphicsPipelines
amdvlk64.dll 32.0.21045.1000

Both official builds already contain #443 and the frame wait, so neither of those is the trigger, and since 206 already fails the window is 244 commits between ddfea92df7 and c54bc228. The ones that touch this title's path:

fef7d2fc6c kepler_compute: emulate tensor programs only for Donkey Kong Bananza
721b189bb7 kepler_compute: emulate all of Donkey Kong Bananza's tensor programs
3944c47805 kepler_compute: emulate tensor programs that no upscale stands in for
204ae115e4 nx2: count the presents that return before their frame is done
6a22450d82 nx2: wait for each of Donkey Kong Bananza's frames
55274de6af vk_scheduler: keep waiting for a deferred submission instead of giving up

The tensor trio is the first thing I would test, because a compute program that starts being emulated is exactly the kind of change that puts new state in front of the driver. I tried to take those three onto my stable base and the cherry-pick conflicts in kepler_compute.h, so it is untested. Writing it here so nobody repeats the work: one bisect build on that trio settles it.

Also worth recording, since it changes what "AMD crash" means here: with the Phi mapping present the title reports zero rejected shaders, and without it 76 rejected shaders and 64 skipped draws, which is the invisible geometry people describe. So at least two of the complaints in this thread have different causes, and one of them is already addressed by an open PR (#492).

Laymans terms?

eden_log.txt
I seem to have the same issue on 6600XT.

Faulting module: amdvlk64.dll
Module version: 32.0.21045.16010
Exception code: 0xC0000409
Fault offset: 0x0000000002ECD3BD

Immediately before the crash, the log shows:
Geometry shader passthrough used with no support
Draw skipped (no pipeline)

happens on both standard and pgo versions

A second AMD behaviour, different from the crash and much easier to work with, because the driver refuses cleanly instead of killing the process.

Mario Kart World, same RX 5700, current build:

1861 presents, playable
0 shader rejections
23 "Graphics pipeline build failed: VK_ERROR_INITIALIZATION_FAILED"
22 distinct pipeline hashes
draws skipped as a result: 128x128 x34, 1920x1080 x24, 960x540 x5, plus 12 at 64x64

What you see in game is a large black region over the track where the terrain should be: the geometry is there, the pipelines are not, so the draw is skipped and you get the void. The 64x64 targets are the size of shadow cascades, which would also explain the shadow problems people report on AMD.

Two things make this worth separating from the crash report:

It is a VkResult, not a fast-fail. The driver says no and keeps running, so you can reproduce it as many times as you like and the session survives. That is the closest thing to a debugger we have on this side.
It is the same family. Both are graphics pipeline state that AMD refuses, one politely and one by killing the process. If someone finds which field is invalid here, it is a good bet the same field matters in the crash.

I have the 22 hashes from an environment gated trace I added locally (EDEN_NX2_PIPE_TRACE). My first version of the trace logs the hash and topology but not the create info fields, and the stage hashes came out zero, so the next iteration logs the full state before the call. If a maintainer tells me which fields matter, that is one build away.

Found it, and it is deterministic. I logged the full create state before every driver call on this card, then counted which states the driver refuses.

topology                created   failed
TRIANGLE_LIST (3)          1588        0    (0%)
PATCH_LIST   (10)            15       15    (100%)
POINT_LIST   ( 0)            10        8    (80%)

Every single pipeline with patch list topology fails with VK_ERROR_INITIALIZATION_FAILED, and nothing else does. In game this is the black region over the track: those 15 pipelines are the tessellated surfaces, their draws are skipped, and there is nothing drawn there.

The create state of the failures, identical in all 15:

stages=3  topo=10 (PATCH_LIST)  restart=0  patches=32
att=1  samples=1  poly=FILL  cull=NONE  depthTest=0  depthOp=7

patches=32 is present on the ones that succeed as well, so the patch control points are not the discriminator; the topology is, and it fails at 100%.

This lines up with something I got wrong this morning and then retracted: vk_graphics_pipeline.cpp forces

if (has_tess_stages) { input_assembly_topology = VK_PRIMITIVE_TOPOLOGY_PATCH_LIST; }

when the game's topology is not patch list. I retracted the claim because in the session I measured, that branch had not run. Now I have a session where it clearly does run, and every pipeline it produces is refused. The driver is telling us the state is invalid, not just drawing it wrong.

The same forcing is the best explanation for the crash, because in Bananza the driver does not return an error for it, it fast-fails the process in vkCreateGraphicsPipelines, which is what I captured with api_dump at the start of this thread.

Note also that POINT_LIST fails 8 out of 10. That is the other rewrite in the same function, Patch topology used without tessellation, using points, and it produces the same class of invalid combination in the other direction.

What this means for a fix, and I would rather the maintainers decide which one:

Stop rewriting the topology and let the tessellation stages be rejected with the rest of the pipeline, so the draw is skipped instead of producing invalid state.
Keep the rewrite for drivers that accept it and skip it on this one, detected through driver_id plus the Windows vendor path.
Find which tessellation stage combination the driver does accept, and build that instead of a bare patch list.

I have the environment gated trace (EDEN_NX2_PIPE_STATE) working and I am happy to run any build with it. What I cannot do is decide for this project which of the three is acceptable, because two of them change behaviour for every title that tessellates.

The measurement is done, and the cause is the rewritten topology, not the formats.

I logged the full create state immediately before every driver call on the RX 5700 and counted refusals per topology:

topology                   created   refused
TRIANGLE_LIST (3)             1588        0
PATCH_LIST   (10)               15       15
POINT_LIST   ( 0)               10        8

Formats, sample count, depth format, attachment count and patch control points are identical between pipelines that succeed and pipelines that fail. The same colors=[202] depthFormat=22 att=1 combination builds 64 times as a triangle list and fails every time as patch list. So it is not the attachment, not the render pass, not the depth state, and not tessellation in the abstract: it is the topology the emulator rewrites to.

Both rewrites in vk_graphics_pipeline.cpp are affected, in opposite directions: patch list when tessellation stages exist, and point list when patch list arrives without them.

I tested the fix for the first half. Dropping the tessellation stages by their real stage flag, keeping the game's topology, converts those pipelines into valid ones:

before   15 patch list pipelines, 15 refused, 64 draws skipped
after    14 of them build as triangle lists, 0 failures, draws happen

That is in PR #548, behind EDEN_NX2_DROP_TESS so it changes nothing unless someone opts in.

The other half is not fixed: 23 pipelines still fail, all of them the patch-list-without-tessellation case that gets rewritten to point list. Those need a decision about what to draw when the input state is inconsistent in that direction, and I do not think that decision is mine.

One correction to my earlier message in this thread, for the record: I first reported topology as the cause and then retracted it because a test where I dropped the stages did not help. The retraction was wrong and so was the test: I was dropping stages by array index, which does not map to the tessellation stages, so nothing was actually dropped. Dropping by stage flag is what made the difference.

One more measurement for whoever picks up the second half, since it rules out the obvious suspect.

The remaining 23 pipelines that fail are not attached to a particular render pass. Their failures spread over five different render passes, and 129 pipelines in total are created against those same five, of which only these 23 fail:

render passes involved in failures      5
pipelines created against those passes  129
of those, refused                        23

So the render pass, the attachment format, the depth format, the sample count and the patch control points are all shared with pipelines that succeed. Whatever is wrong is specific to those 23.

What is specific about them: they arrive with patch list topology but the emulator decides there are no tessellation stages, so it rewrites the topology to point list, and the driver refuses the result. A pipeline that requests patch list topology is, by definition, a pipeline that expects tessellation; if we see no tessellation stages for it, the more likely explanation is that we are not finding them than that the title is asking for something meaningless.

That is the hypothesis I would test next, and it needs one instrumented run: log which program slots are populated when that branch is taken. I had a build for it and it segfaults at startup on my machine, so I am reporting the reasoning rather than the result.

Uhhhh what

Sorry, that was a wall of jargon. Plain version:

Good news first. On the emulator as it is right now, Mario Kart World works on my AMD card and the shadows look correct. What used to look like black holes in the track turned out to be shadows that were not being drawn, and that is fixed upstream already. Nothing you need to do.

Bananza runs on the same build, with no rejected shaders and no driver crash, which is a real change from yesterday. It closed once during my test, but I could not tell whether that was the game, the emulator or my own test script stopping it. I am not going to call it fixed until I have played it for a while without it closing.

When you will see it. The next official build should carry most of this. Until it is out, keep the version that works for you.

And the short version of all that technical noise: the crashes were not your card being broken and not your Windows being bad. They were the emulator handing the driver a configuration it refuses. Two of those have been found and one of them is already fixed in the code. That is why the reports from you and the others mattered: without several cards pointing at the same thing, it would still be guesswork.

Found the switch. It is the geometry stage, and the A/B is clean because I can now drive the game myself instead of waiting for a person to play.

Method: scripted input on the same title, same save, same build, same card, 150 second window per run. The script presses through the menus, then walks and punches in a loop, which reproduces the crash on demand.

geometry enabled (default)   4 runs   4 died    exit 0xC0000409 at 136 to 144 presents, 15 to 16 input cycles
geometry disabled            2 runs   2 survived the full 150 s, 47 cycles, 184 to 204 presents

EDEN_NX2_EXPERIMENTAL_GEOMETRY=0 is what changes it, and nothing else about the run changes. Same offset as before when it dies: amdvlk64.dll +0x2ECD41D.

That lines up with what the api_dump captured on the fatal run: three vkCreateShaderModule calls, a descriptor set layout, a pipeline layout, a descriptor update template, then vkCreateGraphicsPipelines on Thread 12, Frame 1884, which never returns. Three modules is a vertex, geometry and fragment pipeline, and it is the geometry one the driver refuses to build.

So the answer to the question in this thread is: the driver is not failing on a shader we translate badly, it is failing on the pipeline state we hand it when a geometry stage is present. With that stage out of the picture the title runs and presents frames continuously.

Practical consequence, and it matters for how this is prioritised:

EDEN_NX2_EXPERIMENTAL_GEOMETRY defaults to enabled (the check is !value || value != "0"), so every AMD user on Windows is running an experimental path by default, and on this card that path always ends in a driver fast-fail.
Setting it to 0 gives a playable session today. What it costs is the geometry-stage effects in whatever scene uses them, which on this title so far has meant some layered geometry rather than the whole scene disappearing.

I have opened a PR to flip that default to opt-in, because a feature called experimental that crashes a vendor's driver should not be on unless someone asks for it. The measurement above is the argument.

What does this mean? You found it?

The last create state before the fast-fail, from the run that died at 140 presents with scripted input:

stages=3  topo=TRIANGLE_LIST(3)  patches=32  att=2  colors=[224,213]
depthEnabled=1  depthFormat=10  msaa=0  samples=1  poly=FILL  cull=NONE

Nothing in it is obviously illegal: triangle list, two colour attachments, depth enabled, one sample, fill, no culling. The only unusual thing is stages=3, which with this title means a geometry stage is present, and that is the single variable that decides whether the process survives:

geometry on   4 of 4 runs died, 136 to 144 presents
geometry off  2 of 2 runs survived, and a third run survived five full minutes of scripted play

So the state is not malformed in a way I can point at from here, and I am not going to invent a field. What I can say is that the driver dies specifically when a graphics pipeline carries a geometry stage, on the state above, at amdvlk64 +0x2ECD41D, and that keeping that stage out of the pipeline is enough to make the title play.

Two things that would help if someone knows this driver:

If the geometry stage requires output topology or a stream setup that we are not setting, that would be a fix rather than a workaround.
If it is a genuine driver defect in this version, then the workaround in video_core: make the experimental geometry stage opt-in instead of default #563 is the right answer for now, and the version number to avoid is 32.0.21045.1000.

For anyone testing: EDEN_NX2_EXPERIMENTAL_GEOMETRY=0 is the switch, and it costs geometry effects, not the game.

Yeah uh I told one of the testers to take a look cuz idk anything here I just wanna get my game running man I'm not a technician

Anything?

dist: install the MIME package under the Lichii app id (Djihads80#511)

Navigation Menu

Repository navigation

[Crash] DK bananza crashes on loading world on AMD 6000th gens #511

Before submitting

Emulator build

Regression

Last known working build

Game

Graphics card

Operating system

Steps to reproduce

Log / crash dump

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Crash] DK bananza crashes on loading world on AMD 6000th gens #511

Description

Before submitting

Emulator build

Regression

Last known working build

Game

Graphics card

Operating system

Steps to reproduce

Log / crash dump

Activity

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

21 remaining items

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

Lankre commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

CloudP4bbs commented on Nov 4, 2026

StevenCrazyFire commented on Nov 4, 2026

StevenCrazyFire commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions