[Bug 3312] New: server-side mods block native code loading
bugzilla-daemon at icculus.org
bugzilla-daemon at icculus.org
Tue Aug 14 23:57:09 EDT 2007
http://bugzilla.icculus.org/show_bug.cgi?id=3312
Summary: server-side mods block native code loading
Product: Quake 3
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Misc
AssignedTo: zakk at icculus.org
ReportedBy: devhc97 at gmail.com
QAContact: quake3-bugzilla at icculus.org
When looking for native code (.dll, .so), Sys_LoadDll searches the current game
directories of basepath and cdpath for it, and if not found, it loads the QVM,
searching in ALL paths. Consider what happens, when server-side mod doesn't
have a new cgame.qvm.
The client connects to the server, and sets fs_game from 'baseq3' to what mod
it has to, let's say 'myMod'. There are no pk3s to download, because myMod is a
server-side mod. OK, time to load. Start with loading the DLL (sv_pure is off).
Can a DLL be found for the mod called myMod? Searching cgamex86.dll in [
basepath | cdpath ]/myMod/ ... not found. Proceeding to load a QVM. Searching
cgamex86.dll in [ basepath | cdpath ]/myMod/ ... not found, just as with the
DLL. This is where the QVM search and the DLL search differs. The QVM search
continues, this time not with myMod, but with baseq3 (homepath, basepath,
cdpath). QVM found, loading.
In this scenario, the QVM for baseq3 that has been loaded should have been
replaced by the DLL for the same baseq3 mod. So even when we have native code
for a give mod, the interpreter will be loaded in the presence of a server side
mod.
So to fix this I would search all paths for native code and the QVM, and if
native code is found in a the same or higher precedence directory, go ahead and
try to load it.
--
Configure bugmail: http://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the quake3-bugzilla
mailing list