 |
The old behavior was: if there is a dll next to the exe (in the doom3 folder): the exe takes this one (this was convenient for developers) else: extract dll from pk4 into darkmod folder and use this one So, now the exe is now sitting in the darkmod folder and finds a dll, so it thinks it can use this one and doesn't extract it from the pk4. If we let the exe always extract the dll from the pk4, this will be inconvenient for developers. A possibility would be to use time stamps or similar. Another suggestion would be to let the updater handle the issue: let the updater extract the dll from the pk4 into the darkmod folder, disable the code that lets the exe extract it (at least on windows, I don't know what happens on Linux). |
 |
Why is it inconvienient for developers? At least on linux, when you rebuild the DLL, it gets put as ".so" into the directory, as well as stuffed into a .PK4. So regardless of wether it is extracted or not, the new DLL is used. Can't the build process on Windows not be changed to do the same? |
 |
Quick fix implemented in SVN revision 0005577. Existing game dll/so in the darkmod/ directory is ignored and the game dll/so from tdm_game0x.pk4 is extracted and loaded on startup. A more refined fix will be implemented in SVN for future releases. I will mark this issue closed when the refined fix is implemented (whether that be a simple build process change for the Windows project or adding additional logic to the game dll/so loading code). |
 |
I'm moving this from 1.08 to 1.09. taaaki's temporary fix solves the problem for 1.08. His long-term fix will go in later. |
|
|
darkmod_src revision 5723 - A timestamp check has been added to the code that determines whether to use the existing game dll/so in the executable directory or the one in the game pak file. I will mark this issue resolved if there are no issues reported in a week or two. |
|
|
No issues that I am aware of, so closing this. |
|
|
Seems that all is not well. http://forums.thedarkmod.com/topic/14840-more-filesystem-changes-yay/page__view__findpost__p__312950 |
|
|
I can't manage to reproduce this. Every time I throw in a gamedll that is older than the one in the pk4, the new LoadDLL/FindDLL code seems to pick it up and extract the dll from the file. How many other people have experienced the dll issue? I think this will need to be thoroughly tested during the freeze. |
|
|
Any help with conditions to reproduce this would be appreciated. |
|
|
We'll have to test this during the freeze, when we have a package we can load over the top of a 1.08 installation. |
 |
It seems like this is still happening. -------------------- I've just ran the updater under Windows 7 64bit. I've made a differential update from 1.08, with the keep mirrors setting enabled. The update itself worked like a charm. But if I try to run the game via the TheDarkMod.exe, the game crashes. --------------------- Was there a gamex86.dll sitting around after the upgrade? If so, delete it and try restarting TDM. ------------------------ Allright. That was the problem. EDIT: If this can cause such problems, it may be a good idea if the updater/installer would check for such a file and delete it if existent. I guess most people will do a differential update after 2.0 release and may miss this hint. |
|
|
Thing is, the current TheDarkMod.exe looks at the file timestamps for the existing gamex86.dll and the one inside the pk4. It will then make a decision to extract/overwrite the existing dll based on which has the later timestamp. I'd like to find out if other people experience the same issue. If so, it might be a problem with the timestamp comparison. |
|
|
That being said. It might make life easier to just get the updater to delete gamex86.dll / gamex86.so regardless. |
|
|
What is the expected behaviour here? I just ran tdm_updater yesterday and it downloaded some new files, but it did not delete gamex86.dll. Is it supposed to? |
|
|
Yes. I'm moving the code that does the removal so that it will be done regardless what type of installation/upgrade you do. |
|
|
I forgot to check on the last update if this happened or not. |
|
|
Fixed in the 8/20 build. |
|
|
Just checked on the last update and it was deleted successfully. |
- Anonymous
