And there under tools (I think) add marker.

It didn't matter where or what it was called, Quake would then treat it as looping. 

found a link here maybe some info, too

https://developer.valvesoftware.com/wiki/Looping_a_Sound 

Ahk, Win 7 or later for Goldwave so I cant check it, but will fwd to the modder the link to this thread. Thanks all. 

The version I had/have somewhere is pretty old. 

Older versions for XP/etc here: http://www.goldwave.com/release.php 

What are the commands for making DP resemble the software quake engines? 

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]