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. 

yeah this is mod territory. 

https://www.youtube.com/watch?v=JcSCG45tAx4 

Thought port meant engine? 

Thought port meant engine?

It does, but engines wouldn't handle that sort of gamecode - it's something you'd have to do in a QC mod - so the chap asking is barking up the wrong tree.

AD does footsteps, obvs. 

Wasnt sure to post this here or in coding help. Im trying to alter the field "world.message" so it is strcat'd to be something more than just the description. Basicly I made some cute does that appends the Original authors name(s) to the ID maps. However, when the map loads, the message seems to always be either nulled / empty or its something the engine dont want to show. Basicly the line where it use to show in the console is now empty.

I have tried moving it outside of Worldspawn and seems to be no help. Basicly I am doing a strcat in worldspawn to the message field so is this safe? There is no strzone function in older PQ otherwise Id try using that. 

An external .ent file would be the proper way to do this. 

If you want to change the map name in the signon message, then hacking it in the QC strings or the entities text is totally the wrong way to go.

Just change the message sent as part of svc_serverinfo instead.

Or change the Con_Printf in CL_ParseServerInfo.

And be ready to have a fallback for the case where the mapper has already included their name here. 

I disagree about using engine code for what's merely an asset design thing. Unless it's implemented as an extra feature, using a new field instead of hacking world.message.

If this is implemented as an engine hack, it'll need CRC checks to ensure that it won't change the description of all the other start.bsp maps out there, for example (including the ones recompiled for transparent water). It overcomplicates things and creates yet more code to maintain.

Using an external .ent file in the ID1 dir won't affect the start maps of the mods, and will still work with recompiled versions of the vanilla start.bsp. No extra work, and no issues.