Changed files: common/vid_<system>.c, common/vid.h, uquake/menu.c, qw_client/menu.c, AUTHORS
* Corrected the menu system to work as intended (extra options depending on used vid_<system>.c file)
ATTENTION!!! I'm not able to test for the different *nixes, please check if I changed everything correctly, plus the previously disabled extra options have to be checked too. Thanks.
* Fixed where you couldn't get back from console when accessed through menu (taken from qw_client)
* Fixed menu bind problem in QW ( now \"%s\" )
Cvar_Alias_Get now returns void
cl_pred.c is Tonik's client jumping prediction fix
the rest are adding new aliases: s_volume->volume and sv_edgefriction->edgefriction
Also, FULL SCREEN QUAKE IS HERE!!! unfortunatly, so is full screen quake :/. ie if you have the vidmode extentions, you don't have a choice at the moment. Still, that's just a matter of cvars :), but not tonight.
VERY IMPORTANT: read the readme.win file. it tells you what you need to do to get it working,
as there are a couple of things that need to be done by the developer on their own machine.
little more error checking and possibly default to misc/talk.wav if the
file you give it doesn't exist or something. If someone wants to do that
go for it - I'm just adding it to my personal todo list for later so I can
get back to GL fullbright stuff.
Also, there was a bug in configure.in that caused glx not to be built at all on
my system.
NOTE: I changed SRC_DIR to srcdir (GNU `standard'), though I'm beginning to
wonder if that was so good.
are done (sorry if this steps on your toes with the view.c merge Deek) and
I'm almost positive flymode will now work. Even though view offset is
done, it won't.
The reason for this is that cl.stats[STAT_FLYMODE] is pretty much going to
ALWAYS be 0 on a standard server. Since 0 tells us that we're not flying,
this is fine. cl.stats[STAT_VIEWHEIGHT] is also going to be 0, but it
should be 22 for normal views. I could always assume this value is an
offset from 22, but that just seems lame to me. I'll either do it anyway
or we'll have to find a good opportunity in the connect cycle to set the
cl.qfserver qboolean to true.
I'm thinking about using an info key value for this, but we'd be better
served I think by coordinating with QSG to up the protocol version across
all engines.
