I build for windows, and when I try to run the .exe, I get this error:
What’s funny, is if I search the folder for “OpenAL32.dll” I get a result in the build folder. When I right click and “Open containing folder”, the file is not there!
If I right click the search result, copy, then paste into the build folder, it says the file is no longer there! It’s a ghost file!
Sounds like antivirus programs, do you have one installed?
No sir, haven’t used one of those since the DOS days of Buster virus!
OK, and what version of Defold are you using?
1.9.1
For what it’s worth, this project is built sometimes in Linux, and sometimes in Windows, from the same folder. I don’t know how many people dual boot like I do, so not sure if that causes some strange issues.
Also I tried using the version of Java that comes with Defold, this is what my build batch file looks like when building in Windows, for Windows;
"D:/SteamLibrary/steamapps/common/Defold/packages/jdk-17.0.5+8/bin/java.exe" -jar bob.jar --platform=x86_64-win32 --bundle-output "build/windows" --variant debug
The dll should be next to executable when you bundle. Which version of Windows are you using? Which location are you bundling to?
Okay, crisis averted by LCATFM (looking closer at the f-ing manual)
I got it working but it’s a point of curiosity, why my build script was causing this mysterious behaviour. This is what it used to be;
"D:/SteamLibrary/steamapps/common/Defold/packages/jdk-17.0.5+8/bin/java.exe" -jar bob.jar --platform=x86_64-win32 --bundle-output "build/windows" --variant debug
When I looked closer I noticed, for some reason instead of being in a folder called “build/windows”, it was ending up in the folder “build/x86_64-win32”, so the layout of this build command is causing more than one screwy thing to happen, it seems. I actually think I got the basis of this command this from ChatGPT… but since it seemed to work I didn’t think the command structure was a problem, it was outputting a build…
Anyway after following the manual example more closely I came up with this;
"D:/SteamLibrary/steamapps/common/Defold/packages/jdk-17.0.5+8/bin/java.exe" -jar bob.jar --archive --platform x86_64-win32 resolve distclean build bundle --bundle-output "build/windows"
and my windows build ends up in a subfolder of build/windows as expected, with OpenAL.dll intact and the game is fully functional.
It’s just very strange that malforming the build command in any way could cause such strange behaviour as ghost files!!
I would try a different bundle folder, that isn’t in ”build”.
Try e.g ”—bo bundle_win64”
The build/x86_64-win32 folder is where the engin build ends up after being built on the cloud server (or unpacked from bob if you don’t us extensions).
It is part of the ”build” command.
The ”bundle” command is what actually bundles the game, and extracts the OpenAL library.
Ah I didn’t realise that thank you, that explains some things I noticed…