Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(3 edits)

I'm sorry, I made a mistake with the address of the library.But I fixed it and it still doesn't work. Does the build, but still searches for external files. How can this be solved? Is the reason possible in the revision of the engine?

(1 edit)

I think it has something to do with the previous problem of poor loading at startup.

On startup, I get.

"C:\Program Files (x86)\Clickteam Fusion Developer 2.5\d3dx9d_43.dll"

Basically, this should work, but this is the story of the failure to load it.

As in this case, I think the file in Runtime is not being read.

For example, maybe you don't have permission to access the file.

Maybe you could try running CF2.5 with administrator privileges or check the permissions to access the file (DLL) in question?

(4 edits)

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

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.

(1 edit)

If it is built into UnPack, then there doesn't seem to be a build problem.

I am wondering why the DLL is not called.

Would a minimal build, such as the sample file, do the same?

(I can also think of possible effects due to interference from other extensions, perhaps.)

(2 edits)

I tried to build your project specifically. The result was sad identically. That is, the complexity of the project does not solve. The program or add-on does not work specifically in this function, but it works in the rest.

(2 edits)

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)


(2 edits)

I'll check later. My foreign assistant can't download it yet. (I'm in Russia)

The only other thing I can think of is that anti-virus software is blocking the call.

I see that the DLL calling issue was resolved.
(If so, no need for a TEST)

I will continue to investigate the binary embedding call.