Checked DLL access and administrator rights. Unfortunately it doesn't work. This is probably the problem of the program exporter, since the rest of the extension functions work. What is the version of the engine during development? I checked 294.14 and 292.22 where the results are the same
Viewing post in Spine Extension for Clickteam Fusion 2.5 comments
We have confirmed that it works in both versions, so I don't think it is a version difference.
(We did not make it to target a version).
From the fact that the DLL at startup was placed in the windows system folder and worked
It seems to me that the working directory at runtime has something to do with it.
I'll get back to you when I figure something out.
For example, if you build with UnPackEXE, you will find d3dx9d_43.dll in Modules.
This is because CF2.5 loads the DLL in "Runtime" at build time.
If there is no DLL in "Runtime", an error popup appears at build time.
(And I found a bug where the executable file output by UnPackEXE could not be started, but that's another story)
I have already encountered the lack of DLL in Runtime.I installed it forcibly, and this solved the problem. But the game eventually turns to external sources anyway. Placement in the catalog on (C:\Program Files (x86)\Clickteam Fusion 2.5\Data\Runtime) also did not bring a solution. Placing the DLL in C\Windows allows the project to work as well. But later it accesses the external directory anyway. It looks like there are no communication options left.
I checked UnPack builds the DLL into modules. But the game continues to search for an external resource the same way. It's desperation.
We have prepared a "test_ext38.zip" file.
Overwrite this with the extension for building "Data\Runtime\Unicode"
Please experiment to see if the DLL is called by the built executable.
This is a slightly modified version of the program regarding DLL calls.
(Since this is for experimental use, only the stand-alone data for building for spine 3.8)
If the data inside the binary is not called even though it is registered inside the binary, it is thought that there is a mismatch between the information required for the call and the information recorded inside the binary.
If you can provide us with an mfa and resource file that can confirm what is happening, we can conduct a deeper investigation.
Of course, we only need to be able to confirm the event, so the resources you use can be copyright-cleared.
(e.g. filled images, etc.)