| |
Logo by Mongoose and Leonardo da Vinci.
|
Thursday 99.12.30
|
Update 18:15 EST
(Mongoose)
Download quakeworld-991230.tar.gz read below for instructions. New feature of Bot_SV_Talk, and more fixes and code abstraction. I spent most of my time looking for this velocity/time/gravity bug ( small QW demo of bug ) in the code. I will no longer waste time on it, as I have to finish the interface and API - not waste time on client emu bugs for now. I checked all the sv_ vars, checked frame times, and I didn't find it. It must have something to do with setting client velocity - watch the demo.
Update 00:07 EST
(Mongoose)
First go get the CVS source from quakeforge. Then download quakeworld-991229.tar.gz. Now untar the last file somewhere *outside the cvs tree. You need GNU Make version 3.78.1, gcc version 2.95.2 19991109 (Debian GNU/Linux), and GNU ld version 2.9.5 (with BFD 2.9.5.0.19) to be 'leet like me and build this w/o a hitch. At the least you need a modern gcc and GNU make. I won't help people using known buggy, older versions of gcc.
Do the command 'cd quakeworld'
Edit Makefile:
QUAKEFORGE_DIR=DIR_PATH_TO_QUAKEFORGE/quakeforge
BUILD_DIR=bin/quakeworld_sv
INSTALL_DIR=DIR_PATH_TO_QUAKE/quake
examples:
replace DIR_PATH_TO_QUAKEFORGE with /usr/src
replace DIR_PATH_TO_QUAKE with /usr/local/games
Now do the command 'make;make install'
I hope you have fun, this is *the base for the QuakeForge QW bot server. Please help me find the gravity bug, I think it may be my fault or it may be I merged the source into an older CVS source. I didn't add Rich's ASM, since diff said it was the same old song and dance. Please help fix any bugs you see, but DO NOT break coding conventions. This code has to play nice with the CVS code - if you prevert the code, then you won't get it back in the CVS tree. Thanks to Rich for giving me the QW faux client code! Now I can focus on the API and merging with the main source tree. =)
The API can be released in chunks, so I might do that to stave off bot coders writing poor code. If we all use the same interface this will allow me to write the CS/SS API, so that any SS bot can be a CS bot as well. I'm working on the either the networking or routing interfacing code tomarrow, if I can fix the gravity bug. Also the routing API uses SRPII and ATH routing files. The registry API base uses both handwritten and binary ENT files. I will add hand written ATH file support as well, for you odd balls. Note CGF uses SRPII.x files. =)
|
|
|
Monday 99.12.27
|
Update 18:18 EST
(Mongoose)
The PQ IIS server holding this page is dead - you'll see this news a day late at the least it seems. No, I don't know why we don't run apache. =)
Athena/Quake Update 18:07 EST
(Mongoose)
I just made this post on quakeforge, it explains the CS bot issue:
Imho, this project is *the fork... all blessed clients should be built off this base, and we should move trust to the serverside. I'm working on making a server that will allow a speical class of CS bots to get on a server. This way proxy cheats are reduced, but CS/SS authors can make bots that can play over the network w/o worrying about interfacing with the damn server code.
I'm still in design phase for the most part - I will be making an libathenasv.so that can be optionally loaded into a bin based on this fork. That .so will contain server code in a new thread ( already have the TCP admin code finished, but not polished ) that allows bots linked to libathenacs.so to play on that special server. I will also produce a libathenass.so for making pure server side bots. I'm waiting for the unified quake fork to be done before I start coding the interface code for the CS and SS bots for apprent reasons. =)
I hope to finish all the other modules like basic AI ( route module is done ) functions for the athena api, before unified quake is done. Another good thing is after this is done, an author merely has to port their bot's local game interface and make an athena interface for the ss or cs libs to port an entire bot from q, qw, q2, q3, etc.
Updates 14:07 EST
(Mongoose)
I bought a new SMP socket 8 for Q3A bot development.
I'm also going to start helping the quakeforge fork with QW and Qauke source.
QSG is dead.
I got Athena loaded to the CVS server and I'll be working on it, until the unified Quake is ready for me to hack on...
I have lots of ideas to add to Quake: Q3A style gameplay, improving design, and optional athena unified server.
|
|
|
Sunday 99.12.26
|
Updates 19:16 EST
(Mongoose)
New ( compelte ) Makefile for the tar ball I released. I also fixed the posts that had the new news on bottom. Also I found a new Q1 source tree that has colored lighting and new animation code at PQ's own QER.
Linux QW source fork Update 15:18 EST
(Mongoose)
After bitching on the slashdot message boards about it. I'm releasing the cruddy tar ball of my current modified qw source tree here. I hope the new layout is used by someone, I hated the layout of the quake.sourceforge.net tree, but I joined the project anyway. I hope we can come up with a good fork somewhere. Please email me anything reguarding the tar ball, and please put your name/email in the code where make modifications. I'll be keeping the tar ball up to date up here for bot authors, as I doubt sourceforge will like a tree supporting CS bots. Please don't contribute cheat proxy code. I only want to support pure CS bots driven only by AI. I'm making network code now that runs seperate from the QW net code to allow CS bots to connect to the server.
I'll be working on the QW athena API, soon - so bot programmers can port their q2 SS bots to QW CS bots with little hassle. Merry xmas all. Jenny, I care for you alot, hon. ;)
|
|
|
Friday 99.12.24
|
Shout Out 13:54 EST
(Mongoose)
Hey knothead. I hope your parents don't drive you crazy, hon. =)
Modular Athena Project Update 13:37 EST
(Mongoose)
Well I got the QW server and client source in a new tree. Yeah, fork that bitch, BSD! BSD! Just kidding. If anyone can email me with a linux oriented "offical" fork let me know. I've made new Makefiles that let you build the clients and the server seperately, removed that VC++ garbage, and rearanged the code layout.
I'm looking into making an athena interface for QW. I've been rewriting Athena to contain the old MIA and my SABIN code. So far the routing modules and the irc/remote telnet admin server are 100% done and are up and running. The agent sockets are on the drawing board, but the q2shells ( game interface for q2 are about finished. The shell and agent code are either half done or soon to be back on the drawing board. I'm using UDP for agents - the telnet server uses TCP, fyi. I may have enough time over the xmas break to finish the Q2 Modular Athena bots. Of course when the Modular Athena server is finished, all I have to is make an interface into the game code and a game play module for Athena to use- BOOM then Athena can play that game too. The real advanage of Athena is that if you have a home lan, like me, you can run the AI on one machine, the game server on another, and connect and interact on yet another. "586s" are cheap folks, throw a cheap 100/10 nic and linux on 'em and death match. Still looking for a smp socket 8 w/ vrms, chips, and ram to make a new workstation. Fyi, socket 8 is aka "pentium pro". Q3A bots are actually tough on a single cpu 150Mhz box @ 59.60 bogomips!! =)
Looking into supporting at least Q, QW, Q2, Q3. I'll also be adding the mp3 spider I built ( can't sue me for searching for them ) into the athena server as a module. I'm really enjoying modular design, it's a hoot. I forgot to mention that the all the modules are threaded. You can connect and chat/admin with any UNIX telnet client or in windows using a good irc client and /raw. Char/char transmissions are blocked - I'm not going to make a freaking 1K buffer for every luser on the machine. I'm using posix threads currently. Also I'm supporting SRP format files with modern headers, and I may make code to upload/download route files on the admin server module. I plan on having an "AI buddy"/system avatar done for senior project, so I shouldn't have a conflict here.
|
|
|
|
|