Newsgroups: rec.games.computer.quake.quake-c
From: moribund@kos.net (Stephen Hart)
Subject: Re: No more Quake C  in Quake II ?
References: <344406ce.5755894@news.ipf.net> <01bcd9b5$8eac5d60$b517bace@www.smith.ca>
X-Newsreader: News Xpress 2.01
Date: Fri, 17 Oct 1997 05:40:34 GMT
Message-ID: <3446f9ae.0@news.kosone.com>
Lines: 99
Organization: Kingston Online Services
NNTP-Posting-Host: 199.246.3.134
Path: clanworld.com!news.webspan.net!newsfeed.internetmci.com!207.206.0.75!iagnet.net!news-xfer.siscom.net!newsfeed.kcdata.com!news3.kcdata.com!news2.kosone.com!news.kosone.com!asdf
Xref: clanworld.com rec.games.computer.quake.quake-c:3567

In article <01bcd9b5$8eac5d60$b517bace@www.smith.ca>, "Jeff Smith" 
<psmith@wwonline.com> wrote:
>yeah, they are switching over to DLLs, that really sucks though, because
>now people can write viruses and other damaging programs into quake2.
>
>For example, someone could make a MOD where you kill a guy, and a file gets
>deleted from your drive!!  YES IT IS POSSIBLE WITH DLLs!!!
>
>Why is it possible? because DLL's aren't limited to a set of quakec
>commands, they are open to all C++ commands, see what im getting at?
>
>just a word of warning...

First, here's the quote from the 14 page article in PCGamer, Oct 97, pg 117

With the native Win95 support in  Quake II, straight QuakeC has been scrapped 
and replaced with programmable Windows dll files that offer more control than 
QuakeC ever could. "You have full control over the camera view, screen fades, 
pinning objects together, and a lot of things that are going to drastically 
improve the add-on capability," says Carmack. "The dll programming model has a 
whole set of issues that Im still fundamentally convinced is the right thing. 
The extreme amount of control is going to make some really interesting things 
happen."

Me -> My take on this is that you don't create an add on for quake2 by 
creating a dll, you use any language capable of calling .dll to run quake2. 
Of course such a language can then have a command to erase files, but any .exe 
file might do that, and a virus checker won't find it. But it won't be a .dll 
doing it. 

So all Quake2 would care about would be the values passed in as parameters , lo
cations of callback functions, and the values it gets back when it, um, called 
back.  The program doing all this could be anything from fortran to authorware
 to a device driver reading the windspeed and temperature outside. There could 
be hundreds of calls to change things before a setup.  These hundreds of cal
ls could be wrapped up in a .dll which could then be passed the value hqsMain a

    I can then use these 2 codes to set axis limits, colours, etc. for the 
graph.  I can create lots of graphs and change any of them by calling a .dll 
command with a command like SetColour( hMother, hNewGraph7, RED). I can also 
set files a sources for X and Y axis data, give it a pointer to an array, 
check every 650 milliseconds to see if the user has zoomed in on part of the 
graph so I can ...  but I digress.

    I can use any windows language I like. The people who write the package 
are expecting you to potentially have real time data streaming in and 
constantly generating new commands to add a point to this or that graph or 
adjust this axis limit because of a new maximum value. This could be hairy 
palms on the keyboard device driver code. 

     On the other hand, you might be a mellow Visual Basic programmer who 
calls the setup command, then flicks an array of data at it, and says "graph 
This!" . Potentially, the entire program could be creating a command button 
with a mouse, called, say, "Fyunch" putting 3 or 4 .dll calls in the 
Fyunch_Click subroutine, and declaring the dll calls. 

    So, my guess is that Quake2 will be similar. If you want, you would call 
hqsMain=InitiateStandardQuakeSession; 
then call however many functions you want to change the default settings like
SetGravity( hqsMain, MOONS_GRAVITY)

hqmcBeasticle=RegisterMonsterClass( hqsMain, M_BEASTICLE, BeasticleFunc)  
where BeasticleFunc is a monster function written to respond sensibly when 
called with ceratin paremters like BeasticleFunc(hqsMain, Q_ADD_DAMAGE, 
Q_RAIL_BULLET) 

hql1= SetupLevel( hqsMain, "level1.lvl")

hqmB1= AddRegisteredMonster( hqsMain, hql1, hqmBeasticle, 10, 50, 123)    
hqmB2= AddRegisteredMonster( hqsMain, hql1, hqmBeasticle, 20, 60, 123)   // 
place monsters 
hqmBZ1=AddMonster( hqsMain, hql1, Q_BEZERKER, 30, 40, 110)
AddScriptedMonsters( hqsMain, hql1, "level1.mon") // read a list of monsters 
and locations from some file.

then call something like

pbDidHeMakeIt =RunLevel( hqsMain, hql1)

if pbDidHeMakeIt then {
        setup and run level 2
}

etc.

So all Quake2 would care about would be the values passed in as parameters , 
locations of callback functions, and the values it gets back when it, um, 
called back.  The program doing all this could be anything from fortran to 
authorware to a device driver reading the windspeed and temperature outside. 
There could be hundreds of calls to change things before a setup.  These 
hundreds of calls could be wrapped up in a .dll which could then be 
passed the value hqsMain and then make a standard group of setup calls. As 
psmith says, though, you would have to trust such a foreign .dll  On the other 
hand, you could dip your toe into the whole process by just changing a few 
parameters and calling the main program. 

Anyway, that's my guess and Im sticking to it.  

M. O'Ribund
