If hud scaling doesn't do it for you I found a yellow conchars.pcx helped me a lot. Just drop it into baseq2/pics to override the green one. If that doesn't do the trick then you might have to copy it to the mod/pics folder for whatever mods you play. The physical file in the tree overrides the green one in the pak0.pak but if the mod distro has a green one in a pak somewhere I think it overrides it back.
I've cleaned it up and brought the code up to more current usage per ISO C11 and it now compiles without warnings or errors on Linux, Windows and OSX on Visual Studio 2019, GCC and clang. The code in the original ZIP has a gravity tweak that didn't appear to have a logical reason but I left the code in place and added a macro to turn it on if some really wants it that way. See my discussion in the issues tab for the repository, Issue #1.
Warning to Windows VS2019 users: The project is currently set to build straight into the c:\quake2\lmctf folder for debugging purposes so be sure to backup your older gamex86 binaries before building this. When switching from Debug to Release builds, be sure to do a Rebuild solution to fully build the objs and binary.
Q2admin users, rename the binary to gamex86.real.dll or gamei386.real.so to allow q2admin to cascade to it.
Modders: If you make changes, please fork the repo and post pull requests so I can keep it current. Thanks.
for (count = 0, ent = master; count < choice; ent = ent->chain, count++) ;
The crazy comma operators and the dangling semicolon always pressed my WFT button.
Since my age and health conditions make it dangerous for me to venture forth into the dirty world of Coronavirus infestations and since zombie-making infection carriers are indistinguishable from normal humans unless you have infrared vision to spot the fevers, I am confined to my home for the weekend, doing my part to flatten the curve and save the world. I was "essential personnel" Friday and I will be again Monday but once I solve one problem Monday I will be back to saving the world by not participating in it.
So I decided to focus on this one function in Q2 mods called DoRespawn. This is the "Think" function that gets triggered when it's time to respawn items like armor shards, armor jackets, weapons, health boxes and pills, megas, etc. Anything that gets picked up and needs to be respawned after a scheduled time period.
Modern C has different rules than it did back in the days of the creation of Q2 and Microsoft Visual C++ of 1997. Some idioms remain but the particular idiom used by Zoid just makes a code maintainer stop and say "Oh? Hmmmm." Modern C compilers are also better at optimizing code so it's not necessary to resort to idioms in an attempt to make the code faster. Succinct C is not necessarily efficient C.
So here's a fix for the most basic version of DoRespawn with the idiomatic syntax removed and some error checking and reporting in place and some coverage for cases of null pointer dereference. Some versions have more code in place to take various actions on respawn but my primary goal was to refactor the for loops into something more easily understood at a glance and to maintain.
It's a script or bot of some kind. It shoots intermittently, repeats taunts, runs backwards, doesn't seem to work to acquire weapons and when it drives itself into a corner or water it doesn't work to escape and often drowns. I watched it walk backward off a spawn point and into lava.
I'm currently using Quake 2 Pro as the client and Quake 2 DOS as the dedicated server that running on the Maraakate's coop server mod with newly added maps. i don't believe that could be the problem due to changing the maps because of three occurrences the happen as to when this error appears.
I don't think the client matters. Mostly, the client can only ask the server to do something, it's up to the server game code to decide whether it will do it and how it will do it.
The first occurrence is when a player exits the map.
Exits as in taking an exit door, I presume. When that happens the next map opened is the one defined in the current map. All the original single-player maps had a next map, the SP game depended on this. Many DM maps don't. Failing to have a next map defined is supposed to cause the server to choose one, usually from a map list. The map list file (assuming there is one) is defined by the mod code. Some mods didn't always change maps gracefully when this happened. I don't know if this is one of those.
The second occurrence is when the player votes for a different map.
If the mod uses the "map" command to change maps on a vote then the engine will unload and reload the game DLL. This is why you use the "gamemap" command instead. R1q2 will refuse to use "map" in rcon and I assume it will also do so for a voted map but I have not tested this. (IIRC, mods are supposed to use the "gamemap" command in what amounts to a sending of a command string to the engine via the gi.AddCommandString function but I suppose one could put a new map name into the level.changemap string and call ExitLevel.) From this source: https://bitbucket.org/neozeed/q2dos.git … and looking at the coop code, I can see many different map votes: restartmap causes a map command. gamemode causes a map command. coop difficulty causes a map command. warp causes a gamemap command. playerexit causes a gamemode command which causes a map command. Lots of ways to force a DLL reload. Most of them would be necessary since they need to force GameInit. If you are restricting your server to coop only mode I recommend disabling all but the vote warp commands or testing your server to see which are safe to use.
And the third occurrence is when changing the map to a different map though the Q2DOS console. Now, when you mentioned running the gamemap command, I will be sure to use that for running such commands in the Q2DOS console.
I used to use the rcon map command until I was enlightened by r1q2.
I wanted to also mention that when I run the Maraakate's coop server on the alternative game servers listed: r1q2 dedicated, quake2 dedicated, yamagi dedicated, q2pro dedicated they also produce the wrong Game library is version 4 expected 3 and vice versa. I mention this because I presume there might be a possibility that I wouldn't get that FreeLibrary error message for those alternative game servers if they were to work without crashing and without producing the improper Game library version error.
Wrong game library version is a very bad no no. All bets are off and the engine has every right to not run a game DLL of the wrong type.
The game version is a number that specifies the interface between the engine and the game. The interface is the imports and exports to/from the engine and the game DLL. They specify the contract between them and it affects what functions they can use between them. The version number is the first thing the engine checks when it loads the DLL. EVERY engine should reject a wrong version DLL unless it's going to go to some extreme measures to figure out how to accommodate a different version DLL. There is NO WAY to tell, from the version number alone, what the interface looks like.
The coop code in the neozeed repo I cited above is version 4. It will not work with any other engine but Q2dos which, it would appear, expects version 4 DLLs. Looking at the coop code I see they added a function to the engine called cvar_setdescription in the game that is called numerous times in the game startup. An engine that doesn't export this function will fail when the game calls it.
When an engine rejects a DLL for wrong API version number it must never call anything in that DLL and it must immediately unload that DLL and stop game service.
If you want a version 3 DLL of coop I suggest: https://github.com/basecq/q2dos.git but I don't know if it has the same features. There are a lot of differences in the code that I am not prepared to analyze.
All this is TMI and more than you wanted to know but that's what happens when my coffee kicks in and I have a day to spare. I hope it guides you in your troubleshooting.
It sounds like your mod is using the “map” command on the vote or console command. This is an old and common error. You should be using “gamemap” instead. The map command should only be used in your startup script.
I don't think you can crash a server by spamming just one model but you might be able to do it by spamming different new models. The model indexes are assigned as models are needed up to the limit of the game and if a model already exists in the array it isn't added to the indexes. (You can't fill the array by spamming the same model name.)
Coop mode has always been a little unstable in my experience. The original game was all about a single player with monsters and items in the maps and as long as the maps didn't go over the model limit minus one for the player everything was hunky-dory. The player and map entities are reserved during initialization and the map model indexes are assigned as models are spawned during map load. Load a server with multiple players and monster models and you've got a big load.
The error recovery in Q2 was always a bit thin. It'll crash and report a hard error rather than try to discard and replace items and spend time managing memory or entities. It just wasn't designed for that at the inception. Speed and size on a i386/i486 was the design limitation of the time.
It sounds to me more like you had a larger map and lots of entities in that map and the spawning of a hyperblaster was enough to take it over the limit. I don't remember the bsp name for the Upper Palace (edit: it's city3) but I know that one was a heavyweight map even for DM.
Additionally, when they added VWEP to the game they used index 255 for it and depleted the pool by one.
To diagnose this error the "configstrings.txt" file is dumped by the server into it's root when it happens and might be helpful.
Show Posts
