R1Q2 on the other hand has an extensive and proven track record that is solid as a rock.
Quote from: r1 on January 02, 2013, 08:48:49 PMR1Q2 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
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.
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 come from QuakeWorld and ezQuake, which I believed was an incredible client. With Q2pro I realise how bloated ezQuake really is.
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.
Quote from: skuller on January 03, 2013, 09:16:35 AMIt 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.
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
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 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).
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.
Something that would actually impress me is showing that the code base is valgrind- and clang-clean.