View Full Version : Issues with changes taking effect

06-02-2002, 08:32 PM
I would like to state that I've never coded for a Quake based game before. I am a very experienced programmer in the field game engine design.
However, here is my question. I have compiled DLL files made my changes, and now I am ready to move into the debugging phase. My question is this, what are the exact steps for getting the changes to take effect within the game? I've attached JK2MP.exe to the debugger with the commandline +set fs_cdpath x:\jedioutcast +set r_fullscreen 0 +set viewlog 1 +set fs_game TestMod" to start the mod. x:\jedioutcast is my base directory. I start debugging, and my VS.net debugger attaches to the process correctly. Everything seems to start fine, except once the game loads, my changes have not taken hold, even the more simple ones as described in the simplemod file.

Also, when they say "YourJK2Path" do they mean the base directory, gamedata or somthing else completely?


06-02-2002, 08:39 PM
Well, I have yet to get DLL's loaded myself into the game, so right now I have been building the VMs for testing. Maybe you can try that untill someone who knows how to get the game started using DLLs comes along. :jawa

And generally, "YourJK2Path" represents INSTALLDIR\GameData, as the game files are in that.. I myself moved the files out of the GameData and placed them in INSTALLDIR as I don't use the launcher.

06-02-2002, 08:50 PM
Thanks for the explaination. That worked very well :D. Time to set up the post build steps, and get on to the code that really matters.


06-02-2002, 08:55 PM
No problem, and good luck. :cool:


06-02-2002, 09:39 PM

Did you get the game to run from VS in the end then - or are you just using the batch files now?

If you ARE getting it to run from VS now - what did you do? Cos I'm getting the same thing you are / were...

06-02-2002, 09:58 PM
Try this one:

X:\jk2\GameData\jk2mp.exe "+set r_fullscreen 0 +set fs_game modname +set vm_game 0 +set vm_cgame 0 +set vm_ui 0 +set sv_pure 0"

06-02-2002, 10:26 PM
Na - those extra command-line settings haven't made any difference - my rockets are still as fast as ever!!

They worked for you then Subject?

06-02-2002, 10:34 PM
They sure did

06-02-2002, 11:00 PM
Worked fine for me too.

06-03-2002, 06:50 AM
If you want to check if jk2mp.exe is loading your DLLs, you can either check the log (+set viewlog 1) for the following sentence"
loading <module> dll instead of loading <module>.qvm.

You can allso drop down the console and type /vm_game and if it's value = 2 then it's loaded.


06-03-2002, 02:39 PM
OK - well, I still can't get it to work. So I'm going to ask one last question - and then I'm just gonna bite the bullet and make .qvm files every time I wanna test some code. (Even though that's a major pain in the arse IMO - but...)

I just want to double check that the name that has been set for the output DLL is correct. This the DLL that my set-up is creating:


Is this correct? The only reason I ask is because in the console output it says...

Loading dll file jk2mpgame
Failed to load dll. looking for qvm

and so on...

SO, that sounds to me like it's looking for a file called:


I tried re-naming it to this - but it still made no difference...

06-03-2002, 02:56 PM
a) it is jk2mpgamex86.dll
b) the DLL must be in the main modification folder, not the vm directory.

06-03-2002, 03:26 PM

That did the trick. Thx a lot normal.

I would suggest that goes into your resources thread:

Quote from MakeAMod.txt:
4. On the link tab, change path of the "Output file name" to your TestMod directory

This really should be more specific - i.e. what the NAME of the output file needs to be. Because - at least for me - my project wasn't set up to produce the right file name for the DLL.

So, for game - it's jk2mpgamex86.dll

Does that mean that:
For cgame: jk2mpcgamex86.dll
For ui: jk2mpuix86.dll


06-03-2002, 03:32 PM
Hm. I found that the relative path and the filenames were already included in the project settings when I loaded the code. You shouldn't really need to touch them since they are relative, unless you want to not have them built into the Release/Debug/Final directories...