Currently, certain parts of the main engine are used in the Game DLL, but also on the client. These parts are thus not available for modification.
To allow for extensions of the engine and the client, a set of functions could be put into an engine.dll used by the client (and the server). This could be a separate DLL, or simply add to the same DLL already containing the Game Subsystem. Releasing the source of the functions in the engine.dll, and providing empty hooks for other functions would enable the community to tackle several ambitious projects, some of them relevant for Trinity development.
There are various, unconnected, issues that would benefit from a client side DLL use, and the ability to modify the components used. In short, a large number of suggestions and proposals made are easier to implement with, and some of them are impossible to implement without, a Client Side DLL.
The most intruiging possibility is that the community could experiment with client side use of Java (by invoking a Java VM) to e.g. implement autodownload in interaction with a custom Resource Server (but not a Game Server). The community could also experiment with client downloadable Java code, e.g. a new gi.Pmove. See Q3Java for more.
Other possible applications: hooking a client into a web browser. Hooking a client into an editor for interactive preview when placing/spawning entites.
The following problems that have been found with the server side DLL also apply to a client side DLL.
An engine.dll separate from the game.dll requires re-exporting functions from one to the other. If handled in a unified DLL, functions would simply be moved into game.dll.
If the client has a separate small DLL, confusion might multiply. If the client uses the Game DLL, players will be forced to download a rather large and largely redundant binary. However, many players might download entire DLLs already regardless of bandwidth and security, simply because they want the mod for single player games or training, too.
This proposal simply duplicates the mechanisms already used to hook the Game Subsytem into the main engine, when in server mode. It is a tested, known mechanism.
The partical process will be deciding which parts of the engine should and could be exposed, and moving them into a separate source tree while importing the functions remaining in the main engine, but needed by the DLL. The amount of work required depends on the modularity of the Q2/Q3 engine code.
Certain functions will have to be moved from the main engine source to the new (or Game) DLL source base. Headers have to be changed, linkage has to be changed. As a rule of thumb, no function that exposes internal data structures (BSP) can be moved into the DLL w/o inadequate effort. If the source is simply added to the current Game DLL, GetGameAPI will also change. If a separate DLL is used, another GetAPI is required, and wrappers have to be used to re-export functions. In both cases, sources will have to be shuffled around.
void (*Pmove) (pmove_t *pmove);into the DLL.
moveleft/moveright movedown/moveup forward/back lookdown/lookup left/right
char* ResourceGet( char* source, char* dest );where source is a string describing the model/image/map missing, and dest is the default filename the client expects. The Q3 client would simply report missing resources to the DLL by this call. The DLL could respond by downloading it into the desired destination, or into a different location returned. It returns NULL when download fails, or is not attempted.
The community could use this hook to add any kind of autodownload mechanism.
There are a lot of proposals that would be easier to implement, or possible only, with a Client Side DLL. The list below simply gives some examples the illustrate how involved some issues become when the community does not have the means to apply a certain modification themselves.
The Client Side DLL is a short-term hack to do what will otherwise impossible in Q3, which will not have client-downloadable Java. Those that do not want this will not have to use it - they can simply ignore all mods that are not server side only. Server side only mods will still be possible.
This proposal competes with a Q1/Q2 source release. Such a release would force designers to decide between ability to modify versus visual quality.
Implementing a client side DLL for use in single player only does not solve the security issues, and fails to address the applications for multiplayer (prediction).
Submitted 980325, revised 980406, revised 980420, revised 980429, comments to firstname.lastname@example.org.