|
Title: 0.8.5 Bugs Post by: Cacatoes on March 03, 2010, 03:15:07 PM - no semi-colon ";" in chat (already notified)
- oax keeps tracks of the frags number (when changing team), it may also keep track of total played time of a player (otherwise we see people who have 200 frags made in one minute ;) ) Title: Re: 0.8.5 Bugs Post by: Falkland on March 04, 2010, 09:03:18 AM - no semi-colon ";" in chat (already notified) ... This is a part of the fix for the callvote bug ( ";" char is converted to SPACE or so ) Title: Re: 0.8.5 Bugs Post by: RMF on March 04, 2010, 05:58:13 PM Was there a bug with callvoting then? Never heard of it and never bugged me ether. No ; on the opposite did bug me the first day i used 085...
Title: Re: 0.8.5 Bugs Post by: PopeJo on March 05, 2010, 01:14:54 AM still there:
- announce voice sometimes missing, when enemy gets the flag - ubuntu 8.04 and 8.10 (at least) keypresses are dropped when screensaver tries to load (in my case every 10 minutes) - you will notice very easily by playing a big plasma-climb map, like prince_quake (http://q3a.ath.cx/?mapdetails=prince_quake) in defrag Title: Re: 0.8.5 Bugs Post by: MIOW on March 05, 2010, 05:56:54 AM When I turn "hide private" off and return to server browser again it's turned on as in previous version.
Title: Re: 0.8.5 Bugs Post by: Falkland on March 05, 2010, 06:39:38 AM Was there a bug with callvoting then? Never heard of it and never bugged me ether. No ; on the opposite did bug me the first day i used 085... It's the same BUG that affected UrT and still affects all OA081 servers ( with the exception of the Rainbow Servers which were patched after I've reported the BUG and other servers that use an engine compiled with a more recent ioquake3 svn revision) Code:
The patch for this bug was made of 2 parts : - a VM fix - an engine fix Both sanitize the ";" and other special chars that canbe used as a command separator. At ioq3 they have choosen to patch also the engine for all the games in which the VM patch could not be applied. And that's true while you are using Oa085 binaries and you are conected to an oa081 server for example. Title: Re: 0.8.5 Bugs Post by: chaoticsoldier on March 06, 2010, 07:26:52 AM Some more bugs:
Can't spectate freely in am_underworks - I can't move around at all. I am stuck in the one location. Missing elevator texture in ce1m7 - The elevator now has no textures! So far this is the only missing texture I've found. I have no other 3rd party pk3s in any of my baseoa folders. Kamikaze visible through walls - In Hydronex2, the kamikaze is visible from behind the walls when cg_simpleitems is enabled. Axis markers visible on the kamikaze item - When you walk to certain places on Hydronex2 while carrying the kamikaze item, there are axis markers that sometimes appear on it. They appear in certain areas of the blue and red bases and also in the underwater tunnels. I have not tested this on other maps. 0.8.1 demos aren't played perfectly. CorteX mentioned this here (http://openarena.ws/board/index.php?topic=3586.msg30534#msg30534) - It always says the player is out of ammo. - Health item always visible on the right of screen - Often quits with the error: Code: cg_registeritemvisuals: itemnum XXX out of range [0 - 60] Title: Re: 0.8.5 Bugs Post by: Neon_Knight on March 06, 2010, 07:50:05 AM Can't spectate freely in am_underworks I'll fix that. But am_underworks is supposed to be replaced by am_underworks2 JSYK.- I can't move around at all. I am stuck in the one location. EDIT: Try using the crouch key to escape from that area. It works. Kamikaze visible through walls I've reported this long ago, and I've tried to fix this, since it was supposedly a fault in the shaders. There was nothing. :/- In Hydronex2, the kamikaze is visible from behind the walls when cg_simpleitems is enabled. Axis markers visible on the kamikaze item It's for the Invulnerability item, which ATM hasn't any model, neither for the pickup or the effect. Although I don't remember if the Invul is in that map.- When you walk to certain places on Hydronex2 while carrying the kamikaze item, there are axis markers that sometimes appear on it. They appear in certain areas of the blue and red bases and also in the underwater tunnels. I have not tested this on other maps. Title: Re: 0.8.5 Bugs Post by: fromhell on March 06, 2010, 10:24:13 AM Simple items seen through walls is a result of a shader not being found for that cgame sprite
Title: Re: 0.8.5 Bugs Post by: sago007 on March 06, 2010, 11:57:12 AM You can still use ';' in say.
Like this: /say ";)" but no longer like this: /say ;) Messages sent with the chat key works too. I am not entirely sure about the reason (patch taken directly from ioquake3) but as Falkland says it is likely to protect unsafe VMs from receiving unsanitized commands. I could possible create a local /say command that catches that the player writes in /say and put "" around it before sending it to the server. On an unrelated matter: baseoa never had a callvote bug (neither did baseq3). But many mods that improved the callvote code did and we cannot fix them. Title: Re: 0.8.5 Bugs Post by: Marble of Doom on March 06, 2010, 09:12:11 PM BFG and chaingun still appear messed up in in the controls menu.
Title: Re: 0.8.5 Bugs Post by: BlankA. on March 10, 2010, 01:34:24 PM *Double hit sound when using RG. (As in I fire once and it goes "ding - ding").
*Micro FPS stutter (If anyone played Oblivion; That's exactly what it's like). Title: Re: 0.8.5 Bugs Post by: Udi on March 10, 2010, 03:16:20 PM *Double hit sound when using RG. (As in I fire once and it goes "ding - ding"). When your enemy falls down hurting him/herself after you shoot him/her, you can hear a second hit sound, that's due to the g_awardpushing 1. Please check if that's the case. Title: Re: 0.8.5 Bugs Post by: RMF on March 10, 2010, 05:09:30 PM Oh lol i finally get what that is for, thought it had something to do with pushing teammates with rail or lg :P
Title: Re: 0.8.5 Bugs Post by: Cacatoes on March 11, 2010, 03:26:49 PM - Unable to callvote kick names with special characters, because of serverstatus crashing (http://openarena.ws/board/index.php?topic=3548.msg30297#msg30297). Oh, maybe we can call that vote from game menu... fine.
- No sound when commiting suicide (/kill) (or when being killed ?) when holding the kamikaze Title: Re: 0.8.5 Bugs Post by: sago007 on March 11, 2010, 03:45:40 PM /serverstatus has never returned client numbers and never been useful for clientkick. The crash bug is in the binaries on the server.
The new command /clients returns the client numbers that can be used by clientkick. It does not work until the first score event (death) though. The same goes for the clientkick menu, because the client numbers are not braodcasted until the first score event. Title: Re: 0.8.5 Bugs Post by: Cacatoes on March 19, 2010, 08:13:03 AM I had a little issue with votes while playing online, not sure if it can be reproduced:
The game starts, during warmup (i'm not sure of that fact) someone calls a vote for nextmap. Vote quickly fails. Match begins. That same person calls again the vote, which also fails. Then we wait like 30 seconds and the map goes to next one. It happpened on a server where I was admin, and It's not likely some other admin rcon-ed to next map. Title: Re: 0.8.5 Bugs Post by: sago007 on March 20, 2010, 09:31:48 AM The vote bug sound pretty serious but I simply cannot see how it was done. There are only two places where vote-commands are executed and both of them appears to be checked.
Title: Re: 0.8.5 Bugs Post by: Cacatoes on March 20, 2010, 11:03:46 AM The problem also is I'm not sure of this bug, because I wasn't paying attention to it when it happened. If other people experience the same then we could confirm this, maybe it was an hallucination ;)
- /say ";)" doesn't display well, at least on my computer ... no semi-colon. I'd also add the " characters aren't displayed either, but it's not new. - still about parsing, but colors this time (maybe already pointed) : ^3C^1a^3c^1a^4t^7o^5e^3s => displays well on the score board. ^CC^aa^cc^aa^tt^oo^ee^ss => doesn't. This may not be important if we switch to some hexadecimal notation for colors. Title: Re: 0.8.5 Bugs Post by: sago007 on March 20, 2010, 11:39:55 AM I still have hard time forgiving the original Quake 3 coders for not having a permanent escape char like '^'. It seems so wrong that it is sometimes an escape char and sometimes not. The number of bugs throughout the time because of this has been quite large and made a lot of code unnecessarily complicated (that is partly the reason for the many bugs).
I often have the urge to simple make '^' a permanent escape char. The main problem is of course that people that wanted to write "^._.^" would have to write "^^._.^^" instead And yes the ';' does not work. Apparently I was playing on an old binary and the new anti-; in the binary is much more strict than the VM code. Title: Re: 0.8.5 Bugs Post by: menganito on March 22, 2010, 09:09:14 AM - many people are complaining about not being able to switch weapons after upgrade (encountered it only on a non pure server, namely ROFL CTF 4 fishes) - how to solve? I always recommend a complete reinstall.
- with simple items on, i can see the kamikaze item in ctf4ish through walls as well Title: Re: 0.8.5 Bugs Post by: Gig on April 17, 2010, 12:20:46 PM - When you launch a "mod" from the menù, the sound stops working at all, if you have "OpenAl" disabled or not installed. To workaround, you can launch the mod directly from command line (for example, openarena.exe +set fs_game missionpack), or you can install and enable OpenAl. But I think it should be fixed anyway. Tested with OA 0.8.5 under Windows XP. See also here (http://openarena.ws/board/index.php?topic=3673.0).
- Map czest1tourney lacks textures for some jump-pads... - When a rocket explodes, for a moment (few frames), I can see a semi-transparent "square" inside the blast. Is it possible to fix it? Title: Re: 0.8.5 Bugs Post by: Gig on April 19, 2010, 01:36:05 AM You can still use ';' in say. Not working for me (OA .8.5 and Windows XP).. :-(Like this: /say ";)" Title: Command line bug? Post by: Gig on April 21, 2010, 04:48:38 PM Hello everybody. Some news about the previously indicated bugs? Have they been confirmed?
Anyway, I've found another strange thing. Well, if you start the game with something like openarena.exe +exec <cfg file name> +set <variablename> 1 and the cfg file specifies a different value for the same variable (for example, 0), what should happen? I suppose the value manually entered should override the one from the config file, but it seems it is not so. As you can see DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/ModCompat/CorkScrew#Troubleshooting]here (http://([b) ("Troubleshooting" section), launching this way the same mod, in Quake III Arena the value from the command line "wins", while in OpenArena it keeps the one from the config file. Can you check this situation, please? Bye! Title: Re: Command line bug? Post by: Udi on April 21, 2010, 06:29:58 PM Hello everybody. Some news about the previously indicated bugs? Have they been confirmed? The blocky rocket splash is already fixed (http://openarena.ws/board/index.php?topic=1945.msg30148#msg30148), will be included in the next release. The oafix packages also seem to fix the blue bubble portals on ctf4ish. The missing jumppad textures in czest1tourney and ce1m7 are caused by the evil8_base.shader coming with the patch. Don't know which definition exactly, but I guess the evil8.shader coming with 0.8.1 contains all the definitions, so evil8_base.shader can be omitted. Just include an empty text file with the same name in a package numbered higher than the patch. An example package is attached, please test if there is any regression with that. Title: Re: 0.8.5 Bugs Post by: ikao on April 21, 2010, 08:39:32 PM *Double hit sound when using RG. (As in I fire once and it goes "ding - ding"). When your enemy falls down hurting him/herself after you shoot him/her, you can hear a second hit sound, that's due to the g_awardpushing 1. Please check if that's the case. Some times I hear it long after I hit them. Possibly they have jumped down from a high place after being hit by me but it was certainly not because of my rocket. Is that a bug or the expected behavior? Title: Re: Command line bug? Post by: Gig on April 22, 2010, 04:27:24 AM An example package is attached, please test if there is any regression with that. Than you for the informations.Your hotfix works well (now I see those jump-pads), waiting for 0.8.6. :-) What do you mean with "regression"? Possible negative repercussions? It would be nice to update DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]this page (http://([b) every time a bug is fixed... Ah, should I also write there each time I found a probable bug? Let me thank all you guys for the enormous work behind OpenArena! Title: Re: 0.8.5 Bugs Post by: Udi on April 22, 2010, 06:41:21 AM What do you mean with "regression"? By regression I mean that the maps in 0.8.1 are fixed now, but maybe the 0.8.5 maps need the evil8_base.shader (but I didn't noticed missing shaders so far). So the fix may introduce new bugs which didn't exist before the fix. The wiki is a good place to indicate which bugs where fixed, but we could also post in the 0.8.6 todo topic (http://openarena.ws/board/index.php?topic=3566.0). Title: Re: 0.8.5 Bugs Post by: Virus on April 23, 2010, 06:01:44 AM EDIT: Just ignore post, this seemed to be a one-time error, as I can't reproduce it. Sorry!
Bug or feature? When you play a match in single player mode and select any difficulty (lets say "hurt me plenty") and you win, then the corresponding logo shows on the picture in the level select. But when you now replay the level on a lower difficulty setting (like "I can win"), the game does not remember that you beat it before on "Hurt me plenty" and only shows the corresponding logo of a "I can win" victory. Title: Re: 0.8.5 Bugs Post by: Gig on April 24, 2010, 02:54:10 AM Are you sure? I just tried and it kept the previous logo of the higher difficulty level... (at the end of the match I exited to menù from the button, I haven't try to go to the next map)...
Title: Re: Command line bug? Post by: sago007 on April 25, 2010, 03:57:27 AM Well, if you start the game with something like openarena.exe +exec <cfg file name> +set <variablename> 1 and the cfg file specifies a different value for the same variable (for example, 0), what should happen? I think this change was intentional. +set from the command line is now executed very early so that they can be used during system initialization before the "exec" or any other commands can be executed. I am not sure but I believe that is the reason. The original quake 3 used a lot of CVARs during startup that was impossible to change because of it.I suppose the value manually entered should override the one from the config file, but it seems it is not so. Title: Re: Command line bug? Post by: Gig on April 26, 2010, 06:22:33 AM Well, if you start the game with something like openarena.exe +exec <cfg file name> +set <variablename> 1 and the cfg file specifies a different value for the same variable (for example, 0), what should happen? I think this change was intentional. +set from the command line is now executed very early so that they can be used during system initialization before the "exec" or any other commands can be executed. I am not sure but I believe that is the reason. The original quake 3 used a lot of CVARs during startup that was impossible to change because of it.I suppose the value manually entered should override the one from the config file, but it seems it is not so. PS (completely OT, sorry), what are "cakes" mentioned near the number of posts, in this forum? Title: Re: 0.8.5 Bugs Post by: Virus on April 26, 2010, 08:08:30 AM Are you sure? I just tried and it kept the previous logo of the higher difficulty level... (at the end of the match I exited to menù from the button, I haven't try to go to the next map)... Just checked and tried to reproduce the error, but I can't. Looks like it was some strange hick-up on my side... Title: Re: 0.8.5 Bugs Post by: Gig on April 26, 2010, 11:30:32 AM Some little things, please see here (http://openarena.ws/board/index.php?topic=3469.msg31490#msg31490).
Small summary of the linked post: - A small problem: not showing text for picked up items if you enable \cg_alwaysWeaponBar 1. - A smaller problem (or is it intentional?): when you switch weapons, the name of the weapon is not shown (unlike Q3A's behaviour). - A request: is it possible to add the option \g_weaponBarStyle to the menus? Title: Elimination game mode Post by: Gig on April 26, 2010, 12:14:26 PM Two things about the "Elimination" game mode:
- You you set \elimination_roundtime to 0, every round immediately ends. I think it would be (a lot) better if 0=no time limit... so the round would end only when a team has no more players alive. - Map Q3DM6ISH does not appear in the list of the maps available for Elimination. Since -as far as I know- Q3DM6 was one of the most popular maps for OSP Clan Arena in Q3A, and Elimination is basically the same as Clan Arena, I think that Q3DM6ISH should be available for Elimination. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on April 26, 2010, 02:36:25 PM Q3DM6ish had been rejected twice to be commercially included. The first version is too bare, and the second version had been rejected because of the 0.8.0-texture-crisis. It looks like that because it's a Quake3 map remake, it won't be included in 0.9.0 neither, even if it's retexturized again (Neon_Knight made a variant), alongside with wrackdm17, which is currently available.
In other words, that's not a bug, that's a quality reason.. Title: Re: 0.8.5 Bugs Post by: Gig on April 26, 2010, 02:49:00 PM So, 0.9.0 will not have Q6DM6ISH and WRACKDM17? :-( :-( :-( What a bad news... :-( :-(
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on April 26, 2010, 04:28:15 PM IIRC, they'll be available as an addon. But I don't remember exactly.
Title: Re: 0.8.5 Bugs Post by: Falkland on April 26, 2010, 04:34:51 PM So, 0.9.0 will not have Q6DM6ISH and WRACKDM17? :-( :-( :-( What a bad news... :-( :-( Naaaa ... it's not indeed ... Both maps are very bad remakes : they ONLY remember Q3DM6 and Q3DM17 in the name and in the raw form , but they are different in the layouts , in the dimensions and about the game feeling ... Q3DM6ISH is impossible to be played in Elimination : you can only dream about RJ tricks seen in the famous Fatality/arQon Q3 video. You cannot even immagine to play like in Q3DM6 because Q3DM6ISH is smaller than the original map. Anyway there are other maps funny in Elimination like oa_rpg3dm2 or am_galmevish or the meisterlampe-collection (http://openarena.ws/board/index.php?topic=1945.msg30347#msg30347) If you like Q3 maps and you have the q3 texture package, you can use the DC MAP PACK which has also Q3DM6 ( called dc_map11 (http://q3a.ath.cx/?mapdetails=dc_map11) in the pack ) . The pack was released by ID to permit setting up servers for DreamCast console owners. BTW , the pack includes also some inedited maps and some maps included also in QuakeLive. In OA090 you shouldn't need the texture pack because the release should have a large number of texture already replaced. Title: Re: 0.8.5 Bugs Post by: Gig on April 27, 2010, 02:44:15 AM Anyway, what do you think about making \elimination_roundtime 0 = "no round time limit" instead of "no play at all" as now? When I played OSP Clan Arena years ago, I didn't rember a round time limit...
Title: Re: 0.8.5 Bugs Post by: Falkland on April 27, 2010, 09:20:02 AM Anyway, what do you think about making \elimination_roundtime 0 = "no round time limit" instead of "no play at all" as now? When I played OSP Clan Arena years ago, I didn't rember a round time limit... Yes , you are right :-) That's a BUG as it is now because timelimit 0 and fraglimit 0 already mean in order no timelimit and no fraglimit. Title: Re: 0.8.5 Bugs Post by: Falkland on April 27, 2010, 09:26:55 AM [...] In other words, that's not a bug, that's a quality reason.. Uhm ... I'd suggest to let the "Quality Reason" argument out of the topic , else we should ask why all the oa_baseXX , delta , oa_ctf2 ... maps (which objectively are not qualitatively good maps) are still there. Title: Re: 0.8.5 Bugs Post by: Gig on April 27, 2010, 12:52:11 PM Anyway, what do you think about making \elimination_roundtime 0 = "no round time limit" instead of "no play at all" as now? When I played OSP Clan Arena years ago, I didn't rember a round time limit... Yes , you are right :-) That's a BUG as it is now because timelimit 0 and fraglimit 0 already mean in order no timelimit and no fraglimit. Title: Re: 0.8.5 Bugs Post by: Cacatoes on April 28, 2010, 09:48:53 AM Wrackdm17 is a map which seems quite playable. I had fun with it on instarail, and even on allweapons I think it's very decent.
Problem is "they are remakes and fromhell doesn't like that". I personally don't care if they are remakes or not. Title: Re: 0.8.5 Bugs Post by: Gig on April 28, 2010, 02:56:28 PM IMHO:
If there is a copyright problem, it's right to remove them, but if it is not the case, I think that they should stay there (maybe with better textures, if you think it is necessary): as an old Quake 3 lover, altough they differ from the originals, I liked very much the surprise of finding these two maps inside OA, without the need to download and install any extra map-pack. Probably most people downloads a game and uses it with the stuff provided "out of the box"... WRACKDM17 is even better than the original for one detail: the platform with railgun is lower than the main platform, so it is no so easy to "camp" and frag everyone from there. Anyway, this is only my advice, do what you think is the right thing. Most important, in this thread, is to find (and, if possible, fix) bugs... as far as we are, there are various things to work on... Title: Re: 0.8.5 Bugs Post by: RMF on April 29, 2010, 05:09:28 AM Wrackdm17 is a map which seems quite playable. I had fun with it on instarail, and even on allweapons I think it's very decent. Exactly. I really like wrackdm17, almost everyone loves the map on belzerail, and there is even a server dedicated to it (and it's populair)! It's insane to cut one of the best maps out in a new release.Problem is "they are remakes and fromhell doesn't like that". I personally don't care if they are remakes or not. Title: Re: 0.8.5 Bugs Post by: sago007 on April 29, 2010, 10:04:54 AM void4 was also quite popular.
Title: Re: 0.8.5 Bugs Post by: Peter Silie on April 29, 2010, 12:38:55 PM i can´t see problems with maps delivered even if they are just remakes or something else.
if the community doesn´t like them they only will not be played... Title: Re: 0.8.5 Bugs Post by: fromhell on April 29, 2010, 09:00:24 PM void4 was also quite popular. WHAT THE FRICKING HECKOh by the way i've already attempted to sort the 'tributes' into a pack subfolder in my svn working copy, but haven't committed the changes yet. In the folder so far: cbctf1 ce1m7 dm4ish dm4ishv2 dm6ish oa_dm1 oa_dm1v2 oa_dm2 oa_dm3 oa_dm4 oa_dm5 oa_dm5v2 oa_dm6 oa_dm7 q3dm6ish wrackdm17 Did I forget any others? I wonder if a script to pack in the non-q3replacement textures used by these maps could help for these maps to be played by q3 players also could be done. Title: Re: 0.8.5 Bugs Post by: Neon_Knight on April 29, 2010, 09:37:42 PM am_mckinleyish (and am_mckinleyish2) :P
Also delta (resembles mpq3team6) Title: elimination_roundtime 0 Post by: Gig on May 03, 2010, 06:17:30 AM Well, he had previously concluded that \elimination_roundtime 0 should mean "no round time limit" in elimination mode, so the actual behaviour (round immediately ends and you do not play at all) should be corrected.
But this cvar affects other game modes (CTF Elimination and Last Man Standing), so, what should happen in each game mode? I created a table to think about what should be the best behaviour for each mode. Please read, comment, correct it if needed. You can find it DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Talk:Elimination]here (http://([b).[/size] Another thing: could you please also check that timelimit works as expected in these game modes? I tried Elimination with Timelimit 1 (minute) and elimination_roundtime 120 (seconds), to see if reaching the timelimit ends the current round or waits until the end of current round to say who is the winner of the entire match.... well, the match didn't end after 1 minute, and didn't end after 1 or 2 rounds (later then the 1 minute limit). Then I lowered capturelimit and when it was reached, the match ended (but I red "timelimit hit" message in console). Strange... how is it supposed to work, exactly? Title: Re: 0.8.5 Bugs Post by: sago007 on May 03, 2010, 10:14:24 AM Timelimit behaved as expected for me. Just tried in elimination.
timelimit 1 roundtime 120 Started a game. Won a round Timelimit reached. (not over yet because elimination must be won by 2) Sudden death played. Second round won Game ended. I have implemented elimination_roundtime in OAX but I did not consider Last Man Standing. Especially the Overtime modes seems weird because ho can a match go in overtime if a round last forever unless it starts in overtime and is it really overtime then? Title: Re: 0.8.5 Bugs Post by: Gig on May 03, 2010, 11:06:06 AM With "elimination must be won by 2" you mean that you must have a difference of at least 2? So, if timelimit is hit and you are 2-1 the match doesn't end until you get 3-1, 4-2 or so on...? That would be an explanation for my unsuccessful test...
UPDATE: "A team will need to win by at least 2 rounds." (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Elimination#Gameplay]from Wiki site (http://([b)). Ok, mistery solved! ^_^ I did not remember such rule in the old OSP Clan Arena (maybe I never noticed!)... by the way, Elimination is very similar to Clan Arena, but not necessarily the same! :) So, game will continue until a difference of 2 rounds is reached. Same thing with "capturelimit", right? Does this apply also to CTF Elimination and LMS? Anyway, have you read my table for \elimination_roundtime 0? What do you think about it? For the two Overtime modes I propose to let it like it is now (the match immediately starts in Overtime mode, so it will be a very quick match! Maybe it could be funny...), and to make it "no round time limit" for all other modes... I suggest also to add "elimination_roundtime" to GUI, in skirmish/create menù... Can you also take a look DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Talk:Last_Man_Standing#A_question]here (http://([b)? Thank you very much! Title: Re: 0.8.5 Bugs Post by: fromhell on May 04, 2010, 07:32:55 AM am_mckinleyish (and am_mckinleyish2) :P Also delta (resembles mpq3team6) am_mckinleyish seems loose, like gamelivish (since there's only so many layout variations you can do on the center-pit-arena format, which is why my "fan" is still in there despite it being a CRAPPY tribute to dm-deathfan) DELTA GOING THOUGH Title: Re: 0.8.5 Bugs Post by: Cacatoes on May 05, 2010, 07:43:49 AM Hitman and me noticed Hydronex (version 1) is now darker since 085, anyone to confirm ? Shader problem ?
Title: Re: 0.8.5 Bugs Post by: Corvette on May 09, 2010, 08:59:38 AM Sometimes the game randomly says "excellent" despite the fact that I didn't hit anyone with any weapons at all and there is no one around me.
Sometimes it makes the sendmessage/callvote sound despite the fact no one said anything. Title: Re: 0.8.5 Bugs Post by: sago007 on May 09, 2010, 09:03:41 AM Sometimes the game randomly says "excellent" despite the fact that I didn't hit anyone with any weapons at all and there is no one around me. By default it is also played (in lack of a better sound) then someone is on a killing spree. Title: Re: 0.8.5 Bugs - crashing Post by: TyTiger on May 12, 2010, 11:58:17 AM Im not sure if this is a bug or just me being a dimwit, but this problem did not occur on the older version of oa_ded (linux)
My Server sometimes randomly, though usually between game switches exits with the following output: ******************** ERROR: netchan queue is not properly initialized in SV_Netchan_TransmitNextFragment ******************** ----- Server Shutdown (Server crashed: netchan queue is not properly initialized in SV_Netchan_TransmitNextFragment ) ----- Sending heartbeat to dpmaster.deathmask.net Sending heartbeat to dpmaster.deathmask.net ==== ShutdownGame ==== ShutdownGame: ------------------------------------------------------------ AAS shutdown. --------------------------- ] This is my config file, ive combed though it but i don't see anything wrong... Code: // start with: Title: Re: 0.8.5 Bugs Post by: sago007 on May 12, 2010, 12:32:52 PM netchan error are virtually impossible to debug because they are encrypted.
I have been able to reproduce in 0.8.5 in LMS single player frequently on oa_koth2 (why it happens more often there I don't know). The current OAX beta 45 tries to reduce the risk of it happening by preventing heavy transmissions during intermission. But because the problem is random there might still be problems. There are many network parameters that can increase or reduce the probability. Title: Re: 0.8.5 Bugs Post by: TyTiger on May 12, 2010, 12:54:04 PM dang, the pattern i have noticed however it seems to happen when you let the game run to the end, I can however skip maps (mid game) with a vote without issues, maybe something happening at the end of the game before the next one is something to do with it. :s glad i'm not the only one though
Title: Re: 0.8.5 Bugs Post by: TyTiger on May 15, 2010, 07:56:12 AM dang, the pattern i have noticed however it seems to happen when you let the game run to the end, I can however skip maps (mid game) with a vote without issues, maybe something happening at the end of the game before the next one is something to do with it. :s glad i'm not the only one though Just an update, I had noticed this problem goes away when i remove most of the bots, it hasnt crashed yet with just the 2, though to test if it some kinda client over loading thingy your welcome to all crash on my server lol. 93.96.179.19:27960 Title: Detailed shadows? Post by: Gig on May 17, 2010, 03:33:44 PM I don't know it is a bug, but it could be...
I created DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options]Manual/Graphic options (http://([b) page on the wiki site (please, someone with more experience than me can check and expand that page, pleeeeeeeease?), so I tried various graphic options. I remembered about \cg_shadows cvar from Quake 3... 0= no player shadow, 1=simple player shadow (default), 2=detailed player shadow. Maybe, option 2 wasn't perfect, but it worked in Q3A... I tried it with OpenArena, but when I set it to 2, I can see the detailed shadow only for a frame or two, then it returns to standard one (\cg_shadows returns 1). I read DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/FAQ#The_game_isn.27t_as_pretty_as_the_screenshots_:.28]here (http://([b) that it needs also \r_stencilBits 8 to work properly. I tried it, but nothing changed. Any ideas? ??? Title: Re: 0.8.5 Bugs Post by: fromhell on May 17, 2010, 05:07:09 PM You use stencilbits 24 or 32. Using 8 will give overlapping artifacts that look ugly as hell.
In the engine source, the drawing of the shadow is skipped if the model has too many polygons which is bad since OA exceeds its strict requirements anyway. This can be changed without a problem I think. I've had a 20,000 triangle player casting these kinds of shadows without a hitch. on a single core with a 2004 video card Title: Re: 0.8.5 Bugs Post by: Gig on May 18, 2010, 04:13:15 AM Wait a moment... let me understand...
I have a 2000 computer (AMD Athlon Thunderbird 900) with a 2000 video card (GeForce 2 MX)... Detailed shadows worked with Quake III Arena, and I don't remember many FPS slowdowns (but I didn't use them anyway, since this function was not perfect and distracts from gameplay)... If I'm not wrong, shadows option influenced both my shadow and other players' shadows... how can I be sure of the number of polygons for each model? UPDATE: Reading better your post, are you saying that OA always skips to render these shadows because all OpenArena player models have many more polygons than Q3A models? But if it is the case, how did you do the 20,000 polygon test you said? Was it was under Q3A? Was it with a test version of OA? And is it normal that this automatically resets the cvar? My r_stencilbits value is 0 (default)... have I to set it to 24 or 32? What are stencilbits? In the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=FAQ&oldid=2490#The_game_isn.27t_as_pretty_as_the_screenshots_:.28]first version (http://([b) of the "FAQ" page you wrote about 24 or 32, and later DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=FAQ&diff=3282&oldid=3130]someone changed it to 8 (http://([b). Another strange thing... if I try to set 32 bit color depth instead of "default" from "graphics" menu, after applying changes it automatically returns to "default"... why? (OA 0.8.5 under Windows XP) Title: Re: 0.8.5 Bugs Post by: sago007 on May 18, 2010, 10:26:22 AM Another strange thing... if I try to set 32 bit color depth instead of "default" from "graphics" menu, after applying changes it automatically returns to "default"... why? (OA 0.8.5 under Windows XP) This might be an SDL thing. I am not sure if it is even possible to change color depth manually anymore (in Linux this has never been possible). Since the introduction of SDL the resolutions has also been locked to the ones the graphic card lists as possible. This list often skips resolutions under 640x480. Title: Re: 0.8.5 Bugs Post by: Corvette on May 24, 2010, 06:11:54 PM Sometimes the game randomly says "excellent" despite the fact that I didn't hit anyone with any weapons at all and there is no one around me. By default it is also played (in lack of a better sound) then someone is on a killing spree. No, what I'm referring to definitely isn't a feature, it's a bug. I just opened the game and logged into digichalk onto a map and haven't killed anyone and, while I was still tinkering with my speakers to get the right volume, it said Excellent, even after I was fragged. I was definitely not on a killing spree, I hadn't killed anyone (I just entered the game), this is not a feature. Another bug is that I keep on hearing the sound that someone sent a message despite the fact that I see no message. Again, this isn't a feature, it's a bug. Title: Re: 0.8.5 Bugs Post by: Gig on May 25, 2010, 01:19:51 AM You were the only player in that server? I don't know this feature, but Sago's answer seems to me that if anyone is on a killing spree (how many kills to consider a "killing spree"?), everyone will hear that voice...
Title: Re: 0.8.5 Bugs Post by: Falkland on May 25, 2010, 08:38:14 AM No, what I'm referring to definitely isn't a feature, it's a bug. I just opened the game and logged into digichalk onto a map and haven't killed anyone and, while I was still tinkering with my speakers to get the right volume, it said Excellent, even after I was fragged. I was definitely not on a killing spree, I hadn't killed anyone (I just entered the game), this is not a feature. Another bug is that I keep on hearing the sound that someone sent a message despite the fact that I see no message. Again, this isn't a feature, it's a bug. This was already fixed in the current OAX code , making the killing spree sound and chat message available only to the player beeing on the killing spree. Just expect to be corrected in the next OA patch. Title: Re: 0.8.5 Bugs Post by: Corvette on May 25, 2010, 07:35:51 PM Sorry, I misunderstood Sago. Thanks all.
Title: Re: 0.8.5 Bugs Post by: faoa on May 26, 2010, 02:27:13 PM This was already fixed in the current OAX code , making the killing spree sound and chat message available only to the player beeing on the killing spree. Just expect to be corrected in the next OA patch. What?! Does this mean no one else will notice when I'm on killing spree?This would be sad and actually this is the only reason I could think of for this feature (so other know how pr0 your are)... Title: Re: 0.8.5 Bugs Post by: sago007 on May 26, 2010, 02:51:58 PM This would be sad and actually this is the only reason I could think of for this feature (so other know how pr0 your are)... It is still written to the chat with name. But the sound was confusing and is now only sent to the killer.I have removed the centerprint option. It might return but in a different version because the current center print is way too dominating for spree information (and conflicting with the frag message). Title: Re: 0.8.5 Bugs Post by: faoa on May 27, 2010, 02:02:52 AM This would be sad and actually this is the only reason I could think of for this feature (so other know how pr0 your are)... It is still written to the chat with name. But the sound was confusing and is now only sent to the killer.Title: Re: 0.8.5 Bugs Post by: Gig on June 07, 2010, 04:54:13 AM Not sure if it is worth the time it needs, but maybe you could investigate.... it seems that using a r_picmip value higher (=worse quality) than 3 (the maximum you can set from menu), it is not stored correctly and it may easily come back to 3 after a second vid_restart.... More info here (http://openarena.ws/board/index.php?topic=3685.msg32357#msg32357).
Title: Re: 0.8.5 Bugs Post by: fromhell on June 07, 2010, 02:24:28 PM feature
you only 'need' picmip that high if you're using a card from 1994/95 (intergraph realizm and rendition hardware) Title: Re: 0.8.5 Bugs Post by: Gig on June 07, 2010, 03:05:57 PM So you could set "3" as the maximum value, instead of "16", no? Anyway, as I told before, it is not worth the time to spend... (fixing real bugs like the one with SDL audio is far more important)
Title: Re: 0.8.5 Bugs Post by: PWNAGE on June 08, 2010, 03:58:22 AM Im not sure if this one has been said but when i go multiplayer i have to sort by "Human Players" every time. it should just stay set like that like "Show Empty"
I like to have my settings as: Show Empty: OFF Sort By: Human Players But every time i go back its set to Sort By: "Ping Time" Title: Lightning gun bug Post by: Gig on June 22, 2010, 01:55:16 AM Hello, I noticed a bug with lightning gun. I suppose it is not so big, but anyway it should be fixed, I think...
Well, I was playing Elimination mode (or maybe some other mode with g_elimination enabled, I don't remember), and I have been killed when I was using lightning gun. I entered the game again, and immediately fired with lightning gun... and I saw another beam, starting from my own "old" corpse (that wasn't gibbed), that aimed at the same point I was aiming. See the first screenshot: the left beam comes from my old corpse, that is not visible because it is disappearing underground. In the second screenshot: I see that I can fire with lightning gun even when I'm dead, before respawning. I wonder if that ray can hurt someone... I thought the only item usable when you are dead was Kamikaze... isn't so? Title: Re: 0.8.5 Bugs Post by: chaoticsoldier on June 23, 2010, 03:32:22 AM I'm guessing the second lightning beam does do damage. Here's why:
I tested it out with other weapons in Elimination mode and found this bug works with the gauntlet as well. When I held down fire after I died, the gauntlet sound was still playing. Sometimes I could still see the blade spinning just before I respawned. I played around with some bots and after a bot killed me I could still cause damage to it before the next round began. Check out the attached demo. Title: Re: 0.8.5 Bugs Post by: Gig on June 25, 2010, 06:32:08 AM Im not sure if this one has been said but when i go multiplayer i have to sort by "Human Players" every time. it should just stay set like that like "Show Empty" I like to have my settings as: Show Empty: OFF Sort By: Human Players But every time i go back its set to Sort By: "Ping Time" Well, I found here (http://joz3d.net/html/q3console.html) that the two variables are ui_browserShowEmpty <0 or 1> and ui_browserSortKey <number>. They are saved inside your q3config.cfg file, I see. So if you change them, the next time you open OpenArena, will see the last values used. Try to sort for "map name", exit OpenArena and then launch it again: you will find "map name". It seems to work for ui_browsersortkey 1, 2, 3, 4, those from Quake 3 Arena (0=Server Name 1=Map Name 2=Open Player Spots 3=Game Type 4=PingTime). "Sort by human players" is 5, and probably it is not included in the original Q3A, and was added in ioquake3 or OpenArena (I don't know)... and there is a bug. "5" is correctly stored in the configuration file, but when you enter the "multiplayer" menu, that value works like if not allowed, and the program sorts for "ping" (ping is value 4, the default). It's a bug... I don't know if from ioquake3 or OpenArena... Title: Re: 0.8.5 Bugs Post by: sago007 on June 25, 2010, 10:23:11 AM It's a bug... I don't know if from ioquake3 or OpenArena... It is from OpenArena. The only in game menu change that ioquake3 did (and that I know of) is the support for multiple master servers and the credits screen. The value is likely clamped in the beginning on the code... a good example on how many places things can go wrong then editing the classic UI. Title: Re: 0.8.5 Bugs Post by: Gig on June 28, 2010, 04:03:57 PM Similar problem for "hide private": you find it "on", also if you disabled it the previous time you used openarena...
PS: In English, is more correct "only humans" or "humans only"? Title: Re: 0.8.5 Bugs Post by: chaoticsoldier on June 29, 2010, 06:58:28 PM PS: In English, is more correct "only humans" or "humans only"? "only humans"As a general rule, adjectives come before nouns, but there are many exceptions. In this case, "humans only" also makes perfect sense. Title: Re: 0.8.5 Bugs Post by: Gig on June 30, 2010, 01:14:03 AM PS: In English, is more correct "only humans" or "humans only"? "only humans"As a general rule, adjectives come before nouns, but there are many exceptions. In this case, "humans only" also makes perfect sense. "Show only humans"... "Show humans only"... "only" doesn't seem an adjective (it doesn't specify "how" these humans are), but I don't know exaclty what it is... Title: Re: 0.8.5 Bugs Post by: chaoticsoldier on June 30, 2010, 11:20:49 PM "Only" is a hard one. English can be very confusing sometimes.
"We are only humans" (meaning "simply humans") In this context it qualifies as an adverb. Here, "only" is synonymous with "merely", "just" or "simply".When expressing singularity, "only" is an adjective. "Access reserved to humans only".... In these cases "only" is an adjective because it specifies the humans are not with anything else or are separate from something else. Here, "only" means the same as "alone" or "nothing else"."Show only humans"... "Show humans only"... "We are the only humans here".... So it's more like: "Access reserved to humans alone/and nothing else" "Show nothing else but humans" "Show humans alone/and nothing else" "We alone/and nothing else are the humans here" Title: Bloom and exec autompletion bugs Post by: Gig on July 02, 2010, 03:25:00 AM Another couple of bugs:
- A small flaw in "bloom" graphic feature. It seems something like some "bloom" effects on the right side of the screen are someway "reflected" on the first pixels of the screen, on the left (maybe they "exit" outside the screen and re-enter on the other side). Look at the attached image, form oa_shine map. Do you see the azure-blue glow on the left edge? It's related to the triangle of the jump-pad on the right... A similar thing happens when you are using railgun and you are moving: looking carefully, you can notice a small white glow moving on the lower left of the screen (not in this screenshot because I wasn't moving). UPDATE: the bug is much more evident in the SLIMEFAC map, and involves all the four edges of the screen. - "\exec" command uses autocomplete feature: when you write "\exec a" and then press TAB key, the console will list your .cfg files beginning with "a", or, if there is only one matching, will select it. And it's very useful. The problem is that this autocomplete feature works when you are on the main menu, but after you enter a match, it does not work anymore (and it selects default.cfg if I push TAB two times... strange). UPDATE: Bug also reported to the ioquake3 staff, as bug 4794 (http://bugzilla.icculus.org/show_bug.cgi?id=4794). - PS: About railgun... a thing, not related to the "bloom" problem above... The semi-transparent layer protruding (seeming outside) from its chassis does not look very good... is it possible to fix the weapon model somehow? Title: Re: 0.8.5 Bugs Post by: Marble of Doom on July 02, 2010, 09:16:00 PM - A small flaw in "bloom" graphic feature. It seems something like some "bloom" effects on the right side of the screen are someway "reflected" on the first pixels of the screen, on the left (maybe they "exit" outside the screen and re-enter on the other side). Look at the attached image, form oa_shine map. Do you see the azure-blue glow on the left edge? It's related to the triangle of the jump-pad on the right... I've noticed the bloom bug as well. ...The semi-transparent layer protruding (seeming outside) from its chassis does not look very good... I think the transparent layer is apart of a semi-transparent dome on the top of the glowy part on the gun. I agree it does not look very good. IMO the railgun needs a new model it's an ugly gun. Title: Re: 0.8.5 Bugs Post by: fromhell on July 02, 2010, 09:25:49 PM It's hard to come up with a railgun without looking too much like a railgun. :(
Title: Re: 0.8.5 Bugs Post by: Gig on July 05, 2010, 12:55:12 AM I like this railgun instead... I'd simply like to fix that particular...
Title: Re: 0.8.5 Bugs Post by: Gig on July 05, 2010, 02:52:04 PM Czest3ctf appears available for "double domination" mode... but once I launch the game... I cannot find any "A" or "B" point inside.
Title: Re: 0.8.5 Bugs Post by: johnnycage on July 08, 2010, 12:11:34 PM Hello, I have installed OA 0.8.1 for 64bit CPU from Debian Testing repository. I downloaded update 0.8.5 from OA webpage, extract to /usr/games/openarena/baseoa. After run the game main menu and screen was blue, so update is ok. But if I change graphics settings in menu, OA crash. This is full message from console (from run the game to crash):
Code: johnnycage@lenovo:~$ openarena Title: Re: 0.8.5 Bugs Post by: brettalton on July 08, 2010, 02:27:20 PM I may have a PulseAudio problem in Ubuntu 10.04: http://openarena.ws/board/index.php?topic=3833.0
Title: Re: 0.8.5 Bugs Post by: brettalton on July 08, 2010, 02:45:06 PM I also have a really weird error where I try and play single player, but no bots appear, only me. It's not a skirmish, it's the actual single player.
Title: Re: 0.8.5 Bugs Post by: Cacatoes on July 09, 2010, 05:43:10 AM You may consider using the oa.ws release, people seem to experience problems with Debian ones. Eventually check their bug reports.
About the bots, there may be error messages printed in the OA console. Title: Re: 0.8.5 Bugs Post by: Gig on July 13, 2010, 03:34:59 AM Little bug with text color handling.
As you can see here (http://openarena.ws/board/index.php?topic=3725.msg33720#msg33720), text color ^8 is shown as orange in the score table (and in the "Player settings" menu and in the extended "message of the day"), but is shown as black in the console. Title: Favorites and Multiplayer menu Post by: Gig on August 17, 2010, 04:21:58 PM Hi guys! Did someone take a look the the text color ^8 code in the console (see the previous post)?
I want to point out another problem (I wrote about it DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]here (http://([b), and I noticed it on this thread (http://openarena.ws/board/index.php?topic=3854.msg34578#msg34578)): now you get no error message at all when you try to pass the limit of the 16 favorite servers, simply the new server will not be added to the list. Another thing: there is a bug with the "hide private" function: when you enter the "multiplayer" menu, you find it "on", even if the last time you set it "off". Talking about "multiplayer" menu, I suggest an improvement to the server browser interface: to show somewhere the server address (I suggest in the line below "hit refresh to update"), when you select one. I suppose it should not be too difficult to do, and it may be useful. Title: Re: 0.8.5 Bugs Post by: Gig on September 15, 2010, 09:36:47 AM Problem pointed out by Falkland: Fog density is different than Quake 3, sometimes preventing to view also characters with brightskins. Dedicated topic here (http://openarena.ws/board/index.php?topic=3920.0).
Title: Re: 0.8.5 Bugs - Spectating to gain score! Post by: Gig on September 16, 2010, 03:38:42 PM Another bug found (and quite worrying):
When you are playing on Team Deathmatch mode (g_gametype 3), are currently fighting and then you select Esc --> Start --> Spectate... your player suicides and you enter spectator mode... and your team scores a point! Since going to spectate "suicides" your character (not to be confused with "kill" command, that seems not affected by the bug), it is expected that your team loses a point, or at least to not influence score... gaining score for leaving the team has no sense. Same thing if you directly switch from a team to the other: your old team will gain a frag! Original Q3A (tested v 1.32c) seems to not suffer this bug. I don't know if other team-based gametypes suffer of the same bug, but probably not because I suppose TDM is the only team-based gametype that checks for fraglimit instead of capturelimit, right? Example: if you are using bot_minplayers feature, you are in the red team and the team score is 0, then select "spectate", red team score becomes 1 and a bot enters at your place; if you join again the red team, a red bot is kicked, and your team score goes to 2... without having fragged a single enemy! This bug can be used like a cheat! PS: I noticed this while doing some tests to update the "Manual/Spectate" page on the Wiki. DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Manual%2FSpectate&diff=6982&oldid=5855]I removed an old bug warning there (http://([b) (that was found in OA 0.6) and that seems resolved; anyway, choosing "Esc --> Start --> Spectate" while you are already spectating in Tournament mode, still moves you to the bottom of the queue (Q3 does this, too): I don't know if it is a bug or not, however you need no more to use the menu to switch from "follow" to "free" spectate mode (you can simply press "use_item" key, instead), thus you can avoid the problem. Title: Re: 0.8.5 Bugs Post by: sago007 on September 17, 2010, 07:39:15 AM Annoying bug.
Title: Re: 0.8.5 Bugs Post by: Gig on September 21, 2010, 04:32:38 PM Update: the score bug when changing team in TDM mode seems fixed in OAX Beta 47 (http://openarena.ws/board/index.php?topic=1908.msg35098#msg35098).
Title: Re: 0.8.5 Bugs Post by: Gig on September 26, 2010, 06:11:07 AM Another (http://openarena.ws/board/index.php?topic=3578.msg33455#msg33455) problem related with bloom. If I have "bloom" enabled, and I set the texture quality to 16 bits, some sort of semi-transparent square appears on the bottom left corner of the screen... and the framerate drastically goes down. Does this happen only for me?
Another problem (this one not related with bloom, I suppose). It seems that (with cg_oldrail 0), when you shoot with the railgun aiming to a very far object, the inner trace is not drawn. When aiming at other distances (still very far), the inner trace is not drawn and the outer spiral "begins" far, far away from you (unless you use zoom, it is difficult to see the spiral). To try, go to wrackdm17, take the railgun and begin shooting at the opposite "invisible wall" of the map, at various heights... Update: About the railgun bug, it comes from the original Q3A, and I just opened a bug (4774) on the ioquake 3 "bugzilla" site... http://bugzilla.icculus.org/show_bug.cgi?id=4774 Update2: it seems somehow related to the fact that the railgun range is shorter than the machinegun range. Please take a look to this thread! (http://openarena.ws/board/index.php?topic=3998.0) A question: "bloom" feature is from ioquake3 or original from OpenArena? r_bloom seems to not exist under ioquake3... Title: Re: 0.8.5 Bugs Post by: Someone_mad on September 26, 2010, 07:50:26 AM Another bug report:
I've add to my 'Baseoa' folder the bots'n'skin nammed 'Astartes' and then, when I play in single player mode, if I give an order the game just stop but don't quit... First bug I have... :o Title: Re: 0.8.5 Bugs Post by: Cacatoes on September 26, 2010, 10:32:08 AM I just tried, it half-works.
There are 2 files for astartes: the model, and some "bot" file. Ensure you have both in your baseoa. He moves, he shoots with minigun but acts a bit stupid. Then it prints error messages Quote ^1Error: weapon number out of range ^1Error: weapon number out of range ... etc Graion Dilach posted about it (http://openarena.ws/board/index.php?topic=3499.msg29640#msg29640). According to that post, some solution would be to edit the bot files, which include a file which is mispelled. It seems then that OA broke compatibility with Quake 3 bots but those can be adapted to make them work without too big efforts. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on September 26, 2010, 11:06:07 AM Cacatoes, that was a special case, in where even the model was broken as well.
At that time, I mentioned the problem but without stating why or what is that about. Firstly, there is a half-solution DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/FAQ#How_can_I_use_maps.2C_models.2C_mods_made_for_Quake_3_Arena.3F]mentioned on the wiki (http://([b), but IMHO that's a wrong one, because it changes the personality (the acquiring and using percentage) of the bot. The problem comes from the weapon list, which - probably copyright - changes the weapon and the item entities in the botcode. For example, Quake3's FS_HEALTH became FPH. This happens with every entity, while the _i.c and _w.c files are composed only from this entities. If the cause would be the missing missionpack entries, then the bots just wouldn't use them. The "Weapon out of range" message comes from those two files, because the game tries to find the Q3 entries on the OA list... and doesn't find anything. But because the main personality (aim, shoot, etc) are compatible, the bot uses what it gets... the machinegun. Title: Re: 0.8.5 Bugs Post by: Someone_mad on September 26, 2010, 11:49:44 AM Okay okay... Thank's Cacatoes, thank you as well Graion!
:D Title: Re: 0.8.5 Bugs Post by: Gig on September 27, 2010, 06:11:37 AM Firstly, there is a half-solution DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/FAQ#How_can_I_use_maps.2C_models.2C_mods_made_for_Quake_3_Arena.3F]mentioned on the wiki (http://([b), but IMHO that's a wrong one, because it changes the personality (the acquiring and using percentage) of the bot. We could write there about the "personality change" (but not the text chat, right?)... and it would be nice to give alternate instructions for how to fix the bot files without changing the personality... are you able to write down them? Anyway, it seems a bit strange that something like a variable name (like FS_HEALTH) could be covered by copyright...The problem comes from the weapon list, which - probably copyright - changes the weapon and the item entities in the botcode. For example, Quake3's FS_HEALTH became FPH. This happens with every entity, while the _i.c and _w.c files are composed only from this entities. Title: Re: 0.8.5 Bugs Post by: sago007 on September 27, 2010, 11:10:58 AM We could write there about the "personality change" (but not the text chat, right?)... and it would be nice to give alternate instructions for how to fix the bot files without changing the personality... are you able to write down them? Anyway, it seems a bit strange that something like a variable name (like FS_HEALTH) could be covered by copyright... I believe that are more than just a few variable names. dmn_clown wrote the bot files from scrath based on a Master thesis that can be found in many of his posts on this forum. Apperntly the OA bots uses a slightly more advanced fuzzy logic compared to the original bots.Title: Re: 0.8.5 Bugs Post by: Gig on September 27, 2010, 12:12:25 PM Do you mean that the problem would be that bot files would be covered by the iD Software copyright anyway, even if not copied (almost) 1:1 from the basq3 bots? Do you mean that, technically, every quake3 third party bot ever made should be considered a derivative work and thus a copyright infrignment?
Couldn't it be considered, each one of them, like a separate program written in a specific formal languange? Note: I haven't tried to open bot files, or to compare those from q3a with those from oa... But, even if the q3-compatible bot files are still under copyright, why should we not read them? I suppose that the source code of the game, released in GPLv2 by iD Software, contains the instructions to decypher these files, thus the "phrases" written there (including the variable names) should be in GPLv2 as well, and we should be able to hold them here (not the bot files, but the way to read them). Thus, even if the new bots will be written in the new "OpenArena style" (with no copyright problem, and with the support for any new feature you will include in the game), it should be possible to restore the compatibiltiy with the "classic" bot files (the program should be made able to distinguish the old and the new format). The "derivative work" copyright of all the Q3 compatible bot files should not be our problem, since we would not make or distribute them, only will be able to read them. Probably, bots written for q3 will not use the three Team Arena weapons and may still have some problems in particular gametypes like "domination", but I suppose it would be better than now anyway. What do you think about it? Title: Re: 0.8.5 Bugs Post by: sago007 on September 27, 2010, 12:24:49 PM Do you mean that the problem would be that bot files would be covered by the iD Software copyright anyway, even if not copied (almost) 1:1 from the basq3 bots? Do you mean that, technically, every quake3 third party bot ever made should be considered a derivative work and thus a copyright infrignment? I did not say anything about it. However on that subject the Quake 3 SDK likely allowed derivatives, I know the Unreal Tournament license allows it even between versions.The idea behind the current bots can likely be found in dmn_clowns early posts (http://openarena.ws/board/index.php?action=profile;u=343;sa=showPosts;start=1475) they where supposed to be compatible but at some point he made a change that permanently broke compatibility with old bots. I don't understand exactly what. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on September 27, 2010, 02:58:58 PM We could write there about the "personality change" (but not the text chat, right?)... and it would be nice to give alternate instructions for how to fix the bot files without changing the personality... are you able to write down them? Anyway, it seems a bit strange that something like a variable name (like FS_HEALTH) could be covered by copyright... Yep, the text chat's is untouched, because it is the _t.c file. I don't know the reason, what I do know is the effect. Tomorrow I'll write that alternative instuctions. But first I have to test without the TA entities, just to make sure. I always expanded the bots with the TA things... but maybe for a simple user that's too complicated. Sago, to answer your question, the main difference are contained in fuzw.c and fuzi.c which are the OA variants of fw_weap.c and fw_items.c. When I first checked them, back in 2007, I had no C knowledge, but today with a semester of C, as I can see, dmn_clown defined other situations for the bots, and that's why it had to be changed. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on September 28, 2010, 03:44:01 AM OK, I finished my version.
Quote When you put a new bot into your game, and you play against that bot, you ca see that the bot uses only the machinegun and the console gives you ^1Error: weapon number out of range-errors. The problem lies within the differences of the Quake 3 and OpenArena's fuzzy logic but it is easy to correct this. First, check what you've downloaded. If you got two files, like bot-lara.pk3 and md3-lara.pk3, unzip the botfile. If you got only one file, unzip that one. As you may know, pk3-files are usual zip-fles with a different extension and most . Go to botfiles/bots. In there, you'll see four files, usually with the bot's name but with different filename-endings. Two of these files are good as-is, the _c.c and_t.c, but the _i.c and _w.c files are the ones which we have to edit. These are unformatted text-files, so open them with Notepad or something similar. I suggest to open an OA bot to see the difference and to make it easier to correct. You can find them within OA's pak6-misc.pk3 in the same path: botfiles/bots. As you can see, they're using similar files. The problem is actually within those files, so let's start with the _i.c. As you can see, most of the lines within both files are starting with #define, a capslocked expression, some tabulators and a value. These expressions are used in the game to define how hard the bot tries to get the weapon/ammo/item (_i.c) or how much it'd use a weapon (_w.c). But the expressions are different and this is why the bots doesn't work properly. You just have to rewrite these expressions and add the missing ones. Actually, the lines follow each other in the same line, this helps us. Also, in the OpenArena botfile, every line is commented which also aids us, but if you don't know what you should rewrite to hat, here's a complete table which could be used for both _i.c and _w.c: In Quake 3 In OpenArena FS_HEALTH FPH FS_ARMOR FPA W_SHOTGUN SGW W_MACHINEGUN MGW W_GRENADELAUNCHER GLW W_ROCKETLAUNCHER RLW W_RAILGUN RGW W_BFG10K BFW W_LIGHTNING LGW W_PLASMAGUN PGW GWW_SHOTGUN GSGW GWW_MACHINEGUN GMGW GWW_GRENADELAUNCHER GGLW GWW_ROCKETLAUNCHER GRLW GWW_RAILGUN GRGW GWW_BFG10K GBFW GWW_LIGHTNING GLGW GWW_PLASMAGUN GPGW W_TELEPORTER TELW W_MEDKIT MEDW W_QUAD QW W_ENVIRO ENVW W_HASTE HAW W_INVISIBILITY INW W_REGEN REGW W_FLIGHT FLW FLAG_WEIGHT FGW Also there's a last line with an #include "fw_items.c", rewrite that to #include "fuzi.c" in the _i.c and "fw_weap.c" to "fuzw.c" in the _w.c. About the tabulators, don't mind if the table became distorted. One tabulator must be there, the others are unnecessary, they're for easier understanding to the reader and not for the program. If you rewritten these expressions, you're still not finished, because OA doesn't even load the bot, with the following error: ^1Error: file fuzi.c, line 294: can't evaluate NGW, not defined ^1Error: file fuzi.c, line 294: couldn't read expected token ^1Fatal: couldn't load weights This means that you have to add the TA stuff for your bot. I usually set the proxlauncher near the grenade, chaingun between MG and plasma and nail near shotgun. About items, I suggest to put them near the other items but the cubes should get a relative high weight, like 200. Of course you can put zero to them but then the bot won't use them, also if you put zero for the cubes, the bot won't take skulls in Harvester and Overload mode. After you finished these steps, the bot will be fully playable. But it's poosible that the bot was designed using the standard Q3 lines. If that's the case, sometimes you meet with a "^1Error: BotConstructChat: unknown random string XXX" line in the log. If that's the case, grab the _t.c file from the previos location and delete the capslocked lines. If this leaves a {} mark empty, add a line of ""; between them. Or if you want, extend the file with your content, but beware of the punctuations. Opening a generic OA bot's _t.c-file is also helps. Sometimes when you add a bot to the game, you can't select the OpenArena bots instead you sees the Q3 ones. If this happens, your new bot came with a bots.txt. Open the bot's pk3 and open the scripts subfolder. There delete every Q3 entry from bots.txt, just leave your bot's one. Save and rename it to botname.bot. Rezip it and you're done. Although I'm not completely sure about grammar and I wrote it as an addendum to the current one on the wiki, not as a replacement, even if somewhere repeats the previous. I won't put this to the wiki until someone nods. Title: Re: 0.8.5 Bugs Post by: Cacatoes on September 28, 2010, 05:11:26 AM I can't aprove your text since I have no knowledge about that, but that looks good ;)
Almost makes worth the repackaging, hosting, image previewing of every of ioq3 models. Heh, I don't feel courageous enough (and more importantly I have no good host for non-free material ... maybe we could get in touch with ioquake3 to see if there is something to do on these points). Title: Re: 0.8.5 Bugs Post by: Graion Dilach on September 29, 2010, 01:28:15 AM Well, Cacatoes, for you I have a question about making sense, then. ;)
Almost, but I think the main problem of _w.c and _i.c are easily fixed, compared to the different and thereby missing entries from rnd.c, which results with the BotConstructChat error, mentioned in my documentation. My idea of solving that is just a workaround and it'll waste some of the character. I don't know if rnd.c has a character limit, also to solve it, Chaoticsoldier should be connected, since he works on the OA _t.c files. Title: Re: 0.8.5 Bugs Post by: Cacatoes on September 29, 2010, 05:41:12 AM Okay I admit I didn't read thoroughly your text and only had an eye glimpse.
Quote The problem lies within the differences of the Quake 3 and OpenArena's fuzzy logic but it is easy to correct this. Hmm, maybe better if you don't even mention that fuzzy logic story. The problem isn't: we have to take logic courses and modify the A.I code of bots to solve the problem, right ? The problem rather is: because of a few variable names not corresponding. Right ?capslocked expression => expression in caps ? tabulators => tabulations Quote Actually, the lines follow each other in the same line, this helps us Do you mean: the order of lines is the same between the files ?Quote Also, in the OpenArena botfile, every line is commented which also aids us I even wonder if it's a mistake, but a french could have made that one. In french the verb "Aider" is to help, but in english AIDS refers to the HIV virus. So let's say, "helps" ?Quote what you should rewrite to hat, Spelling ? Remove "to [t]hat"When you say "I usually set the proxlauncher near the grenade", we understand you, but more concretely it means: I usually assign a value to the proxlauncher which is near the grenade launcher's one. Right ? Otherwise we could think the matter is the order of the lines. Finished :) Title: Re: 0.8.5 Bugs Post by: Graion Dilach on September 29, 2010, 07:09:37 AM Okay I admit I didn't read thoroughly your text and only had an eye glimpse. Quote The problem lies within the differences of the Quake 3 and OpenArena's fuzzy logic but it is easy to correct this. Hmm, maybe better if you don't even mention that fuzzy logic story. The problem isn't: we have to take logic courses and modify the A.I code of bots to solve the problem, right ? The problem rather is: because of a few variable names not corresponding. Right ?capslocked expression => expression in caps ? tabulators => tabulations True. Quote Quote Actually, the lines follow each other in the same line, this helps us Do you mean: the order of lines is the same between the files ?Yes. Quote Quote Also, in the OpenArena botfile, every line is commented which also aids us I even wonder if it's a mistake, but a french could have made that one. In french the verb "Aider" is to help, but in english AIDS refers to the HIV virus. So let's say, "helps" ?AFAIK, that verb is in English as well, and even the expression of "first aid" refers to it. Quote Quote what you should rewrite to hat, Spelling ? Remove "to [t]hat"Yep, spelling. Also, I saw a poosible just after I putted this up but I had to go. Quote When you say "I usually set the proxlauncher near the grenade", we understand you, but more concretely it means: I usually assign a value to the proxlauncher which is near the grenade launcher's one. Right ? Otherwise we could think the matter is the order of the lines. Oh, OK. Now this is why I wanted a read before I put it into the wiki. Title: Re: 0.8.5 Bugs Post by: Gig on October 01, 2010, 11:06:48 AM I wrote to dmn_clown via email, to ask him about why the bot scripting was changed...
Quote from: Gig Hi Clown. His reply:> I found your email address on your profile on the OpenArena Forums. > > Could you please take a look to > http://openarena.ws/board/index.php?topic=3578.msg35205#msg35205 > and remember to us how the thing went when OpenArena broke compatibility > with Q3A bots? > > Thank you! Quote from: Clown f I remember correctly, you'll have to re-write the *_c.c and the My following reply, with his reply:*_i.c files because I redefined things due to the copyright concerns. If you keep the weapon weights, etc. the same, the bots personality should not change. Quote from: Gig => To be honest, that's not much. The source code of the game, thus, how to > "read" the bot files should be under GPLv2, and it seems a bit strange that > iD Software did not allow people to create their own bot files due to the > copyright of their original bot files... Quote from: Clown ID's botfiles weren't included in the GPL code dump of quake 3. So without an official acknowledgment from them (i.e. a release of the specific files with a GPL header), they aren't GPL. Quote from: Gig > Anyway, at that time, wasn't it possible to maintain double compatibility, > to read both the old Q3 format and the new OA format? Quote from: Clown I don't believe it would be ethical to do that as it would have I further replied saying that I can imagine that those chunks of code (those to read the bot files) should have ever been in the source code of the game, unless they were stored in a separate file since the beginning or iD Software removed them when releasing the source code, like with the calls to Punkbuster... but it would seem strange. Clown has not answered to my latest mail yet.required copying chunks of code that you are not legally allowed to copy for distribution with anything that is not quake 3. I'm still confused... Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 01, 2010, 11:30:57 AM Well, I don't consider this as a huge issue because this is a point which differs Quake 3 and OpenArena.
About dual format, I think as well that it doesn't archiavable because in the original Team Arena, the original Q3 bots could not be used. So we should write an altered bot-reader code which would use only the pure Q3 things. I consider OA bots using TA stuff is a next step of evolution and if that needs a rewrite of two files per bot, I accept it gladly and rewrite them by hand. Since we're talking about a relatively easy method, which only needs a simple text editor, ten minutes and a bit brainwork, I think it's acceptable. It's true that the bot-reading code is in the source code. And that's used in OpenArena as well. The changes were made in the weapon and the item selection part of the code... interstingly, these parts really had to be rewritten by scratch, because these are indeed missing. Since I started playing with OA 0.7.0, I did numerous botconversions back and forth, and although Quake 3's variable names are easier to understand, I'd vote for the current specification, because if they'd use the same variable names, you would get that "^1Error: file fuzi.c, line 294: can't evaluate NGW, not defined / ^1Error: file fuzi.c, line 294: couldn't read expected token / ^1Fatal: couldn't load weights" error every time you'd use a bot designed for Quake 3. Title: Re: 0.8.5 Bugs Post by: Gig on October 01, 2010, 11:46:03 AM Would it be possible to add some check that recognizes bot files for Q3A and, since they are not compatible, will prevent them from automatically joining the match with bot_minplayers active?
So, one may put in his favourite q3a model and don't care about the related bot... Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 01, 2010, 11:53:48 AM It'd be possible, but I don't know if it'd worth the effort. That should check for an Quake 3 variable from _ i.c or _w.c before putting the bot to the botselection screen... but I've got a better idea.
OA bots should use the extension .oabot instead of general .bot. That's easier to implement, and with that modification, an unmodified Q3 bot won't even turns up in the menu and thereby ingame. Title: Re: 0.8.5 Bugs Post by: sago007 on October 01, 2010, 11:59:59 AM I further replied saying that I can imagine that those chunks of code (those to read the bot files) should have ever been in the source code of the game, unless they were stored in a separate file since the beginning Since the beginning the bots fuzzy logic was stored in separate files outside the engine. One could possible recognize it in one of the main source files by doing something like: Code: #ifnotdefined FPH Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 01, 2010, 12:15:53 PM That's correct, and that's why I could learn Q3 botcode using simple logic. Then two years later, on my first C lesson I was shocked to see that it wasn't that new for me that I firstly thought...
Well, general Q3 bots tries to incorporate fw_weap.c and fw_items.c instead of fuzi.c and fuzw.c, maybe those two fw files should contain the ifdefs. But I'm not remember what is the loading order... also a value should be copied to the TA items as well. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 01, 2010, 01:54:32 PM OK, new question:
Are the filenames fw_weap.c and fw_items.c are copyrighted, or can we use those filenames? Because if we can, here's the answer for this bot-problem. Note that standard OA bots never try to load these two files, while all Q3 bots do. So I hope the answer is yes, because this is the only thing came up my mind. Title: Re: 0.8.5 Bugs Post by: fromhell on October 01, 2010, 03:18:32 PM Now, that is an interesting question. I can't find any references to those two files anywhere in the q3 source...
I guess it can't hurt, can't say i've heard of a lawsuit over a mere filename. Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 02, 2010, 03:54:34 AM The original fw_weap.c and fw_items.c are part of Quake 3 and are in pak0.pk3/botfiles.
These two files are based upon Sago's idea and the fact, that Q3 bots' _w.c and _i.c calls them. If you decide to accept them, should I write them a header, like dmn_clown did or it's fine having only pure code and no explanation? Title: Re: 0.8.5 Bugs Post by: fromhell on October 02, 2010, 01:32:24 PM Would simply making those files 'include' OA's equivelants work?
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 03, 2010, 02:16:11 AM Well, the variable names are different and it needs modificating the bots' _i.c and _w.c, while the problem is that there's no support by default.
Title: Re: 0.8.5 Bugs Post by: Gig on October 04, 2010, 02:50:30 PM Graion, what are you planning to do exactly? I'm a little lost...
Another thing: about a bug that seems very small, but why let it be there? :) It seems that, when you start the game for the first time (temporarily rename your q3config.cfg file to make a try), if you go to the "gam options menu", you see thare is no crosshair (the first option allows you to see it).... look more attently, and you see that it is drawn in black instead of in white as usual... After you launch a match for the first time, and then come back to the menu, you will see it white as usual. If you manually select different color values, there are retained instead, but if the first time you leave the "crosshair shows health" disabled, after launching your first match you will find it enabled again. These are small problems that seem to affect only the settings you see/enter before and when launching your first match ever... anyway, if you want to take a look to the thing... By the way: since when the "crosshair shows health" option is enabled, the selected crosshair colors are ignored, could you please add a short description of this, when you mouseover those options? Thank you! Title: Re: 0.8.5 Bugs Post by: Gig on October 06, 2010, 03:27:05 AM Graion, I see you asked for a SVN commit (http://openarena.ws/board/index.php?topic=1945.msg35363#msg35363) for some files related with the bot compatibility... could you please explain me what are they, and what is the "chat problem" you mentioned there? Thank you!
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 06, 2010, 08:30:39 AM I try my best, but all the information are on the previous page.
OK, as you may already know, the differences between OA bots and Q3 bots are just variable names, how they refer the weapons, items and various chatlines from rnd.c. Those two files I posted and wrote were based on Sago's idea and they fix the weapon and item referring. But I haven't done adding the missing the chatline variables, they're still different, and some Q3 bots will still complain, but that's not a huge problem, they'll work as they should. I'm planning to fix that as well, but only after getting a response from Chaoticsoldier, since I'd like to add that new lines as a side project of his. From a simple user's POV, consider those files as a gate between the two game. Maybe that's the closest I can say. I can't tell you more. Not that I don't want to, I just don't know how to make myself and this thing understand on English. I'm a bit nerdy and while I see this logic, I can't write it down. Possibly on Hungarian it'd be uccessful, but on English... maybe rereading my explanation from last week and Sago's coding are enough. Title: Re: 0.8.5 Bugs Post by: MyLittlePwny on October 06, 2010, 08:47:12 AM I think what you're describing is called a "shim (http://en.wikipedia.org/wiki/Shim_%28computing%29)". ^_^
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 06, 2010, 08:55:22 AM Indeed, that's the correct definition. But I never heard of it 'til this minute. Thanks! :)
Also, that pk3 is enough for the fix. Title: Re: 0.8.5 Bugs Post by: Gig on October 06, 2010, 12:33:02 PM Thus, this should restore the compatibilty, allowing to "translate" the variable names? It's more or less what I suggested some posts ago... but I thought that someone said that the changes from Q3A to OA bot files were "more than variable names".
Anyway, I suppose the Q3 bots still will not use the TA items, right? Just to know what to write in the help pages when 0.8.6 will come out... Title: Re: 0.8.5 Bugs Post by: fromhell on October 06, 2010, 03:27:36 PM A model remap file feature would be decent for mods but it'd probably mean easy cheating so i don't know. It'd fix some mods though
as in a file like: Code: model/player/klesk/red model/player/gargoyle/red Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 07, 2010, 10:06:07 AM Anyway, I suppose the Q3 bots still will not use the TA items, right? Just to know what to write in the help pages when 0.8.6 will come out... Wrong. They will. Well, if they use every Q3 item they'll use TA items as well. My shim copies the weight of Q3 items to the TA slots and I did a test to see if it works as it should by putting Biker to OA and took a test on Blitzkrieg. After I saw that he prefers the plasma mainly, I did a second one on oa_koth1, for the chain. And in that game, lead poisoning became a main source of dying. Title: Re: 0.8.5 Bugs Post by: Gig on October 07, 2010, 10:12:08 AM And will they also recognize the rules of the new game types (Overload, Harvester, One flag CTF, Domination....)?
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 07, 2010, 10:20:12 AM I think so, since they have everything that the OA bots has. But hey, test it and believe in your own eyes.
That pk3 from SVN Commits are for you, simple kind of users. No more thing needed, just that in your baseoa. Title: Re: 0.8.5 Bugs Post by: Gig on October 07, 2010, 10:35:19 AM I will try it for sure! :)
Just a question of time... UPDATE: I did some try... It seems that Q3-compatible bots (like Johnny5, Number4 and Homer) use TA weapons (I noticed these bots seem to like nailgun much, much more than chaingun), and know they have to shoot at the enemy obelisk in Overload mode, and to touch the flags in Domination mode. Man, you are great! Another cake for you!!!! :) Title: Re: 0.8.5 Bugs Post by: Gig on October 07, 2010, 04:21:21 PM A model remap file feature would be decent for mods but it'd probably mean easy cheating so i don't know. It'd fix some mods though as in a file like: Code: model/player/klesk/red model/player/gargoyle/red Why "easy cheating"? Because people could remap to very bright models? If this is the problem, maybe this feature could be limited only to models that the server owns (if you "redirect" to a model that the server does not own, you would see Sarge instead)... just an idea... or maybe "protect" in some way the conversion table, so that a guy would not be able connect to pure servers if he altered it, changing the values included with OpenArena... Title: Re: 0.8.5 Bugs Post by: Gig on October 08, 2010, 12:01:54 PM The bot compatibility patch is a great thing... what about advertising it, placing it in the downloads section directly on the site, placing a sticky thread on the forum or similar?
It is a great fix for OpenArena, I think people should not have to wait until the next release (and nobody knows when it will be) to take advantage from it! Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 08, 2010, 01:28:18 PM It seems that Q3-compatible bots (like Johnny5, Number4 and Homer) use TA weapons (I noticed these bots seem to like nailgun much, much more than chaingun), and know they have to shoot at the enemy obelisk in Overload mode, and to touch the flags in Domination mode. Well, bots which like the shotgun will prefer the nail as well, the plasma-lovers will use the chain much and the grenadiers will love the proxmine. And I should try Overload once. BTW, FAQ's regarding section is updated. Title: Re: 0.8.5 Bugs Post by: Gig on October 08, 2010, 06:22:33 PM Maybe DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=FAQ&diff=7146&oldid=7068]a little drastic (http://([b), but I suppose it may work. :) Is it possible to host the file in a place where people could download it without having to register to the forum?
Fromhell, could you please put it somewhere on the openarena.ws ftp space, for example? By the way, is there somewhere a page that explains how to write a bot file for OpenArena? Graion (and everyone that reads this, obviously!)... what do you think about the eventuality to "remap" model names (http://openarena.ws/board/index.php?topic=3578.msg35432#msg35432) -where not available a real model with the same name- (and/or the same thing for missing bot files, or even maps, too?) to improve compatibility with some Q3A mods? Title: Re: 0.8.5 Bugs Post by: Cacatoes on October 08, 2010, 08:08:21 PM I didn't follow the discussion. Isn't that work meant to be commited to SVN thread ? Otherwise when it's complete one can host it here (http://openarena.tuxfamily.org/upload/).
Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 09, 2010, 12:55:21 PM It has already been completed and commited as SVN revision 935, Cacatoes. But the current version still needs a fix, although I can and will prove on my own that download.
I think the model and bot remap could be possible. I did something similar to ARQ, actually. But the map is too much, and it can't be changed that simply. About bot-writing, IMHO it's easier to get BotStudio, write a Q3 bot then converting it to OA on the hard way then writing a OA bot from scratch. BotStudio has a GUI and as far as I remember, it has a documentation. Combining with that documentation I wrote on the previous page, it should be more than enough. Title: Re: 0.8.5 Bugs Post by: Gig on October 10, 2010, 05:28:25 AM I see you updated the download link for the patch. Good.
What about writing a page on the wiki (for example "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Creating_a _bot]Creating a bot (http://([b)"), writing where to find that BotStudio software (and, if available, some documentation for it), and then include the conversion guide you wrote here? Title: Re: 0.8.5 Bugs Post by: Gig on October 15, 2010, 05:15:47 AM If someone is interested, I found a guide about Q3 bots that seems enough detailed:
http://dev.johnstevenson.co.uk/bots/20585341-The-Quake-III-Arena-Bot.pdf Title: Re: 0.8.5 Bugs Post by: chaoticsoldier on October 15, 2010, 08:05:07 PM That's a good read. It's full of great information, but there's so much technical stuff to filter through.
If you'd like to know more about creating or editing bots, I strongly recommend following the link on p87 and download q3abotedit.zip. The documents in that .zip are very easy to understand. I found that file about a year ago and it taught me a lot. Title: Re: 0.8.5 Bugs Post by: Gig on October 16, 2010, 04:42:21 AM Yes, let's put also this link here: ftp://ftp.idsoftware.com/idstuff/quake3/tools/q3abotedit.zip
Note: This forum does not like "ftp" links, it adds automatically an "http" before them, making them wrong. Copy-paste in your browser the address, removing the "http" part. However, I still hope that Graion will create that "Creating a bot" page to explain how to write them in the "OA" style... Title: Re: 0.8.5 Bugs Post by: Graion Dilach on October 16, 2010, 05:00:45 AM Maybe next week.
Considering that my first documentation wasn't that understandable that I've thought first, also that I had to upgrade an SMF forum from 1.1 to 2.0 which took ca. 15 hours this week as part of a strill unfinished website redesign, I don't know when will I get to write another one. Also, firstly I'd like to synchronize the Q3 chat variables with the ones used by Chaoticsoldier. I still don't even started that one. I must say that nothing is forgotten, but my timetable is too cruel. Title: Re: 0.8.5 Bugs Post by: Neon_Knight on October 16, 2010, 09:26:18 AM Yes, let's put also this link here: ftp://ftp.idsoftware.com/idstuff/quake3/tools/q3abotedit.zip (ftp://ftp.idsoftware.com/idstuff/quake3/tools/q3abotedit.zip) Fixed, use the ftp tag to link FTP files:Note: This forum does not like "ftp" links, it adds automatically an "http" before them, making them wrong. Copy-paste in your browser the address, removing the "http" part. However, I still hope that Graion will create that "Creating a bot" page to explain how to write them in the "OA" style... Code: [ftp]ftp://heregoestheftpurl.com/ftpfile.exe[/ftp] Title: Re: 0.8.5 Bugs Post by: Gig on October 16, 2010, 10:03:28 AM I never noticed the "insert ftp link" icon next to the "insert email" icon...
ftp://ftp.idsoftware.com/idstuff/quake3/tools/q3abotedit.zip (ftp://ftp.idsoftware.com/idstuff/quake3/tools/q3abotedit.zip) Title: Re: 0.8.5 Bugs Post by: Gig on October 19, 2010, 10:06:13 AM Another bug, or better, two bugs.
This time it comes with the weapon bar and the elimination_grapple. You can see it in the screenshot. To reproduce: - set cg_weaponbarstyle to 3 - set elimination_grapple to 1 - load a map in Elimination mode - check the weapon icons: the icon of the grapple appears like a "missing texture" until you select it (when you select it, the icon becomes loaded). It seems to happen with weapon bar style 2, 3, 4, 5, 6, 7. Note: this seems to not happen if the weaponbarstyle was 0: if you did not set it to 3 before the test, do it now and then load another map. Change map also after the icon has been loaded once. - There is a red line (that should indicate the ammo level, by the way it probably may be omitted since the grapple does not consume ammo), and it is placed at the wrong place (there is no weapon at the position of the red line). It seems this happens with cg_weaponbarstyle 1, 3, 6 and elimination_grapple active. Title: Re: 0.8.5 Bugs Post by: Gig on October 20, 2010, 12:00:20 PM I did some tests with the "g_motd" and the "motd.cfg" (I used them to update DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Servers&diff=7505&oldid=7244]this, could you please check I did all correcly (http://([b)?).
And I noticed that when you update the motd.cfg file, the new message is immediately active on the next connecting clients.... but when you update the g_motd variable, the clients loading screen still shows the old message, until the server has loaded another map (or restarted the current one). Is it possible to have the "g_motd" message immediately updated after you change it? (This is the update request of this post.) - Side note: the cvar does not result "latched" like some other settings that need some kind of "restart" to be effective. ---------- PS: Do you know if there is some way to have the "motd.cfg" message shown for longer time, or re-shown without having to \reconnect? Title: Re: 0.8.5 Bugs Post by: Cacatoes on October 20, 2010, 12:21:35 PM With the motd file, the message is printed again if you change your team (join spectator, change team, or new map).
I thought there was a cvar to change for how long motd is displayed but I don't find it and there may not be. Admins can eventually print text with Custom Votes, or there may be a way to extend the admin system so that commands like !motd are available. Having that text displayed for long can be annoying because MOTD can take the whole screen, so default value seems good to me. Usually motds dont pollute the visual screen but remains in the console logs, that's why I think extending the admin system with that command could be a better idea. Title: Re: 0.8.5 Bugs Post by: Gig on October 21, 2010, 02:45:47 PM Since one can see the "long" message of the day when going to spectator mode or changing team, I suppose there is no need to do the things more complicated with a cvar to change its duration.
PS: I don't know about the admin system.... I don't understand what you mean. Anyway, if some dev likes it... Title: Re: 0.8.5 Bugs Post by: Cacatoes on October 21, 2010, 03:31:42 PM The admin system is this (http://code.google.com/p/oax/wiki/Admin), though addition of new commands isn't documented there, maybe in some UrT doc.
Title: Re: 0.8.5 Bugs Post by: Gig on October 21, 2010, 04:07:20 PM Wow... I'm sorry I'm not capable of adding the documentation for it. However, if it is related to the Tremolous documentation, maybe we may link it (if we find it).
For the moment, I simply did DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Servers&diff=7525&oldid=7514]this (http://([b). Not much, for something that is probably a good admin system, and that should be covered (more or less) in detail... but at the moment I cannot do more. Title: Re: 0.8.5 Bugs Post by: RMF on October 29, 2010, 01:30:40 PM At the start of a game, set cg_drawrewards 0. Then near the end, last minute or something, set the variable back to 1. If you played a bit well, you'll see all awards you got during the game in a row. Like it has cached them and is now playing them all.
Title: Bots in CTF Elimination Oneway Post by: Gig on November 01, 2010, 08:42:03 AM This one is not excacly a bug, but it is something that may be improved a bit. If one plays CTF Elimination with the One way capture (http://CTF_Elimination#One_way_capture) option enabled, when you are in the defensive team, attacking the enemy base is not very useful, if noone is there: bots in defensive team probably should tend to remain in their own base or roam around the map, or, if they go to the enemy base, should go back if they find no enemy to frag there. And when you are in the offensive team, remaining in your base is not very useful, since the enemy cannot pickup your flag and you have nothing to guard (maybe one may want to stay away from the battle, in order to survive until the end of the round? But if the time goes out, the defensive team will win anyway! And avoiding the battle, in general, is not a nice thing in OpenArena, right?): probably, bots in the attacking team should tend to an all-out attack...
Graion (or some other developer), what to you think about it? Is my thought right? Is it possible to tune a bit the bots behavior in this gametype (when both g_gametype 9 and elimination_ctf_oneway 1 are true)? Title: Re: Bots in CTF Elimination Oneway Post by: sago007 on November 01, 2010, 10:29:11 AM Graion (or some other developer), what to you think about it? Is my thought right? Is it possible to tune a bit the bots behavior in this gametype (when both g_gametype 9 and elimination_ctf_oneway 1 are true)? Currently the bots have no concept of being eliminated and does not change there behavior if all offensive players are dead because they expect them to respawn in a few seconds. The reason why I send half the bots towards the enemy flag in Oneway capture is that if all players remained at the base the enemies would reach the base with full power and could easily run away and with all defenders in the base none could intercept. If you are a human with bot players you would be happy that some bots stay home because they will weaken the welcome committee once you return. I did try with different behaviors some year ago but it didn't really work you always had the feeling that the bots played better before. Title: Re: 0.8.5 Bugs Post by: Gig on November 01, 2010, 10:57:03 AM But at least they should know that, if all their team-mates have been fragged (and they are in the attacking team), they should stop defending the (useless) flag and go attacking by their own, because their team-mates will not respawn, no?
From what I understand, now there is even the risk that all the "attacking" players of both teams (devensive and offensive) are fragged, and those remaining will be stuck each one in his own base, until the time runs out? Title: Re: 0.8.5 Bugs Post by: sago007 on November 01, 2010, 10:59:27 AM From what I understand, now there is even the risk that all the "attacking" players of both teams (devensive and offensive) are fragged, and those remaining will be stuck each one in his own base, until the time runs out? That is the case. They will go on offense at some point but the time will likely run out first.Title: Re: 0.8.5 Bugs Post by: Gig on November 01, 2010, 12:14:20 PM I suppose this may be a problem for CTF Elimination even without the "oneway" mode...
Would it be very difficult to make a bot know it is the last player still alive on his team, and then making it work like when it is the only player of a team? Title: Re: 0.8.5 Bugs Post by: Graion Dilach on November 01, 2010, 03:38:11 PM I'm not very familiar (mean: I don't even know where it is) with Elimination code, but if there is a variable which keeps the amount of alive team-members, it sounds possible.
Title: Re: 0.8.5 Bugs Post by: Gig on November 06, 2010, 10:39:07 AM Sago, do you know if such variable exists?
PS: Yesterday I played on a server that used the "Aftershock" mod, with the Elimination gametype. When you remained the last player in your team, a message appeared on the screen (with not-too-big fonts) for some seconds, informing you about this. Maybe we could implement something similar also in baseoa. Title: Re: 0.8.5 Bugs Post by: sago007 on November 06, 2010, 11:30:22 AM Sago, do you know if such variable exists? The server keeps the number of players alive in the array countsLiving[TEAMNUMBER] but it is not currently exposed to the bot logic.PS: Yesterday I played on a server that used the "Aftershock" mod, with the Elimination gametype. When you remained the last player in your team, a message appeared on the screen (with not-too-big fonts) for some seconds, informing you about this. Maybe we could implement something similar also in baseoa. I have thought about making, some alternatives to centerprint (cp): cp (standard centerprint -big fint) cp1 (a little smaller - disappears if cp is used) cp2 (even smaller - disappears if cp or cp1 is used) cp3 (small message above cp, different color) cp4 (small message above cp, different color, removed if cp3 is active) The idea is that at must two messeges can be displayed to the player simultaneously and the client should be able to prioritize them. Title: Re: 0.8.5 Bugs Post by: Gig on November 06, 2010, 01:13:19 PM Sago, do you know if such variable exists? The server keeps the number of players alive in the array countsLiving[TEAMNUMBER] but it is not currently exposed to the bot logic.Do you think you could co-ordinate with Graion to work around this? More, I did a test in oa_ctf4ish, and it seems that also in standard CTF (gametype 4), if a bot is the only player of his team (for exaple, you switch to spectator mode), it will continue to defend the base. It seems that in a 1vs1 CTF with bots, it is very unlikely that someone will score soon. Bots should know if they are the last or only player on their team: in this case, they should go to get the enemy flag even if they were previously in defense (and obviously, after they get the enemy flag, they should look for their own flag if the enemies stole it). With the necessary differences, this should be applied to all the team-based gametypes that have an objective different from just wandering around killing the enemies. PLEASE READ the following: And I found a major bug (maybe two, but maybe they are two aspects of the same one) while doing these tests... but I'm not sure on how to reproduce, seems if I add the bots manually using addbot command (and I don't know if the fact that then I changed team is related or not)... I was 2 (me and bot) vs 1 (bot), and I used team orders to ask "everyone report" and I was very surprised when BOTH the bots replied me with team chat, saying "defending the red flag"... even the blue bot!!!!! Another absurd thing I noticed, continuing the tests, was seeing two bots in the same team fighting each other... and one of them carrying and capturing its own flag!!!! Both bots were red (in the colour and in the score table), but one of them was acting as blue player! See the screenshots! The red bot is capturing the red flag! Please, load a ctf map and then do some tests, adding and removing bots, giving the "everybody report" order etc... This seems a quite worrying bug... I don't know if it affects also other team-based gametypes. Title: Re: 0.8.5 Bugs Post by: sago007 on November 06, 2010, 01:33:04 PM Please, load a ctf map and then do some tests, adding and removing bots, giving the "everybody report" order etc... Interesting. There has always been problems with bots not knowing what team they are on... yet no sure way of reproducing it. This seems a quite worrying bug... I don't know if it affects also other team-based gametypes. EDIT: And I still cannot reproduce it reliably. The problem with bots not knowing what team they are on has existed forever. In a previous version I changed the way the bot discovered there own team color to read it directly from the game logic rather than from the bot string. My guess is that ent->client->ps.persistant[PERS_TEAM] and level.clients[i].sess.sessionTeam is out of sync... I don't know why there need to be two places for the same value. EDIT2: Just realized that the bot code skips the place where sessionTeam is set. Title: Re: 0.8.5 Bugs Post by: Cacatoes on November 06, 2010, 05:50:21 PM Quote ..and one of them carrying and capturing its own flag!!!! Both bots were red (in the colour and in the score table), but one of them was acting as blue player! See the screenshots! The red bot is capturing the red flag! Hééé what problem with that ? That's his own right...I'm pretty sure the "TEAMMATE" bug vote has been fixed, and probably isn't related to this. But right now I just remembered about the new (0.8.5) voting system problem, which gives quite weird results and is almost unusable in its current state. The vote issue is "yes" too often, we've been dealing with it for some while, and it's quite an annoying one, so right now I can't remember if something has been done to fix it. Edit: Oh, now I remember why I wanted to post. These kind of behaviours I've seen with bots is when I was using the !commands. Like !putteam Sarge Red, etc, or !shuffle. I just tried and had like 2 bots in red (with me), no one in blue. "!putteam Sarge blue" didn't made him change team but then he aggressed his mate. Like Gig I used "/addbot sarge" with no further arguments. Some way to put yourself admin in local games is to specify a "/rconpassword sauerkrauten" then "/rcon !setlevel caca 5" (note: I always mess with the order of args with !setlevel command) Title: Re: 0.8.5 Bugs Post by: sago007 on November 06, 2010, 06:12:02 PM I'm pretty sure the "TEAMMATE" bug vote has been fixed, and probably isn't related to this. But right now I just remembered about the new (0.8.5) voting system problem, which gives quite weird results and is almost unusable in its current state. The vote issue is "yes" too often, we've been dealing with it for some while, and it's quite an annoying one, so right now I can't remember if something has been done to fix it. I have not done anything about. What is the problem? A vote should never be "yes" if there are at least as many "no" votes as "yes" votes.Edit: Oh, now I remember why I wanted to post. These kind of behaviours I've seen with bots is when I was using the !commands. Like !putteam Sarge Red, etc, or !shuffle. I just tried and had like 2 bots in red (with me), no one in blue. "!putteam Sarge blue" didn't made him change team but then he aggressed his mate. Thanks! That made it possible for me to reproduce and fix the problem. As expected it was caused by the sessionteam that was not set for bots. It should be fixed in OAX r242Title: Re: 0.8.5 Bugs Post by: Gig on November 06, 2010, 06:36:22 PM Quote ..and one of them carrying and capturing its own flag!!!! Both bots were red (in the colour and in the score table), but one of them was acting as blue player! See the screenshots! The red bot is capturing the red flag! Hééé what problem with that ? That's his own right...This was ironic, right? A player touching his own flag should cause it immediatley be teleported to its base, he should not be able to pickup it (except for some mods, that introduced a "return the flag" gametype where you have to bring your own flag to your base manually). PS (if it could be somehow useful to Sago to check his theory): not sure... but probably in my tests I used the "addbot" command in the format "\addbot <botname> <skill> <colour>"... Title: Re: 0.8.5 Bugs Post by: Cacatoes on November 06, 2010, 07:34:02 PM About the vote,
I haven't been able to identify the behaviour, but I guess several players will tell you 085 votes are screwed up. Sometimes, everything goes well and votes work as they should. Indeed, 3-3 leads to "no" and that's fine that way. The problem is, sometimes, you think the issue of the vote will be one thing, like, you see votes being accumulated to "No", then suddenly results are reversed. "No" goes down to 0 and there are several Yes votes. I think it comes magically in one step, it's not the behaviour which is "one changes his/her mood and corrects the vote". Some players have fun changing from F1 to F2 all the time but this is little annoyance, and in that case the effect is directly visible on the vote counts. Title: Re: 0.8.5 Bugs Post by: Gig on November 06, 2010, 07:42:58 PM I have thought about making, some alternatives to centerprint (cp): cp (standard centerprint -big fint) cp1 (a little smaller - disappears if cp is used) cp2 (even smaller - disappears if cp or cp1 is used) cp3 (small message above cp, different color) cp4 (small message above cp, different color, removed if cp3 is active) The idea is that at must two messeges can be displayed to the player simultaneously and the client should be able to prioritize them. To use different font sizes seems a very good idea (useful, for example, in customized killing sprees (http://openarena.ws/board/index.php?topic=3955.msg35743#msg35743))... I don't know how "cp" is used in the source code, but why the different color? The color isn't manually customizable for each message, using ^1, ^2, etc? Do you mean that the "default" color will change? For example, a standard message "begins with" ^7, but you can customize it, and a standard chat line is ^2, but you can customize it, right? Do you mean that cp3 would begin, for example, with ^3, and cp4 would begin, for example, with ^4, but they would still be customizable? -------------------- About the bots bug, I did a rapid test in the classic Q3A, in q3ctf4: when I set them one per team (and I spectate), the bots seem a little more aggressive than in OpenArena, and maybe seem to attack the enemy base more frequently... but they seem much more interested in fighting each other than grabbing that flag (they picked up it only once in some minutes)! I've not been able to reproduce the "team colors/behaviors screwed up" bug, there... Title: Re: 0.8.5 Bugs Post by: sago007 on November 07, 2010, 02:47:02 AM I don't know how "cp" is used in the source code, but why the different color? The color isn't manually customizable for each message, using ^1, ^2, etc? Do you mean that the "default" color will change? For example, a standard message "begins with" ^7, but you can customize it, and a standard chat line is ^2, but you can customize it, right? Do you mean that cp3 would begin, for example, with ^3, and cp4 would begin, for example, with ^4, but they would still be customizable? Colors can always be overwritten (if the message is about a team) but it might be a good idea to give default colors too. If we one day want to change all colors of one message it we only need to change it in one place.Title: Re: 0.8.5 Bugs Post by: Gig on November 07, 2010, 04:51:37 AM For me, it's okay.
Title: Re: 0.8.5 Bugs Post by: jhardin on December 26, 2010, 01:11:58 PM netchan error are virtually impossible to debug because they are encrypted. I have been able to reproduce in 0.8.5 in LMS single player frequently on oa_koth2 (why it happens more often there I don't know). The current OAX beta 45 tries to reduce the risk of it happening by preventing heavy transmissions during intermission. But because the problem is random there might still be problems. There are many network parameters that can increase or reduce the probability. This is a known problem, and is not random - if you have bots enabled and load a map that does not support bots, it will eventually crash: http://lists.ioquake.org/pipermail/ioquake3-ioquake.org/2007-November/002135.html http://quake3world.com/forum/viewtopic.php?t=9220 It was apparently fixed in ioquake upstream in May 2009: http://svn.icculus.org/quake3/trunk/code/server/sv_net_chan.c?r1=1552&r2=1596 Are there any plans to include ioquake server-side updates in 0.8.6? It would probably be a very good idea, as the OA server code seems to be getting a bit stale... Title: Re: 0.8.5 Bugs Post by: sago007 on December 26, 2010, 01:44:34 PM It was apparently fixed in ioquake upstream in May 2009: You are talking about a different problem.http://svn.icculus.org/quake3/trunk/code/server/sv_net_chan.c?r1=1552&r2=1596 Are there any plans to include ioquake server-side updates in 0.8.6? It would probably be a very good idea, as the OA server code seems to be getting a bit stale... If it was fixed in revision 1596 then it would be fixed in 0.8.5 because it was based on some 17XX revision. Netchan errors can be caused by hundred of different things. Title: Re: 0.8.5 Bugs Post by: jhardin on December 26, 2010, 04:15:40 PM It was apparently fixed in ioquake upstream in May 2009: You are talking about a different problem.http://svn.icculus.org/quake3/trunk/code/server/sv_net_chan.c?r1=1552&r2=1596 If it was fixed in revision 1596 then it would be fixed in 0.8.5 because it was based on some 17XX revision. Netchan errors can be caused by hundred of different things. ...frack. I dug into this a little deeper and it seems that Gentoo's OpenArena 0.8.5 package is the 0.8.1 sources plus some individual patch files. If I pull the compiled OpenArena executable out of the OA 0.8.5 patch file and run it in place of the one that Gentoo compiles from scratch, the crash does not occur. Any possibility of there being an 0.8.6 package that is the complete build-it-from-scratch sources, in addition to a precompiled update .ZIP as was done for 0.8.5? Thanks. Title: Re: 0.8.5 Bugs Post by: sago007 on December 31, 2010, 06:23:29 PM Any possibility of there being an 0.8.6 package that is the complete build-it-from-scratch sources, in addition to a precompiled update .ZIP as was done for 0.8.5? All OA binaries have been in the test thread for some time and can be found here: http://files.poulsander.com/~poul19/public_files/oa/dev081/The binaries in the 0.8.5 patch is either "-14" (windows) or "-13" (linux). The source is in the tar.bz2-files. Title: Re: 0.8.5 Bugs Post by: jhardin on December 31, 2010, 10:04:58 PM Any possibility of there being an 0.8.6 package that is the complete build-it-from-scratch sources, in addition to a precompiled update .ZIP as was done for 0.8.5? All OA binaries have been in the test thread for some time and can be found here: http://files.poulsander.com/~poul19/public_files/oa/dev081/The binaries in the 0.8.5 patch is either "-14" (windows) or "-13" (linux). The source is in the tar.bz2-files. Okay, then let me modify my request: could the current version of the source tarball be copied to http://openarena.ws/svn/source/081/ whenever a stable release is done? Gentoo builds stuff from scratch, and the latest code tarball available from an "authoritative" source (i.e. the project's SVN repo URL above) is the (now-stale) 0.8.1-1 tarball. Can the openarena-engine-source-0.8.x-13.tar.bz2 or -14 source tarball for the 0.8.5 release be copied there immediately? Or is there a different authoritative server (besides poul19's home directory) for the 0.8.5 release that Gentoo should be pulling the sources from? Thanks! Title: Re: 0.8.5 Bugs Post by: Gig on January 23, 2011, 04:54:03 AM Hi guys! Do you remember this post (http://openarena.ws/board/index.php?topic=3578.msg33455)?
It talked about the problem that "autocomplete" for "exec" command does not work after you enter a map. The guys at ioquake3 have just created a fix (https://bugzilla.icculus.org/show_bug.cgi?id=4794). Is it possible to apply it to OpenArena? Title: Re: 0.8.5 Bugs Post by: sago007 on January 23, 2011, 03:13:22 PM Is it possible to apply it to OpenArena? Yes, but soon it might be applied to ioquake3 and that would be preferred, especially since it is not OpenArena specific. Title: Re: 0.8.5 Bugs Post by: sago007 on February 10, 2011, 05:23:37 PM Looks like this was included in ioquake3 revision 1892.
I will create a new engine snapshot soon. ioquake3 patches are coming very quickly at the moment but enough has been done to try it out. Title: Re: 0.8.5 Bugs Post by: Neon_Knight on February 10, 2011, 05:32:12 PM Is there a chance for, at least, a 0.8.6 code-patch?
Title: Re: 0.8.5 Bugs Post by: Neon_Knight on March 01, 2011, 01:06:19 PM The icons for the Neutral Flag (also used in Domination) and the Red and Blue skulls are missing.
Title: Re: 0.8.5 Bugs - Client fatal crash Post by: Scorpena on April 16, 2011, 02:00:10 AM If any OA guru can help me, please.
While loading defrag mod game crashes. Log: Quote ----- FS_Startup ----- ---End log---Current search path: <...here maps list goes...> C:\Games\openarena-0.8.5\baseoa\pak0.pk3 (1042 files) <...here maps list goes...> handle 1: video/idlogo.roq ---------------------- 32543 files in pk3 files cl_voip will be changed upon restarting. r_stencilbits will be changed upon restarting. r_mode will be changed upon restarting. g_spSkill will be changed upon restarting. execing default.cfg couldn't exec q3config.cfg couldn't exec q3config.cfg couldn't exec autoexec.cfg Closing SDL audio device... SDL audio device shut down. ------ Initializing Sound ------ Loading "OpenAL32.dll"... ----- Client Shutdown (Client fatal crashed: Couldn't open C:\Games\openarena-0.8.5\baseoa\pak0.pk3) ----- RE_Shutdown( 1 ) ----------------------- or another log: Quote <...here maps list goes...> ---End log---handle 1: video/idlogo.roq ---------------------- 32543 files in pk3 files RE_Shutdown( 1 ) or: ... Quote <...here maps list goes...> ---End log---handle 1: video/idlogo.roq ---------------------- 32543 files in pk3 files cl_voip will be changed upon restarting. r_stencilbits will be changed upon restarting. r_mode will be changed upon restarting. g_spSkill will be changed upon restarting. execing default.cfg couldn't exec q3config.cfg couldn't exec q3config.cfg couldn't exec autoexec.cfg OpenAL capture device closed. ------ Initializing Sound ------ Loading "OpenAL32.dll"... ----- Client Shutdown (Clie C:\Games\openarena-0.8.5\baseoa\batcula.pk3 (56 files) C:\Games\openarena-0.8.5\baseoa\apocalyptica.pk3 (27 files) C:\Ga Such log last time appears only while loading defrag mod (and aftershock), other mods work fine. C:\Games\openarena-0.8.5\baseoa\pak0.pk3 is in the map list. Windows XP SP3. Open Arena 0.8.5 with openarena-engine-bin-0.8.x-20 dated 07.03.2011 (was applied after some maps didn't loaded and game went out to defrag menu). Till now all went well, but past few days cant launch defrag mode. :( I thought the cause was in audio drivers and reinstalled audio drivers and OAL, but nothing changed. Video setting wasnt changed. Can u give me a piece of advice how to launch defrag and avoid crash? ??? Title: Re: 0.8.5 Bugs Post by: Gig on April 16, 2011, 06:37:44 AM Maybe some pk3 your machine recently autodownloaded makes some conflict.
Search in your baseoa and defrag folders for recently created pk3 files, rename them (like example.pk3.test) or move them of from their folders (e.g. on the desktop). Then try again. Title: Re: 0.8.5 Bugs Post by: Scorpena on April 16, 2011, 08:37:30 AM Maybe some pk3 your machine recently autodownloaded makes some conflict. Search in your baseoa and defrag folders for recently created pk3 files, rename them (like example.pk3.test) or move them of from their folders (e.g. on the desktop). Then try again. Thank you. I used this trick, but recently it happens way too often - almost after every map. So it looks exactly like an annoying bug. :) Interesting moment was when game crashed on a map ghost-duck.pk3, which worked stable right before that, and i had to move it off. And I dont understand, why other gamers doesnt have such troubles on same maps? Also, why .pk3 file, which is simple zip archive, conflicts with the program core up to crash in usual environment? Why I have to find, try and delete it manually instead of receiving some standart program message, like "<example.pk3> map conflicts with program function <xyz>" in working defrag mod without silent core crash? :-\ Also another bug: Quote ... ---End log---recording to demos/temp/current.dm_71. Couldn't write q3config.cfg. Stopped demo. Not recording a demo. recording to demos/temp/current.dm_71. Couldn't write q3config.cfg. SaveRecord(): failed to open system/records/ruined-ghost_mdf_cpm.rec for writing. Warning: failed to open demos/temp/current.dm_71 for copy. (source) ^3Autorecord: demo copy failed.^7 Stopped demo. Not recording a demo. Title: Re: 0.8.5 Bugs Post by: Gig on April 16, 2011, 06:15:12 PM And I dont understand, why other gamers doesnt have such troubles on same maps? I'm not a developer, someone else may answer better.Also, why .pk3 file, which is simple zip archive, conflicts with the program core up to crash in usual environment? Why I have to find, try and delete it manually instead of receiving some standart program message, like "<example.pk3> map conflicts with program function <xyz>" in working defrag mod without silent core crash? :-\ Anyway, inside a pk3 (zip) file there can be various kinds of stuff, organized in files and folders (textures, models, maps, bots, sounds, game logic...). When you launch the game, OpenArena loads all the stuff from the pk3s in "baseoa" folder (in both your installation folder and "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Homepath]homepath (http://([b)" folder), and from the pk3s in the folder of the current mod. All that stuff is put together, but what happens if inside different pk3s there are two or more files with the same name? Only the latest one is loaded (loading order depends from in which folder the pk3 is and from the alphabetical order of the pk3 files). This allows useful things like patches simply adding a new pk3 with a "higher" name that overrides previous stuff. But this may also bring to some problems: e.g. if you have a map that is designed to use a "test.jpg" texture, that is stored in pak0.pk3 file, but you have a pak1.pk3 file that has got a different texture called "test.jpg", the map will not show the one that the author intended. And if some pk3 contains some game logic modify, the risk of major problems goes up. Such problems are more probable when playing offline, since when playing online the "pure check" ignores pk3 files that are not present on the server. See also (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Using_Mods#Notes_for_Server_Administrators Title: Re: 0.8.5 Bugs Post by: Scorpena on April 17, 2011, 05:08:59 AM I'm not a developer, someone else may answer better. Anyway, inside a pk3 (zip) file there can be various kinds of stuff, organized in files and folders (textures, models, maps, bots, sounds, game logic...). When you launch the game, OpenArena loads all the stuff from the pk3s in "baseoa" folder (in both your installation folder and "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Homepath]homepath (http://([b)" folder), and from the pk3s in the folder of the current mod. All that stuff is put together, but what happens if inside different pk3s there are two or more files with the same name? Only the latest one is loaded (loading order depends from in which folder the pk3 is and from the alphabetical order of the pk3 files). This allows useful things like patches simply adding a new pk3 with a "higher" name that overrides previous stuff. But this may also bring to some problems: e.g. if you have a map that is designed to use a "test.jpg" texture, that is stored in pak0.pk3 file, but you have a pak1.pk3 file that has got a different texture called "test.jpg", the map will not show the one that the author intended. And if some pk3 contains some game logic modify, the risk of major problems goes up. Such problems are more probable when playing offline, since when playing online the "pure check" ignores pk3 files that are not present on the server. See also (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Using_Mods#Notes_for_Server_Administrators Thank you very much for your concern. So, for now manual moving troublesome .pk3 files off the baseoa folder is the only way... And as for your example, i hope that developers can implement some debug mode, which allows at first, full diagnostics, at second, using not last, but selected (checked) file (texture, model, map, bot, sound, game logic...) with the exact map in exact mod - f.e. test.jpg from pack120beta.pk3, not from pack098.pk3 or pack126.pk3. Resulting settings can be separated in file or folder, one ini/cfg position for one map. Title: Re: 0.8.5 Bugs Post by: Gig on April 17, 2011, 06:47:15 AM Troublesome pk3s may also be in the mods folder.
About changing the behavior like you said, I suppose that it would not be possible for various reasons: - This Pk3 management is the way Quake 3 was designed from its origin, and iquake3 and OpenArena follow it. Changing it may break compatibility with tons of stuff made until now. - How to specify a map to use a specific version of a certain folder/filename? Calculating an hash control for each texture file, and store it inside the .bsp file? I suppose that would need to modify also the tools used to create maps (NetRadiant, BSPC, etc.) -with the map and bsp formats-. - It would make harder to make patches (example: adding need to modify and recompile each map if you wish to change a texture. And what would you do if you do not have the required version of the texture and have no access to the map source to apply a different one and recompile? Well, this case is not easy to manage even now, but it would be even worse.) I don't know how they mange this kind of problems in more modern games... but I suppose that for idTech3-based games the only thing to do is to rely in mod creators and server admins, hoping that they carefully think to (and test) what they do when put in additional stuff on their servers. (And map creators that add their own textures, to use "original" names, to minimize risk of duplicated filenames) I don't know if there could be some way to make more debug info available (like the system trying to guess which are the pk3 files that clash)... but probably this question should be posted to the ioquake3 team (opening a bug ticket on Bugzilla (https://bugzilla.icculus.org/)), instead of the OpenArena team. Anyway, I'm not a developer, I repeat... PS: About your errors, are you sure the user account that runs OpenArena has got read/write permissions on your installation and "homepath" folders and all of their subfolders and files? Title: Re: 0.8.5 Bugs Post by: Gig on November 02, 2011, 12:52:50 PM The bug of the grapple icon appearing as "missing" with some cg_weaponbarstyle values (using elimination_grapple 1 in elimination type) until you select it (see http://openarena.ws/board/index.php?topic=3578.msg35650#msg35650 for more details), seems to have not been fixed (even if in the wiki it was said it could have been already fixed).
Tested with OAX B50. Strangely enough, now the hook "light rope" shader and the hook (not the weapon) model appear as missing (while in OA 0.8.5 are shown correctly) when you shoot it! Maybe the problem with the red ammobar is fixed, instead (as reported in OAXB49 changelog). Title: Re: 0.8.5 Bugs Post by: sago007 on November 02, 2011, 01:41:06 PM The bug of the grapple icon appearing as "missing" with some cg_weaponbarstyle values (using elimination_grapple 1 in elimination type) until you select it (see http://openarena.ws/board/index.php?topic=3578.msg35650#msg35650 for more details), seems to have not been fixed (even if in the wiki it was said it could have been already fixed). The page never claimed it to be fixed. I just asked if it still existed before looking into it.Tested with OAX B50. Appears that fromhell used a model that does not exist in 0.8.5 and I did not notice and therefore did not include it.Strangely enough, now the hook "light rope" shader and the hook (not the weapon) model appear as missing (while in OA 0.8.5 are shown correctly) when you shoot it! edit: About the light rope Title: Re: 0.8.5 Bugs Post by: Neon_Knight on November 02, 2011, 03:27:56 PM So far, how many bugs pointed in this thread were fixed? And how many are still remaining?
Title: Re: 0.8.5 Bugs Post by: Gig on November 02, 2011, 05:39:06 PM This wiki page
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Bugs tries to act as a "recap" of bugs listed in this and other threads... As you can see, some of them have been fixed, but there are various remaining... PS: Sago or Fromhell, could you please fix the missing crosshair in anaglyph 3D mode, before the next OA release? Thank you! Another important thing before a "final" 0.x version would be to provide the invulnerability powerup stuff. Title: Re: 0.8.5 Bugs Post by: fromhell on November 02, 2011, 06:48:02 PM Appears that fromhell used a model that does not exist in 0.8.5 and I did not notice and therefore did not include it. edit: About the light rope :/ The grapple shader would be broken either way since precaching the grapple doesn't precache the rocket or ligtningbolt. My grapple stuff is in the SVN iirc and it's also coming to 088 Title: Re: 0.8.5 Bugs Post by: Gig on November 03, 2011, 02:01:14 AM Fromhell, are you still sure with your 0.8.8 deadline date (is that the right word? Maybe I've said a stupid thing...)? Wouldn't it be better to estabilish a few things (important but quick enough) to be fixed before it?
Title: Re: 0.8.5 Bugs Post by: Cacatoes on November 04, 2011, 11:23:18 AM Maybe this bug has already been reported
I can't reproduce it at all time. Scenario: - I spec someone for some time - then I press "Enter" to get back to free view - my move keys are temporarily set back to WSAD (while I usually dont use that to move) Title: Re: 0.8.5 Bugs Post by: Gig on November 04, 2011, 12:28:03 PM If you want to add it to the list DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]here (http://([b)...
Title: Re: 0.8.5 Bugs Post by: SooKee on November 11, 2011, 11:36:07 AM To be honest I'm not sure if this should be under "bugs" or "ideas/requests".
When running under Linux, OA outputs its console to the 'standard error stream' (STDERR). Could this be changed to the 'standard output stream' (STDOUT)? Or is there some reason it needs to be the error stream? Also under Windows the console is not output at all. Is it possible to enable the console output to the standard streams (STDOUT|STDERR) just like it does in Linux? A few people have wanted to keep game logs and it is not possible on Windows (except using condump which is not really very easy). Title: Re: 0.8.5 Bugs Post by: WingedPanther on November 11, 2011, 01:35:44 PM On linux, you could probably pipe the stderr to the same stream as stdout (I've seen it done), but the default is to have them go to different locations because you want to be able to locate error messages when debugging.
Title: /callvote timelimit bug Post by: Virus on January 19, 2012, 04:19:49 AM Found a bug:
Players can successfully vote for a ridiculously high timelimit. This ends the running game like voting a timelimt shorter than the game is running. But after that it ends every game before it starts and thus changes map over and over and no play is possible. Title: Re: 0.8.5 Bugs Post by: Gig on January 19, 2012, 12:42:49 PM Found a bug: Players can successfully vote for a ridiculously high timelimit. This ends the running game like voting a timelimt shorter than the game is running. But after that it ends every game before it starts and thus changes map over and over and no play is possible. AFAIK, server admins can set maximum allowed timelimit and fraglimit values (for some unknown reason, idSoftware did not allow to vote for capturelimit at all!), as well as allowing to vote for map_restart, thus making previously voted changes effective. See also: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Servers UPDATE: Sorry, I misread your post (my answer is partly out of context). Now I get the point. I will test it when I can. I imagine a server admin setting g_voteMaxTimelimit, however, should be enough to prevent this from happening to his server. Title: Re: 0.8.5 Bugs Post by: Gig on January 19, 2012, 02:30:53 PM The highest timelimit value that seems to work is 107374. If you set it to 107375 or higher, the match immediately ends.
The match immediately ends also if you enter a number between -1 and -107374. If you enter a number like -107375, the match does not end immediately. I imagine Sago may do something for this, if he wants. Of course, after 0.8.8 release. Absurdely high fraglimit instead, does not seem to cause the match end (at least with my quick test, with noone to frag!), even if very high numbers, like 100000000, will write a different goal value on the screen; it is even possible to set the fraglimit to negative values, e.g. -1. Title: Re: 0.8.5 Bugs Post by: grey matter on January 19, 2012, 02:38:14 PM Excuse me hijacking this thread; will you be maintaining a separate server-side-only branch for fixes like this? This'd allow server admins to apply fixes from the development version without requiring updates/downloads on the client.
Title: Re: 0.8.5 Bugs Post by: sago007 on January 19, 2012, 02:47:09 PM Excuse me hijacking this thread; will you be maintaining a separate server-side-only branch for fixes like this? This'd allow server admins to apply fixes from the development version without requiring updates/downloads on the client. Not for fixes like this that can be fixed by setting a cvar but if problems cannot be fixed that way and the problem resides serverside then it can be fixed.Title: Re: 0.8.5 Bugs Post by: grey matter on January 19, 2012, 02:52:52 PM You'll obviously still need to announce such cvar default changes to the admins, since they won't be magically applied otherwise.
P.S.: What Virus and Gig mentioned sounds more like a bug which should be fixed, regardless of cvar settings for vote limits. Title: Re: 0.8.5 Bugs Post by: Gig on January 19, 2012, 03:31:24 PM I suppose what Sago meant is that this particular bug does not justify to do an unscheduled release, or a specific server fix, considering that server admins can simply use a cvar to prevent the problem. In practice he said that he may make some serverside patches in case of major problems, but in this case... that's not the case. Hotfixes cause fragmentation, let's use them only if really needed. I suppose.
This does not mean that the bug will not be fixed. It will probably be fixed for the release after 0.8.8.... it will be OA 0.9.0/OA3, probably. Anyway it's better if I do not talk in the place of Sago. How to fix this partcular bug? 1) Hard coding any "timelimit" value higher than 107374 automatically revert to 107374? Or to a "round" number, like 100000? And any value lower than 0 automatically revert to 0? This way, one may keep g_voteMaxTimelimit and g_voteMinTimelimit untouched, and change "timelimit" variable only. It would not require to change any "default" value from what quake3 had, and should work with existing configs. 2) Hard coding some g_voteMinTimelimit and g_voteMaxTimelimit limits? (What should happen in case of 0? Servers should be able to have no time limit somehow...) 3) Changing g_voteMaxTimelimit "default" value from 0 to something like 1000? The server admin may change it and allow the game to crash anyway. And it would not be applied automatically to existing configurations. Which one do you suggest? Or a combination of them? NOTE: Gamecode (game logic) fixes will not affect old mods, AFAIK. But I don't know if it would be possible (or advisable!) some fix at engine level (maybe changing default values? That still sounds a partial solution anyway.). PS: We can "suggest" to use a different g_voteMaxTimelimit value in standard server configuration example DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Servers#Server_config_example]here (http://([b) right now, if you wish... Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 21, 2012, 08:58:56 AM I think that this bug ought to be solved in a way or another for the next OA release, else most admins will end up with a serious problem (remember that they are not all crawling the official forums, and they are not expecting that standard variables needs to be fixed in order to avoid their servers being corrupted and unusable). To me, this is clearly an exploit.
The 3rd solution that Gig proposed seems good enough for me, changing the default value of those two cvars should fix the problem. Hard coding could be also nice to permanently fix this problem, but there are a lot of other cvars that can make the game bug if they are set to a bad value, so if one hardcode a security for this cvar, it would be more coherent to also fix those other cvars (or at least plan it in the TODO). For now, I think that just changing the default value should be enough. I really want to stress this point, because, even if I won't be touched by this exploit, leaving it as is can lead to a lot of havoc in the servers, with automated scripts that would callvote a bad timelimit, and this would bring down a lot of servers. Title: Re: 0.8.5 Bugs Post by: sago007 on January 21, 2012, 10:22:58 AM The solution I came to based on the code:
* Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored). * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read. * Changed default g_voteMaxTimelimit to 1000 An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000. I normally advice against infinity time limits. The engine will boot all clients and restart itself if the game takes to long (several days) to prevent internal variables to overflow. On the topic of updating gamecode after a release (the -23 server can use alternative gamecode) is a rather demanding operation on the server admin. But it can be quite useful especially for generating extra log. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 21, 2012, 11:43:15 AM Thank you Sago, I think you've made great decisions, your fix is perfect.
On the topic of updating gamecode after a release (the -23 server can use alternative gamecode) is a rather demanding operation on the server admin. But it can be quite useful especially for generating extra log. Updating can be automated if the updates are centralized, the best being a single url to access the latest head branch of the project. I will gladly make a script for that and release it publicly, and implement it on a server as I have posted here: http://openarena.ws/board/index.php?topic=4420.0 And adding extra logging facilities is a very good idea, I will gladly participate to that if it's implemented! Title: Re: 0.8.5 Bugs Post by: Gig on January 21, 2012, 06:54:51 PM * Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored). * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read. * Changed default g_voteMaxTimelimit to 1000 An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000. Excuse me, I don't understand a thing: the problem with timelimit 0 is due to g_votemaxtimelimit new behavior (like it seems reading "at the letter" the last sentence above) or about timelimit new behavior (like it seems reading all your post)? Timelimit 0 will not work in any case or only in case of voting? I know that you do not like exceptions, but I suggest you to allow to set timelimit 0 (with the exception being allowing 0=infinite, that is >1000). Timelimit 0 always worked as "no time limit" since q3 (and will continue working in old mods, right?), thus the change would seem like "removing a feature" (even if I know that a timelimit of 1000 would be very similar to infinite). I'm not sure I understood your sentence about clients: did you say that timelimits >1000 will continue working, but in that case warning sounds will not be played (they will be played instead with lower timelimits)? Title: Re: 0.8.5 Bugs Post by: sago007 on January 22, 2012, 04:42:14 AM Excuse me, I don't understand a thing: the problem with timelimit 0 is due to g_votemaxtimelimit new behavior (like it seems reading "at the letter" the last sentence above) or about timelimit new behavior (like it seems reading all your post)? Timelimit 0 will not work in any case or only in case of voting? This is not new behavior but is different default behavior. The server admin can allow people to vote for infinite time limit if g_votemaxtimelimit is set to 0 (disabled).I know that you do not like exceptions, but I suggest you to allow to set timelimit 0 (with the exception being allowing 0=infinite, that is >1000). The original point about g_votemaxtimelimit was to stop the cases where a player would go to a server change to a ridiculous map/gametype remove frag/time limit and then hope it took a long time for an admin to discover that the server was unplayable. By forcing a max time limit the server would eventual return to normal within a given time. I'm not sure I understood your sentence about clients: did you say that timelimits >1000 will continue working, but in that case warning sounds will not be played (they will be played instead with lower timelimits)? The client will just not play "1 minute remaining", "5 minutes remaining" or "sudden death" if the timelimit is > 1000 and is hit. Otherwise the client would start the match by saying "sudden death" due to an overflow in the client code.Title: Re: 0.8.5 Bugs Post by: Gig on January 22, 2012, 05:49:05 AM Thank you for answer.
I understand that timelimit knows that 0 means "infinite", but I don't understand why the voting code and g_votemaxtimelimit have to know that 0 means infinite and so is >1000 and thus not allowed. Why can't g_votemaxtimelimit (and the voting procedure itself) just manage 0 as 0 (<1000), letting timelimit decide what do to with that value later? People will hardly understand why 0, a value correctly between g_voteMINtimelimit (0) and g_voteMAXtimelimit (1000) will not work... and working instead if g_votemaxtimelimit is changed to 0. Ps: your note about why having g_votemaxtimelimit <> 0 is good (even if the "auto-fix" you mentioned works only in case of a map rotation script detailed enough to set gametype etc. each time), but the new default should be enough for that. :) Update: Now that I think about it... if it wasn't for this avoiding-infinite-matches, the first two fixes you did may have been enough to fix the immediat-match-end bug... if now server works correctly even with timelimits like 1000000, default max vote limit hay have been keeped as 0. Another question: about the 5min/1min/sudDeath sounds not played if timelimit >1000... 1000 is a hardcoded value or it follows g_maxvotetimelimit? I suppose the first one... Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 22, 2012, 09:12:04 AM if now server works correctly even with timelimits like 1000000, default max vote limit hay have been keeped as 0. No, I agree with Sago about setting a value (that is anyway much too high to be attained in a normal game anyway). Noone wants an infinite game, this is generally a negligence, while having a server that works and is playable is something everyone wants, and having an infinite timelimit is proved to be a very bad practice as Sago said. If the game still allows for timelimit 0 (to support some badly coded mods), then there's really no need to support callvote timelimit 0. Title: Re: 0.8.5 Bugs Post by: Gig on January 23, 2012, 01:50:31 AM Okay.... but read this... I thought about it while sleeping, more or less.
What about changing default setting for g_voteMINtimelimit, too? Setting it to 1.... This way, the ability to vote for 0 or not would be left to it, instead of g_voteMAXtimelimit... and it would be much more logical/intuitive for users, IMHO. Examples: g_votemintimelimit 1 (new default) + g_votemaxtimelimit 1000 (new default) = not possible to vote for 0. g_votemintimelimit 1 (new default) + g_votemaxtimelimit 200 (example, changed by admin) = not possible to vote for 0. g_votemintimelimit 0 (changed by admin) + g_votemaxtimelimit 1000 (new default) = possible to vote for 0. g_votemintimelimit 0 (changed by admin) + g_votemaxtimelimit 0 (changed by admin) = possible to vote for 0. What do you think about this solution? PS: I don't know what the engine does now if an admin erroneously sets g_voteMINtimelimit HIGHER than g_voteMAXtimelimit... Title: Re: 0.8.5 Bugs Post by: sago007 on January 23, 2012, 10:27:54 AM It does not sound more logical to me.
If I wanted to ensure limit the voteable timelimit to 15 minutes+ I would set: g_votemintimelimit 15 g_votemaxtimelimit 0 (disabled) And the timelimit would be limited to [15;Inf[ g_vote(min/max)fraglimit follows the same principle. Title: Re: 0.8.5 Bugs Post by: Gig on January 23, 2012, 04:14:52 PM Well, I said that I was not sure about what the game does in case of min>max! :)
Anyway, this is not necessarily against what I wrote above. We can add one more case to the examples list above: g_votemintimelimit 1 (new default) + g_votemaxtimelimit 0 (changed by admin) = possible to vote for 0. In other words: if at least one of the two variables would be forced by the admin to 0 (while the game would provide defaults different from 0 for each variable, instead), then it would be possible to callvote for 0. In other words: new defaults would discourage infinite matches in two different ways... and if the admin would like to allow 0 anyway, he may just change one of the two variables to 0, according to what other limit (upper/lower) he wants to keep. Do you like it? Title: Re: 0.8.5 Bugs Post by: Gig on January 23, 2012, 04:44:03 PM Wait, I've just made some tests with OpenArena 0.8.8 RC4 (thus, before your changes).
I've seen what the game does: if g_votemintimelimit=0 and g_votemaxtimelimit >0, you cannot vote for 0. if g_votemintimelimit > 0 and g_votemaxtimelimit =0, you can vote for 0. If g_votemintimelimit>g_votemaxtimelimit, you cannot vote at all. Maxlimit already considers 0 as infinite (and is >1, >100, >1000, etc.), while minlimit simply totally ignores 0. Setting g_votemintimelimit to 0 or to 1 seem to not make any difference at all. Sorry Sago, it seems I missed the point previously. I started from the wrong understanding that when you said Quote An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000. was due to some changes in the code (and you tried to explain to me before that is was not a new behavior, but I hadn't catched anyway). I didn't know that g_votemintimelimit 0 was the same than setting it to 1 (and that any mintimelimit value does not prevent you from setting an infinite limit).... and thought that you changed something.Then, right... your fix is good. I just gave you a cake for that. Sorry for having made you waste some time. The only question remaining is about the limit of 1000 over that "x minute warning" is not played by the client... is that an hardcoded limit (as I imagine) or it follows some cvar? PS: Off topic a lot, but just a reminder for the future: I hope OA 0.9.0/OA3 will introduce capturelimit voting (unlike original Q3, now there are more gametypes that use capturelimit than those that use fraglimit -and if you switch from CTF to Domination, you really need to change the capturelimit!-) without the need of using custom votes. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 23, 2012, 09:50:54 PM PS: Off topic a lot, but just a reminder for the future: I hope OA 0.9.0/OA3 will introduce capturelimit voting (unlike original Q3, now there are more gametypes that use capturelimit than those that use fraglimit -and if you switch from CTF to Domination, you really need to change the capturelimit!-) without the need of using custom votes. I support this idea. Or even better: add a simple system of variable substitution in custom callvote file. This way, we could simply make a custom callvote like "seta capturelimit $1; map_restart", and we could also do a lot of other things. Title: Re: 0.8.5 Bugs Post by: Gig on January 24, 2012, 02:00:42 AM Also that custom voting improvement sounds nice (but I don't know how to limit user's range of allowed values, in that case... maybe two more variables that work as boundary for $1? Okay for numeric variables, but for alphanumeric?). It may need some thinking... what about an apposite thread in the "idea pit" section?
But the support for capturelimit voting (possibly creating g_votemincapturelimit and g_votemaxcapturelimit cvars) should be done before it (IMHO it's more urgent), and, if possible, should be available in stock game without the need of admin tweaks and without consuming precious custom votes slots (how many are they? 8?). Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 24, 2012, 03:23:35 AM But the support for capturelimit voting (possibly creating g_votemincapturelimit and g_votemaxcapturelimit cvars) should be done before it (IMHO it's more urgent), and, if possible, should be available in stock game without the need of admin tweaks and without consuming precious custom votes slots (how many are they? 8?). The first 12 ones are shown in the menu if I remember well (there's not yet a support for a scrollbar in this menu), but the voteconf.txt file is limited to 170 lines exactly, any more lines are not read at all. This limit should also be removed if possible. Title: shuffled game / physics Post by: Virus on January 25, 2012, 03:17:12 PM saw this:
) ps37ctf being played / jumping walls is possible as normal on the server ) shuffle voting successful ) ps37ctf restarts / no one can jump on the walls now seems only temporary for the shuffled game Title: Re: 0.8.5 Bugs Post by: Peter Silie on January 25, 2012, 04:02:28 PM afaik ps37ctf needs some special settings on the physics. so this shouldn´t be a bug - just a config prob.
Title: Re: shuffled game / physics Post by: GrosBedo on January 25, 2012, 06:13:17 PM saw this: ) ps37ctf being played / jumping walls is possible as normal on the server ) shuffle voting successful ) ps37ctf restarts / no one can jump on the walls now seems only temporary for the shuffled game Probably the server admin just tweaked manually the gravity and has fixed physics. See if it does the same bug when just doing a map_restart. If that's the case, this is just a normal bug, which should be fixed with g_gravityModifier in the next release. Title: Re: 0.8.5 Bugs Post by: Gig on January 26, 2012, 12:28:11 PM Maybe it's late for 0.8.8, but if most admins tweak that map to give a certain gravity to it to allow to get over a wall, why do not edit the map in a next OA release to make that wall a bit lower or to change its default gravity?
Title: Re: 0.8.5 Bugs Post by: Neon_Knight on January 26, 2012, 12:34:02 PM Because it's a setting which affects every map as equal. So the solution must be provided by the server admins themselves.
BTW, that CPMA mapping guide everyone wants us to follow says that framerate dependant jumps is something to be avoided. Title: Re: shuffled game / physics Post by: Virus on January 26, 2012, 01:52:56 PM saw this: ) ps37ctf being played / jumping walls is possible as normal on the server ) shuffle voting successful ) ps37ctf restarts / no one can jump on the walls now seems only temporary for the shuffled game Probably the server admin just tweaked manually the gravity and has fixed physics. See if it does the same bug when just doing a map_restart. If that's the case, this is just a normal bug, which should be fixed with g_gravityModifier in the next release. tested like this: ) other map was on ) voted ps37ctf / can't jump walls ) voted map_restart / can't jump walls ) later ps37ctf is on as part of the map rotation / can jump walls This shows changed gravity? Code: pul1ctf: ---------------- Also tested on a second server. Here I can jump walls whatever vote I to see the map. Title: Re: 0.8.5 Bugs Post by: grey matter on January 26, 2012, 01:55:18 PM You can set a different value for each map inside the .bsp/.map. Just set a "gravity" key on worldspawn (that's what Gig suggests. It does not affect other maps in any way).
Still it's not a good idea to try to force g_gravity to a certain value as a mapper, (frame-dependant-) physics should be up to the admin to decide. Title: Re: 0.8.5 Bugs Post by: Neon_Knight on January 26, 2012, 02:01:32 PM AFAICT, no map has the gravity setting set among the default OA maps. Not even ps37ctf(2).
Title: Re: 0.8.5 Bugs Post by: Gig on January 26, 2012, 02:36:21 PM I suppose the gravity setting is part of the mapper's taste.
E.g. a mapper may set a lower gravity in a space map... but also making mapsdesiged to emulate 125 fps physics while using accurate physics instead may be a lecit use of it, I suppose. Of course, one may take in account that a server using 125 fps physics in a map with the gravity tweaked to emulate 125 fps physics, too... would make even higher/longer jumps than expected. Title: Re: 0.8.5 Bugs Post by: Gig on January 26, 2012, 04:27:41 PM @Virus: I can imagine that the first server you are referring to is using "accurate" physics with tweaked gravity (pmove_float 1, g_gravity 756), while the second server is using fixed 125 fps physics with default gravity (pmove_float 0, pmove_fixed 1, pmove_msec 8, g_gravity 800 -gravity may simply be omitted-).
The result is more or less the same, but in the first case a map restart -that does not trigger the rotation script- resets the gravity to 800 and you cannot do that jump anymore, while in the second case the gravity is always 800 and so you do not experience the problem. You can try these settings playing locally (pmove changes are immediately effective), and try what happens after you do a map_restart. About the console log you posted: could you please post a little more detailed log? It seems that "Server: g_gravity changed to 800" is done after the end of the ps37ctf match but before the next map loading... but usually it should be done after map loading, to be sure it is keeped. Isn't somewhere in the log a gravity changed to something less than 800? Explaination about the various kinds of physics: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics Map rotation script example that -along with other things- changes gravity: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Configuration_examples/Weapon_rotation#Changing_gravity_and_speed UPDATE (I thought this, but I forgot to write it): Anyway, with 0.8.8, the new g_Gravitymodifier feature will workaround this problem of automatically resetting to default gravity. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 26, 2012, 04:38:30 PM tested like this: ) other map was on ) voted ps37ctf / can't jump walls ) voted map_restart / can't jump walls ) later ps37ctf is on as part of the map rotation / can jump walls This shows changed gravity? Yes, it's a perfect example. When admin try to tweak g_gravity by himself, he has to set it after the map loading, such as: Code: seta maprotation1 "map ps37ctf2; seta g_gravity xxx; seta nextmap vstr maprotation1" So the adjustement of the gravity only takes place in the case of a map rotation, when the variable is called (with vstr), so when you do anything that bypasses the map rotation (such as map_restart, map, shuffle - that calls map_restart btw, and warmup too because at the end of warmup it does a map_restart), you lose the gravity setting because the gravity setting is contained in the map, and reset at the map loading. Of course, one may take in account that a server using 125 fps physics in a map with the gravity tweaked to emulate 125 fps physics, too... would make even higher/longer jumps than expected. Indeed Gig is right, but only if the server enables framerate-dependent physics. With pmove_float, it would be ok for everyone, no way to jump higher. But this would only fix the problem for one map, all the others won't get the benefits, and the servers admins don't want just a few selected maps to have the right 125 physics while most others (like q3 maps) don't. Another solution would be for the game engine to totally ignore the gravity setting contained in the maps, this way, servers admins could set one g_gravity for all maps. But the problem is that some maps set a different gravity, and this is part of the gameplay. Currently, no OA map use a different gravity as Neon_Knight pointed out, but in the past there were, such as Void4, and there are a few third-party maps that use a different gravity too. The best solution is a gravity modifier or a pmove_float behavior modifier (both would have pretty much the same result and application). The gravity modifier has been chosen and implemented by sago007, and I think that it's a perfect solution, because it will work on every map, even third-party maps. Plus it can be tweaked to simulate other physics such as 333 fps-physics. Could be fun too. Title: Re: 0.8.5 Bugs Post by: Gig on January 26, 2012, 05:18:29 PM Yes, gravitymodifier should do the trick. It is a good improvement. Obviously, it will not fix everything under every single situation.
Example 1: We know that "g_gravity 756 @accurate" is very similar to "g_gravity 800 @125fps", but this is thanks to trials by someone, AFAIK, not due to a specific math calculation. In other words: we don't know how to calculate how to simulate 125fps physics (while using accurate physics) for a map designed with a gravity different than 800. And the same will apply to g_gravitymodifier: we can assume that 800:756=1:x, then (756*1)/800, then we can suppose that g_gravitymodifer 0,945 should be the right setting to emulate gravity 800 @125fps physics under accurate physics (I haven't tried yet)... but if the starting gravity is different than 800? Who knows? Example 2: g_gravitymodifier will not change at map_restart, and will be changed at the next step of map rotation script only (if the admin changes it at that step!)... okay. But if you callvote for a map out of the script, you will keep the old gravitymodifier on the new map, until the map rotation script will be triggered. If the gravitymodifer is simply used to emulate 125fps physics on maps designed for gravity 800 (probably, it will be its most common use), it should be allright... but if that was used to do something strange, weird results may happen. E.g. you have a map which has got g_gravity 600; admin sets g_gravitymodifier to 1.333 because he does not like the "low gravity" effect (and the map does not contain fundamental jumps that would not be possible with 800 gravity)... people votes for another map, which has got 800 gravity, and gravitymodifier will remain 1.333, thus emulating 1066 gravity and potentially making that map unplayable. This is not a very probable scenario, but may happen and this is just an example to say that g_gravitymodifier is useful but is not a magic wand for everything. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 27, 2012, 07:30:12 AM @Gig: indeed, someone should do some maths about the physics calculations to make sure that g_gravityModifier should work in any scenario, but I guess it should, since it's a multiplier, and framerate-dependent physics pretty much work the same as a multiplier to the gravity. But rigorous maths should clears this out. Or at least some testing, I'll see if I can do some.
Title: Re: 0.8.5 Bugs Post by: sago007 on January 27, 2012, 10:33:47 AM framerate-dependent physics pretty much work the same as a multiplier to the gravity. But the multiplier varies with g_gravity (and sometimes 91 fps is better than 125 fps). There is a good explanation here: http://www.psycco.de/125fps/UpsetChaps%20Quake3%20Guide%20-%20Why%20Your%20Framerate%20Affects%20Jumping.htm The second graph in the first post is wrong but the second post explains everything. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 27, 2012, 12:59:52 PM Thank's for the link Sago but I know these calculations, but these calculations demonstrate the influence of variating framerate, but not the gravity (or as it is called in this paper, the acceleration).
Theoretically, framerate and gravity are two constants that are dependent on each others. If we multiply one, then the other gets the same multiplier theoretically. This is why I think it should end up the same. If I remember well, the reason why players jump higher with 125 fps-physics is that theoretically it "skips" some frames. Hence, we could say that the concrete effect is to raise the acceleration/gravity. So fixing framerate, but raise acceleration/gravity should do the same result, whatever the gravity is set to (because the framerate-dependent physics are also proportional - I think - to the gravity). Now this is not a formal demonstration so this assumption (gravity and framerate-dependent physics correlation) could be wrong. Title: Re: 0.8.5 Bugs Post by: sago007 on January 27, 2012, 01:15:24 PM In the calculations on the page the gravity is defined as 800. One can change the gravity instead of the framerate in the calculations.
I thing I remember that at g_gravity = 600 you jump higher with maxfps=90 than maxfps=125 because the rounding errors goes the other way. Title: Re: 0.8.5 Bugs Post by: sago007 on January 27, 2012, 04:19:45 PM The first 12 ones are shown in the menu if I remember well (there's not yet a support for a scrollbar in this menu), but the voteconf.txt file is limited to 170 lines exactly, any more lines are not read at all. This limit should also be removed if possible. I have not yet found a good way to communicate a longer list. I do it for maps but that is not without trouble.voteconf should not be limited to 170 lines. It should be limited to 4096 bytes. A number chosen because it should be able to hold 12 entries, also the current trap_-functions are not that effective at reading files and the token-functions needs to work on a single buffer. Remember that an entry might contain an exec-command that are much more effective for larger scripts. The main reason I haven't added custom votes with parameters is because I do not know how to present them properly in the UI. And I believe that they should be presented in the UI. Title: Re: 0.8.5 Bugs Post by: Peter Silie on January 27, 2012, 04:21:28 PM Cmon guys: be creative!
it is not about authors intention, it is about GPL! If he had the idea in mind, that his map should stay as he created it, he had choosen one of those "watch but don´t touch" licences microsoft offers. But he had choosen the GPL. Grab god_ps37ctf and be happy. i just moved the walls 8 units down. no more serverside settings to make this map enjoyable (btw: this version prevents rail campers and has more possibilities ;) ). Just dl, include it and all is fine: http://download.tuxfamily.org/openarena/upload/god_ps37ctf.pk3 btw: no reason to worry: oa_ctf4ish was changed too. :D pps: if you still like ps37ctf you could also change the wall ;) Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 27, 2012, 05:59:36 PM @sago:
About g_gravity, I'll see if I can make some calculations. About voteconf.txt, indead that may be the case (limitations to the number of characters and not the lines), but I'm already using variables and only doing vstr (much more cleaner anyway in a voteconf file that to define everything in the file), but I'm still limited: I'm mainly using it to callvote different gametypes and configs, and I'm currently limited because of the voteconf. Anyway that's better than nothing, but it is still a limitation that prevent creativity unleashing ;) About variables substitution, I understand your point, but I think that custom callvotes do not necessary have to be presented in the UI since they are special functions dedicated to power users (do you know of any new player that may callvote a custom setting? even most power users do not use them yet nor know their existence). So if at least it work in console, it's pretty much perfectly fit the targeted audience and application (advanced options for advanced users). And anyway, if the admin really want it to fit in the GUI, he can still convert its callvote in a version without variables substitions but with more entries. Another argument is that many mods add their own callvote functionalities without making them show in the GUI, but the functionality is here if needed and I think that's all that is needed. Plus, there is a possibility to input a description, so if we get a command such as /callvote custom help <command> that shows the description of the custom vote entry, everything's ok. So, I do understand your point of trying to open the new functionalities to everyone, but I think that trying to fit callvote custom with variable substitution into the GUI is overkill and unnecessary. One thing at a time. And variable substitution would really be a GREAT feature! @Peter Sillie: thank you for editing the map, it indeed fix the problem with this map, but as I pointed out before, it does not solve it for every map. I still support the g_gravityModifier ;) Title: Re: 0.8.5 Bugs Post by: Peter Silie on January 27, 2012, 06:13:22 PM @Peter Sillie: thank you for editing the map, it indeed fix the problem with this map, but as I pointed out before, it does not solve it for every map. I still support the g_gravityModifier ;) As Neon_Knight said before: it is a bad mapping behaviour to make maps depending on a frame rate. There are some reasons to do so (the mapper does not know how his brushes/entities will be used), but usualy brushes as made as in ps37ctf just should be lowered 8 units to make them usable for players. Still have in mind, that FPS125 isn´t the default value on stock q3 - it depends on your hardware. if you made a map, which is just playable on 125 (or 333 which is more obvious), you made a bad map. btw: i don´t know a further oa map which has the same prob as ps37 has. any examples? Title: Re: 0.8.5 Bugs Post by: 7 on January 28, 2012, 01:59:03 AM btw: i don´t know a further oa map which has the same prob as ps37 has. any examples? Well, there is the classical one in oa_dm3: in the the rail gun room, you can take a shortcut to the mega health (and the railgun) at 125 fps. Normally you have to jump onto the lower part of the construction that supports the rail gun, but at 125 fps you can jump straight onto the higher part of the construction and get to the mega health much quicker. I have attached a screen shot to indicate the exact place. Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 28, 2012, 02:53:18 AM As Neon_Knight said before: it is a bad mapping behaviour to make maps depending on a frame rate. There are some reasons to do so (the mapper does not know how his brushes/entities will be used), (...) Exactly, that's the main reason why I say that editing a map is not a longterm solution, because now that the map is edited, maybe there are new tricks that were not possible before, and this is an infinite cycle... The problem is not that maps are not playable, but that tricks are limited, because most tricks are found using 125 fps. There are even more tricks at 333 fps, but one has to keep in mind that 125 fps was the official minimal requirement for defrag competitions, so historically this explains the prevalence of 125fps-physics for tricks. And about other examples, I can cite oasago2 where there are some jumps (like from the shotgun to bridge and shotgun to railgun) that are only possible with >= 125fps-physics. And we can continue with a very long list of examples for nearly every map... Title: Re: 0.8.5 Bugs Post by: Gig on January 28, 2012, 08:45:31 AM Considering that rounding errors change way depending from gravity AND fps (Sago said that with gravity 600 you jump higher @90 fps than @125 fps), using gravitymodifier to emulate 125fps physics would mean to set it lower than 1 in that case. Uhm...
Maybe the only advise we can say to mappers it to design new maps with "accurate" physics in mind? About hidden custom votes... even if not in the menu, I think all possible custom votes should be listed at least in console (maybe the thirteenth line in the list in the menu may simply say "type xxxx in console for complete list"?). But I don't know how to face the problems sago mentioned. Sago, a curiosity: I tested that now timelimit -1 does not immediately end the game anymore (good). But does it act as infinite, as 1, or what? Ps: that timilimit 1000 limit over that "x minute warning" sound is not played anymore by the client, is an hardcoded value or is related with some cvar? Title: Re: 0.8.5 Bugs Post by: GrosBedo on January 28, 2012, 05:58:44 PM @Sago and Gig: About g_gravityModifier, yes I think you're both right. Indeed, the rounding function is not linear, so that g_gravityModifier (which is linear) can't really simulate the rounding error of framerate-dependent physics for every value of g_gravity.
But anyway, that's a nice workaround meanwhile some get the genius idea that could fix it all. And why not implement an artificial rounding error to simulate framerate-dependent physics from accurate physics? I know this may seem to defeat the purpose at first, but in the end, it would move the rounding error from the clients to the server, so that every player will get the very same physics. In the end, it would attain the goal: framerate-independent physics? Title: Re: 0.8.5 Bugs Post by: sago007 on January 29, 2012, 06:38:13 AM And why not implement an artificial rounding error A broken solution could emulate a broken system but is that really what we want?pmove_fixed is still an option that forces consistent rounding errors based on pmove_msec although with risk of frameskips. But does it act as infinite, as 1, or what? It affects as "disabled" (0 = Off) or "infinity" (0 = Infinity) depending on your point of view.On a side note OAX r294 does now allow scripts per map/gametype. So you can now have your disable_ replace_ g_gravity and other variables as you desire and have them processed no matter how you change map. Also note that the g_gravityModfier is also meant as a way to start a low gravity server that works relative to the map and not just a way to break physics again. Title: Re: 0.8.5 Bugs Post by: Gig on January 30, 2012, 04:14:30 PM Sago, I noticed your post here (http://openarena.ws/board/index.php?topic=1945.msg42706#msg42706) about voting fix. I asked you there, but probably it is better to ask you here instead of there.
Do you mean that fix this would fix the light voting feature? In this case, we could restore it as default (instead of the classic voting you reintroduced for 088), and invert the dmflag you created to manually set lightvoting, to manually set standard voting instead. What do you think? If we want to do that inversion, it is better to do it before an official release uses that dmflag in a certain way (to avoid later confusion)... Title: Re: 0.8.5 Bugs Post by: sago007 on February 03, 2012, 09:38:25 AM Sago, I noticed your post here (http://openarena.ws/board/index.php?topic=1945.msg42706#msg42706) about voting fix. I asked you there, but probably it is better to ask you here instead of there. Personally I prefer classic voting. Anyway this have an importance close to 'none' on the importance scale. Title: Re: 0.8.5 Bugs Post by: Gig on February 03, 2012, 05:54:38 PM Does this mean that 088 will use classic voting by default, and it will be possible to use "fixed" (in the meaning of bug-less) light voting using the dmflags? I thought light voting were preferred and you wished to make them default again... anyway, for me it's the same: I was mostly worried about changing default and dmflags behavior in later version may cause confusion... but if you say they will remain this way, I suppose it should be okay.
Anyway, can you confirm me that voting fix you mentioned is about the "famous" bug that was mysterious... and that the fix will be in 088? Title: Re: 0.8.5 Bugs Post by: Virus on February 05, 2012, 07:59:39 AM The solution I came to based on the code: * Changed server logic to support all values of timelimit (calculations can no longer overflow and negative ones are ignored). * Changed client logic to ignore timelimit > 1000 (no 5/1 minutes remaining messages). Protecting the code against overflow would make the code much harder to read. * Changed default g_voteMaxTimelimit to 1000 An annoyance about setting g_voteMaxTimelimit to 1000 is that "callvote timelimit 0" does no longer work because Infinity > 1000. I normally advice against infinity time limits. The engine will boot all clients and restart itself if the game takes to long (several days) to prevent internal variables to overflow. Doesn't the fix against overflow in the check Code:
Code: /* So having g_voteMaxTimelimit = 1000 does block timelimt=0 in the third condition without need as voting timelimt 0 is not evil. Title: Re: 0.8.5 Bugs Post by: Gig on February 09, 2012, 04:48:32 PM Three different things:
1) Sago, did I understood correctly that in 088 lightvoting is fixed but disabled by default? 2) Have you read Virus' post? 3) Do you know what means that "WARNING: Server is not allowed to set pmove_float=1" message that I sometimes find in client's console? Title: Re: 0.8.5 Bugs Post by: grey matter on February 10, 2012, 07:39:57 AM 3) Do you know what means that message that I sometimes find in client's console? Quote WARNING: Server is not allowed to set pmove_float=1 This happens when a cvar has CVAR_SYSTEMINFO in code/game/, but not in another game module (e.g. cgame). You either need to fix this in gamecode or patch CL_SystemInfoChanged() in the engine (while the first one is the correct solution). Title: Re: 0.8.5 Bugs Post by: sago007 on February 11, 2012, 03:47:13 AM Three different things: 1) yes1) Sago, did I understood correctly that in 088 lightvoting is fixed but disabled by default? 2) Have you read Virus' post? 3) Do you know what means that "WARNING: Server is not allowed to set pmove_float=1" message that I sometimes find in client's console? 2) yes 3) As gray matter said it means the cgame you are using does not have a cvar named pmove_float with CVAR_SYSTEMINFO (cgame in 0.8.5 and 0.8.8 has it). This could happen then joining an unpure 0.8.5 or 0.8.8 server (that supports pmove_float) with a 0.8.1 or other client (that does not support pmove_float). Title: Re: 0.8.5 Bugs Post by: Gig on February 11, 2012, 04:32:20 AM Thank you. :) The info in 1) helped me to update DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Special_game_options&action=historysubmit&diff=11755&oldid=11611]here (http://([b).
About 3), I have to do some more tests, now that I know that. It sounds quite strange because none of my OA installations (I have OA installed in various folders, to make tests) is at 0.8.1 level, IIRC (wait, maybe I disabled 085 pk3 in one of those installations while doings some tests with demos compatibility? I don't remember, I have to check that. But I find it unlikely: I would have noticed the 081 red menu in that case), and I don't remember to have sv_pure disabled on any of them. Title: Re: 0.8.5 Bugs Post by: Virus on February 14, 2012, 08:51:12 AM Three things
1) Sometimes I don't see the title of the vote, hence I don't know what it is about. I think this is only with many (16) players (and only if it is not me calling the vote). (http://img200.imagevenue.com/loc24/th_30584_vote_fail_122_24lo.jpg) 2) Server kicking players: Again many players. Now someone calls a shuffle vote (one case I didn't see the title, so maybe restart-vote) and the vote passes. When the vote applies it kicks me: Code:
http://www.urbanterror.info/forums/topic/8272-error-cl-getservercommand-a-reliable-command-was-cycled-out/page__view__findpost__p__161410 3.) zoom: When I use +zoom bound to a key: run in one direction -> press zoom -> additionally/newly press (and keep holding) some other direction key Consequence is that I can't move into the newly pressed direction at all, also if I release the zoom-key. Repressing the new direction-key gets over it without the zoom on. Title: Re: 0.8.5 Bugs Post by: Virus on February 14, 2012, 02:13:33 PM One more:
On WrackDM17 I pushed an enemy, so he fell down alive and I got a frag rewarded for this. At the same time I made the shot, I walked off the layer thus falling down myself too. The rewarded frag came first, next I hit the bottom of the level but I took no damage and survived. Title: Re: 0.8.5 Bugs Post by: RMF on February 17, 2012, 12:10:15 AM There has always been a bug in wrackdm I think. That you just pushed someone else and got a push-frag is probably unrelated.
I don't have the same problem as #3, not that I tried but I'd surely have noticed such an issue before. I zoom and move all the time. Title: Re: 0.8.5 Bugs Post by: Gig on February 17, 2012, 02:00:35 AM About 1), sometimes I noticed that thing, too.. but had no idea about the reason. You said it may be related with the total number of players in the server (happening only with many players, and when you are not the one who calls the vote)... Maybe this info may be useful for Sago to find the problem. It would be nice to test it with 0.8.8, with light voting on (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Dmflags#Light_voting]dmflags 512 (http://([b)) and off (dmflags 0).
|