Yes, latest master works, no more manual mangling with the code needed for Vulkan on Debian. And smart approach to the problem BTW! Thanks! 
Now let’s do some Vulkan-powered Ridge Racing…!
1 Like
Tried the Latest Version but I get this Error:
Using Docker
I don’t get what it Means and how to fix it
Try cleaning up the folder and also build with this command
docker build --no-cache -f Dockerfile.windows -t goosestation-builder-windows .
I made a New Folder for it and it Worked but says it’s Version 0.3 (24 May 2026 13:52:57) from the 0.6 Version from the Link you gave to Download it from
It’s here:
https://codeberg.org/hueponik/goosestation-builder/archive/v0.6.1.zip
BTW I’ve tagged v0.6.1 to address some regressions
1 Like
Use that and Got the Same Thing saying it’s version 0.3
Found it, I forgot to bump upstream revision in the dockerfiles. try re-downloading same v0.6.1
1 Like
Did that and sadly same Issue
See Here:
Could you forgot to change up the top?
As File Size was bigger then last one I built
0.6.1 Just build today
Echoing reported by DemitryCzarevich,
Retroarch on Switch, seems a new mcd file is created every time you save, unable to load most recently saved file. Testing on Final Fantasy VII.
1 Like
Can’t use switch rn, but tried to replicate this on 0.6.1 with wipeout xl, it shows memcard content. I do save then restart and go back to save/load menu. The save is still there after restart…
This could me multi disc game fail, I’ll check this later.
… And still can’t reproduce
Save in ff7, restart RetroArch, start disc1, load - file is there. Start disc2, load - file still there
…reproduced. Looks like saving in one game overwrites save from another game. And 2 different discs of ff7 are considered same game. Which is good actually, gamedb multidisc works! I’ll get this fixed
3 Likes
Check v0.6.2 (https://codeberg.org/hueponik/goosestation-builder/archive/v0.6.2.zip), memcards should be fixed now
2 Likes
It seems that after adding the UPSTREAM_COMMIT file to store the variable for the downloaded DuckStation build within the Makefile script itself (I’m not familiar enough with the code to say for sure), these very UPSTREAM variables were lost, because while the tarball is downloaded, it isn’t extracted into the src/ folder, the duckstation-e8938f06347e4837c32ef4c71c21cbd43245f244 folder is created, but it is empty; even if you manually unpack the contents of the tarball from the .cache folder into it, the script stops with the same error
I compiled version 0.6.1 without any issues, but I ran into problems with version 0.6.2
1 Like
Still running into memory card issues in 6.2 on switch.
Each time the file is saved, a new mcd file is created (screenshot)
1 Like
I think you’re missing rsync, which is now a requirement. I use it to avoid stale builds and still be able to not rebuild everything every run (which I do tons)
1 Like
Thanks for the report! This appears to be switch’s thing, you can’t rename into existing file there.
The fix is on master branch
Okay that works now with Update
1 Like
@hueponik Thanks for the tip about rsync; I installed that package and the core compiled without any issues. And thanks for adding a short SHA for the core version to the info file - I was just about to ask for that feature, since I wanted to know which version of DuckStation is used when building the core.
Tests: I haven’t encountered any issues with memory cards (Windows OS), including with multi-disc games; this might be because I launch them from an .m3u list, and my memory card is named using the .m3u file name plus the memory card slot number (e.g., Final Fantasy VII [PAL] [ENG] [Europe]_1.mcd).
Unfortunately, the issue with being unable to properly close content that isn’t from “History” or “Playlist” remains, alas 
The only solution is to completely restart RetroArch.
1 Like
The New Version Updates fine for me now
1 Like
first load the Goosestation core via the “Load Core” menu, then load the game via the “Load Content” menu, play for a bit (even just watch the opening screens), and then select “Close Content” - the core resets but does not unload completely;
Hm, it’s not crashing or anything is it? I think this is “by design”. I wanted to add the mode where you can just boot bios without the game.
So you load the core. Then you can either load the game with it or just boot it. Then if you close content, you don’t close the core… You can also use “unload core” button to actually unload the core.
What’s your usage scenario that is ruined by this logic?