View previous topic :: View next topic |
Author |
Message |
mh

Joined: 12 Jan 2008 Posts: 909
|
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Tue Mar 23, 2010 7:12 pm Post subject: |
|
|
I'd love to see someone else take charge a bit, while I'm inactive. It shouldn't die just cause I'm experiencing a lack of time or having other priorities, this feels like an important project!
Overall, I'd like to see this project be very open, whoever wants should be able to go in and poke at it, make things more clear and come to some kind of conclusion, even if it means dropping things for the moment. There's always room for new features in future versions.
My first draft got some valid critique, and ideally I'd like to see people who find certain things to be big problems go in and change them. For example, my list of extensions got huge, hardly a reasonable start for a new standard.
I'm much more of a "bigger-picture" kind of guy, and prefer to provide framework support, rather than decide on the specifics, especially considering I have little to no clue how hard features are to implement. I'm merely deciding on a usefulness-basis, but that focus might not be the best to work with?
I'm loving all the discussion about and around QSB, but I feel it's not enough. I see QSB as something that's bigger than me. Even if I got the ball rolling, it's not my project! It belongs to everyone. The idea of what QSB is supposed to be seems to be sinking in in the community, and I'd love to see more people take charge a bit. These kinds of things can evolve very naturally, you just have to have the guts to step up!
 _________________ Look out for Twigboy |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Apr 06, 2010 5:48 am Post subject: |
|
|
LordHavoc wrote: | What is needed is that one or more knowledgable modders/level designers work independently or together to write draft documents for capability extensions, different from normal extensions in QuakeC because they define entire sets of capability, ensuring compatibility as a whole with things that demand this capability subset.
After a draft proposal is written, it can be refined with feedback from the community, then written up as a technical document in final form and listed on a website like quaddicted, and then as each engine adds support for the capability, they can be added to that page's list of supporting engines.
Then level designers and modders can simply state "this requires URRE_MAPLIMITS_V1 - see www... for a list of engines that can run this." |
Here's a specific list of quakeC->engine communication used in my 'QCCx' compatible mods:
Code: |
//-------------------------------------------------------------------
// OFFSETS FOR INTERNAL QUAKE.EXE DATA STRUCTURES
//-------------------------------------------------------------------
float SV_ACTIVE ;// = %0; - might need to change this for linux/mac
float SV_PAUSED ;// = %1; - might need to change this for linux/mac
float SV_LOADGAME ;// = %2; - might need to change this for linux/mac
float SV_TIME ;// = %4; - might need to change this for linux/mac
float SV_LASTCHECK ;// = %6; - might need to change this for linux/mac
float SV_LASTCHECKTIME = %8;
float SV_NAME = %10;
float SV_MODELNAME = %26;
float SV_WORLDMODEL = %42;
float SV_MODEL_PRECACHE = %43;
float SV_MODELS = %299;
float SV_SOUND_PRECACHE = %555;
float SV_LIGHTSTYLES = %811;
float SV_NUM_EDICTS = %875;
float SV_MAX_EDICTS = %876;
float SV_EDICTS = %877;
float SV_STATE = %878;
float SV_DATAGRAM = %879;
float SV_DATAGRAM_BUF = %884;
float SV_RELIABLE_DATAGRAM = %1140;
float SV_RELIABLE_DATAGRAM_BUF = %1145;
float SV_SIGNON = %1401;
float SV_SIGNON_DATA = %1403;
float SV_SIGNON_MAXSIZE = %1404;
float SV_SIGNON_CURSIZE = %1405;
float SV_SIGNON_BUF = %1406;
float CL_ACTIVE ;// = %0; - might need to change this for linux/mac
float CL_SPAWNED ;// = %1; - might need to change this for linux/mac
float CL_DROPASAP ;// = %2; - might need to change this for linux/mac
float CL_PRIVILEGED ;// = %3; - might need to change this for linux/mac
float CL_SENDSIGNON ;// = %4; - might need to change this for linux/mac
float CL_LAST_MESSAGE = %6;
float CL_NETCONNECTION = %8;
float CL_CMD = %9;
float CL_CMD_FORWARD = %12;
float CL_CMD_SIDE = %13;
float CL_CMD_UP = %14;
float CL_WISHDIR = %15;
float CL_MESSAGE = %18;
float CL_MESSAGE_DATA = %20;
float CL_MESSAGE_MAXSIZE = %21;
float CL_MESSAGE_CURSIZE = %22;
float CL_MSGBUF = %23;
float CL_EDICT = %2023;
float CL_NAME = %2024;
float CL_COLORS = %2032;
float CL_PING_TIMES = %2033;
float CL_NUM_PINGS = %2049;
float CL_SPAWN_PARMS = %2050;
float CL_OLD_FRAGS = %2066;
float CL_SPAM_TIME ;//= %2068;
float QS_ADDR ;// = %4118; - might need to change this for linux/mac
float QS_IN_ADDR ;// = %4119; - might need to change this for linux/mac
float QS_ADDRESS ;// = %4122; - might need to change this for linux/mac
float QS_MOD ;// = %4138; - might need to change this for linux/mac
float QS_CLIENT_PORT ;// = %4139; - might need to change this for linux/mac
float PR_VERSION = %0;
float PR_CRC = %1;
float PR_OFS_STATEMENTS = %2;
float PR_NUMSTATEMENTS = %3;
float PR_OFS_GLOBALDEFS = %4;
float PR_NUMGLOBALDEFS = %5;
float PR_OFS_FIELDDEFS = %6;
float PR_NUMFIELDDEFS = %7;
float PR_OFS_FUNCTIONS = %8;
float PR_NUMFUNCTIONS = %9;
float PR_OFS_STRINGS = %10;
float PR_NUMSTRINGS = %11;
float PR_OFS_GLOBALS = %12;
float PR_NUMGLOBALS = %13;
float PR_ENTITYFIELDS = %14;
|
These hold values within the engine that quakeC can touch like
Code: |
self.cl = *SubInt(AddInt(PSTRING_TO_PQUAKEC, &self.netname), 4 * CL_NAME);
self.netconnection = *AddInt(self.cl[CL_NETCONNECTION], PC_TO_PQUAKEC);
p = AddInt (&self.netconnection, QS_ADDRESS * 4);
ip = @AddInt (p, PQUAKEC_TO_PSTRING);
cprint4(self.netname, " connected from ", ip, "\n");
|
the PR_VERSION for example can tell the mod itself what version the engine is used. |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 06, 2010 10:34 am Post subject: |
|
|
PR_VERSION = 6. always, at least if qccx hacks are used.
Code: |
cprint4(self.netname, " connected from ", infokey(self, "*ip"), "\n");
|
Is more readable, and how you'd do it in quakeworld.
I don't personally see a practical and robust use for any of those fields that is not already provided by DP's extensions or unmodified QuakeWorld, or just caching stuff. _________________ What's a signature? |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Apr 06, 2010 5:39 pm Post subject: |
|
|
:O then infokey should be a standard  |
|
Back to top |
|
 |
Spike
Joined: 05 Nov 2004 Posts: 944 Location: UK
|
Posted: Tue Apr 06, 2010 5:52 pm Post subject: |
|
|
Code: |
cprint4(self.netname, " connected from ", self.netaddress, "\n");
|
Is how you'd do it in DP.
Personally I get scared by the explosion of new fields, but hey. _________________ What's a signature? |
|
Back to top |
|
 |
Teiman
Joined: 03 Jun 2007 Posts: 309
|
Posted: Tue Apr 06, 2010 6:34 pm Post subject: |
|
|
It will be a good idea that wen possible, to netquake to use quakeworld features, cloning how work in quakeworld. This will make the differences betwen the two flavours of quake smaller, so code and expertise can be reused more often. I can't stress this enough. |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|