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... 

I thought all the engines since day 1 supported colored text using the ' ^ ' character?

Turns out if I push a string in QC and use one of the extended colors with that character, Darkplaces will print it with bprint or sprint with the new color, but I noticed PQ does not seem to support this? Have not tried Fitzquake or other engines yet. 

I thought all the engines since day 1 supported colored text using the ' ^ ' character?

Engines that support it are actually a minority.

It was one of those niche features that appeared in one or two engines way back at the dawn of time - i.e very soon after the GPL code release, and IIRC on the ancient (and long-dead) QER site - but was never really documented nor standardised, and never really picked up by any others. 

^ is pretty much just DP+FTE (and q3 onwards, obviously, but that's quake3 and not quake).

if you just want 'red' text, you can use \b (iirc) within a string to toggle it in fteqcc or frikqcc.
so maybe that's why you think it works in more engines. 

I appreciate your comments about q_version, though yes 1 doesnt work unless two online, is kinda moot since you know your own client version. :|

I can make it so it's only mm2 and/or only before a match is going; and limited to once per minute response.

That said there is also a command to just disable it called cl_echo_q_version... 

as for ^ color chars I'd rather see full ANSI support with blinking characters and the full set of extended characters too! ;)
but then Quake was kinda unique with it's own custom character set... 

q_version was never anything but a social feature to create awareness of modern clients.

And get people to upgrade.

If you were using glquake or ProQuake 3.50 and someone typed q_version, 2 things might happen:

1) You see may everyone else on the server was using ProQuake4, Qrack (later DirectQ supported it, but wasn't around at the time).

2) Another player might ask you what you are using and why and someone might even suggest you are using a cheater client.

The social pressure thing worked wonders and I can recall connecting and doing a q_version check and within weeks it was close to 100% modern clients.

At the time, it was important to get people to upgrade so automatic map download had a near 100% rate and people could play custom maps, ctf, coop servers, rocket arena automatically. 

 

Any Quake 1-2 Ports With Monster Footsteps? [EDIT]
Posted by crystallize [94.180.115.39] on 2016/04/22 15:01:24
Hello.
It would be intresting to see a port where monster sounds are synched to animation, unlike Q2 with gibbed monsters screaming or making falling sounds. 

That is soooo not an engine thing. 

A fiend or a spawn or a dog or a shambler making footstep sounds would be odd.

Maybe someone could make a model with those monsters wearing boots. 

I believe AD has footstep sounds for every enemy type. The shambler footstep is the biggest and heaviest but also kind of muted/muffled.