The ezQuake scientist crew has been working hard in the lab to bring us a monsterous release that is ezQuake 1.9 Stable.
A list of 120 new features, fixes and changes is included since the version 1.8 which was released exactly 11 months ago.

The previous release aimed purely on providing the user with easy configuration and usability of the client, this release is however different. It has several new features in various areas. Let's have a brief look at them:

Graphics:
For a long time we haven't seen any new graphical effects in the client, but this release changes this with:
- powerupshells is a nice effect adding a flashing thin layer on players carrying powerups; http://ezquake.sourceforge.net/gallery/powerupshells.jpg
- bloom effect: light sources in the game have a decent distorted diamond or globe surrounding them; http://ezquake.sourceforge.net/gallery/bloom.jpg
- VWEP support: you can now see which weapon the player is currently holding in his hands (limited to observers only);
+ initial support for luma textures on all objects

Observing features:
- significantly improved support for QuakeTV: Chat, better buffering, and many others; this upgrade should be the main reason why to switch to 1.9 as soon as possible because most QuakeWorld matches nowadays are observed via QuakeTV
- teaminfo table for QuakeTV and MVD: one look at it tells you everything about the team you are watching
- weapon stats - old feature rewritten from scratch so that it can be used by observers on QuakeTV
- autotracking - rewritten and added a universal "autotrack" command that works everywhere
- demo rewinding: this has been a requested feature for a very long time and has now finally been added

Usage simplification:
- use one (currently running) client instance for playing demos, watching QuakeTV or opening qw:// links
- qw:// protocol support - the client can easily be configured to open qw:// links that will connect you to any given server immediately
- zip, pk3, gz, tar support - add more custom media to the game in these more friendly formats than the original .pak format
- modern models have been added as accepted by the client's f_modified models check

Advanced configuration:
- cl_vsync_lag_fix - helps reducing lag of LCD/TFT displays
- teamforceskins / enemyforceskins - helpful teamplay features
- Windows Raw Input - new mouse input method


Full Changelog and credits:
[ http://ezquake.sourceforge.net/docs/?changelog-19 ]
Download ezQuake 1.9 (client standalone):
[ http://ezquake.sourceforge.net/download/ ]
Download nQuake (quakeworld package):
[ http://nquake.com/ ]
Upgrading guide:
[ http://ezquake.sourceforge.net/docs/?upgrading ]
FAQ:
[ http://ezquake.sourceforge.net/docs/?faq ]
Screenshots:
[ http://ezquake.sourceforge.net/gallery/ ]
Official statement from ezQuake crew:
[ http://sourceforge.net/forum/forum.php?forum_id=817184 ]
Report Bugs:
[ http://sourceforge.net/tracker/?group_id=117445&atid=678559 ]
Request features:
[ http://sourceforge.net/tracker/?atid=678562&group_id=117445 ]
#ezQuake on Quakenet IRC:
[ irc://irc.quakenet.org/ezquake ]

great job everyone

Yeah, now you just need 240 new features for 2.0

gotta love you guys

"demo rewinding"? Outstanding! Thanks guys!

Congrats guys, nice work!!!

--//--

Question: Do I have to change any files, besides the .exes, if I'm upgrading from previous 1.9 beta 1? Thx!

what does "raw" input mean when using in_mouse 3?

I like style of updates, they are not often but you guys always add only usefull stuff instead of throwing in ridiculous number of half baked features that even don't work correctly most of the time. Great job, ezQuake is best client in whole world of fps games.

?

--//--

Another question. Will the security module be released soon? (no hurry just asking)

You don't need a security module. It's built-in now.

Well done. Now I can download demos/maps from European servers at 70kb/s not 3kb/s !!

When is this used? Since i use in_m_os_parameters 2 and im_mouse 2 and it's a great difference between 1.8.3 and 1.9 when using same cmdline and cfg.

Unfortunately to the worse for 1.9. Can't aim no more when using 1.9, mouse feels unresponsive and like if mouseacceleration is on :S

Had to go back to 1.8.3

Yawn.

in_mouse 3 perhaps, pretty clearly stated in the changelog/docs too.


Those changelogs aren't made for nothing people. Time to go and read that god damn thing already.

Yes, and since u hopefully read my whole post you can clearly see i stated I use "in_mouse 2", and still feel a great difference that according to docs should be there?

Or did I miss something else?

Yes and I can't explain it, unless some in_* default parameters were changed between the versions. Someone told me there's difference but I can't confirm it at all, not that I'd use dinput but still.

Except for one thing: you can't have +cfg_load xxxx on the cmdline if you want to initialize input properly.

And I don't have +cfg_load in cmdline either, and a good answer from someone who knows what's been changed would be appreciated so I know if there is a fix or workaround or something.

Why this sour attitude Renzo?

From the looks of it you didn't bother reading the changelog and/or documentation.


Guess on how many "help" channels I've been and seen this kind of behaviour (basically lazyness, nothing more, easier to ask than to check it yourself) even if the topic says "read FAQ, read manual, do something before asking" yet still people take the lazy way. (hello #oer, hello #qtv, hello #qw-dev)


It's nothing personal, it's just too common.

However if you manage to get someone to confirm the different input when using direct input (or in_mouse 2) then you should make bug report on the ezQuake tracker with providing steps on how to recreate the problem, if there's any. That's the place where you will get some answer sooner or later.

Yeah I totally understand what you mean, if that would have been the case. And I did read the docs, that's why I stated the question.

If you quote my sentence after where you now stopped, I start with: "Since I use in_m_os_parameters 2 and in_mouse 2 and it's a great difference ...",
meaning that I feel a difference that I didn't think should be there, asking if the other inputmethod is used in in_mouse 2 too.

Johnny_Cz: Got an answer?

Don't use cmdline. Don't use in_m_os_parameters other than 0 with in_mouse 2 as that setting doesn't have any effect with DInput.

Will try it, cmdline looks like: -dinput -m_smooth -noforcemaccel

But still doesn't answer my question about the difference between 1.8.3 and 1.9 since I use same cmdline and cfg to them both and still there is a difference?

We've added an option to change the size of the buffer of the direct input, try that. That and adding Raw Input (which doesn't affect DInput), no other changes in mouse code. That answers your question fully I think.
If you want us to help you track down your problem further, use the bugreport form.

does ezquake need a security module anymore?

if it doesn't why it still says "Fail: security module not found" at startup?

ezQuake never needed a security module.
Ask your league admins why they don't require security module anymore.
It says so because it was unable to find the security module.

Why hasnt the error message been removed?

Why should it be removed? It was always like this, nothing's changed.
Security module for 1.9 might be published later.

and then...


?? O_o ??

and i ask myself how iam able to remove that damn black line when using r_bloom 1 oO

see this screen to understand what i mean...

dunno it happened since the first alpha/beta build i used (dunno which exactly that was oO)... and iam really curious about what causes that =/
i would really like to use r_bloom 1

(relevant?) pc specs:

CPU: AMD Athlon XP 4000+ (singlecore)
RAM: 4gigs of ddr1 original infinion
GPU: xfx geforce 7800gtx 256mb
Monitor: BenQ FP93GX

i am willed to post my cfg if needed oO

i would really like to get a helping answer, since i can't find a way to fix it myself...

thank you in advance,

sincerly oRe

change your conwidth or conheight a bit, by about 50 or so, and it'll vanish.

What's there to wonder?

ezQuake as a client does not require security module to make it run, it's that simple.

If league admins want some sort of anti-cheat security module for model/sound/whatever checks, ezQuake can support such, so it also can be published later.

Think of it as an extension or plugin.

You have to understand that security modules published officially by ezQuake and making ezQuake dependent solely on the module being there is a violation of GPL rules. Therefore, ezQuake does not need the security module, but can use it if it's there.