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.
Quote from: empezar
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".
Quote from: Jay Dolan
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.
Quote from: Jay Dolan
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).
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.
Quote from: r1
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.
Quote from: r1
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.
Quote from: empezar
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
If SkulleR is merely saying: anticheat.dll encrypts its message channel to the AC root server; well, yes. Isn't that what one would expect?
I was saying that I would expect anticheat to search just for active Quake 2 cheats currently loaded into memory, yet the anticheat protocol readily provides commands to read arbitrary directories and files from disk outside of Quake 2 base directory. While I suppose these commands have some semi-legitimate purpose (searching for offline cheats? checking for modified system files? maybe even scanning web browser history for cheating sites?), they are a security hole if someone gains unauthorized access to anticheat server and/or data stored there. (Anyway, silent anticheat.dll auto-update feature itself is a big security hole as well). Very little is known about how anticheat server is run, what user data exactly is preserved, etc. Earlier versions of anticheat.dll didn't event check server certificate making man-in-the-middle attacks on anticheat message channel possible.
I understand anticheat would be less efficient without these features, so they are perhaps "necessary evil". What I don't really like is that how many servers and even leagues are requiring use of anticheat lately. Instead of requiring known or suspected cheaters to use anticheat in order to play, they are forcing many legitimate players deliberately install a "backdoor" on their system and put their privacy to risk. I no longer want to make my client part of this.
I don't think so but I'd like to read your thoughts on why the Loxo server has not crashed with ED_Alloc: no free edicts nor has it crashed with SEG-FAULT or bad data overwrites. Typical LOX num_edicts runs in the 500 to 700 range on 12 players and custom maps. It's been a long time since the server had a heavy load.
Most likely it has never hit the 1024 entities limit. R1Q2 server will almost definitely crash once an attempt to link an entity beyond MAX_EDICTS is done.
Quote
But why does it say this in the original game.h?
Well that comment is generally true. It just needs to mention that server can handle not more than 1024 entities.
You seem to be mixing up MAX_PACKET_ENTITIES (maximum number of entities in client frame, which is 128) and MAX_EDICTS (maximum number of entities in game from server and client points of view).
Perhaps there was intent to make maxentities completely configurable, but that never got implemented in server and client. As a result, game allocates memory for entity array dynamically, while client and server use fixed arrays. Actually, ge->max_edicts field is never referenced by 3.20 server code, but in many places server implicitly assumes ge->num_edicts to be less than MAX_EDICTS. If server encounters an active entity beyond MAX_EDICTS, bad things will happen (server may silently overwrite memory).
So it is a good idea for a mod author to verify that maxclients < maxentities <= MAX_EDICTS at server startup.
You can't have more than 1024 entities in Q2 without bumping MAX_EDICTS constant and thus changing the network protocol. Setting ‘maxentities’ cvar alone to 2048 won't help (once 1025'th entity is allocated server will crash anyway).
When converting from binary to text LMPC shows "read error" message for some reason, but it appears to be harmless (apparently it doesn't handle end-of-demo packet well?).
To know which entity is assigned to what player, one needs to look up playerskin number by looking at configstrings packet (LMPC inserts handy comments to ease this task). Relative playerskin number is equal to client slot number on the server, and client entity number is always client slot number plus one.
Changing modelindex to 255 on entity 13 worked fine for me with that demo, in a sense that player entity is now visible. I didn't use keygrip though, but LMPC and a text editor. Here's the result.
Another solution might be to ID the chased player and then not render him in the chasing client.
This is how it works in OpenTDM/OpenFFA mods. It requires cooperation from the server to hide player entity from the specified client. Both R1Q2 and Q2PRO servers support this. Game API has been extended so that a new shared field ‘clientNum’ has been added to the beginning of gclient_s struct:
struct gclient_s { player_state_t ps; // communicated by server to clients int ping;
// the game dll can add anything it wants after // this point in the structure int clientNum; };
A compatible game mod fills this field with current client POV number: it is equal to client slot number for normal players, and changes for spectators that are chasing other players. Server looks at this field and hides player entity from client frame if necessary. A question remains is how the server would know that game mod is ‘clientNum’ aware and actually fills it with meaningful information, and how the game mod would know if it can safely use ‘clientNum’ for in-eyes chasecam. This is implemented though game/server features cvars. On startup, R1Q2 and Q2PRO servers set a read-only cvar ‘sv_features’ to a bitmask of supported features, among them is GMF_CLIENTNUM feature:
In turn, game mod sets a read-only cvar ‘g_features’, exporting a bitmask of features it supports. Server then looks if ‘g_features’ has GMF_CLIENTNUM bit set, and if so, it respects ‘clientNum’ field. Game mod looks if ‘sv_features’ has GMF_CLIENTNUM bit set, and if so, it implements ‘proper’ in-eyes chasecam view by simply copying the playerstate of chased player to spectator playerstate (changing pm_type to PM_FREEZE and setting PMF_NO_PREDICTION bit of course). This is an example of how it can be done:
Show Posts
