OpenJK caches mod .dlls?

[razorace]

Is OpenJK intentionally caching loaded .dlls in the /my games/<modname> folder whenever loading a mod? 

 

This is causing a frustrating problem when actively working on .dll code.  Whenever I compile new versions of the .dlls, I have to manually delete the cached .dlls for my newly compiled .dlls to work correctly.  Is there a setting I can set to ignore the cached .dll files?

[Exmirai]

run game with  +set fs_homepath "."

[Raz0r]

The behaviour for extracting DLLs is the same is retail JA.

We introduced proper user profile support on all OSes (not just *nix) so people no longer have to run the game as admin.

 

There are a few ways around this when developing:

• Compile with the portable switch, or run with +set fs_homepath "."
• Build your DLLs and PK3s into whatever fs_homepath is set to
• Split everything up: +set fs_homepath "<generic-writable-directory>" +set fs_cdpath "<mod-working-directory>" +set fs_game "mymod"

  This will assume the current directory is your install directory, i.e. read-only folder containing just base/assets*.pk3 and you can install mods etc to the generic fs_homepath directory which you treat as a writable GameData folder.

So there's no bug or issue, you're just using a method that incidentally worked well with retail JA.

I recommend leaving the cwd/base directory entirely clean with just assets*.pk3, using fs_homepath to store your long-time mods/configs/screenshots, and using fs_cdpath (game will only read from there) for your work-in-progress assets and DLLs

 

As an added bonus, I have my fs_homepath on Dropbox so I can play with the same profile on all computers.

[Xycaleth]

Is OpenJK intentionally caching loaded .dlls in the /my games/<modname> folder whenever loading a mod? 

 

This is causing a frustrating problem when actively working on .dll code.  Whenever I compile new versions of the .dlls, I have to manually delete the cached .dlls for my newly compiled .dlls to work correctly.  Is there a setting I can set to ignore the cached .dll files?

Just to clarify, where are you putting your mod DLLs? I'm assuming in GameData/<mod name> but you didn't mention this. Ideally, people should be using only the My Games/OpenJK/ folder but old habits die hard and we're not sure how to persuade people to change their habits. Although, looking at the current code in OpenJK, it should be loading the DLLs from your GameData/ folder first :/

[ensiform]

Right, as Raz0r said it isn't doing anything differently other than using fs_homepath for ALL writes.  If you have dangling dlls in the GameData/mod folder it'll still try to use those though.

 

FWIW, I would recommend getting the value of fs_basepath and setting fs_homepath to that directly instead of using the "." shortcut.  Not all things know how to actually do proper comparison on "some path" and "."

[razorace]

Before I continue, here are my Visual Studio debug settings.

 

Command: D:\Steam\steamapps\common\Jedi Academy\GameData\openjk.x86.exe

Command Arguments: +set fs_cdpath "D:\QRS_Depot\OJP\Enhanced" +set fs_game ojpenhanced +set fs_dirbeforepak 1 +set sv_pure 0 +set viewlog 1 +devmap mp/duel4

Build Output Folder: D:\QRS_Depot\OJP\Enhanced\ojpenhanced\

 

I'm working on a mod based off the original JKA SDK code and the autobuilt openjk executables are simply dropped into my steam install directory for JKA.  (The steam executables don't allow Visual Studio debugging due to their DRM.)

 

The behaviour for extracting DLLs is the same is retail JA.
We introduced proper user profile support on all OSes (not just *nix) so people no longer have to run the game as admin.
 
There are a few ways around this when developing:

• Compile with the portable switch, or run with +set fs_homepath "."
• Build your DLLs and PK3s into whatever fs_homepath is set to
• Split everything up: +set fs_homepath "<generic-writable-directory>" +set fs_cdpath "<mod-working-directory>" +set fs_game "mymod"
  This will assume the current directory is your install directory, i.e. read-only folder containing just base/assets*.pk3 and you can install mods etc to the generic fs_homepath directory which you treat as a writable GameData folder.

So there's no bug or issue, you're just using a method that incidentally worked well with retail JA.
I recommend leaving the cwd/base directory entirely clean with just assets*.pk3, using fs_homepath to store your long-time mods/configs/screenshots, and using fs_cdpath (game will only read from there) for your work-in-progress assets and DLLs

As an added bonus, I have my fs_homepath on Dropbox so I can play with the same profile on all computers.

 

Please clarify as to what the "portable switch" is.

 

Adding +set fs_homepath "." to my existing Command Arguments just cause a crash immediately on startup.

 

I'd rather not build into my fs_homepath because my mod's working directory is inside my source control folder structure.

 

Adding +set fs_homepath "D:\Steam\steamapps\common\Jedi Academy\GameData" makes the game use "D:\Steam\steamapps\common\Jedi Academy\GameData\ojpenhanced" for read/writing cfgs and cached .dlls.  However, this doesn't solve my problem as the game still attempts to use cached .dlls in "D:\Steam\steamapps\common\Jedi Academy\GameData\ojpenhanced" over the latest .dlls in "D:\QRS_Depot\OJP\Enhanced\ojpenhanced\".

[ensiform]

Portable switch is an option you can set during the compliation of the OpenJK code.  To make it not use homepath at all.  This will never be defaulted on the main builds.

 

The ordering that dlls are loaded from with OpenJK are as follows:

fs_basepath, fs_homepath, fs_cdpath.

 

In jamp it was just fs_basepath, fs_cdpath.

 

So, going with your most recent attempted changes try this:

• Don't have any of your game DLLs contained in a pk3 within the mod folder
• Make sure there are no game DLLs within the mod folder.