I would add a new and stable mvdsv which could be able to verify clients authenticity.

- that is a broken link. I googled and my best best would be this instead: https://github.com/ezQuake

This kinda hit the nail on the head.
You must know what to google for, and then find your way to the diamonds, which in this case is GitHub.
And as a non-developer, GitHub isn't really any wet dream of a website (in terms of usability) = when I finally get there, I don't know what to do.
I'm just a simple farmer, I want my "download now (for Windows)"-button, not some "pull requests" or "issue tracking".

If we trail back to the start, which is (for many) this site - qw.nu - you only have the link in the header pointing to http://ezquake.sourceforge.net/ - which doesn't get me what I really want (described in my previous post).

The link is valid. It is just nothing there yet! The Github link you posted is indeed the developer oriented entry point. The one I posted is supposed to be the entry point for humans.

Similar to this:

https://osxfuse.github.io/ which is the human entry point to https://github.com/osxfuse
http://premake.github.io/ which is the human entry point to https://github.com/premake

When you load my link, there is even additional documentation on how to create these pages. They also have pre made templates. So one does not even need graphics skills. Also no HTML required as well as I think they support a wiki like syntax.

The infrastructure is there. It just needs some reading and some effort to get it up and running. Its a joined effort unless someone volunteers to do a shitload of work himself.

I agree, a download button and an .exe and .dmg file for Win and OS X would be great for non-developers like myself. Even if I managed to get ezQuake 3.0 working by using the how-to from the github page, I was never sure I'd done everything right, and if I hadn't already known the process of showing the contents of an OS X app to get to the sorta hidden qw dir and so on, I wouldn't know where to put my hud, textures, configs etc.

For the record, EQ 3.0 is working flawlessy on my 2009 MBP running OS X Yosemite.

So it's baiscally done, and just needs a finishing touch like .dmg and .exe files ... or?

It needs more fixing tbh. But sure you could grab the sources and build binaries on your own. I had plans on putting up a nightly build server for Windows atleast (or use localghosts previous nightly build server, however IIRC it was too old and needed updating).

I'll see if I can dig up the TODO list for 3.0 to see what I thought was necessary to fix before an official release.

Developers are more than welcome! Github pull requests, send me patches, post patches in the forum, doesn't really matter

Good luck. You're trying to solve a practically unsolvable problem. Why? Because the server is not in control of the client and never will be.

Well, how about hijack the qw source code, make auth keys and release community's official builds for both mvdsv and ezquake which sources are not public?

First of all that would be a GPL breach. And it still won't solve the problem. The client can always do what it wants including satisfying the server by weird replies to auth requests or whatever it needs to do. We have gone over the security module debacle a dozen of times..

Yey! \0/ dimman \0/

I know that russians won't be happy atm about 3.0 because it breaks support for cyrillic letters.

I would gladly take a patch if someone feels like doing a proper one for it though. Otherwise it will have to be put on the future-improvement list unfortunately.

There are some other things to fix up before a release feels possible, looking into it.

Also:

What do you want to get fixed to the release? Got any problems with anything? Want to change something? Want to add something? Speak up

(Feel free to use the Github Issue page, not a necessity if you don't have an account, but if you do then please use this link)

I'm gonna try Windows 10 now. I assume 3.0 and Blood_Dogs how to will work on 10 too?

A pretty large problem occured while I was observing through QTV. Players disappeared completely from scoreboard and everyone I spectated had the LG shooting animation constantly, on DM2. There was also random rocket/grenade explosions occuring frequently. This is the reason I went back to 2.2x.

I tried 3.0 the other week using my regular config:

• It wouldn't detect my high resolution textures that i always use, i got the default low res ones.
• Keyboard layout was switched back to non-swedish (typed underscore instead of a question mark for example).
• Fov (and thus sensitivity?) is weird compared to how it's in 2.2, i guess it has to do with the aspect ratio stuff for which i have compensated in my regular config.

Are these known issues or is there perhaps a newer version of 3.0 i can try out? Version gives me ezQuake 3.0 Alpha R4621 ~4BF8793

Suggestion:
A solution to "wait 2 seconds" when trying to change map (after current map just loaded).
Maybe queue the command?

Eh? Never heard of anything like it. Anybody else experienced this? I suspect there's something else going on..

Weird about the texture stuff, haven't touched that intentionally anyway. Can you see if you can figure out why it happens or if you find a solution to it? Otherwise if you could provide me with as much info as possible and I'll see if I can reproduce it and find out why it happens.

Keymap support has been dropped. Is there a big demand to bring it back? If so then I'll look into it.

Regarding fov, yeah just drop your compensations. There is no more wideaspect or settings like that. If you had fov 115 on a CRT then use fov 115 no matter the screen resolution/display/aspect ratio, it will always look the same in 3.0. So yeah it's a little bit of work to set it back to what you had on a CRT, but then you don't have to care ever again

That's a pretty recent version, no big changes (yet) since then. Meag fixed the bug with some screenshots missing the scoreboard on match end and I fixed some other small stuff.

Some nice changes/additions in 3.0 I could mention:
/qtv qw.foppa.dk:27501 (to get to the QTV of that server. If you are already connected to a server then just hit /qtv to get to its QTV)
/join works from QTV now

I've seen weird behaviour when cl_demospeed isn't set to 1... the particle system pauses (so explosions seem to hang in mid-air, you get no rocket trails), sounds aren't played unless they are for the viewentity, etc. But the entities move around as normal, so it looks very strange - but I can replicate this on my version of 2.2. Setting cl_demospeed 1 (or demo_setspeed 100) fixes it, although a reconnection is sometimes needed else random muzzleflashes seem to appear. I'm not sure what to do about fixing it - should we just ignore demo playback speed when connected to QTV, or should a QTV stream be pausable?

Disappearing completely from the scoreboard sounds like the QTV bug with corrupt userinfo - to test, browse to http://qtv/nowplaying in a browser and see if the players are listed correctly on the resulting webpage. If they're blank there (or not appearing at all) then it's a fix for the server admin unfortunately - the client will get sent the corrupt userinfo when you connect and won't be able to do anything with it.

If the above explanations don't apply then I'm happy to spend time investigating.

Where did /qtvlist go? i really miss it =)

From the git repo:

EX_QTVLIST: New module to parse JSON from Atrophy's QTV API

New command:
qtv [gameserver:port] - If connected to a game server, find a QTV
stream address and connect to that QTV, otherwise connect to the QTV
associated with specified server:port, if found.

Changed commands:
qtvlist - Renamed to qtv_query_sourcelist
qtvdemolist - Renamed to qtv_query_demolist

join - It's now possible to join a gameserver from watching through QTV,
just type /join

No issues for me on Windows 10 with the build I compiled. BTW I shouldn't get any credit for writing down some notes, Dimman and friends did all the work

No issues for me on Windows 10 with the build I compiled. BTW I shouldn't get any credit for writing down some notes, Dimman and friends did all the work

Are you running on Windows, and are the textures jpeg?

Just tried this on Windows 10, using same settings, config etc.

Noticed two things: I get US keyboard layout instead of Norwegian (annoying, but not that important), and my FOV changes, I took screenshots standing at the same place pointing the same way. (And also, 3.0 saves screenshots as png, not jpg.)

I have a 16:10 monitor with conwidth 768 and conheight 480. I supposed the solution is to revert to 640/480 as 3.0 fixes the 4:3 to 16:10 by itself (?), so I tried that, and I get the correct width, but now I have different height.

I'll let the screenshots explain:

EZQ 2.2 with 768/480 -- my original FOV


EZQ 3.0 with 640/480 -- same width as original, but less height


EZQ 3.0 with 768/480 -- same height as original, but wider


What's happening here? And what would be true to original QW? I think the console font looks too fat and squeezed when using 640/480 in 3.0, so I don't think that's the solution. Or maybe I've been playing with a FOV that's not quite proportionally correct all this time, so there's no point trying to replicate my 2.2 FOV?

What would be correct settings for 3.0 and 16:10 monitor?

Noticed another thing:

When running 2.2 and 3.0 with exact same settings, the vid_gfxinfo shows slightly different values:

2.2 has 32-bit color and 8-bit stencil:


3.0 has 24-bit color and 0-bit stencil:


Now what is stencil anyway? And can QW even differentiate between 24- and 32-bit color? Should I expect 32-bit / 8-bit in 3.0 instead of 24-bit / 0-bit? If so, are there settings I should look at? Or doesn't this matter at all? I didn't notice anything different when playing ...

First of all, most of the things you mention has been addresses previously in this thread.

Have you made sure that your resolution is the same in both cases? (Nevermind, It look like it when looking at the screenshots). The video resolution commands have changed in 3.0. Use vid_width X and vid_height Y to set a custom resolution plus set vid_usedesktopres to 0. By default it uses your desktop resolution. The vid_mode cvar is gone (because it was far from user friendly) so if you want to use any other resolution, either use the menu or specify vid_width/vid_height and set vid_usedesktopres 0.

I think your problem is related to fov rather. You have to adapt it back to your 4:3 fov as mentioned earlier, see previous posts.

Basically don't listen too much to what it says, the color bits being 24 is because thats just a hardcoded dummy. Has a FIXME in the code to actually fetch the correct value. However for the stencil buffer it seems like I have to specify that I actually want an 8bit stencil buffer. Everything else in regards of SDL2 seems to give me the highest possible value it can achieve. I'll fix this and hopefully the color bits reporting too later.

See: stencil buffer

Thanks. Gonna test. Do I use vid_width etc. in command line when starting EZQ, or just in config?

Don't use cmd-line unless necessary. Type it in cfg or console (hit vid_restart if changing in console)

But as I said I think your problem is that you use the same fov value as you have in 2.2, that will not be the same in 3.0. Lower your fov to whatever you had on 4:3 CRT.

The following worked for me to get .jpg support back into the Windows build:



Had a bit of a nightmare getting this to work as I was following advice to run autoheader... don't, it will remove the fix for Windows systems as the library shares the typename 'boolean' with Windows library functions. Everything will compile but the types will be different sizes when compiling the library and ezquake, and no jpegs for you.

Hopefully this helps the reports of textures not loading.