|
Title: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 02, 2010, 11:40:27 AM Hi,
My server OpenArena cresh randomly My OS is Debian Lenny 5.0.5 Only OpenArena is from unstable version openarena-data (0.8.5-3) openarena-server (0.8.5-4 and others) Older version 0.8.1 was okay Log and config: http://game1.xline.cz/oa/log/ Tomas Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on September 02, 2010, 11:53:14 AM That crashlog.txt file reports 403 Forbidden, I can't read it.
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 02, 2010, 11:58:00 AM Sorry, is it log (crashlog.txt) OK
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on September 03, 2010, 04:28:42 AM Do these crash appear often ?
Seems unlikely, but do you add bots once the server is started ? Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 03, 2010, 04:40:47 AM Yes,
If play boots or player, server crash in 30minutes - 2 hours Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on September 03, 2010, 05:43:49 AM Maybe there is no bot support in one of the maps you play.
If the crash always happen on the same maps, that would explain. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 03, 2010, 08:32:58 AM Server crashes independently of the map :(
Could be a old library of Debin Lenny? (That would be a problem) Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on September 03, 2010, 03:41:41 PM If it happens often, you may try to install the openarena.ws release (not the debian one) and see if it solves anything.
I run Debian too on most of my servers, your problem is not likely due to a library, more likely due to some exotic setup (if I learned my lessons well, your crash comes from the virtual machine of the game, not from the engine/system itself) Do you use some custom pk3s in your server ? (like mods, maps/ressources...) Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 04, 2010, 06:57:58 AM This is default (clean) install from Debian.
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 04, 2010, 09:13:51 AM Test:
Debian Leny and OpenArena from unstable/testing repository - Server crash Debian Testing and OpenArena from unstable/testing repository - Server Where is error? Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on September 04, 2010, 06:12:08 PM And if you try with this+that ?
http://openarena.ws/download.php?view.2 http://openarena.ws/download.php?view.3 Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 24, 2010, 12:38:13 PM Server is OK on original file from http://openarena.ws/
Where is bug? (I prefer a package of Debian) Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on September 25, 2010, 04:16:23 PM Hard to know the reason of the bug.
Check last error messages every time, try to reproduce the crash (try to know its conditions : specific maps, specific settings with bots, specific game modes...). It's not even sure official OA release runs better than the Debian one, maybe you just got luck with the first. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on September 25, 2010, 05:12:08 PM Debian has started to use compiled so files instead of qvms. The so-files was only meant for debugging and greatly increases risks of a crash.
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on September 26, 2010, 03:15:24 AM Crash log often ends:
Kill: 2 2 26: Player_name killed Player_name by MOD_KAMIKAZE Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 11, 2010, 05:33:25 AM Thanks for reporting this. My guess would be that it's a NULL pointer dereference somewhere in qagame, possibly related to the kamikaze - NULL pointer dereferences will crash the native-code version, but would just quietly do the wrong thing in the bytecode interpreter, as far as I can see.
If you can rebuild the Debian version of openarena with debug symbols (DEB_BUILD_OPTIONS="noopt nostrip") and get a backtrace from a crash with gdb, that would be very useful. I realise those instructions are rather too short to be useful, I'll try to provide more detailed instructions later. I assume you're using some sort of wrapper script to run the server repeatedly and capture crashlog.txt whenever it dies? If so, please send me a copy, and hopefully I can modify it to pick up backtraces from gdb automatically. I had to remove the bytecode from the PK3 files in Debian for licensing reasons, but the engine still has the bytecode interpreter/JIT, so if you replace the PK3 files installed by openarena-data with the ones available from here, the Debian engine build is still able to run the bytecode versions of the game logic (if both bytecode and native-code are available, it'll normally prefer to run bytecode, unless configured specially). It'd be very useful to get a crash backtrace, though - any crash in the native-code build indicates that there's a bug somewhere. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 11, 2010, 02:57:55 PM Here's a version built with debug symbols, with a script added to run it under gdb. Install the appropriate one of:
http://people.debian.org/~smcv/openarena-server_0.8.5-5~debug_i386.deb (32-bit) http://people.debian.org/~smcv/openarena-server_0.8.5-5~debug_amd64.deb (64-bit) From your crash log it looks as though you'll want the i386 version. Instead of running openarena-server, if you run "/usr/share/games/openarena/openarena-server-gdb", it should add a backtrace to the crash log when it crashes. Please do that, try to crash it (adding a lot of players/bots might help to make it crash quicker), and send me the log. To check that the crash logging is working, you can simulate a crash with: pkill -ABRT openarena-server Note that that command will "crash" every OpenArena server on your machine, if you're running more than one! The log from simulating a crash like that won't be any help to me, but you can use it to check that the crash logging is actually working: if it is, you'll see a lot of gdb output at the end of the crash log, starting with something like this. Program received signal SIGABRT, Aborted. __strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy.S:1107 1107 ../sysdeps/x86_64/multiarch/strcpy.S: No such file or directory. in ../sysdeps/x86_64/multiarch/strcpy.S Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 11, 2010, 05:07:42 PM While trying this out with many bots, I got one server crash caused by a missing NULL check: client was NULL in the backtrace I saw. I can't see how it would happen in practice (both players and bots have a client structure) and couldn't reproduce it, so this may or may not the same bug glabasnat saw, but the change would be good to have regardless.
I'm doing an updated debug build with this fixed. When it finishes compiling and uploading, it'll be at: http://people.debian.org/~smcv/openarena-server_0.8.5-5~debug2_i386.deb Code: commit 80f2967f82314bf10e975d1b00678b9b4327eae9 Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 11, 2010, 05:18:20 PM Now uploaded. However, openarena-server-gdb turns out not to be quite right: you'll need to edit it and change where it says "/usr/games/openarena" to be "/usr/games/openarena-server". I'll fix that in the next build.
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on October 12, 2010, 03:48:36 AM Heh, your efforts are quite appreciated :)
I had something in mind, which is: try to find configurations which make the server crash (simple). Right now you may be aware if a map doesn't have some bot script, and the server tries to add bot, then it crashes (or at least it complains a lot. There are also a few issues about "spawnpoints" which if they do not exist in certain gametypes (starting a deathmatch on a CTF map) will crash the server. They're not related to the engine but to the QVM, I didn't take that initiative from now because I wasn't sure what developers were able to do against it, to fix it, nor if it was worth, I'm also ready to start back using the debian package if I know there is care for it and if it's maintained. Goal would be to get better stability for OpenArena servers. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 12, 2010, 05:25:43 AM They're not related to the engine but to the QVM, I didn't take that initiative from now because I wasn't sure what developers were able to do against it, to fix it If you use native code for the game logic that'd normally be bytecode (the native-code version is qagamesomething.so or qagamesomething.dll, the bytecode version is qagame.qvm in the PK3 files), you're more likely to see hard crashes rather than things quietly going wrong... but if you can get a backtrace for those crashes, it's also easier to fix them :-) We can't use the bytecode version in Debian/Ubuntu because there's no suitably licensed compiler for it, so we get more crashes, but more debuggability, as a side-effect. Hopefully that'll mean I send in a series of one-line patches and things get more reliable for everyone! I've left an openarena-server running on a spare machine with 16 bots fragging each other at an accelerated g_speed, I'll see whether any of them manage to trigger another crash... Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: glabasnat on October 13, 2010, 02:32:38 PM Good work,
I tested: openarena-server_0.8.5-5~debug2_i386.deb openarena-data (0.8.5-3) Server is online 24 hours :) Tomas Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on October 13, 2010, 02:50:18 PM I can't see how it would happen in practice It turns out you can trigger this by setting off the Kamikaze close to a non-player object (e.g. anything you can pick up), so I'm fairly confident that this is what caused glabasnat's crashes. sago007 applied it in svn as r239, and it'll be fixed in Debian as version 0.8.5-5. Hopefully I can get a freeze exception to get this into Debian 6. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on October 25, 2010, 02:03:47 PM I gave this debug package a try but I didn't find as many problems as I was expecting.
I might install it on other played servers, but it happens my servers are quite stable these days. Only crash I was able to reproduce was because of missing spawn points. Take this map: http://download.tuxfamily.org/openarena/autodownload/baseoa/schism-b2.pk3 Start this map with g_gametype 4 (CTF), and join either blue or red team (or ask a bot to do so). It will crash with: Code: ClientUserinfoChanged: 0 n\^7Caca^2t^7oes\t\1\model\arachna/red\hmodel\arachna/red\g_redteam\\g_blueteam\\c1\7\c2\5\hc\100\w\0\l\0\tt\0\tl\1\id\144F10ADA851FC79008571529BE91EE4 This is only an issue if maps are not properly made, which shouldn't happen with standard OA maps. When used on a server in a regular way (in deathmatch mode), a simple callvote to change gametype would then crash the server. This bug has been mentionned several times on the forum but is not listed on the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]Wiki (http://([b) as of now. I also have a question about the OpenArena Debian package: would it be useful to have some default configuration for servers, and /etc/init.d scripts ? That would be another plus to encourage the use of Debian package over oa.ws ones when installing them on servers. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 01, 2010, 12:03:42 PM This is only an issue if maps are not properly made, which shouldn't happen with standard OA maps. When used on a server in a regular way (in deathmatch mode), a simple callvote to change gametype would then crash the server. The problem is that the game cannot do anything about the problem so it tries to shutdown the game in order to let the script that started the server do its magic. Or in case of a listening server it can drop back to the menu to let the player pick another map.There are not many options: The map has no spawnpoints, so running the game logic is not an option. nextmap might not be set, so the game cannot go to the next map. Restarting the map has no effect as the problem will still be there. The default config cannot be loaded directly because it is only known to the startup script and the problem might have been caused by it anyway. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 01, 2010, 12:12:16 PM What about using the deathmatch spawn points if there are no team spawn points? The map probably would not be completely working anyway (if the author did not put in team spawn points, I suppose he did not put in flags), but at least this would not crash the server.
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 01, 2010, 12:22:30 PM What about using the deathmatch spawn points if there are no team spawn points? It does but the map in question specifically forbids using them in team games so they are removed before the game starts. This is why I say that there must always be one ffa spawnpoint in a map that does not have gametype restrictions on it. Looking at the map schism-b2 in NetRadiant it is clear that it was meant to shutdown in team games. I pointed it out for Nean_Night here http://openarena.ws/board/index.php?topic=2170.msg25801#msg25801 as the maps in that thread suffered for the same problem. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 01, 2010, 12:32:29 PM In this case, I suppose the only thing to do is to ask the map creator to fix the map (IMHO it is better to have a map that starts in any gametype, even if it does not work correcly, than having a server shutdown)...
If a map is released under the GPL and its .map file is available, one may add the missing entities by himself. It is even possible to add new entities without modifying the .map file, starting from the .bsp instead (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Entities-only_editing]Entities-only editing (http://([b)), but I have some questions about the right way to DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Talk:Entities-only_editing]respect the GPL license (http://([b) after doing it. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 01, 2010, 12:39:18 PM If a map is released under the GPL and its .map file is available, one may add the missing entities by himself. One can. The map-file is available under the GPL. It was included in 0.8.0 but was removed due to license problems with the textures.I have looked in the map file therefore I know that the problem is that all spawnpoints are marked as "noteam". Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 01, 2010, 01:07:26 PM I read DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers]here (http://([b) that
Quote //seta g_voteMaps "/ctf_inyard/oa_ctf4ish/hydronex/oasago2/" (no longer available in 0.8.5) Since this looks a bit strange that the server admin has got no way to customize the callvotable maps list, I suppose that it has been moved to an external configuration file. Is it this way? It seems that the page does not mention it...An external text file may be used to support additional options, like allow the server admin to set the available modes for each map, for example: Quote mapname // this line will allow the map to be launched in all the gametypes (like it is now, right?) The callvote system should check this list when someone asks for a "callvote map x" or "callvote g_gametype y": if the map is flagged as not available with the gametype, the vote would not start, returning an explaining error to the user (and maybe to the server console).mapname 0/1/ // this line will allow the map to be played only in these gametypes mapname n/3/4/ // this line will allow the map to be played in all the gametypes, except these mapname n // this line will make the map not available at all mapname * // this line will allow the map to be played in all the gametypes mapname a // this line will allow the map to be played only in the gametypes allowed by the arenas.txt file for that map (the gametypes where you would find the map when starting a match from the GUI). If the map is not listed there at all... I don't know. This would fix the callvote problem. But implementing this system would need some work for Sago... But there would be a problem with the map rotation script: if the players switch to a gametype that is supported in the current map, but is not supported in the next map, what should happen? Maybe, in this case, the engine should automatically switch to the 2nd next map, the 3rd, etc (continuing to execute the additional commands -like changing the fraglimit- included in each line of the rotation script, even if that map is skipped; remember that a line of the rotation script may also change the gametype, fixing the situation or not), until it finds a compatible map; if no compatible map is in the rotation script, maybe it should continue to use the current map until the players will change the gametype again, selecting one compatible with at least one map in the rotation script. Maybe also the "map" and "g_gametype" commands entered directly from the server (without the callvote) may check the list, and prevent from loading the map or asking for a confirm before continuing (in this case, something like typing another command, like map mapname /f or forcemap mapname and g_gametype x /f or forcegametype x?)... I suppose that devmap, spmap and devspmap commands may simply ignore the list. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on November 01, 2010, 04:04:37 PM What if the server changes back g_gametype to 0 if it detects this problem, that would allow players to call for another vote, which they would do if their intent really was to play a CTF map.
I noticed oa_bases3cl has this problem too. Edit: I misread but that was almost the same suggestion Gig did. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 01, 2010, 05:58:06 PM Your solution seems different enough from mine (I suppose that with "detects this problem", you mean to ''automatically'' detect if a map has not valid spawn points available, a thing I didn't thought about).
Maybe it could be faster to implement, and it should workaround this specific problem without the need to do long customization to the server admin. My solution seems longer to implement, and then will need a manual work from the server admin before being effective. But it would allow to workaround more kinds of problems (like maps that do not crash the server, but do not work with some gametypes), and in general it would give a powerful customizing tool in the hands of the server admins (giving them complete control over the allowed maps/gametypes list). Who knows, maybe the better thing would be a combination of the two... Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 02, 2010, 09:14:36 AM What if the server changes back g_gametype to 0 if it detects this problem Gametype 0 might have the same problem.Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 02, 2010, 12:57:01 PM Well, whato do you think about my idea?
- Do you like it? - How much work/time would it take? ... and... what's the current mode to set the available maps? A config file? What's its name? How it works? When using old mods written for Q3A, they use that file, the "old" g_voteMaps, or nothing? Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 02, 2010, 01:21:10 PM Well, whato do you think about my idea? Currently there is votemaps.cfg and it can be changed with the g_votemapsfile-cvar. ... and... what's the current mode to set the available maps? A config file? What's its name? How it works? When using old mods written for Q3A, they use that file, the "old" g_voteMaps, or nothing? Original Quake 3 mods have no limits on voteing unless the mod provides them. Current OAX uses the files maps_dm.cfg, maps_cft.cfg, maps_dd.cfg, maps_elimination.cfg and so on for the autochange map feature. One could redirect the g_votemapsfile-cvar to one of these and force a map from that pool. There is currently a lack of UI to change the maps_GAMETYPE.cfg files and it is also annoying that it was recently brought to my attention that cfg-files in pk3-files cannot be logically overwritten. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 02, 2010, 03:15:41 PM I didn't know that the "autochange map" feature (currently in OAX) used additional files, I thought that it was reading the arenas.txt info. I was wrong.
Simply setting "g_votemapsfile" to one of those files would not fix the problem: it would allow the right maps for the current gametype, but what would happen when one will callvote another gametype? The map list would become wrong... Maybe those files may work as the base table, implementing a way that the game would automatically control a different file depending on the actual/requested gametype (instead of checking the single file of my idea)... and the additional checks (those about the rotation script, etc) should be implemented anyway, I think. PS: in the maps_dom.cfg file you could add the islanddm map, I tested and it works with that gametype (6 domination points). Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Cacatoes on November 03, 2010, 05:56:23 AM What if the server changes back g_gametype to 0 if it detects this problem Gametype 0 might have the same problem.Hmm, cycle through gametypes then ? :D I am not against handling this problem through the start-script and restart the server, reset the config, etc, but I have weird feelings about this and thought there should be a solution within the game. Of course one can build a map with no spawn point at all (who's the admin who would use it, really, means he wouldn't even have tried the map... though some admins leave the possibility for players to upload maps on the server with a web interface), or maybe there should be a safe mechanism to reset the server config. I don't know from a software engineering point of view how this problem can be dealt, but I thought some software should accept any input and digest them in a safe way. Now sorry if I harass you with this problem, I can live with it and if I have a miraculous solution which pops in my mind I'll tell you :) Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 03, 2010, 11:18:23 AM I am not against handling this problem through the start-script and restart the server, reset the config, etc, but I have weird feelings about this and thought there should be a solution within the game. You must remember that the map authors also uses the game to test new maps and if the game makes a lot of assumptions it can mean that the map author misses important information that ruins the map in some other ways. Very fast restarts might disconnect clients anyway. I don't know how the game handles other situations like some variables approaching the upper limit, the binary somehow restarts itself in those situations. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: smcv on November 05, 2010, 04:44:03 AM I also have a question about the OpenArena Debian package: would it be useful to have some default configuration for servers, and /etc/init.d scripts ? There's already a feature request for this, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503106 (we're in freeze for Debian 6.0 at the moment, so if I work on it before that's released, the resulting packages will go into experimental). If you have suggestions/prototypes/patches please email them to that bug; the Debian package for tremulous-server might be useful to base things on. Please feel free to report bugs in the Debian BTS, and open a bug with severity 'wishlist' if you want other Debian-specific features (I don't read this forum regularly, but I'm subscribed to openarena, openarena-server and openarena-data bugs). Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 05, 2010, 07:00:19 AM Somebody knows if DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/InitScript]this script (http://([b) automatically restarts the server if the game crashes?
Anyway, in this case (missing spawn points) the server goes down since it cannot load a map, but I suppose the process would still be there, and an external script would not be able to manage the situation... Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Falkland on November 05, 2010, 10:02:30 AM Somebody knows if DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/InitScript]this script (http://([b) automatically restarts the server if the game crashes? [...] No , by what I see ... but in a recent commit , ioquake3 has added running pid support ( a text file with process id stored in /var/run ) so the script , or another one managed by cron daemon , could check pid file presence and then restarting the server if it's not there anymore ( eg after a server crash ) Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 05, 2010, 10:15:04 AM Somebody knows if DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/InitScript]this script (http://([b) automatically restarts the server if the game crashes? It does. It uses daemon (http://www.libslack.org/daemon/) with the --respawn parameter. The program also keeps the pid, so one can use "service oa_ded stop" like a normal daemon. It was a requirement I had when writing the script that it should automatically restart. However it has other limitations like I had to make a copy of the script and call it oa_ded2 and change NAME in the script to something else.Previously I used a normal script with a while loop but that was annoying then killing the process. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 05, 2010, 11:34:23 AM Sago, maybe in your post you used "then" in the place of "when"?
Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 05, 2010, 11:38:03 AM Sago, maybe in your post you used "then" in the place of "when"? I didTitle: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 06, 2010, 08:49:16 PM Hey, Sago, what do you think about enhancing votemaps.cfg, allowing the admin to optionally set the allowed callvotable gametypes for each map, like I suggested above (http://openarena.ws/board/index.php?topic=3909.msg35972#msg35972)?
Maybe we could even make the "autoswitch map" feature point to the same file... Let me explain why I think that an enhanced votemaps.cfg file would be better than using the maps_GAMETYPE.cfg files. - Probably, a single file should be easier to manage than 11/12 separate files. To add a new map to the list, you would have to add a new line to a single file (even if there is the need of writing some additional values if one wants to hide the map in some gametypes, that is quite probable but not possible at the moment), instead of opening and adding a new line in many files. - One may prepare more variants of his votemaps file, and then select which to use (only one is active at once), using the already existent g_votemapsfile variable. Not so easy instead, if using the maps_gametype files (overwriting the files from the Operating System each time? Creating 12 more variables like maps_ctffile, maps_ffafile, etc?)... - The single file could use that "(a)utomatic" option that would read arenas.txt to determine the allowed gametypes for that specific map. Note: I hope that in the next release the associations in the arenas.txt files will be more accurated than in 0.8.5: I wrote a post here (http://openarena.ws/board/index.php?topic=3566.msg35950#msg35950) with a proposal about how to organize ourselves to test all the maps and then update arenas.txt (we should do it few weeks before the new version will come out). Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 07, 2010, 03:45:25 AM Let me explain why I think that an enhanced votemaps.cfg file would be better than using the maps_GAMETYPE.cfg files. - I believe multiple files are easier to manage... they could be easily generated also by a script. A file with whitespace separated values... it does not get much simpler as this. - Probably, a single file should be easier to manage than 11/12 separate files. To add a new map to the list, you would have to add a new line to a single file (even if there is the need of writing some additional values if one wants to hide the map in some gametypes, that is quite probable but not possible at the moment), instead of opening and adding a new line in many files. - One may prepare more variants of his votemaps file, and then select which to use (only one is active at once), using the already existent g_votemapsfile variable. Not so easy instead, if using the maps_gametype files (overwriting the files from the Operating System each time? Creating 12 more variables like maps_ctffile, maps_ffafile, etc?)... - The single file could use that "(a)utomatic" option that would read arenas.txt to determine the allowed gametypes for that specific map. Note: I hope that in the next release the associations in the arenas.txt files will be more accurated than in 0.8.5: I wrote a post here (http://openarena.ws/board/index.php?topic=3566.msg35950#msg35950) with a proposal about how to organize ourselves to test all the maps and then update arenas.txt (we should do it few weeks before the new version will come out). - The gametype files are selected by g_votemappool, so they can be changed too. The syntax is consistent with other votelists but generally the idea of making a list in a single cvar is not that good. - Arenas.txt is annoying to read. The code in the UI layer that reads it are also a bit unfortunate and it is only in the UI layer, so if one wants to call it from the game-code the code needs to be copied... and it is not nice code to copy. The most important part is the code simplicity. It is not hard to make a complicated format but it makes it harder for the next programmer to guess what is going on. It also make it less dynamic. The mappool solution can be extended to new gametypes simply by changing the cvar (and implementing the gametype). Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: Gig on November 08, 2010, 12:05:03 PM - The gametype files are selected by g_votemappool, so they can be changed too. The syntax is consistent with other votelists but generally the idea of making a list in a single cvar is not that good. G_votemappool? Could you please tell me more about it? I just checked in OAX B47, but this cvar seems to not exist...Quote - Arenas.txt is annoying to read. The code in the UI layer that reads it are also a bit unfortunate and it is only in the UI layer, so if one wants to call it from the game-code the code needs to be copied... and it is not nice code to copy. Moving that part of code to an external procedure/function, accessible from all parts of the game, would be too complicated, or would break compatibility with something?PS: Remember that I'm not even sure about the difference of arenas.txt and .arena files... is the first the "default" one, used for "stock" maps only, and the latter are specific files for each custom map? What about using the deathmatch spawn points if there are no team spawn points? It does but the map in question specifically forbids using them in team games so they are removed before the game starts. This is why I say that there must always be one ffa spawnpoint in a map that does not have gametype restrictions on it. Title: Re: OpenArena Server Crash 0.8.5 on Debian Post by: sago007 on November 08, 2010, 12:25:20 PM It is called g_mappools. Default value is "0\maps_dm.cfg\1\maps_tourney.cfg\3\maps_tdm.cfg\4\maps_ctf.cfg\5\maps_oneflag.cfg\6\maps_obelisk.cfg\7\maps_harvester.cfg\8\maps_elimination.cfg\9\maps_ctf.cfg\10\maps_lms.cfg\11\maps_dd.cfg\12\maps_dom.cfg\"
It is the value of g_gametype followed by the pool to use. A option to generate the pools from the arenas-file would be 15-20 times more efficient. You will likely want to overwrite the default values. Plus it is limited to 15 gametypes... not a problem at the moment though. I believe they are called notteam and notffa but it is described in the entity editing window in NetRadiant like all the other options. |