gl_texturemode gl_nearest

The rest can be difficult. 

Getting DarkPlaces to look correct is only partially achievable. I have a particle font I got from somewhere that allows particles to be square and pixelly. gl_texturemode gl_nearest is good. Water will not twist unfortunately. I have not found a way to re-enable the twist effect and is the only reason Darkplaces is not a fully supported and true Quake engine, for all its interesting options. 

You're better off just using a different engine for the true software look. Darkplaces' whole shtick is about looking fancy. Why use it at all if you wont use its features? 

Really it's true strength is for use in total conversions where you want to use cool stuff like the Q3 bsp format and md3 models.

For playing Quake? Ehhhhh... not so good. 

Because i want to use CSQC, great QC extensions, great multiplayer and a stable codebase. :D 

With Darkplaces you have a prvm command so you can check globals and look at entity specific fields etc, using the command prompt.

Is this something just in Darkplaces? I thought all the legacy engines have it, but apparently no? 

fte has 'poke_MODULE' commands that you can use to get/set various qc terms (ents can be read by number).

every engine supports saved games (with the possible exception of dedicated servers). saved games are always text, and should allow some sort of inspection, although figuring out entity numbers may be awkward. 

Interesting - yea, Darkplaces has a crash.dmp option you can set, and turns out its merely doing a save game (.sav) just before crashing.

It does comment each bracketed field past the worldspawn with "entity" [x] so you can find them, however I imagine the save game would be numbering all the edicts past worldspawn as entity 1, and incrementing, which I guess can be a pain sifting through.

I had thought the legacy engines from way back like Winquake etc, all had the prvm command , but maybe it was the "edicts" command. I remember doing that and it would just spit everything out to the console.

Cant recall if I used it to actually set things during the game and test them though. 

code dump:
Cmd_AddCommand ("edict", ED_PrintEdict_f);
Cmd_AddCommand ("edicts", ED_PrintEdicts);
Cmd_AddCommand ("edictcount", ED_Count);
Cmd_AddCommand ("profile", PR_Profile_f);
you mean those? I'd kinda forgotten about them tbh, sorry.
iirc, edicts is basically unusable because it fills the console buffer too easily.
either way in vanilla there's no way to peek at globals without saved games.
fteqw+fteqccgui has a watch list thing that's updated with each single-step, or you can just mouse-over stuff too, of course. 

That looks like them.

DP also lets you use the prvm to filter things , ie:

prvm_edicts server model

Prints all the edicts on the current server to the console and shows their current model string.


You are right, edicts command crashes the engine. DP removed it but some other engines like Direct Q are still using it. Fitzquake 0.85 does not crash tho.. 

Saw this a long time ago, I guess its a Proquake feature, thought I once saw it being able to detect Darkplaces clients connecting as well but not sure. As it stands when I use the "Manquake" version of Proquake, it always seems to detect Proquake, just different veersions. Are the engines using a standard ID and a tag of some sorts to ID the engines, or is this all now just a passing fancy?


string ()
PQ_Version =
{
local float i, ch, sum;
local string format = " with proquake version 0.00";
local string x;

i = self.netconnection[QS_MOD] / %1;
if (!i)
return " with a non-proquake client";
else if (i == 1)
return " with an unknown proquake client";
else if (i == 2)
return " as a qsmack client";

ch = floor (i / 4096);
i = i - ch * 4096;
sum = hex_ctof (hex[ch * %2]) * 16;
ch = floor (i / 256);
i = i - ch * 256;
sum = sum + hex_ctof (hex[ch * %2]);
ch = floor (sum / 10);
x = ftos (ch);

i = %23;
strcpy (format[i], x); i = i + %1;
strcpy (format[i], "."); i = i + %1;

sum = sum - (ch * 10);
x = ftos (sum);
strcpy (format[i], x); i = i + %1;
strcpy (format[i], "0");

return format;
}; 

proquake added som extra byte or two at the end of its connection requests. this is meant to contain some [engine]mod id, and the version of it. proquake also added 16bit client->server coords only for proquake clients, and nothing else that's particuarly special.
this resulted in pretty much every NQ client suddenly pretending to be proquake because it was the only way to get 16bit angles at the time.
so really, all that code can actually detect is whether the developers of said client actually gave a fuck about multiplayer or not.

it also depends upon qccx hacks that will break with any engine that even attempts to provide sandboxing, with offsets that are highly specific to the server in question.
adding hacks with assumptions about memory layouts is evil, but if the engine doesn't actually provide any extensions then really the only choice is to hack said engines. 

What Spike said, I had to fake qrack to telling proquake server's it is pq3.50 compatible so that it will allow players to use the 16-bit angles. once the handshaking is established pq will send angles as such and qrack will read them. Other engines like Qspasm connecting to a PQ server will only use 8-bit angles and thus be at a disadvantage. :( btw pq server/clients in this fashion also break demos played on other non proquake clients... 

Do the 16 bit angles allow fullpitch?

So I guess older engines and even Darkplaces still only has 8 bit angles, and therefore if a non pq clients is on a pq server, their angles are not as precise, is that how it works? 

angle cheats are separate from angle precision.

darkplaces pretends to be a proquake client too.
its own network protocol always uses 16bit angles, for both client->server AND server->client.

because proquake's angle thing is strictly client->server, it doesn't break demos because it doesn't even appear in demos (so r00k is wrong in that regard, unless there's some other difference that I'm overlooking, like proquake's svc_print encodings, but those should just look glitchy).

the fitzquake protocol also uses 16bit client->server angles. however, proquake doesn't support that, so quakespasm is indeed limited to 8bit angles on public deathmatch servers, but not when playing singleplayer. 

btw pq server/clients in this fashion also break demos played on other non proquake clients...

It is well known that ProQuake demos play even in the original Quake/WinQuake/GLQuake.

And by extension JoeQuake --- which uses ProQuake network code -- this is why speed runners use JoeQuake to record their demos [amongst other reasons]. 

Why could not each engine have its own cvar that more or less corresponds to its clienttype and version?

IE: cvar FitzQuake = "Fitzquake 0.85"

Then feed this field into something decided upon to be 'universal' in the engine community in case they 'give a shit' about mp...heh.

As it stands now the code I posted is I guess cute, it can announce what client a player is using when connected...if it were to work accurately that is. At least if the structure did pass a unique string to read to the layman qc modder, they could perhaps customize some mods to take into account the many differences in all the engines and give the user a better experience, ideally... 

1: cvars are not normally server-visible. making them server-visible also implies making all cvars server-visible, like ones that contain rcon passwords or other things that shouldn't be scraped.

2: string parsing is not possible/feasable without server extensions, limiting the servers that can actually benefit from it to those that either don't support anything but their own by default(dp), or that already have their own auto-detection(fte).

3: http://xkcd.com/927/

4: really, it would need a whole list of 'compatible with' much like user-agent strings in http. string parsing is annoying, did I mention that yet?

5: encouraging people to use client-specific features also encourages people to depend upon incompatibilities. the end result is probably not very good in the long term. don't get me wrong, it'd be nice to know what each client supports, but doing it on a per-feature basis rather than a per-client basis helps to encourage people to actually adopt the standard properly rather than getting modders to add a hundred different hacks for each client.

6: quakeworld clients can be distinguished fairly easy by reading that client's userinfo string.
of course, this still requires knowing everything about every client.
I admit that I've used it for blacklisting clients that don't appear to implement standards properly, and I know mvdsv uses it for both blacklists and more annoyingly whitelists.
whitelists suck by the way. you end up straight back with trying to pretend to be some other client. and then all the complaints about cheats start. whitelists suck.



so yeah, it'd be nice for servers to be able to tell what they're actually talking to, but at this point I seriously doubt anything is going to change, and even if it did, it probably isn't going to be TOWARDS compatibility, at least in the long run. 

what i meant as "break" was that all demos play back with 8bit angles. So, in slow motion watching a demo from first person pov, the aim isnt as smooth as the player saw when recording.

this is in cl_input.c

[code]
if (!cls.demoplayback && cls.netcon->mod == MOD_PROQUAKE) // JPG - precise aim for ProQuake!
{
for (i=0 ; i<3 ; i++)
MSG_WriteAngle16(buf, cl.viewangles[i]);
}
else
{
for (i=0 ; i<3 ; i++)
MSG_WriteAngle(buf, cl.viewangles[i]);
}
[/code] 

btw Qrack breaks demos because the number of lightmaps increased for halflife map support, which i could easily scrap but then i have 1000s of demos that were recorded with that fact. :| 

the viewangles displayed by an nq demo are exactly as precise as was displayed when it was being recorded, on acount of each demo packet containing 3 floats for angles, no truncation at all, not even to 16bit.
those writes are irrelevant when playing back a demo. that buffer isn't sent anywhere on playback, even if its still made.

If you recam a demo or have qc generating some sort of chasecam with forceangles/svc_setviewangle then yeah, you're probably going to end up with 8bit data getting expanded to floats, purely because the result is based upon the server->client precision (which is unmodified by proquake).

regarding lightstyles, you'll find this nice line memset (cl_lightstyle, 0, sizeof(cl_lightstyle)); inside CL_ClearState. Or, in other words, you can omit any lightstyles following an svc_serverinfo that are empty (whether recording a demo or serving to clients), and your halflife support etc still works, without any needless incompatibilities. Obviously if a map/mod does use one of those lightstyles then that's the map/mod's problem rather than yours.
Really, support for 255 lightstyles should be a standard feature by now. 

Chatted with Zop last night, and he says that command ' q_version ' was I guess a Manquake type of mod where participating engines could code in their response string, and it would be initiated using the 'say' command. Doing it alone on a server would not yield a response, however more than 1 player on a server would trigger each client to respond with their engine version. According to Zop, the admins voted that out of the RQ games so I guess its either commented out in the eng source or deleted, but I guess this is one way of doing it. 

in CL_ParseString i call this...

void Q_Version(char *s)
{
extern cvar_t cl_echo_qversion;
static float qv_time = 0;
static float qi_time = 0;
char *t;
int l = 0, n = 0;

if (cl_echo_qversion.value == 0)
return;

t = s;

while (*t != ':')//skip name
t++;

l = strlen(t);

while (n < l)
{
if (!strncmp(t, "q_version", 9))
{
if ((qv_time > 0) && (qv_time > realtime))
{
return;
}

if (cl_mm2)
Cbuf_AddText (va("say_team Qrack version %s\n", VersionString()));
else
Cbuf_AddText (va("say Qrack version %s\n", VersionString()));

Cbuf_Execute ();
qv_time = realtime + 20;
break; // Baker: only do once per string
}
if (!strncmp(t, "q_sysinfo", 9))
{
if ((qi_time > 0) && (qi_time > realtime))
{
return;
}

GetMem();
GetMHz();

if (cl_mm2)
{
Cbuf_AddText(va("say_team %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer));
Cbuf_AddText(va("say_team Video mode %s \n", VID_GetModeDescription (vid_modenum)));
#ifdef WINVER
Cbuf_AddText(va("say_team Windows Version %x \n", WINVER));
#endif
}
else
{
Cbuf_AddText(va("say %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer));
Cbuf_AddText(va("say Video mode %s \n", VID_GetModeDescription (vid_modenum)));
#ifdef WINVER
Cbuf_AddText(va("say Windows Version %x \n", WINVER));
#endif
}
qi_time = realtime + 20;
Cbuf_Execute ();
break; // Baker: only do once per string
}
n++; t++;
}
}

all client-side... 

Qrack goes one step further than ProQuake in that, if the player who initiated the q_version in mm2 mode then Qrack will respond in mm2. 

1: requires annother player on the server.
2: can potentially be exploited to get other kicked/muted from the server due to spamming.
3: working around the previous issue makes it unreliable.
4: the reply is indistinguishable from many other possible responses.
5: the reply is totally not standardized.
6: you can't tell what the client is until a not-insignificant time after the player is already running around.

its fine for players to know what other players are using, for those that are curious about it, but its useless for mods.

quakeworld standardized upon f_version triggering the main response, after fuhquake, but also works for fte and fodquake too, but I guess ezquake has an off-by-one error...