Another Quake 2 package - nQuake2

[empezar]

Glad to be sparking even more competition.

I hope nQuake2 will get some attention anyway, and that Q2pro evolves into a better alternative partly thanks to the exposure given.

At this point, including two clients in the package is too much work.

You are all free to use my work as it is GPL. Source code here: https://sourceforge.net/projects/nquake/files/nQuake2%20%28Win32%29/v1.0/

[VaeVictis]

R1Q2 on the other hand has an extensive and proven track record that is solid as a rock.

except the random crashes that happen all the fuckin time some people even use that as an excuse to stay on 3.20

it doesn't really matter what client you use, but including several would be epic.... larger install file, or option to pull files via ftp off a mirror or something for other clients, and just choose which one you want when installing... aprq2 and r1q2 would only add to the package

probably the best route to take with a starter package though is a minimal approach, and once people know what they want they can modify it accordingly

[quadz]

R1Q2 on the other hand has an extensive and proven track record that is solid as a rock.

except the random crashes that happen all the fuckin time

For what it's worth, this has been my experience with r1q2 as well. Crashes a few times a month, seemingly at random. (And on the most generic maps & mods, for instance the dm server.)




With regard to the current R1Q2 vs. q2pro usage stats, one might imagine those numbers would be all but invisible to new players. As long as (whichever) installer gets them smoothly into the game, I doubt whether they'll be too concerned about the relative popularity of their particular client?


Regards,

quadz

[fdrjk]

I never have any problems with AprQ2 because it's the best client out there. 

[empezar]

Since different clients require different configs, I will probably not add more clients to nQuake2.

I have a really good configuration setup now. nQuake2 really has the feel of a modern game. Much thanks to Q2pro, for really being a pro client. I come from QuakeWorld and ezQuake, which I believed was an incredible client. With Q2pro I realise how bloated ezQuake really is. We have a lot to learn from Q2pro.

I have too little experience with R1Q2 to say anything about it, except that I dislike the idea of an anticheat module, and that it's not developed anymore. Any bugs that arise with Q2pro will hopefully be fixed. And clients come and go. Just because R1Q2 is the most popular client right now doesn't mean that no other client can take its place.

[The Happy Friar]

I can't contribute to the package but I can give comments on what my friends encountered when they play Q2 LAN @ my house last saturday, and that might help for new players:

*settings wouldn't hold between mods.  This was the biggest issue.  When you reconnect to a server from an already running client it wouldn't run the autoexec.cfg or config.cfg in the mods folder if you had the mod already installed.
*no mouse support in the main menu like so many other games.
*player models don't display for some mods in the multiplayer setup menu
*no list of controls.  The idea of making the console background or loading screens a KB+mouse layout was an AWESOME idea.  Could be customized for each mod.
*no option to reset to hud to a stock default.  One person used the Q2Kickstarter from TS, & the rest of us used a copy of Q2 I keep on a USB key drive.  The ones who use mined had a HUD they didn't like.
*R1Q2 worked great on the Windows machines but the Mac needed to run arq2 to run in a Windows Emulator.  Get someone to double check the client you use runs on a Mac/Linux emulated Windows too.

[skuller]

Need help compiling the latest Q2pro client from sources. I have no idea how to do this. nQuake2 will be Windows only so I will only need a Windows binary.

I've prepared SDKs for MinGW-w64 and Visual C++ 10.0 to make building Windows version of Q2PRO from Git easier. These SDKs include all additional libraries and headers Q2PRO requires. See the Q2PRO homepage for download links and instructions. For building on Windows, Visual C++ compiler included in Windows SDK 7.1 package from Microsoft is probably the best option.

It would be a good idea to distribute resulting q2pro.stripped.pdb (after renaming it to q2pro.pdb) file along with q2pro.exe to make runtime crash dump generation more detailed.

The client is the single most important design decision here. Its stability is paramount and trumps features any day of the week. More players will no doubt experience the said crashes, resulting in more random confusion.

I do fully agree that client stability is important. All crashes that are properly reported will be investigated and fixed.

R1Q2 on the other hand has an extensive and proven track record that is solid as a rock.

It has an older code base so that no crash bugs are immediately visible. But throw a corrupt input at it for example, some robustness problems R1Q2 has will become more evident.

I come from QuakeWorld and ezQuake, which I believed was an incredible client. With Q2pro I realise how bloated ezQuake really is.

Thanks for kind words, avoiding code (and feature, to lesser extent) bloat is one of design principles of Q2PRO

[empezar]

Great skuller!

I have a feature request, pretty simple one. (I didn't find any way of submitting feature requests on your git page.)

I'd like to have a "user.cfg" or something in \baseq2 or \q2pro or something, which gets executed last of all configs, "system wide" i.e. even after mod autoexec.cfg. This means execution order should be default.cfg -> q2config.cfg -> autoexec.cfg (all mod specific) -> user.cfg (one file, system wide).

That way I can have keyboard configs, name, etc in the nQuake2 installer and print it to user.cfg. That way I won't have to do this for every mod I play after a fresh install:

name Empezar
bind shift +moveup
m_pitch -0.022

The list of changes needed for every new mod is bigger for some of my friends. Having this in the installer would reduce the time needed to get started.

[Jay Dolan]

It has an older code base so that no crash bugs are immediately visible. But throw a corrupt input at it for example, some robustness problems R1Q2 has will become more evident.

I'm sorry, but that test suite is laughably irrelevant. I've never used Q2Pro, so I can't comment on its stability in general and I don't question that you've made a significant effort to make it so. But I've also never in my 15 years of playing and eventually developing for Quake2 encountered a malicious .bsp file. You should develop a more practical test suite if you want to show off your client's stability.

[quadz]

It has an older code base so that no crash bugs are immediately visible. But throw a corrupt input at it for example, some robustness problems R1Q2 has will become more evident.

I'm sorry, but that test suite is laughably irrelevant. I've never used Q2Pro, so I can't comment on its stability in general and I don't question that you've made a significant effort to make it so. But I've also never in my 15 years of playing and eventually developing for Quake2 encountered a malicious .bsp file. You should develop a more practical test suite if you want to show off your client's stability.

On the other hand, nobody had encountered a malicious JPEG either -- until people started making them.

I suppose one could argue that Q2 isn't popular enough to likely attract any malware authors, but that wouldn't be the sort of equivocation I'd want to hear from anyone writing software intended to run on my desktop.

And while I'm generally wary of 'slippery slope' arguments, I nevertheless think a zero tolerance policy is the only effective stance against potential crash cases in my code.

When developing my own software, my feeling is if I were to knowingly allow a single potential crasher edge case to persist in the code, then I'm likely to allow another one sometime later, and eventually another... because why would I stop at just one? And eventually my codebase is littered with potential defects. And as development continues and interactions between modules and their data changes and evolves, eventually some of these rotten edge cases are going to bite me or my users.

So what I like most about skuller's test suite is not that it tests against malformed BSP files in particular, but that it appears to show a significant level of dedication toward software quality in general.

So... 


quadz

[reaper]

vote map X, q2 crashes and your computer's taken over!?

 

[Jay Dolan]

So what I like most about skuller's test suite is not that it tests against malformed BSP files in particular, but that it appears to show a significant level of dedication toward software quality in general.

So... 


quadz

Arg, I'm really tempted to explore this subject by offering up a code review, but I literally just do not have time right now. I'm leaving Massachusetts today, driving back down to home in Naples FL. I have briefly scanned the Q2Pro code. My personal opinion is that the model loading code is being used as a strawman case that Q2Pro is more stable than other clients. Every Quake2 client I've played with has crash cases in it. And the network protocol is by far the easiest and most likely attack vector.

Something that would actually impress me is showing that the code base is valgrind- and clang-clean. Just my $0.02. 

[quadz]

My personal opinion is that the model loading code is being used as a strawman case that Q2Pro is more stable than other clients. Every Quake2 client I've played with has crash cases in it. And the network protocol is by far the easiest and most likely attack vector.

I see. Well, granted if that were the primary motivation rather than this being a reflection of an overall zeal for code improvement, then yeah: that would be... sub-optimal.

I have insufficient data to speculate on that.

However, any way one slices it, the testbed-inspired fixes would seem to constitute genuine improvements to the codebase.

[skuller]

I have a feature request, pretty simple one. (I didn't find any way of submitting feature requests on your git page.)

Feel free to post feature requests the same way as other issues on github.

I'd like to have a "user.cfg" or something in \baseq2 or \q2pro or something, which gets executed last of all configs, "system wide" i.e. even after mod autoexec.cfg. This means execution order should be default.cfg -> q2config.cfg -> autoexec.cfg (all mod specific) -> user.cfg (one file, system wide).

I've added logic to exec postexec.cfg file (if it exists) after mod-specific autoexec.cfg. If you place postexec.cfg in baseq2/ it will become "system wide".

I'm sorry, but that test suite is laughably irrelevant. I've never used Q2Pro, so I can't comment on its stability in general and I don't question that you've made a significant effort to make it so. But I've also never in my 15 years of playing and eventually developing for Quake2 encountered a malicious .bsp file. You should develop a more practical test suite if you want to show off your client's stability.

A reference to that test suite is pretty relevant as it questions the idea that "R1Q2 is rock-solid". I'm making no claim that Q2PRO is rock-solid either, every software has bugs. I've spent some time to improve code robustness in areas other developers overlooked or didn't consider important, that is the point the test suite illustrates. It would be certainly nice to increase test suite coverage by expanding it to other resource formats loadable by Q2, but that is a lot of work.

That you've never seen a malicious .bsp file doesn't mean it can't be created on purpose for targeted attack. Computer security works by patching the hole before it gets exploited, not the other way around.

Something that would actually impress me is showing that the code base is valgrind- and clang-clean.

Not sure what you mean by "clang-clean", but I regularly use clang for development builds and never had any problems with it. Feel free to report any issues you find with valgrind (from a few test runs with memcheck I didn't see anything suspicious).

[empezar]

Is this new postexec.cfg something new or did you just add it? I can't get it to work with 26 dec build.