OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: sago007 on June 22, 2008, 02:56:28 am



Title: Open Arena Expanded Beta 50
Post by: sago007 on June 22, 2008, 02:56:28 am
Open Arena Expanded (OAX) is the non-engine development of Open Arena.

These releases are previews of what to come. Distributed as a mod for easy testing.

Up to Beta 21 known as "Elimination". Old thread here: http://openarena.ws/board/index.php?topic=831.0

Latest files:
Mod: http://files.poulsander.com/~poul19/public_files/eliminationSource/oaxB50.zip
Source: http://files.poulsander.com/~poul19/public_files/eliminationSource/openArenaExpansionB50.tar.bz2

Old versions still available here:
http://files.poulsander.com/~poul19/public_files/eliminationSource/

SVN can be found at Google code:
http://code.google.com/p/oax/

Change logs will be posted as replies but links will always be updated here.


Title: Re: Open Arena Expanded Beta 22
Post by: sago007 on June 22, 2008, 03:00:00 am
New in Beta 22:
Quote
Renamed the mod
Team spawn points in Double Domination (optional)
Log information about Awards, captures, rounds etc. (Not yet in harvester, Obelisk and Last Man Standing)
Removed "Dedicated" option from "Start Server". It caused a nasty freeze when used.
Removed unimplemented "g_voteStrictGametypes"

The log information is inspired by: http://openarena.ws/board/index.php?topic=866.0
and log according to this table (LMS is missing):
Code:
award syntax: Award: #1 #2: S1 gained the S2 award
#1 and S1 are the client number and nick
#2 and S2 are the award types, corresponding to the following table:
Code:

#2 | S2
----------------
 0 | GAUNTLET
 1 | Excellent
 2 | Impressive
 3 | Defense
 4 | Capture
 5 | Assist


CTF syntax: CTF: #1 #2 #3: S1 got the S2 flag! / S1 captured the S2 flag! / The S2 flag has returned! / S1 returned the S2 flag / S1 fragged S2's flag carrier
#1 and S1 are the client number and nick, when there is no client involved #1 = -1
#2 and S2 are the team number and name
#3 is the event number, corresponding to the following table:
Code:

#3 | Event description
----------------------
 0 | Flag is taken
 1 | Flag is captured
 2 | Flag is returned
 3 | Flagcarrier got killed


1FCTF syntax: 1FCTF: #1 #2 #3: S1 got the S2 flag! / S1 captured the flag! / The flag has returned! / S1 fragged S2's flag carrier
#1 and S1 are the client number and nick, when there is no client involved #1 = -1
#2 and S2 are the team number and name
#3 is the event number, corresponding to the following table:
Code:

#3 | Event description
----------------------
 0 | Flag is taken
 1 | Flag is captured
 2 | Flag is returned
 3 | Flagcarrier got killed

HARVESTER syntax: to be determened

OVERLOAD syntax: to be decided

ELIMINATION syntax: ELIMINATION: #1 #2 #3: Round number S1 started! / S2 wins round S1  by eleminating the enemy team! /
 S2 wins round S1 due to more survivors! / S2 wins round S1 due to more health left! / Round S1 was a draw!
#1 and S1 are the round number
#2 and S2 is the winning team or -1 if not interresting.
#3 is the event number, corresponding to the following table:
Code:

#3 | Event description
----------------------
 0 | Round started
 1 | Win by elimination
 2 | Win by survivors
 3 | Win by health
 4 | Draw


CTF_ELIMINATION syntax: CTF_ELIMINATION: #1 #2 #3 #4: S2 got the S3 flag! / S2 captured the S3 flag! /
 The S3 flag has returned! / S2 returned the S3 flag / S2 fragged S3's flag carrier /
 The round has stated, S3 team is attacking! / S3 defended the flag! / S3 eliminated the enemy team!
#1 and S1 are the round number
#2 and S2 are the client number and nick, when there is no client involved #2 = -1
#3 and S3 are the team number and name
#4 is the event number, corresponding to the following table:
Code:

#4 | Event description
----------------------
 0 | Flag is taken
 1 | Flag is captured
 2 | Flag is returned
 3 | Flagcarrier got killed
 4 | Round has stated
 5 | Win by defending
 6 | Win by elimination
 7 | Win by survivors
 8 | Win by health
 9 | Draw


LMS syntax: LMS: #1 #2 #3: Round S1 stated / S2 is the last man standing! / S2 is the last man standing after overtime! /
 S2 survived the round!
#1 and S1 are the round number
#2 and S2 are the client number and nick, when there is no client involved #2 = -1
#3 is the event number, corresponding to the following table:
Code:

#3 | Event description
----------------------
 0 | Round stated
 1 | Last Man Standing
 2 | Last Man Standing after overtime
 3 | Survived the round (but not alone)

DD syntax: DD: #1 #2 #3: S1 took point A for S2! / S1 took point B for S2! / S2 scores!
#1 and S1 are the client number and nick, when there is no client involved #1 = -1
#2 and S2 are the team number and name
#3 is the event number, corresponding to the following table:
Code:

#3 | Event description
----------------------
 0 | Point A is taken
 1 | Point B is taken
 2 | Scores

DOM syntax: DOM: #1 #2: S1 took control of point S2
#1 and S1 are the client number and nick. There is always a client in this gametype.
#2 and S2 are the number and name of the point taken.


Title: Re: Open Arena Expanded Beta 23
Post by: sago007 on July 07, 2008, 11:34:56 am
New in Beta 23:
Quote
Fixed missing Point B (White) in Double Domination
Added function to filter bots in server browser (requires new engine)
Added function to filter private servers in the browser (requires new engine)
Sends names of allowed votes if a wrong command is entered
Removes mines in Elimination, CTF Elimination and LMS between rounds
Now shows if it is a IPv4 or IPv6 server in games browser
Stereo vision
Removed credits (there was none anyway)
Removed Cinematics (the list was almost empty)

Some of these things require the new engine. Filter bots will only work for servers using this mod.


Title: Re: Open Arena Expanded Beta 23
Post by: fromhell on July 07, 2008, 11:49:25 am
Will filter bots make its way into missionpack?


Title: Re: Open Arena Expanded Beta 23
Post by: sago007 on July 07, 2008, 11:55:05 am
Will filter bots make its way into missionpack?
The server will broadcast the number of human players currently playing (not including spectators). But it is the GUI that decides if the it is the number of humans or the number of clients that should be showed. I have not really looked into the missionpack GUI but it should be a simple job.


Title: Re: Open Arena Expanded Beta 24
Post by: sago007 on July 09, 2008, 04:19:42 pm
New in Beta 24:
Quote
Larger buffer to hold all colors in server names (to prevent a new sprintf overflow like 0.7.6)
No more color overwrite in server browser
cvar vote strings are no longer SYSTEMINFO
Removed some CVARs only relevant for Missionpack in baseoa
Removed g_lightningdamage cvar


Title: Re: Open Arena Expanded Beta 24
Post by: Neon_Knight on July 10, 2008, 03:50:29 pm
Great. ^^
I like Q3TA more than Q3A itself.

I have one question. How can I play Harvester/Overload/1FCTF?


Title: Re: Open Arena Expanded Beta 26
Post by: sago007 on August 24, 2008, 09:50:45 am
Well, just to prove that I actually work on some of the bugs.

This solves many of the bugs in the game logic.

Changelog:
Quote
New in Beta 26:
Load flagbase in baseoa in CTF games to stop the null from appearing at the flags.
VMs believes they are baseoa
Fixed LMS not accepting notteam anymore.
follow1 and follow2 no longer causes an infite loop then cycling.
Includes spectators then counting humans
Big fat text in the middle of the screen then a team is dominating in DD

Some missing things:
Cannot see who got the white flag in oneflag in baseoa
Harvester does not work in baseoa
AllRockets gameoption produces 'Weapon out of range' error when playing with bots.


Title: Re: Open Arena Expanded Beta 27
Post by: sago007 on September 03, 2008, 06:35:14 am
And the changelog
Quote
New in Beta 27:
Harvester fixed
You can mine yourself now
Number of skulls is printed in Harvester
Flag status in One Flag Capture is on the screen
oneflag, overload, harvester and dom are now selecteble through the UI

Everything should be ok now (game logic wise) except for the Out of Range bug.

EDIT: The Out of Range bug should have been fixed too. I forgot about it in changelig.


Title: Re: Open Arena Expanded Beta 27
Post by: Neon_Knight on September 03, 2008, 09:34:02 am
Great. ^^
I have adapted my two CTF maps in order to be playable with the missionpack. :)


Title: Re: Open Arena Expanded Beta 28
Post by: sago007 on October 10, 2008, 02:53:34 pm
Changelog:
Quote
New in Beta 28:
Chaingun prediction effect while unlagged
Some model/name changes in missionpack

Just small changes. I am not available for the next week or so, but feel free to post comments anyway.


Title: Re: Open Arena Expanded Beta 28
Post by: fromhell on October 10, 2008, 02:54:18 pm
I am not available for the next week or so
bad news for 0.8.1 :(


Title: Re: Open Arena Expanded Beta 28
Post by: Neon_Knight on November 24, 2008, 09:44:05 am
What about these for Harvester:

Code:
#3 | Event description
----------------------
 0 | Skulls are taken
 1 | Skulls are captured
 2 | Skullcarrier got killed

Harvester syntax: Harvester: #1 #2 #3: S1 got S3 S2 skulls! / S1 captured S3 S2 skulls! / The S2 skull carrier has been killed! / S1 fragged S2's skull carrier
#1 and S1 are the client number and nick, when there is no client involved #1 = -1
#2 and S2 are the team number and name
#3 is the event number, corresponding to the above table.
S3 can be the number of skulls

And these for Overload:

Code:
#3 | Event description
----------------------
 0 | Obelisk is under attack
 1 | Obelisk attacker is fragged
 2 | Obelisk destoyed

Overload syntax: Obelisk: #1 #2 #3: S1 is attacking S2 obelisk! / S2 obelisk aggressor has been fragged! / S2's obelisk has been destroyed!
#1 and S1 are the client number and nick, when there is no client involved #1 = -1
#2 and S2 are the team number and name
#3 is the event number, corresponding to the above table.
S3 could be the number of skulls

I don't know if I understood well. My $0.02.


Title: Re: Open Arena Expanded Beta 29
Post by: sago007 on January 09, 2009, 07:02:00 pm
Beta 29
Changelog:
Code:
Chaingun kill message is no longer the same as the machinegun kill message
bot_minplayers works better but still not perfect.
Starting challenge system programming. Currently there are no challenges, it only counts kills and awards against humans. Therefore it is currently called 'statistics'
I would have made so many cool thing like vote menu, team VOIP, support for more maps and so on. But my idea of implementing a 'Challenge' system there a players work online is recorded turned out to take more work than anticipated.

The Challenge system
Currently the challenge system only records kills and deaths against other humans and awards in human only games. My plan is to also count number of times an air rocket hit, accuracy, spreas, two kills with one shot, suicidal attack and many more. Possible with small medals then a round number is reached like 10 air rocket kills.

I don't know if I should remove it again. There is a risk that people get carried away and focus more on the challenges than the games (ie. playing to defensively to get a sprea). However a player that have a hard time winning anything online might find it rewarding that he can follow his progress and therefore keeps playing online.

It has been used in other games and worked great in Call of Duty 4+5 but not so good in Left 4 Dead.


Title: Re: Open Arena Expanded Beta 29
Post by: Neon_Knight on January 09, 2009, 07:33:33 pm
What about including awards for team efforts? I mean, quantity of flag retrievements, flag carrierings, dom point securing spree, (also dom point capturings) skull scoring, etc... That can make players spend a little bit more of teamplay.


Title: Re: Open Arena Expanded Beta 30
Post by: sago007 on January 17, 2009, 03:19:15 pm
Beta 30
Changelog:
Code:
Bots now attack the Obelisk in Overload
Bots should now acknowlegde the gametype property of items (not tested)
If g_awardPushing is enabled players will get frags for killing with a mover (be aware that this makes it possible to be noted for a teamkill even if friendly fire is off)
Changed message for teamkill from "you fragged <TARGET>" to "you fragged ^1TEAMMATE^7 <TARGET>"
Telefrags and crushing are now in Stats
Team only voice chat (cg_voipTeamOnly) enabled by default. While this function is enabled any value the player assign to "cl_voipSendTarget" will be overwritten when a player joins or leaves the team.
Crosshairs will now change to white if a colored crosshair is choosen and for some reason the server does not support it.

VOIP teamspeak possible being the biggest news.
Crushing is mainly targeted q3tourney6ish with its player triggered trap.
While playing with bots and enjoying killing them with the trap I noticed that the game made it appear that I scored points for killing a teammate. I can imagine all sorts of disasters if the game make people think that killing allies is a good idea.


Title: Re: Open Arena Expanded Beta 30
Post by: Neon_Knight on January 17, 2009, 04:10:50 pm
Great, downloading. ^^

What about the voting menu? You've said that's one of the things you were working.


Title: Re: Open Arena Expanded Beta 30
Post by: sago007 on January 17, 2009, 04:37:51 pm
You've said that's one of the things you were working.
It is currently only on the planning stage. I am considering the best way to tell the client what maps the server has.


Title: Re: Open Arena Expanded Beta 30
Post by: Neon_Knight on January 17, 2009, 04:40:14 pm
Maybe with some maplists.lst file the server should make with mapnames, just like Q2?


Title: Re: Open Arena Expanded Beta 31
Post by: sago007 on January 24, 2009, 05:50:17 pm
Beta 31 is up.
Changelog:
Code:
* Vote system now a lot more robust. Especially the kick functions are now more likely to kick the correct player
* Vote menu for calling votes - does not yet support Kick and Map functions.
* Clamp on cg_errorDecay as suggested by jessicaRA
* New ui_demo2.c by jessicaRA
* From ioquake3 svn-1492: fix overflow in CG_ParseTeamInfo
* From ioquake3 svn-1494: fix potential segfault (found by DerSaidin in xreal)
* From ioquake3 svn-1493: security fix: prevent command injection via callvote
* Mouse wheel works in mods menu
Don't worry about map and kick in vote menu it will come.

I'll try to upload a screenshot showing the Call Vote menu.

EDIT:
And guess who has just found a bug just minutes after release. (me). "Call Vote" is not grayed when g_allowVote is 0, making the client think that he can call a vote.


Title: Re: Open Arena Expanded Beta 31
Post by: sago007 on January 24, 2009, 05:56:06 pm
Screenshot:
(http://brie.ostenfeld.dk/~poul19/public_files/callvote_gametype.jpg)
With:
g_voteGametypes "/0/4/8/9/10/11/"
g_voteNames "/map_restart/nextmap/map/g_gametype/kick/clientkick/g_doWarmup/timelimit/fraglimit/"
g_allowVote "1"


Title: Re: Open Arena Expanded Beta 31
Post by: Neon_Knight on January 24, 2009, 06:20:47 pm
AWESOME!!!
You rock sago!!! ^^

For me... OA is complete. Only to pulish what is already done. ;D


Title: Re: Open Arena Expanded Beta 31
Post by: Neon_Knight on January 25, 2009, 06:06:42 am
Uhm... I have a sugestion for next beta. ^_^º

Could you put grapple between (or at the left side of) gauntlet and machinegun in weapon order and/or make it not being selectable with prev/nextweapon, if it's possible?


Title: Re: Open Arena Expanded Beta 31
Post by: sago007 on January 25, 2009, 08:00:15 pm
Could you put grapple between (or at the left side of) gauntlet and machinegun in weapon order and/or make it not being selectable with prev/nextweapon, if it's possible?
Sounds like a good idea... maybe add keybind for gauntlet in options menu. Are there any maps that have the gauntlet?


Title: Re: Open Arena Expanded Beta 31
Post by: Neon_Knight on January 25, 2009, 08:08:29 pm
Apart of some third party maps, my am_mckinleyish (http://openarena.ws/board/index.php?topic=2311.0) gives grapple to every player which spawns in the map. ;D

I'll start redoing the map from scratch tomorrow, since it's damn small. :/


Title: Re: Open Arena Expanded Beta 32
Post by: sago007 on January 26, 2009, 08:35:24 am
Beta 32 is up. Time for a short break.

Changelog:
Code:
* Grapple can be bound in option menu
* Grapple is now placed before gauntlet
* Grapple will never be selected then autoswitching from a weapon because you ran out of ammo
* You can get "No ammo" even if you have the grapple
* Client side cvar "cg_cyclegrapple" to tell if Grapple should be part of the weapon cycle. Default is 1 since there are no default key.
* Allowed maps for voting is now read from votemaps.cfg if it exists.
* Call Vote is grayed if disabled on the server
* Call Vote Kick implemented (uses clientkick to kick players)
* Server side cvar "elimination_grapple" added. Allows grapple in elimination gametypes.


Title: Re: Open Arena Expanded Beta 32
Post by: Neon_Knight on January 26, 2009, 09:15:12 am
This topic should be stickied. This should be tested like the new binaries as well.

Thank you Sago. :)


Title: Re: Open Arena Expanded Beta 32
Post by: pulchr on January 26, 2009, 09:35:39 am
well done sago

truly appreciated


Title: Re: Open Arena Expanded Beta 32
Post by: Neon_Knight on January 26, 2009, 09:48:50 am
To anyone who is interested, could it be possible to have a test server for OAE?

It could be great, since we have already a beta maps server, to have one for these, since it's as equal as important to the project. That should help sago and others who are working on it to improve what's already done.

Also, I'd like to say that I have two maps for Single Domination testing: am_lavaarena (http://openarena.ws/board/index.php?topic=2170.0) and hydronex2 (http://openarena.ws/board/index.php?topic=2629.msg20880#msg20880). Both have three control points.

EDIT: I almost forgot... Noob Sauce and Snickersnack were working on a Grapple model, so you can follow their work here (http://openarena.ws/board/index.php?topic=2673.0).


Title: Re: Open Arena Expanded Beta 32
Post by: Cacatoes on January 27, 2009, 04:06:23 am
To anyone who is interested, could it be possible to have a test server for OAE?

Huhu, I'm running another OA server on the same machine, actually beta31 but I'm updating ... it's ROFL Chatroom ( 88.160.192.237:27961 ) ; it also uses latest SVN builds (and it's listed by dpmaster, so I confirm the bug got fixed)


Title: Re: Open Arena Expanded Beta 32
Post by: Neon_Knight on February 04, 2009, 03:10:44 pm
I have an idea for Challenge feature:
What about the inclusion of achievements? Most of today's games have these awards. I also have thought on the following: (excuse my lack of creativity for names)

Quote
Offline achievements:

Nice start: Beating Tier 1
Not so bad: Beating Tier 2
Space cadet: Beating Tier 3
Crashed on Sago: Beating Tier 4
Muddy waters: Beating Tier 5
Angels get fire: Beating Tier 6
Master down!: Defeating Final Boss

Experienced: Beating Tier 1 on Nightmare
Getting out: Beating Tier 2 on Nightmare
Space veteran: Beating Tier 3 on Nightmare
Entering the castle: Beating Tier 4 on Nightmare
Red waters: Beating Tier 5 on Nightmare
Angels get rosted: Beating Tier 6 on Nightmare
The Master Is No More: Beating Tier 7 on Nightmare

Mastering: Winning a match in every gametype at Instant Action

These two will be unlocked when player has played on all the official maps at least once:
I Play Alone: Play 100 complete Instant Action matches ONLY on official maps
I don't have a life: Play 1000 complete Instant Action matches ONLY on official maps
-------------------------------------------------------------
Online achievements:

World knowledge: Winning a match in every gametype

These two will be unlocked when player has played on all the official maps at least once:
I Play With Others: Play 100 complete online matches ONLY on official maps
I share my life: Play 1000 complete online matches ONLY on official maps

Blood everywhere!: Winning a match in every official map on Free For All
Good guy: Winning a match in every official map on Team Deathmatch
Head to head: Winning a match in every official map on Tournament
My collection of flags: Winning a match in every official map on CTF
Fake piece flag: Winning a match in every official map on One Flag CTF
Skullhead!: Winning a match in every official map on Harvester
Destroyer: Winning a match in every official map on Overload
Seek & destroy!: Winning a match in every official map on Elimination
Kill & Run!: Winning a match in every official map on CTF Elimination
This area is mine!: Winning a match in every official map on Double Domination
Dominator!: Winning a match in every official map on Domination

Pummeler: Having 100 frags with Gauntlet
My little BIG gun: Having 100 frags with Machinegun
BANG! BANG!: Having 100 frags with Shotgun
Nice exploding balls: Having 100 frags with Grenade Launcher
Launcher: Having 100 frags with Rocket Launcher
Little nice blue balls: Having 100 frags with Plasma Gun
Eagle Eye: Having 100 frags with Railgun
Electroshocker!: Having 100 frags with Lightning Gun
POOFER!: Having 100 frags with BFG
Pinner Up: Having 100 frags with Nailgun
Like Gruyere Cheese: Having 100 frags with Chaingun
Spidy ones: Having 100 frags with Prox Launcher mines

Retriever: Having 100 flag returns at CTF
You won't steal my flag!: Having 100 flag carrier kills at CTF
That flag is mine!: Having 100 flag carrier kills at One Flag CTF
You get what you Harvest: Having 100 kills at Harvester, which ended on points for your team
Skull retriever: Having 100 skull points by delivering skulls to enemy base at Harvester
Your worst perdition: Having 100 points by fragging enemy crystal on Overload
Worst nightmare: Having 100 points by frags on Elimination and CTF Elimination
Flag nightmare: Having 100 points by flag caps on CTF Elimination
Area controller: Having 100 points by point captures on Double Domination
Do not pass: Having 1000 points by point captures on Domination

Serial Killer: Have 100 Excellent awards
Where Eye Is, Bullet Is Too: Have 100 Impressive awards
Hand-To-Hand: Have 100 Humilliation awards
Almost Perfect: Have 100 Accuracy awards
Untouchable: Have 100 Perfect awards
The Flag Is Mine: Have 100 Capture awards
I Help My Team: Have 100 Assist awards
You Won't: Have 100 Defense awards
I don't thought on others, if someone like to help with names or changing/deleting awards, is welcome to do that.

EDIT: Another one: what about a GUI before connecting a passworded server which asks for password, overwriting password cvar and reset it once the player leaves the server to blank? Can be better that than writing manually at the console "password lalala".


Title: Re: Open Arena Expanded Beta 32
Post by: sago007 on February 05, 2009, 06:24:47 am
What about the inclusion of achievements? Most of today's games have these awards.
That is my idea. But apart from the obvious I would also collect more exotic challenges like: Air kills, captures for undermanned team, winning with frags mostly from top of the scoreboard.

I think I'll upload Beta 33 later today. It will have password support, a crash fix for when gametype-flags was used on bot roams, removed gametype flag "ctfelimination" (uses "ctf" now).

Map voting is a bigger problem than expected and it is unlikely that it will make it in time for 0.8.2


Title: Re: Open Arena Expanded Beta 32
Post by: Neon_Knight on February 05, 2009, 06:50:41 am
:/

What's the bigger problem with MV?


Title: Re: Open Arena Expanded Beta 32
Post by: sago007 on February 05, 2009, 07:27:31 am
What's the bigger problem with MV?
The server might have thousands of allowed maps. Transfering all of the map names to all client even if they don't want to vote can put pressure on the server. The solution to that is to get map names as they are needed but that gives a problem since game, cgame and q3_ui are all separate and q3_ui can only talk indirectly with the server through cgame. In addition there are no current framework in the code for triggering UI events from cgame that will need to be created. The UI can be set to constantly pull from cgame but that can (and occasionally will) trigger an event overflow in the engine.

I believe the 'correct' way to solve the problem is to create a way for cgame to notify q3_ui. I have tried it with CVARs but the cvar update function did not perform as expected. Every touch to the event system makes the engine more likely to stop with a "too many events" error or something like that.

The UI behave differently than game and cgame.

EDIT:
Ok, I have looked a little more into it and I might be able to send commands as console commands.


Title: Re: Open Arena Expanded Beta 33
Post by: sago007 on February 05, 2009, 05:47:02 pm
Beta 33 is up.

Changelog:
Code:
* Call Vote Map implemented
* Fixed infinity loop bug caused by bot_roams with gametype flags
* Gametype flag "ctfelimination" removed, replaced by "ctf"
* Password promt when joining servers
* g_humanplayers is no longer a SERVERINFO CVAR
* g_lms_mode is now a SERVERINFO CVAR
* Changed tab order in some vote menues
* If gametype are changed by a vote then the map will now automatically restart and reassign nextmap.
* You no longer get grauntlet award against bots in stats
* Stats no longer recorded during warmup
* Hook are no longer selected by default on spawn
* Flags are used for domination points instead of using Point A from DD

I did get map voting to work although I have to disable pausing while the menu is showing but that would be the case anyway when playing online.


Title: Re: Open Arena Expanded Beta 33
Post by: epicgoo on February 05, 2009, 07:44:02 pm
omg stop coding...
NICE


Title: Re: Open Arena Expanded Beta 33
Post by: Neon_Knight on February 05, 2009, 08:02:59 pm
Sago, you're my idol...
I've baptized the planet where half of the SP happens with your nick already. ;D


Title: Re: Open Arena Expanded Beta 33
Post by: fufinha on February 07, 2009, 09:46:54 am
Is there a page on the wiki that lists all the extra cvars?

I remember seeing vote stuff before but can't find it. Is it possible to vote options? For example in noghost you can do something like g_allowvote_* where * is the option.

I can then do g_allowvote_vstr and have things like..

set q3dm6 ; set nextmap q3dm7;

.. then someone calling a vote can do /callvote vstr q3dm6 without breaking the rotation and/or have other stuff set with the vstr



Title: Re: Open Arena Expanded Beta 33
Post by: Neon_Knight on February 07, 2009, 06:30:03 pm
I have ideas for bot ordering:

One Flag CTF:
- Get the flag (Attack)
- Escort our flag carrier
- Kill the enemy flag carrier
- Defend the base
- Camp
- Report

Harvester:
- Collect some skulls
- Kill some enemies
- Defend the base
- Camp
- Report

Overload:
- Attack the enemy generator
- Defend the base
- Camp
- Report

That way, two more orders can be introduced on normal CTF:
- Kill the enemy flag carrier
- Escort our flag carrier


Title: Re: Open Arena Expanded Beta 34
Post by: sago007 on February 08, 2009, 06:44:42 pm
Beta 34 is up.

Changelog:
Code:
* Can now handle 20*1024 charecters in the *.arena file list. Significantly increases the number of maps supported.
* No maps are ignored if number of single player maps are not divideble by 4.
* CVAR_SYSTEMINFO is now set in cgame to allow game to override them
* Powerups recorded in stats
* Support for custom votes with a votecustom.cfg (I shall post an example)

Most noteworthy is that the game is no longer limited to a little over 100 maps.

A votecustom.cfg file can look like this:
Code:
{
votecommand "lms_custom"
displayname "Change to Last Man Standing on dm4ish?"
command "g_gametype 10 ; g_instantgib 0; map dm4ish"
}
{
votecommand "ffa_custom"
displayname "Change to instantgib FFA on dm6ish?"
command "g_gametype 0 ; g_instantgib 2 ; map dm6ish"
}

votecommand is the command the client must execute. It may not contain spaces!
displayname is the name displayed while the vote is going on
command is the string that will be executed if the vote passws.

The above can be called using "/callvote custom ffa_custom"
Typing "/callvote custom" will list the first 12 custom commands.
The menu will show the first 12 entries.


Title: Re: Open Arena Expanded Beta 34
Post by: pulchr on February 08, 2009, 06:56:03 pm
good work! just a question or two - is it possible to show regular votes to give more info.

like if i do a "/callvote map thisisthenewmap" the game will show something like: "pulchr called a vote to change map to thisisthenewmap, press F1 for yes, F2 for no".

would also be nice for the kick vote "/callvote kick annoyingplayer teamkiller" to be shown like "pulchr called a vote to kick annoyingplayer, reason: teamkiller".

just ideas :P


Title: Re: Open Arena Expanded Beta 34
Post by: Neon_Knight on February 09, 2009, 03:00:11 pm
I have another:

- Independant limits for DOM, Double DOM, Harvester, Overload and (CTF) Elimination/Last Man Standing. Reason: These gametypes play very differently each other and some GTs get more fast to score than others. An example is CTF and Harvester. You can score 8 skulls on Harvester faster than you capture 8 flags on CTF. On DOM/DDOM case, since DOM scores a point per sec, depending on the controlpoints you have, you can score in seconds the amount of points needed for DDOM. (For example 8, it's easy to score 8 points in DOM in less than a minute, something which makes )

The ideal (I guess) limits for gametypes should be:
FFA/DM: 20 frags, 15 minutes.
TDM: 50 frags, 15 minutes.
1on1/Tourney: 20 frags, 10 minutes.
CTF: 8 flags, 15 minutes.
1FCTF: 5 flags, 15 minutes.
Harvester: 20 skulls, 15 minutes.
Overload: 3 points, 15 minutes.
(CTF) Elimination: 10 rounds/10 wins, 20 minutes total. (Something like 3 minutes or 3:30 per round)
Last Man Standing: 1 round/win, no time limit.
Double DOM: 3 points, 15 minutes.
DOM: 100 points, 15 minutes.


Title: Re: Open Arena Expanded Beta 33
Post by: fufinha on February 15, 2009, 08:43:58 pm
Is there a page on the wiki that lists all the extra cvars?

I remember seeing vote stuff before but can't find it. Is it possible to vote options? For example in noghost you can do something like g_allowvote_* where * is the option.

I can then do g_allowvote_vstr and have things like..

set q3dm6 ; set nextmap q3dm7;

.. then someone calling a vote can do /callvote vstr q3dm6 without breaking the rotation and/or have other stuff set with the vstr



Yo hoo..,. hey sago..  is there an oa cvar list for server admins?




Title: Re: Open Arena Expanded Beta 33
Post by: sago007 on February 16, 2009, 08:48:17 am
Yo hoo..,. hey sago..  is there an oa cvar list for server admins?
There are not that many new ones but the most common are located in example server config on the wiki.


Title: Re: Open Arena Expanded Beta 33
Post by: fufinha on February 16, 2009, 10:11:31 am
Thank you. I was going to create one if none exists already.

I'll do a cvarlist and should be able to catch them that way


Title: Re: Open Arena Expanded Beta 34
Post by: SharpestTool on February 19, 2009, 09:28:52 pm
sago, is OAX gonna become part of the game release?


Title: Re: Open Arena Expanded Beta 34
Post by: Neon_Knight on February 20, 2009, 04:56:32 am
Ehrm...

These releases are previews of what to come. Distributed as a mod for easy testing.

(http://lafuerzadelmal.foroes.net/users/48/81/81/smiles/763971.png)


Title: Re: Open Arena Expanded Beta 34
Post by: SharpestTool on February 20, 2009, 11:15:28 am
ooops....yeah i posted that from my phone last night in bed...was too lazy to get my ass up to read the whole thing on the comp...

my bad...thanks for the info though neon




Title: Re: Open Arena Expanded Beta 35
Post by: sago007 on March 13, 2009, 04:17:11 pm
Beta 35 is up.

Just small changes.

Changelog:
Code:
* You can now command bots in One Flag, Harvester, Obelisk and Domination.
* Last Man Standing will no longer count connecting players as survivors.
* Quad will no longer spawn if q_quadfactor <= 1.0
* Added CVAR 'g_logfile2stdout'. If set to 1 on a dedicated server a copy of the log will also be sent to standard out. Removes debug information from stdout. Must be considered experimental. Garbage data might occour.
* Changed the way the game picks the spawn point to prevent maps with few spawnpoints that are marked with nobot or nohuman from hanging the game.
* Midair suicide while g_awardpushing is enabled will result in a point to the attacker.
* cl_guid is now written to the log file for all human players joining


Title: Re: Open Arena Expanded Beta 35
Post by: Neon_Knight on March 13, 2009, 05:26:04 pm
Awesome. ^^


Title: Re: Open Arena Expanded Beta 35
Post by: SharpestTool on March 14, 2009, 12:19:30 am
That midair suicide thing is a great idea...sews up an exploit from killbinding stat whores....

Too bad not too many people use g_awardpushing 1...

I think its the coolest feature...especially when g_friendlyfire is 1 and you're playing with your friends on your own team and got teamspeak going...OOOOOOOOPPPPPPSSSSSSSSSSSS.... lol


Title: Re: Open Arena Expanded Beta 35
Post by: Udi on March 14, 2009, 09:07:53 am
Quote from: sago007
* Midair suicide while g_awardpushing is enabled will result in a point to the attacker.

Why that? Do you have applied the scoring system of Nexuiz, where you get a frag when your enemy falls into void because of you? If not, then why gets the attacker a point if he hits you midair, but after that you kill yourself? Like I make a mistake, jump into void, nobody is around, but someone hits me with machinegun while I fall, after that I kill myself and bam! He scores a point undeserved. I know some players can rail me while I'm falling, some pro players can even rocket me, and suicide takes away these frags. But I think there will be more frags given undeserved than taken away rightfully.


Title: Re: Open Arena Expanded Beta 35
Post by: Neon_Knight on March 14, 2009, 09:42:44 am
Making frags are like scoring goals on soccer or american football: you don't deserve them, you just make them. :D


Title: Re: Open Arena Expanded Beta 35
Post by: Udi on March 14, 2009, 10:38:56 am
Making frags are like scoring goals on soccer [...]: you don't deserve them, you just make them. :D

I'm really sad to hear that from a guy living in Argentina :(.


Title: Re: Open Arena Expanded Beta 35
Post by: sago007 on March 14, 2009, 10:40:10 am
Quote from: sago007
* Midair suicide while g_awardpushing is enabled will result in a point to the attacker.
Like I make a mistake, jump into void, nobody is around, but someone hits me with machinegun while I fall, after that I kill myself and bam! He scores a point undeserved.
It is a point but not the main reason g_awardpushing is disabled in OA by default. Sure the attacker was given a free point instead of you loosing one but that just means fewer negative points and that is a thing that you most likely wanted by turning g_awardpushing on in the first place.

The main reason for being disabled by default is that people can start trying to push rather than kill and that can be considered a gameplay change. 


Title: Re: Open Arena Expanded Beta 35
Post by: 0kelvin on March 14, 2009, 10:57:25 am
openarena


Title: Re: Open Arena Expanded Beta 35
Post by: Neon_Knight on March 14, 2009, 11:02:07 am
Making frags are like scoring goals on soccer [...]: you don't deserve them, you just make them. :D

I'm really sad to hear that from a guy living in Argentina :(.
It was a sarcasm ::)
That "living in Argentina" part was unneccesary BTW...


Title: Re: Open Arena Expanded Beta 35
Post by: Udi on March 14, 2009, 11:41:28 am
That "living in Argentina" part was unneccesary BTW...

I didn't mean it in an offending way, but I was pointing at the high place Argentina has in FIFA World Rankings (http://en.wikipedia.org/wiki/FIFA_World_Rankings).


Title: Re: Open Arena Expanded Beta 35
Post by: Neon_Knight on March 15, 2009, 12:18:24 pm
Ahhhhhhh, sorry, I was thinking on another thing.
My mistake. ^_^º

And yes, I like to watch soccer, but I'm very bad at playing it, lol.

BTW, OnTopic. Sago, I tried to test this with the new SP:

Code:
* Can now handle 20*1024 charecters in the *.arena file list. Significantly increases the number of maps supported.
And it didn't worked. So I had to keep the SP maps on arenas.txt and the other maps under morearenas.arena U_U


Title: Re: Open Arena Expanded Beta 35
Post by: sago007 on March 15, 2009, 01:46:07 pm
And it didn't worked. So I had to keep the SP maps on arenas.txt and the other maps under morearenas.arena U_U
The total amount of charecters allowed are now 20*1024 but there is still a limit of 4096 bytes per file. If I allowed arenas.txt to be bigger it would be a problem for mods that has the limit but still needs to read the arena.txt file.


Title: Re: Open Arena Expanded Beta 35
Post by: SharpestTool on March 15, 2009, 06:19:15 pm
Quote from: sago007
* Midair suicide while g_awardpushing is enabled will result in a point to the attacker.
If not, then why gets the attacker a point if he hits you midair, but after that you kill yourself? Like I make a mistake, jump into void, nobody is around, but someone hits me with machinegun while I fall, after that I kill myself and bam! He scores a point undeserved.

With g_awardpushing 0
You fall into void, he shoots you
Him: 0
You: -1

With g_awardpushing 0
You fall into void, he shoots you, you /kill
Him: 0
You: -1

With g_awardpushing 1
You fall into void, he shoots you
Him: +1
You: 0

With g_awardpushing 1
You fall into void, he shoots you, you /kill
Him: +1
You: -1

With g_awardpushing 1, the point is going to him regardless.....so dont cost yourself one.


Title: Re: Open Arena Expanded Beta 35
Post by: sago007 on March 15, 2009, 06:38:00 pm
With g_awardpushing 1
You fall into void, he shoots you, you /kill
Him: +1
You: -1
The way it is implemented in Beta 35 is like this:

With g_awardpushing 1
You fall into void, he shoots you, you /kill
Him: +1
You: 0

I consider using kill while falling to the void or burning in lava to be perfectly acceptable as death is unavoidable anyway. On a lot of OA maps you can fall for a long time before getting killed making a /kill very attractive or in team games even necessary.  If you /kill fast enough he cannot get a point unless it was him who sent you flying.


Title: Re: Open Arena Expanded Beta 35
Post by: SharpestTool on March 16, 2009, 03:03:09 am
guess i misread it originally then lol

i knew i was missing something :(



Title: g_awardpushing
Post by: zed on March 25, 2009, 12:48:51 pm
Quote from: sago007
With g_awardpushing 1
He shoots you, you fall into void
Him: +1
You: 0

Is there a timeout for pushing? What about he hits me and 1 minute later I fall into the void? Is it still his point or my suicide? Ideally, a shot should only count as a push if it is ultimatively responsible for a player falling into the void. This is probably difficult to calculate (although one could use bot code to check whether an ideal player could have reached another platform).

BTW: Is pushing an award (like gauntlet, impressive, ...) that needs an icon? hehe
(http://img166.imageshack.us/img166/5392/awardpushing.png)



Title: Re: g_awardpushing
Post by: sago007 on March 25, 2009, 06:29:16 pm
Is there a timeout for pushing?
In 0.8.1 there is a 3 (or 4, I don't remember) seconds timeout. In Beta 35 this has been reduced to 200 miliseconds but only time while safely on the ground is counted.

I considered (and still considering) only counting a push if a certain amount of force was inflicted but on some maps you can actually push a player rather far with rapid fire weapons. If you enable q_awardpushing (and it will be disabled by default) it is most likely to limit the amount of negative scores and in that case you would rather give two cheap kills than deny one actual kill.


Title: Re: Open Arena Expanded Beta 35
Post by: pulchr on March 26, 2009, 01:25:57 am
ctf4ish is one map that comes to mind when thinking about it. using the machinegun to push players jumping on the pads are very effective :)


Title: Re: Open Arena Expanded Beta 36
Post by: sago007 on April 25, 2009, 01:45:02 pm
Beta 36 is up.

Changelog:
Quote
New in Beta 36:
* Callvote map menu now responds the first time it is activated
* pmove_float added. Makes the physics framerate independent but cost up to 8 times as much network traffic (worst case, normally only a few percent). Mostly for LAN gaming. Note that you must reduce g_gravity to ~756 to get 125 fps gravity.
* Fixed vote exploit (some bugs still remain, needs rewrite)
* Fixed a bug that allowed a client to call more than 3 votes in a single game.
* cg_oldRail now defaults to 0
* Added restore system based on guid. You no longer loose scores when changing team, spectating or leave+rejoin
* Chainging team or leaving the game now counts as a suicide to prevent misuse of the restore system. In Team Deathmatch the team will be compensated so they don't loose points by loosing a player to the other team.
* You cannot ban localhost anymore (the system needs rewrite)
* g_elimination cvar added (like g_instantgib and g_rockets, but full elimination arsenal, health and damage rules)
My main reason to start again was that I figured out the problem with the callvote map menu.

The biggest news is the restore system, that allows you to change team or go spectating or even leave the game and only loose 1 point (0 if you are already dead). The game only remembers the last 32 players so you can be unlucky that it forgets you but it is still better than nothing.


Title: Re: Open Arena Expanded Beta 36
Post by: pulchr on April 25, 2009, 03:52:10 pm
great work as always sago!

i don't know if this has been fixed in the these betas but in the server browser the different game modes doesn't filter servers correctly. or i've seriously misunderstood :P

well, if i pick harvester for example i get lots of servers that doesn't play harvest, same for overload, one flag capture and elimination. huh? :)


Title: Re: Open Arena Expanded Beta 36
Post by: sago007 on April 26, 2009, 01:19:44 pm
well, if i pick harvester for example i get lots of servers that doesn't play harvest, same for overload, one flag capture and elimination. huh? :)
I have noticed it but have forgotten it every time I sat with the code. Will fix it soon. Gametypes affected: One Flag, Obelisk, Harvester and Domination.


Title: Re: Open Arena Expanded Beta 37
Post by: sago007 on April 26, 2009, 06:57:54 pm
Beta 37 is up with the promised change. Some other UI improvements made it as well.

Changelog:
Quote
New in Beta 37:
* g_humanplayers might make fewer mistakes now
* Gametype filter now also works for One Flag, Obelisk, Harvester and Domination
* First Connect screen reminds new players of some important settings
* bot_nochat >= 2 will now stop all bot chat
* Added "Optimize for LAN" to "start server"
* Added "Physics" to "start server"
* Added "Oneway capture" to "start server" for the CTF Elimination gametype
* Added comments to pure and All Rockets in "start server"
* Fixed LMS mode bug in "start server"


Title: Re: Open Arena Expanded Beta 37
Post by: Neon_Knight on April 27, 2009, 09:01:52 am
The first connect screen is very convenient. I'm wondering if it's cfg dependant, for example, if you delete your q3config.cfg it appears again or if you keep your old config makes it to not appear after all.

Great work as always, sago. ^^


Title: Re: Open Arena Expanded Beta 37
Post by: sago007 on April 27, 2009, 09:14:08 am
The first connect screen is very convenient. I'm wondering if it's cfg dependant
It uses the CVAR ui_setupchecked (inspired by ui_cdkeychecked). If you delete/loose the q3config.cfg it will reappear but you are likely to set the variables again anyway.

These first time screens are very common today and I think there is a good reason for that. However too many options can be annoying therefore I allow the player to simply click "Accept" without entering anything.


Title: Re: Open Arena Expanded Beta 34
Post by: dash9 on April 29, 2009, 04:55:12 am
good work! just a question or two - is it possible to show regular votes to give more info.

like if i do a "/callvote map thisisthenewmap" the game will show something like: "pulchr called a vote to change map to thisisthenewmap, press F1 for yes, F2 for no".
Correct me if I'm wrong, I understand you want more info displayed in the console, when a vote is called.

would also be nice for the kick vote "/callvote kick annoyingplayer teamkiller" to be shown like "pulchr called a vote to kick annoyingplayer, reason: teamkiller".

Having a kick reason displayed seems useful.
It would also be useful if there would be more info displayed (on the playing screen, and ofcourse in the console also) when somebody calls a clientkick vote, because it shows only a number, and you have to manually check who is that client.. that is if you know how to do it.. and if you remember :D  .. and it's no fun.


Title: Re: Open Arena Expanded Beta 37
Post by: pulchr on April 29, 2009, 05:47:18 am
well, actually i would like different kind of output shown in different containers. for example i don't want the chat mixed with the text about what player killed another player...
the log about all those things fill up to quickly and the chat disappears - causing you to either miss what was said or forcing you to pull down the console to see.

i would like a chat-container with team chat, ordinary chat and votes. one container for all the other stuff like kills and such.

the different chat and combat logs (http://img296.imageshack.us/img296/9034/wowscrnshot031008002659dj2.jpg) in world of warcraft is an example of how i would like it. that random dude's screenshot shows the chat to the left and combat information to the right.


Title: Re: Open Arena Expanded Beta 37
Post by: dash9 on April 29, 2009, 08:02:22 am
one container for all the other stuff like kills and such.
and stats :D
Yes, sounds great!


Title: Re: Open Arena Expanded Beta 37
Post by: SharpestTool on April 29, 2009, 01:21:12 pm
well, actually i would like different kind of output shown in different containers. for example i don't want the chat mixed with the text about what player killed another player...
the log about all those things fill up to quickly and the chat disappears - causing you to either miss what was said or forcing you to pull down the console to see.

i would like a chat-container with team chat, ordinary chat and votes. one container for all the other stuff like kills and such.

the different chat and combat logs (http://img296.imageshack.us/img296/9034/wowscrnshot031008002659dj2.jpg) in world of warcraft is an example of how i would like it. that random dude's screenshot shows the chat to the left and combat information to the right.

RTCW:ET Does this too...


Title: Re: Open Arena Expanded Beta 37
Post by: pulchr on April 29, 2009, 01:26:17 pm
it was so long ago that i played enemy territory that i'd forgotten. i'm sure there are lots of games out there with a similar solution - there's a good reason for it.


Title: Re: Open Arena Expanded Beta 37
Post by: SharpestTool on April 29, 2009, 04:33:07 pm
No worries...I just mentioned it cuz ET is q3 based and has an SDK out if Sago or anybody else wanted to draw some inspiration from it...


Title: Re: Open Arena Expanded Beta 37
Post by: pulchr on April 30, 2009, 02:09:09 am
ah, i didn't think that far. maybe that could be used as a guide for ideas.


Title: Re: Open Arena Expanded Beta 38
Post by: sago007 on May 02, 2009, 04:53:26 pm
A lot of the UI changes should properly be moved to the missionpack menu system. There have already been a lot of work in the classic menu considered that it is supposed to go away at some point.

Anyway. Just a small update. Not big just some small but annoying bugs:
Quote
New in Beta 38:
* g_humanplayers always 0 during intermission
* bots now read team status from game rather than ai config string. Hopefully stopping bots from shoting at there own team during certain changes.
* challenges.cfg renamed to challenges.dat, to indicate that it is not a text file
* Removed compiler warning in TeamCvarSet
* pmoved_fixed now gets disabled if pmove_float is selected in the UI

I have some other work to attend to so there might be some time till the next update unless somethings goes terrible wrong.


Title: Re: Open Arena Expanded Beta 39
Post by: sago007 on May 08, 2009, 09:38:59 pm
Something went terrible wrong. Disconnecting players made double drop. In Harvester where two skulls was dropped per disconnect.

Quote
New in beta 39:
* Fixed double throw bug when a client disconnected
* No killed message then a client leaves (still counts as a suicide)
* Added 91 Hz fixed framerate to startserver (pmove_msec 11)
* More ingame information about pmove


Title: Re: Open Arena Expanded Beta 39a
Post by: sago007 on May 15, 2009, 03:55:15 pm
B39a is up

No new qvms

Only code cleanup:
msys can now compile the code in windows
files moved to folders
removed lots of unused files
upgraded tools
added svn repository


Title: Re: Open Arena Expanded Beta 39a
Post by: Neon_Knight on June 08, 2009, 04:22:21 pm
Harvester related:

Sound playing:
- When I score: both TeamCap & EnemyCap sound plays (Should play TeamCap, as when I capture a flag on CTF)
- When one of my teammate scores: EnemyCap sound plays (Should play TeamCap, as when some of my teammate captures a flag on CTF)
- When one of the players on the other team scores: TeamCap sound plays (Should play EnemyCap, as when some of the enemy players capture our flag on CTF)

Also things to note:
- In some maps bots won't go instantly for the skulls until some frag has been done. Or they won't go for the skulls directly, but I think this is just some thing with the maps. (I was playing on reptctf3 which hasn't any clipping)
- Also, when a player switch teams in Harv, the enemy skull appears at the receptacle, ready to be taken and delivered to the enemy skull pod. This is bad, as it will make people to change teams just to betray their own team and ruining the game.
- And one more... in Team Arena the skull carrier can be recognizable easily for the skulls it carries behind him. Look at this video from TA trailer (http://www.youtube.com/watch?v=1YzHeLA5_vQ) at 0:36.


Title: Re: Open Arena Expanded Beta 39a
Post by: feidi on June 08, 2009, 04:25:41 pm
How about having a 'shuffle' feature similar to QuakeLive? That is, players can call a vote /callvote shuffle and if successful, teams will be randomized and equalized and map reset. Would be good for public play imo.


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 15, 2009, 09:24:55 am
Beta 40 is up.

Longest changelog in Elimination/OAX history. I have discovered at least one duplicate on the list but it would have been the longest changelog anyway.

Changelog:
Quote
New in Beta 40:
* Fixed CleanStr
* Added color 8 (menu color)
* BG_Alloc/BG_Free added. replaces G_Alloc
* Mines will self destruct very quickly if placed near the flag
* Kill sprees/death sprees and multikills added
* Some fixes backported from ioquake3
* Servers with no humans on are considered empty if "Only humans" is enabled
* Added elimination_lockspectator: 0=no lock, 1=cannot follow enemy, 2=must follow teammate (For Elimination and CTF Elimination only)
* Different crosshairs per weapon
* Crosshair pusle can be disabled
* Skulls are now visible on Skull carriar in Harvester
* Bots are now a little better at understanding prox mines
* Added deathShader to scoreboard in missionpack (for Elimination and CTF Elimination only, missionpack only)
* Breath and Dust effect backported from missionpack
* Added elimflags and voteflags than are now used to tranfer some booleans to save network traffic
* Vote system is more secure
* Vote can now pass even if majority is not reached then time runs out. It requires twice as many yes votes as no votes through or high percentage of yes votes.
* log2stdout cvar removed
* Teams can now be shuffled
* pmove_fixed on be default
* pmove_msec defaults to 11 (controversial - I know)
* Non-rcon based admin system (ban, kick, lock teams, cancel votes etc.)
* Shullfle teams function added. Can be called by an admin "shuffle" or by "callvote shuffle"
* Parts of code has been cleaned a little
* Duplicate GUID check
* Added G_GlobalSound
* Server command handling now modularized ( ClientCommand & ConsoleCommand )


Title: Re: Open Arena Expanded Beta 40
Post by: pulchr on June 15, 2009, 11:35:51 am
awesome as always! but might i ask why the pmove_msec setting is set at 11 as default?


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 15, 2009, 11:56:01 am
but might i ask why the pmove_msec setting is set at 11 as default?
Because it is the closest to actual quake 3 physics.

pmove_float =1 would result in actual quake 3 physics but it will also use slightly more bandwidth.

pmove_fixed does not require extra bandwidth but has other problems like dropping sound but that must be something solveable.

The old behavior with framrate dependent physics is just unacceptable today.


Title: Re: Open Arena Expanded Beta 40
Post by: Udi on June 15, 2009, 01:56:42 pm
Great release :D! Will we have some announcer voices to the killing sprees?

I have a GUI request. On the skirmish panel, could you swap the game mode and the map changing arrows? It can be confusing sometimes. And could you add two arrows (left and right) for the gamemode changing? There's a lot of gamemodes and if you click just one more, you have to go all round again. I imagined something like this:

(http://udionline.hu/fajlok/oa-gui-request.jpg)


Title: Re: Open Arena Expanded Beta 40
Post by: Neon_Knight on June 15, 2009, 02:46:50 pm
Even greater one, sago. I like most of those changes, and I guess I'm not the only one. ^^

But... there's a bug, at least it happens to me... :/
It happens no matter what config I have.
It happens with the following gametypes: CTF, 1FCTF, Harvester & CTF Elimination.

In Skirmish mode, the game freezes, sometimes after loading and sometimes when loading. No matter the map too.

PC Specs:
- A7V600-X
- Sempron 2800+
- 1GB DDR
- XFX5500 256MB DDR2

Anoymore you need for this one? Anyone had the same problem?


Title: Re: Open Arena Expanded Beta 40
Post by: pulchr on June 15, 2009, 03:21:42 pm
Udi's suggestion is a very good one. there's far too many game modes to only be able to go one step forward. buttons for previous and next would make it much better.

edit: the sentence made no sense...


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 15, 2009, 03:59:12 pm
I should mention that there are documentation here: http://code.google.com/p/oax/w/list for the in development functionality.

@Neon_Knight: I fail to reproduce the problem.


Title: Re: Open Arena Expanded Beta 40
Post by: Neon_Knight on June 15, 2009, 04:01:50 pm
Start a skirmish match.
Select CTF/1FCTF/Harvester/CTF Elimination.
Select any map.
Left everything as it is on the next screen and start. The game for some reason freezes here or after loading.


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 15, 2009, 04:17:36 pm
I still cannot reproduce it... it might be because of my aligned models (that is the only thing I can see that only affects these gametypes). Try opening the pk3 file and remove the aligned models.


Title: Re: Open Arena Expanded Beta 40
Post by: Neon_Knight on June 15, 2009, 05:05:43 pm
Tried.
It now happens on 1FCTF and eCTF. Very weird... :/


Title: Re: Open Arena Expanded Beta 40
Post by: schlorri on June 15, 2009, 06:05:09 pm
How does this shuffle feature work? Sometimes when i shuffle 3vs3 teams it generates 4vs2 teams, is this normal?


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 15, 2009, 06:43:00 pm
How does this shuffle feature work? Sometimes when i shuffle 3vs3 teams it generates 4vs2 teams, is this normal?
It does not shuffle the bots. It places the humans like this:

1. red team
2. blue team
3. blue team
4. redteam
5. go to 1

If you run it in single player it will just shift the human player to the red team.


Title: Re: Open Arena Expanded Beta 40
Post by: SharpestTool on June 15, 2009, 09:15:27 pm
@NeonKnight,  I have failed to reproduce the problem as well. Can you provide a more detailed description of what you are seeing on screen when it freezes/locks up?  Like are there some specific parts of the loading screen that it keeps freezing on?  Also, what's your config like? Maybe if we narrow down the cvar's we could figure out what I screwed up!!! lol :)

@Udi, Killing Sprees/Death Sprees, and Multikills were designed to be an additional option, customizable by the user/server, that wouldn't change the default gameplay behavior.  So the short answer is no, unless someone is willing to do the sound recording themselves ( since there aren't any GPL/PD spree sounds I know of ).   I have my personal setup configured to play the spree/multikill sounds from NoQuarter for ET (which come from Unreal Tournament I think).  If you look around, I'm sure you can find some yourself...then see the documentation here http://code.google.com/p/oax/w/list (http://code.google.com/p/oax/w/list) for how to configure them.   

Also for the GUI requests, I'm not quite sure what the status of the MissionPack GUI, but I think at some point it's going to be completely integrated.
PS: The MissionPack GUI is MUCH MUCH MUCH Easier to develop since it is a sort of markup/scripted deal, code does not have to be written for every single menu.  (I've loaded the RTCW GUI up with ioQ3 before...of course nothing worked but it loaded/looked right).

HAPPY !KICKING, !BANNING, !WARNING, and !SLAPPING btw.



Title: Re: Open Arena Expanded Beta 40
Post by: Udi on June 16, 2009, 12:55:49 am
@Udi, Killing Sprees/Death Sprees, and Multikills were designed to be an additional option, customizable by the user/server, that wouldn't change the default gameplay behavior.

Ok, thanks. So it's possible to add sounds, but there won't be any by default, because it would change the gameplay.

Also for the GUI requests, I'm not quite sure what the status of the MissionPack GUI, but I think at some point it's going to be completely integrated.

You mean the GUI that leileilol posted some time ago (http://openarena.ws/board/index.php?topic=2958.0)? The preview image is missing, it had a blueish color just like the new homepage design (http://openarena.ws/board/index.php?topic=2985.0). I'm just guessing, but fromhell wants 0.8.2 to look modern/blue, and this redesign is far more easier with the missionpack menu system, so the new look would be accomplished by integrating the missionpack menu. So if I'm right, you are waiting for fromhell's order: "Paint it blue!" and the whole GUI would be rebuild (which would be awesome ;))?


Title: Re: Open Arena Expanded Beta 40
Post by: sago007 on June 20, 2009, 09:14:31 am
Start a skirmish match.
Select CTF/1FCTF/Harvester/CTF Elimination.
Select any map.
Left everything as it is on the next screen and start. The game for some reason freezes here or after loading.
I was able to reproduce it with hydronex2 in Overload at least I think it is the same problem (freeze at the loading screen, log shows that the map was loaded). It was caused by an AAS bug introduced in Beta 30 that relates to bots and the gametype flag.

Could you check if the bug you describe exist in Beta 30 but not in Beta 29?


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on June 21, 2009, 01:06:16 pm
Beta 41 is up.

g_persistantpowerups will properly be hated as much as any of the other changes backpported from missionpack but the code now has a lot less of the annoying "#ifdef missionpack"

The game now forces vertex off by default. The system is inspired by the tournament mode suggested earlier. fairflags currently has 3 flags:
1 - basic lock - limits fov and zoomfov to 140
2 - extended lock - limits r_picmip, r_intensity, r_overbrightbits, r_gamma, etc. to sane values.
4 - vertex lock - disables vertex light on all clients.

cg_autovertex will automatically enable vertex if the lock is disengaged. For other cvars you will need a script to reset them.

Changelog:
Quote
New in Beta 41:
* Persistant powerups are now toggleable (default off in baseoa, default on in missionpack) - g_persistantpowerups
* Penality points in 1 on 1 are awarded to the opponent rather than subtracted.
* Negative scores in FFA are no longer possible.
* Changed default ammo count in Elimination
* Exclude bots from duplicate names check
* Missionpack now supports ui_humansonly
* Fixed wrong gamenames in Missionpack server browser
* Removed Mplayer as an option in Missionpack server browser (still no support for different master servers through)
* Removed remaining references to punkbuster
* Kemikazie and Invincibility are now availeble (beware that Invincibility is missing models). Availble in bases3 only (as far as I know)
* Fixed infinity loop bug in AAS code caused by the gametype flag.
* Generally improved the bot's Area Awareness System.
* Added basic 'fariness' system. The CVAR is 'fairflags'. Default value 7 (1+2+4). 1 verifies some basic values. 2 verifies some extended graphics settings. 4 disables vertex light. 
* Added CVAR cg_autovertex. Automatically enables vertex light if allowed. Off by default. Gets enabled if you enable vertex light through the menu.
Note: The fairness system might result in a vid_restart if it detects a bad r_ cvar after the render has been initialized


Title: Re: Open Arena Expanded Beta 41
Post by: pulchr on June 21, 2009, 01:45:42 pm
typo - i guess it should be g_persistentpowerups?


Title: Re: Open Arena Expanded Beta 41
Post by: feidi on June 21, 2009, 06:25:21 pm
how about adding binds to drop the current weapon and to drop the flag? Would be very nice for TDM as well...


Title: Re: Open Arena Expanded Beta 41
Post by: Falkland on June 22, 2009, 11:51:17 am
Beta 41 is up.

g_persistantpowerups will properly be hated as much as any of the other changes backpported from missionpack but the code now has a lot less of the annoying "#ifdef missionpack"

The game now forces vertex off by default. The system is inspired by the tournament mode suggested earlier. fairflags currently has 3 flags:
1 - basic lock - limits fov and zoomfov to 140
2 - extended lock - limits r_dipstick, r_intensity, r_overbrightbits, r_gamma, etc. to sane values.
4 - vertex lock - disables vertex light on all clients.

cg_autovertex will automatically enable vertex if the lock is disengaged. For other cvars you will need a script to reset them.

Changelog:
Quote
New in Beta 41:
...
* Added basic 'fariness' system. The CVAR is 'fairflags'. Default value 7 (1+2+4). 1 verifies some basic values. 2 verifies some extended graphics settings. 4 disables vertex light. 
* Added CVAR cg_autovertex. Automatically enables vertex light if allowed. Off by default. Gets enabled if you enable vertex light through the menu.
Note: The fairness system might result in a vid_restart if it detects a bad r_ cvar after the render has been initialized

Those changes are very interesting IMHO :

A control over snaps like those ones could be also useful : server-side engine already forces snaps to be equal to server's sv_fps when the client value is higher than server's sv_fps , but it forces to 1 when a client has set it to a negative value , and infact permits to be 1 < snaps < server's sv_fps ... it could be useful to not permit to set snaps too low ( 1 or so is ridiculously used sometime to cause lag and/or by a flag carrier to win a match at sudden-death ) or to set to be equal to server's sv_fps ... CPMA doesn't permit to clients to set snaps ... it automagically tunes it to server's sv_fps ( usually set at 30 in quite all servers )

Is it possible to use the same or such a similar method to force to 0/inactive value all known client cheats cvar/vars ( I mean bots/aimbots cvars ) like punkbuster ( try to do ?) does ?

Is it possible to eventually have them in a list and read the list from a txt/dat file that can be updated with newer cvars lists ?

The system could be eventually improved/extended :

- 1 : using an encrypted format for the file
- 2 : automatically exclude all the legit cvars ( to forbid adding also legit cvars in the list )
- 3 : sharing the file between all and/or a group of servers and when the list is updated on one server , the change is extended to all the servers and/or to all of the servers of the group.
- 4 : automatically dumping all the ingame-in-memory-loaded cvars of a suspected client in a different file - not to the common server log file - so to permit a post-analysis ... recording demos is meaningless against some kind of bots running one or more humanization algorithm.

Hard work , I know ...


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on June 22, 2009, 12:19:47 pm
I think it would be wasted work. If people want to cheat they can do it (but should and may not).

I created the system simple and easily toggleable in the hope that there will be enough servers without the system so that people who want to don't want the limits can just play on these server instead. The fairflags will then roughly reflect the servers and the opponents you wish to play.


Title: Re: Open Arena Expanded Beta 41
Post by: Graion Dilach on June 22, 2009, 03:14:43 pm
Quote
* Negative scores in FFA are no longer possible

This means falling won't give negative score? Nooo... I like seeing how dumb the bots on Suspended... (Suspended is much more safely when camping than moving... there are too many holes!)


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on June 22, 2009, 03:31:02 pm
This means falling won't give negative score?
It sill subtracts a point but only if there is something to subtract from (the score will not be negative). The player could just leave and come back to get reset to zero anyway.

But yes the bots/noobs will just stay on 0 points forever.


Title: Re: Open Arena Expanded Beta 40
Post by: Neon_Knight on June 28, 2009, 11:37:50 pm
Start a skirmish match.
Select CTF/1FCTF/Harvester/CTF Elimination.
Select any map.
Left everything as it is on the next screen and start. The game for some reason freezes here or after loading.
I was able to reproduce it with hydronex2 in Overload at least I think it is the same problem (freeze at the loading screen, log shows that the map was loaded). It was caused by an AAS bug introduced in Beta 30 that relates to bots and the gametype flag.

Could you check if the bug you describe exist in Beta 30 but not in Beta 29?
I didn't saw that post. I'll check that tomorrow if that wasn't changed on OAXb41.


Title: Re: Open Arena Expanded Beta 41
Post by: chaoticsoldier on July 08, 2009, 12:36:22 am
I noticed that when you kick a player it says, for example:
Quote
/kick Sarge
Sarge was kicked
  suicides.

Quote
/kick all
Player all is not on the server
Kyonshi was kicked
Jenna was kicked
Sarge was kicked
  suicides.
  suicides.
  suicides.

Why does it say "suicides."? Is this intentional?


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 10, 2009, 05:28:55 pm
Why does it say "suicides."? Is this intentional?
Not really. But I didn't find a logical place to remove the message.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 11, 2009, 11:26:48 pm
Another report...
There's a problem with both Kamikaze & Invulnerability holdables, in cg_simpleitems 1, they'll show if their part of the map is drawn, making them visible through walls. Can this be fixed?

I've done an icon for Invulnerability, so it will show up on cg_simpleitems 1, despite that there's no model for it and it's forcefield yet. I'll upload it to SVNC thread.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 12, 2009, 02:51:25 am
making them visible through walls. Can this be fixed?
It is a shader problem and I know nothing about shaders.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 12, 2009, 09:19:49 am
Well, I actually took a look at icon shaders and the icon images themselves and there's nothing wrong. Strange. :/
Kamikaze & Invulnerability are the only icons which have this problem, and both the shaders and icons seems normal.


Title: Re: Open Arena Expanded Beta 41
Post by: Falkland on July 12, 2009, 09:25:38 am
Another report...
There's a problem with both Kamikaze & Invulnerability holdables, in cg_simpleitems 1, they'll show if their part of the map is drawn, making them visible through walls.

I remember something like this also with MP weapons ... so if it was fixed for weapons , it can be fixed also with powerups


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 12, 2009, 10:22:40 am
Another thing (sorry if I look as an unpleasable fanboy :D)

What about making players to return to their bases in 1FCTF, Harvester & Overload after their team scores, just like in Elimination?

That will prevent base/center camping in those modes. UT3's Greed made the scoring player to return to his/her base after scoring, but since unlike Greed there's a central point where the objective lies on the first two modes (a camping objective) and most players will remain in the enemy base waiting for the respawning of the crystal in the third one, it can be a tweak there.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 12, 2009, 06:44:11 pm
What about making players to return to their bases in 1FCTF, Harvester & Overload after their team scores, just like in Elimination?
I think the idea is that a team should dominate the middle.


Title: Re: Open Arena Expanded Beta 41
Post by: feidi on July 13, 2009, 06:11:22 am
How is the accuracy calculated for rockets? If it's "shots that hit / total number of shots" then a more descriptive variant could be the total splash damage inflicted divided by the total number of shots.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 13, 2009, 07:36:46 am
What about making players to return to their bases in 1FCTF, Harvester & Overload after their team scores, just like in Elimination?
I think the idea is that a team should dominate the middle.
Actually that "dominate" becomes a "camping", (center area in 1F/Harv, enemy base on OL & both bases on DD) which IMHO is bad for normal gameplay and makes those gametypes to suck and not being accepted.

I have a better idea instead:
What about having a switch "Respawn after scoring" for the following gametypes: 1FCTF, Harv, OL and DD? You can put it in normal CTF, but there's CTF Elimination for that.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 17, 2009, 01:52:19 pm
Problem here... I don't know if it's on OAX or what, but for some reason the game automatically changes my lightning to vertex while on SP. This doesn't happen on devmap mode. I didn't tried in Skirmish.
Is this a bug or there's a reason fort his? I'm using OAXb41 with autovertex = 0 and my normal settings uses lightmap. (Which is what I want)


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 17, 2009, 02:23:05 pm
Problem here... I don't know if it's on OAX or what, but for some reason the game automatically changes my lightning to vertex while on SP.
Bug confirmed. The game does not check cg_autovertex in singleplayer and presumes it being true.

Fixed in revision 143


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 17, 2009, 02:41:10 pm
Great one. ^^
Another bug I've found: I was bored, so I've started a new SP game, but in the last match to win the tier, no matter if I win or lose, it won't let me pass to the next tier. I've tried with normal OA0.8.1 and it worked the way it should.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 17, 2009, 04:44:09 pm
Great one. ^^
Another bug I've found: I was bored, so I've started a new SP game, but in the last match to win the tier, no matter if I win or lose, it won't let me pass to the next tier. I've tried with normal OA0.8.1 and it worked the way it should.
Any idea in what version it was introduced?


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 17, 2009, 04:52:40 pm
TBH I have no idea, I should download the other versions (from b27?) and check. But in b41 no matter if I win or lose, the game thinks I lost.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 17, 2009, 05:14:13 pm
TBH I have no idea, I should download the other versions (from b27?) and check. But in b41 no matter if I win or lose, the game thinks I lost.
I think it was introduced in either Beta 41 (maybe broken because of some missionpack single player stuff) or Beta 34 (different ways of finding single player levels).


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 17, 2009, 05:18:16 pm
I'll try b40 and b33/34 then...


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 17, 2009, 07:09:35 pm
Another bug noticed, and this one comes from OA 0.8.1. (I don't know if it was there before)
On the SP, the already won matches in the actual tier gets lost after restart! For example, I won 3 of 4 matches in the tier, then close OA. When I open again OA, the three matches I won before didn't get saved. That's another annoying thing.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 19, 2009, 10:48:56 pm
Sago, the SP "no-win" bug occurs on b41 only.

Win the first 3 matches of the tier, and in match 4 no matter if you win or lose, the game take it as a lose.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 20, 2009, 08:53:15 am
I think it is fixed now... postgame was not called in single player.


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 20, 2009, 09:20:40 am
Yep, fixed now. ^^


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on July 29, 2009, 02:40:15 pm
Bug report:
- Double Domination: Only announcer sounds are playing when scoring. The normal background music doesn't plays neither if my team scores or the enemy team does.
- Double Domination AI: I've noticed on 1on1 matches that bots tend to take the A point and not the B point, unless the player makes the bots to go to them. Maybe it's a weight issue. Are the bots just getting stupidness or it's a problem with their AI?


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on July 30, 2009, 07:06:48 am
- Double Domination AI: I've noticed on 1on1 matches that bots tend to take the A point and not the B point, unless the player makes the bots to go to them. Maybe it's a weight issue. Are the bots just getting stupidness or it's a problem with their AI?
The bots pick a domination point to dominate and stick with it. It will toss a coin every 10 minutes and might change point then. The bot will also change point if ordered to do so. If a bot becomes the team leader he will try to distribute the bots but if always ends in a 2 on one point and 1 on the other.

I have not done any AI programming myself the points are just set as long term goals that the bot wants to be at.

For more than one bot I believe this strategy is the most successful strategy that the bots can be expected to understand. I think they would be caught in the middle too often if they were allowed to go to both points.


Title: Re: Open Arena Expanded Beta 41
Post by: feidi on August 09, 2009, 05:16:47 pm
Is cg_thirdperson already cheat protected? If not, then please make it so.


Title: Re: Open Arena Expanded Beta 41
Post by: fromhell on September 02, 2009, 12:58:20 am
Why? It's only range and angle (as well as the orbit) cvars that need to be protected. Third person isn't really playable without aa 3d crosshair anyway.

Also I forgot to 'commit' my new colors.

ui_controls2.c
Code:
// OLD
//static vec4_t controls_binding_color  = {1.00f, 0.43f, 0.00f, 1.00f}; // bk: Win32 C4305

// New!
static vec4_t controls_binding_color  = {0.58f, 0.70f, 0.81f, 1.00f};

ui_qmenu.c
Code:

// Original colors
/*
vec4_t menu_text_color    = {1.0f, 1.0f, 1.0f, 1.0f};
vec4_t menu_dim_color       = {0.0f, 0.0f, 0.0f, 0.75f};
vec4_t color_black    = {0.00f, 0.00f, 0.00f, 1.00f};
vec4_t color_white    = {1.00f, 1.00f, 1.00f, 1.00f};
vec4_t color_yellow    = {1.00f, 1.00f, 0.00f, 1.00f};
vec4_t color_blue    = {0.00f, 0.00f, 1.00f, 1.00f};
vec4_t color_lightOrange    = {1.00f, 0.68f, 0.00f, 1.00f };
vec4_t color_orange    = {1.00f, 0.43f, 0.00f, 1.00f};
vec4_t color_red    = {1.00f, 0.00f, 0.00f, 1.00f};
vec4_t color_dim    = {0.00f, 0.00f, 0.00f, 0.25f};

  vec4_t pulse_color          = {1.00f, 1.00f, 1.00f, 1.00f};
vec4_t text_color_disabled  = {0.50f, 0.50f, 0.50f, 1.00f}; // light gray
vec4_t text_color_normal    = {1.00f, 0.43f, 0.00f, 1.00f}; // light orange
vec4_t text_color_highlight = {1.00f, 1.00f, 0.00f, 1.00f}; // bright yellow
vec4_t listbar_color        = {1.00f, 0.43f, 0.00f, 0.30f}; // transluscent orange
vec4_t text_color_status    = {1.00f, 1.00f, 1.00f, 1.00f}; // bright white

*/
// NEW AND IMPLOVED colors
vec4_t menu_text_color    = {1.0f, 1.0f, 1.0f, 1.0f};
vec4_t menu_dim_color       = {0.0f, 0.0f, 0.0f, 0.75f};
vec4_t color_black    = {0.00f, 0.00f, 0.00f, 1.00f};
vec4_t color_white    = {1.00f, 1.00f, 1.00f, 1.00f};
vec4_t color_yellow    = {1.00f, 1.00f, 0.00f, 1.00f};
vec4_t color_blue    = {0.00f, 0.00f, 1.00f, 1.00f};
vec4_t color_lightOrange    = {0.30f, 0.45f, 0.58f, 1.00f };
vec4_t color_orange    = {0.30f, 0.45f, 0.58f, 1.00f};
vec4_t color_red    = {0.55f, 0.65f, 0.73f, 1.00f};
vec4_t color_dim    = {0.00f, 0.00f, 0.00f, 0.25f};

// current color scheme
vec4_t pulse_color          = {1.00f, 1.00f, 1.00f, 1.00f};
vec4_t text_color_disabled  = {0.35f, 0.24f, 0.29f, 1.00f}; // light gray
vec4_t text_color_normal    = {0.30f, 0.45f, 0.58f, 1.00f}; // light orange
vec4_t text_color_highlight = {0.76f, 0.89f, 0.93f, 1.00f}; // bright yellow
vec4_t listbar_color        = {0.13f, 0.26f, 0.38f, 0.30f}; // transluscent orange
vec4_t text_color_status    = {1.00f, 1.00f, 1.00f, 1.00f}; // bright white

I'll commit related 'new scheme' assets into the SVN, however I want to have a different name for the new menu background textures to keep 'classic red' scheme in q3 mods compatible and not-clashy.


Title: Re: Open Arena Expanded Beta 41
Post by: Falkland on September 02, 2009, 12:08:42 pm
Why? It's only range and angle (as well as the orbit) cvars that need to be protected. Third person isn't really playable without aa 3d crosshair anyway.

Toggling cg_thirdperson with a script can be used in 1v1 to see enemy while hiding behind corners.


Title: Re: Open Arena Expanded Beta 41
Post by: sago007 on September 14, 2009, 08:56:44 am
I know I said I would have more time after the 7th of September but work has taken longer than expected.

I have commited the colors. I also changed the color of the licens notice to dark blue.

Is it just me or is the 'light gray' color now a little bit orange? Looks wierd to me.

I think the serverlist will also need a color modification.

I have not looked at the media yet, so maybe the colors are just fine.


Title: Re: Open Arena Expanded Beta 41
Post by: Falkland on September 16, 2009, 01:47:29 pm
The current DM and 1v1 player spawn function used in OA081 ( and that is standard in ioquake3/q3-1.32 ) chooses a random spawn point between the furthest ones from the area where the player is dead ( SelectRandomFurthestSpawnPoint )

This function has 2 issue :
- in FFA has the tendence to produce telefrags
- in 1v1 makes spawn points too much predictable

CTF and the other team gameplay modes follow a different rule ( team-based-random spawn points ) , so they aren't affected

I've noticed that since OAXB35 the spawn function is changed ( it was substituted by an ancient code ... probably previous than Q3-1.32b ) to avoid telefrags : the spawn point is chosen random between all the spawn points that don't telefrag with the exclusion of the nearest one to the area in which the player was fragged.

This function seems to solve telefrags , but it doesn't solve the problem of the prediction of spawn points/spawnfrags in 1v1 because while the nearest spawn point is excluded , the probability that the killer will frag the opponent while respawing is still high because the opponent can spawn while the killer is going around the map and collecting items.

Killer's position should be a parameter to evaluate where the opponent should spawn as specified in the CQ3 TechSheet : http://www.promode.org/wiki/index.php/CQ3_Tech_Sheet

Quote
...

Player Spawning

Description

Respawns are biased away from player corpse

Specifics

* Spawnpoints overlapped by players are ignored
* Nearest spawnpoint to corpse is ignored
* Nearest spawnpoints to killer are ignored. Depends on total spawnpoints amount


Exceptions

* Deathmatch modes always use full random for suicides
* Flag modes always use full random among team spawnpoints

...

Full random is a solution that doesn't seem to be desiderable at all : http://www.promode.org/forum/viewtopic.php?f=18&t=3979

Q4 seems to have a much more advanced solution :

- All spawnPoints are grouped in a list
- When a player is fragged a random spawnpoint is choosen as the possible candidate .
- A first check is done to see if something is in the way on the possible spawn point
- If the spawn point is currently visible , the spawn point is skipped and the routine continue to cycle
- Once founding a valid spawnpoint , the chosen spawn point is removed from the list of the available spawnpoints
- When there are no more spawpoints in the list , the list is filled again with all the map's spawnpoint.



Title: Re: Open Arena Expanded Beta 41
Post by: Wiiyamoto on September 22, 2009, 09:50:44 am
I'm also posting this video here that shows Team oaN's new server running off oaxB41. We find this mod very cool and very unique. It just adds cool little features to the open arena experience

http://www.youtube.com/watch?v=duuSku56t_o

Thanks to sago (SharpestTool) We were shown this mod to be used on our server. We hope to see everyone when we make the server public :D Thanks for making this mod it will surely go a long way in OA


Title: Re: Open Arena Expanded Beta 41
Post by: Neon_Knight on September 22, 2009, 10:41:36 am
Well, good news for you Wiiyamoto. Read the first post of this thread. :D


Title: Re: Open Arena Expanded Beta 41
Post by: Wiiyamoto on September 22, 2009, 12:21:27 pm
:D :D :D :D You have Wii's support for this mod and oax development. oaN will be happy to show off any new features and new mods you can come up with on our servers. :)


Title: Re: Open Arena Expanded Beta 41
Post by: Cacatoes on September 25, 2009, 06:32:46 pm
Aesthetic bug:
In Double Domination game mode (tried with oasago2), you can play alone while "awaiting players", if you take control of points, it will say "your team will score in X seconds", but here as it waits for other players the counter continues and goes negative :D
Happens with oaxB41.


Title: Re: Open Arena Expanded Beta 42
Post by: sago007 on September 28, 2009, 10:44:34 am
Beta 42 is up.

This is primarily to show the new colors. I personally think the text in the ingame menu is too hard to read.
The background is read from  the default place... it should be renamed too for compatibility.

Changelog:
Quote
New in Beta 42:
* g_persistantpowerups is now renamed to g_runes
* vertex light is no longer forced on in single player
* Now runs the correct logic then a single player map ends
* Blueish menu
* Added clientkick_game, same as clientkick but located in the game code, so it can be improved without touching the engine
* Double Domination counter will no longer count forever during warmup (however points will not respawn)


Title: Re: Open Arena Expanded Beta 42
Post by: Cacatoes on September 28, 2009, 02:15:08 pm
I installed OaxB42 on ROFL Various Couscous (http://dpmaster.deathmask.net/?game=openarena&server=212.85.158.133:27981&showplayers=1).

Aesthetic bug#2: :P
Seems there is a typo in Server Browser, line "Servers", you can chose between Local, Favorites, and Internet1.
It's been here with oaxb41 and b42.

Note: I also felt like it switched back to "Favorites" even if I didn't ask for it as I only set it to "Internet" usually, maybe my imagination ;)


Title: Re: Open Arena Expanded Beta 42
Post by: sago007 on September 28, 2009, 03:04:49 pm
It does sound stupid that it says Internet1 if there is only one option. The reason is of course that you can now change the master server you want to list.


Title: Re: Open Arena Expanded Beta 42
Post by: Cacatoes on September 28, 2009, 03:30:35 pm
Not a bug but a feature, okay, that's fine sorry ;)


Title: Re: Open Arena Expanded Beta 42
Post by: chaoticsoldier on September 29, 2009, 01:09:56 am
Actually, I also thought this was an error.

If it isn't possible to put a space before the 1, perhaps it could say Internet(1) or something similar instead so it looks more deliberate and less like a typo.


Title: Re: Open Arena Expanded Beta 42
Post by: Neon_Knight on October 17, 2009, 09:15:46 am
Suggestion: Classic/MP mode. g_classic
By default, TA mode: g_classic 0

Classic mode will disable the following items on maps. (Q3 style) MP mode will enable them: (TA style)
- Nailguns
- Chainguns
- Prox Launchers
- Runes (g_classic 1 would force g_runes 0)
- Kamikazes
- Invulnerabilities

It can even be included in the voting menu.

EDIT: In the next releases of OAX you should include the file textures/sfx/jcb2.tga, otherwise it'll display a "not found" black & white cube sometimes. :/


Title: Re: Open Arena Expanded Beta 43
Post by: sago007 on October 23, 2009, 08:49:38 am
Just small changes. I am not going to start something big right now while a patch is considered.

Changelog:
Quote
New in Beta 43:
* Colored crosshair support by chaing RGB values
* BG_CanAlloc introduced, can predict out-of-memory errors and handle them - adding too many bots no longer crashes the game
* Some missing blueish menu items
* Added g_catchup, that makes cheap frags a little more expensive if activated
* A few notices added to UI in different places
* Server source is now: Internet, Internet(2), Internet(3) ... instead of Internet1, Internet2, Internet3 ...
* Dead players are sorted last in Elimination/CTF Elimination
* Some imports from ioquake3: Ratio selection, new ClientCleanName and new bglib

The crosshair colors are possible the most interresting new thing. cg_crosshairHealth must be turned off for it to work.

g_catchup is by default disabled but if it is enabled it will reduce damage done to low scoring players by up 50% (rounded up).

The catchup cvar is targeted public servers: If it is set to 5 then the damage will be reduced by 5% for each frag above 5 that the target is behind. If the target has a higher score than the attacker 100% damage will always be dealt. If the target is at most 5 frags behind the attacker 100% damage will be dealt. Catchup can therefore not be used to overtake the firstplace (except by providing momentum). Catchup does not work in team games.

BG_CanAlloc has been introduced to prevent the crash from this thread: http://openarena.ws/board/index.php?topic=3358.0

The idea of sorting dead players last are taken from: http://openarena.ws/board/index.php?topic=3062.0


Title: Re: Open Arena Expanded Beta 43
Post by: Udi on October 23, 2009, 12:35:45 pm
* Some missing blueish menu items

The cursor, slider button and the checkbox buttons are still yellow. I recolored them too, but I will give the blueish menu a little more love next week. I'll follow the oaxB43 filenames and shaders, so it will be easy to add. The in-game menu is hard to read because the semi-transparent background is missing, I will investigate in that too.

The crosshair colors are possible the most interresting new thing. cg_crosshairHealth must be turned off for it to work.

RGB crosshairs are awesome :D! Having a bigger orange dot in front of me increases the gaming experience a lot. Will it be a colorpicker in the options for people without console know-how? Sorry, there are three sliders that I missed...

Addition:
Is OAX using the Brainworks bots already? Because I noticed that on the lowest difficulty the bots behave different than in OA 0.8.1: they don't shoot each other, but sometimes stuck facing each other and still running. Almost like the Smokin' Guns bots, it really looks stupid.

If I finish a single player map in OAX, and quit, my progress won't be saved. But if I complete it in OA, than the same progress is seen in OAX too. Don't know if it is a bug or feature, just asking.

Addition 2:
When playing skirmish in Elimination and CTF Elimination mode after the capture limit is reached I get the following error:
Code:
Netchan queue is not properly initialized in
sv_netchan_transmitnextfragment
All the other gametypes are fine.


Title: Re: Open Arena Expanded Beta 43
Post by: sago007 on October 23, 2009, 03:10:46 pm
Addition 2:
When playing skirmish in Elimination and CTF Elimination mode after the capture limit is reached I get the following error:
Code:
Netchan queue is not properly initialized in
sv_netchan_transmitnextfragment
All the other gametypes are fine.
Thanks. I had not noticed, I think I know why.

The bots has not been touched lately.

cg_crosshairHealth needs to be toggleable through the menu for people  without console know-how, it appears to be on by default, just never noticed because the shaders has never allowed colors before.

I think the single player progress problem is caused by the way the engine handles cvars. Then loading a mod it is copied from the mod you are running, so if you after completing a single player mission in oax and load OpenArena in the mods menu the result will be copied back to baseoa.


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on October 24, 2009, 01:54:27 pm
Beta 44 is up

Just fixed the (CTF)Elimination crash bug and made it possible to disable cg_crosshairHealth

Changelog:
Quote
New in Beta 44:
* cg_crosshairHealth toggleable in the menu
* Fixed crash during intermission in Elimination and CTF Elimination if a human was dead while the capturelimit was reached and possible other situations.


Title: Re: Open Arena Expanded Beta 44
Post by: Udi on October 30, 2009, 12:01:33 pm
Here's a lil' graphics only patch for the bluemenu, compatible with oaxB44. Regenerated all the buttons, because the glow was too large and was cut off by the border, the ingame menu frames have now a 80% transparent black background and logo256.tga and logo512.jpg contain the new logo.

Package: http://udionline.hu/fajlok/z_bluemenu_v3patch.pk3 (http://udionline.hu/fajlok/z_bluemenu_v3patch.pk3) (only the updated ones, just copy it into your oaxB44 folder)
Sources: http://udionline.hu/fajlok/bluemenu_v3_sources.zip (http://udionline.hu/fajlok/bluemenu_v3_sources.zip) (all the sources, not just the updated ones)


Title: Re: Open Arena Expanded Beta 44
Post by: Udi on November 01, 2009, 04:04:52 am
Last time I've made a mistake, both addbotframe.tga and cut_frame.tga were cut down on the sides, which could only be visible on bright maps like ctf_compromise, but it was really disturbing. Updated the previous patch with the right images.

Package: http://udionline.hu/fajlok/z_bluemenu_v4patch.pk3 (http://udionline.hu/fajlok/z_bluemenu_v4patch.pk3)
Sources: http://udionline.hu/fajlok/bluemenu_v4_sources.zip (http://udionline.hu/fajlok/bluemenu_v4_sources.zip)


Title: Re: Open Arena Expanded Beta 44
Post by: Mr. D on November 01, 2009, 10:29:00 am
I've realise in "select bot" submenu the buttons have still got the old theme

(http://img263.imageshack.us/img263/2831/selectbot.jpg)


Title: Re: Open Arena Expanded Beta 44
Post by: Udi on November 01, 2009, 12:28:47 pm
I've realise in "select bot" submenu the buttons have still got the old theme

What version do you use? I've no bugs in current OAX, and there's not even an accept button and the model images are on the left side while there's the current model on the right side.


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 01, 2009, 01:47:03 pm
A change I would like to make is having the bluish background and logo have a different name, so they don't collide with old files but I don't know how to change the names or what names needs to be changed.


Title: Re: Open Arena Expanded Beta 44
Post by: Mr. D on November 01, 2009, 02:08:20 pm

Quote

What version do you use? I've no bugs in current OAX, and there's not even an accept button and the model images are on the left side while there's the current model on the right side.

I have oax 44 beta + bluemenu v4;  in my oa version it appear this, and i have also removed the additional models in my folder but nothing happened...


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 01, 2009, 02:44:12 pm
the bot menu does the old theme


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 03, 2009, 08:51:13 am
There were some ioquake3 fixes also over the VM code that should be applied to OA VM too ( eg . http://svn.icculus.org/quake3?view=rev&revision=1726 ) ...

For a list of the ioquake3 commits about VM , check the ioquake3 commits ML -> http://icculus.org/pipermail/quake3-commits/

It was fixed also a very ancient Q3 bug which consists in the assignement of the ASSIST AWARD to the player capturing flag : http://icculus.org/pipermail/quake3-commits/2009-October/001561.html



Title: Re: Open Arena Expanded Beta 44
Post by: schlorri on November 11, 2009, 05:14:20 am
Hello...long time no see :)

I'm too lazy to read this whole thread, so i dont really know if this bug was reported already.
In the current 0.8.5RC1 is a bug regarding the pushingAward system. If you send the flagcarrier flying in CTF + he kills himself -> the flag is not returned.


all the best
schlorri

Edit: I cannot compile current oax-svn sources:

Code:
code/game/g_syscalls.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’
make[2]: *** [build/release-linux-x86_64/baseq3/game/g_syscalls.o] Fehler 1   

line 34: Q_EXPORT void dllEntry( intptr_t (QDECL *syscallptr)( intptr_t arg,... ) ) {

i removed Q_EXPORT and it works...whats that Q_EXPORT?



Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 12, 2009, 11:14:05 am
The Q_EXPORT problem was added somewhere in September: A backport from ioquake r1609 was not complete.

On Linux Q_EXPORT is defined empty.

I have added the Q_EXPORT to q_shared.h

I guess replacing this line:
player_die (ent, ent, &g_entities[ent->client->lastSentFlying], 100000, MOD_FALLING);
with
player_die (ent, ent, &g_entities[ent->client->lastSentFlying], 100000, MOD_SUICIDE);
will fix the problem with the flag not being returned.

Now there are two different degrees of seriusity in this: Does the player still drop the flag? If not it is a very serious problem.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 12, 2009, 11:49:21 am
The Q_EXPORT problem was added somewhere in September: A backport from ioquake r1609 was not complete.
...

It was added in this commit : http://icculus.org/pipermail/quake3-commits/2009-September/001526.html

Basically it's a workaround to have the same characteristics that linux shared libraries have when compiled with the switch -fvisibility=hidden

As I already said there were many fixes in the latest 2 months and maybe others will come : for example there's a proposal for a significant change in the netcode to avoid some kind of exploits -> http://lists.ioquake.org/pipermail/ioquake3-ioquake.org/2009-October/003688.html


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 12, 2009, 02:09:48 pm
For a list of the ioquake3 commits about VM , check the ioquake3 commits ML -> http://icculus.org/pipermail/quake3-commits/
I am on that mailing list.

The stuff about the new protocol sounds interesting. I have a few ideas myself most related to autodownload.


Title: Re: Open Arena Expanded Beta 44
Post by: SharpestTool on November 15, 2009, 11:31:00 pm
It was fixed also a very ancient Q3 bug which consists in the assignement of the ASSIST AWARD to the player capturing flag : http://icculus.org/pipermail/quake3-commits/2009-October/001561.html

Thats not a bug...you frag the other teams flag carrier, you get the assist award.  LOL what an amazing display of politics about a gameplay feature by classifying it as a bug.

btw Sago...where do I find the assets for the new UI stuff in this version of OAX?  I made some changes and was testing em, and got all kinds of missing textures. 



Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 16, 2009, 01:37:19 am
btw Sago...where do I find the assets for the new UI stuff in this version of OAX?  I made some changes and was testing em, and got all kinds of missing textures. 
The easiest way is to download B44 and take the media from there... it is copied from some other thread and also part of the first 0.8.5 patch.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 16, 2009, 07:05:51 am
Thats not a bug...you frag the other teams flag carrier, you get the assist award.  LOL what an amazing display of politics about a gameplay feature by classifying it as a bug.

As now in OA081 you get an assist award if you are the flag carrier and you score : if it's not a bug I don't know how to classify this. They've not removed the assist award in all the situations ... check the link of the bugzilla entry in the commit report.


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 16, 2009, 07:32:03 am
As now in OA081 you get an assist award if you are the flag carrier and you score : if it's not a bug I don't know how to classify this.
There is not always a border between features and bugs.

Strafejumping and rocketjumping was obviously bugs but then ID tried to fix them it caused an uproar and they become reclassified as features.

Is the assist award a bug? I don't know but there is no damage in changing its behavior, so I have done so in svn.

The splash damage through walls is different though. There are a lot of maps (especially space maps) there this functionality is used as a feature to knock people off from below a platform.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 16, 2009, 08:45:20 am
Is the assist award a bug?

If you are the flag carrier , you score and you get the assist award , actually I think it's a bug ( logic bug ) : the assist should be awarded to the buddy(ies) near the flag carrier that help him/her to score or at least to all the other team mates.

The splash damage through walls is different though. There are a lot of maps (especially space maps) there this functionality is used as a feature to knock people off from below a platform.

Maybe , but this is a bug in maps like oa_dm1 where the splash damage hits players on the bottom near the MH gate/room and anyway in *dm17 a player cannot stay and spam for ever since he will have to recharge weapons ( admitting that he would be still alive ) ... and this bug affects also UrbanTerror when grenades splash damage hits players through floors and walls too. Actually I think this is another bug affecting physics ( like constant rocket speed ) : in reality a bomb can destroy a wall but if the power is not enough the wall protects who's near the wall on the opposite side of the explosion.



Title: Re: Open Arena Expanded Beta 44
Post by: Udi on November 16, 2009, 08:58:56 am
If you are the flag carrier , you score and you get the assist award , actually I think it's a bug ( logic bug ) : the assist should be awarded to the buddy(ies) near the flag carrier that help him/her to score or at least to all the other team mates.

The capturer only gets the assist award if he/she fragged the enemy carrier, returned the flag, and after a short time (5 secs?) captures the flag. I think it's more logical to award him or her for fragging/returning/capturing and all that really fast. And because it's a complex thing it's very rare so even if it is regarded as a bug it can stay.

and this bug affects also UrbanTerror when grenades splash damage hits players through floors and walls too. Actually I think this is another bug affecting physics ( like constant rocket speed ) : in reality a bomb can destroy a wall but if the power is not enough the wall protects who's near the wall on the opposite side of the explosion.

Changing the rocket speed calculation and fixing the splash damage over walls issue would change gameplay and OA has a rule for that. UrbanTerror on the contrary aims for reality so they fix it, and if a completly new shooter (even space shooter) would be started it should be fixed too, but we are tied to the Q3 legacy.


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 16, 2009, 09:24:09 am
And because it's a complex thing it's very rare so even if it is regarded as a bug it can stay.
I have actually removed it. Not because I consider it a bug but because I find it unlogical that you are awarded for assisting yourself.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 16, 2009, 09:35:06 am
Changing the rocket speed calculation and fixing the splash damage over walls issue would change gameplay and OA has a rule for that.

The rocket speed calculation bug is almost accepted as a feature - see defrag - but the splash damage passing trough walls and floors no , also because they've explicitelly fixed the thing in QuakeLive.

BTW, I've had another - single *sigh* - issue with the 200hp ( better defining it as the "more than 100hp rocket damage" ) rocket damage bug : last saturday I was playing a duel in CPMA on cpm22 map ... I had around 75 hp , no armors ... got the MH coming from the YA place , got 175/170 hp and I was fragged by a rocket launched by my opponent staying near the RL/GA place while jumping and going versus him ... I thought of a prediction error ( anyway I have cg_predictitems set to 0 ) but the MH was not there anymore and he claimed to not get it. I've tried to reproduce it with him after the match end , but had no luck.

I think this is a BUG that occurs in certain circumstances caused by a VM error in calculating damage : I think it's produced because the VM calculates damage without ignoring splash damage while a player is jumping ( not touching the ground ) and is beeing hit by a direct rocket. Maybe it's related to client prediction errors of other kind + world incoerences between VMs ( client1 VM , server VM , client2 VM ) or it's related to client differences ( one faster , another slower ) and/or by an "in action"  lag ... I will continue to investigate the thing .

The -ffast-math switch was removed by the OPTIMIZE string while compiling VM as shared libraries for an analogue reason : it produces some kind of damage errors in certain circumstances , but this bug was reproducible indeed.


Title: Re: Open Arena Expanded Beta 44
Post by: Airwolf on November 16, 2009, 01:47:28 pm
BTW, I've had another - single *sigh* - issue with the 200hp ( better defining it as the "more than 100hp rocket damage" ) rocket damage bug : last saturday I was playing a duel in CPMA on cpm22 map ... I had around 75 hp , no armors ... got the MH coming from the YA place , got 175/170 hp and I was fragged by a rocket launched by my opponent staying near the RL/GA place while jumping and going versus him ... I thought of a prediction error ...

I believe this happens when you are simultaneosly hit by multiple players rather than one, except only one of the sound feedbacks is played back, in your case the RL sound, but maybe u were railed at the same time for example. Also when it has happened that you think you were the one who killed someone with more than 100 HP maybe you hit someone with a handicap lower than 100 which produced the kill.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 16, 2009, 02:14:21 pm
I believe this happens when you are simultaneosly hit by multiple players rather than one,

It happened for me quite always only in duels :/

... but maybe u were railed at the same time for example.

This is true in most ( quite always ) of the cases in CPMA , because of the fast switch weapons , but this time I've asked confirmation to my opponent and he claimed to have shot only a rocket :/

Also when it has happened that you think you were the one who killed someone with more than 100 HP maybe you hit someone with a handicap lower than 100 which produced the kill.

Naa ... I am sure my opponents had no handicap.

Anyway I'll continue to investigate the thing.


Title: Re: Open Arena Expanded Beta 44
Post by: SharpestTool on November 16, 2009, 03:19:35 pm
Sweet...some real conversation in OA about the assist award...

I'm good with whatever gets decided on, just thought it should be in OUR hands and not ioQ3's for our game.

Falkland...was antilag on? 


Title: Re: Open Arena Expanded Beta 44
Post by: davidd on November 16, 2009, 05:08:18 pm

Falkland...was antilag on? 

Yes maybe only your client had registered you picking up the megahealth, but something went wrong with sending that packet to the server. (or was delayed because of ping). So the server had not seen you pick it up, but already hit by the rocket, so 75hp -> killed.

I am not saying this is what happened, i am asking you if this is possibly what happened.

I'll translate the last sentence in my weak french.
Je ne dit pas que cela c'est que se passeee, mais je demande a vous (ou) que c'est comme ca.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on November 16, 2009, 05:54:14 pm
Falkland...was antilag on?  

The OA antilag ( unlagged ) is applied only to insta-weapons that don't have splash damage ( MG , SG , LG , RG, NG , CG ) ... CPMA doens't have a real antilag system : you can adjust your ping/hit issue with a good combination of cg_lagHax , cg_nudge , cg_xerpclients and cg_predict .

And anyway I've never seen this bug on OA081 , only in OA071 ( and this is a good thing :-) )

Yes maybe only your client had registered you picking up the megahealth, but something went wrong with sending that packet to the server. (or was delayed because of ping). So the server had not seen you pick it up, but already hit by the rocket, so 75hp -> killed.

Yes , this makes absolutely sense and could explain what I've seen ( my client registered MH pickup -> prediction error and/or transmission error as a consequence of my higher ping - 98 msec -> get fragged with 75 hp ) , but if so the MH pickup was lost too because it was not there anymore.

And this doesn't explain another action happened in an OA071 duel in which I've fragged my opponent with a single rocket in aggressor map while he was jumping over the YA near the teleport to RG and after he had picked up the MH. (We both had quite the same ping )

Anyway I will continue to investigate the thing and if it would be clear it's an error depending only by my side , I will apologize in public forum ... thank you for reading :-)



Title: Re: Open Arena Expanded Beta 44
Post by: Cacatoes on November 16, 2009, 08:21:33 pm
I'll translate the last sentence in my weak french.
Je ne dit pas que cela c'est que se passeee, mais je demande a vous (ou) que c'est comme ca.
Falkland è italiano, no ? (I don't talk italian at all ;))

"Je ne dis pas que cela s'est passé ainsi, mais je vous demande si c'est le cas"
"Je ne dis pas que ça s'est passé comme ça, mais je te demande si c'est le cas" (more familiar and spoken-like way) ;)


Title: Re: Open Arena Expanded Beta 44
Post by: Neon_Knight on November 21, 2009, 10:45:53 am
When trying to compile the SVN build, I obtain this:

Code:
lcc -DQ3_VM -S -Wf-target=bytecode -Wf-g  -I..\..\..\code\q3_ui -I..\..\..\code\qcommon   ../../../code/q3_ui/ui_rankings.c
../../../code/q3_ui/ui_rankings.c:283: undeclared identifier `grank_status_t'
../../../code/q3_ui/ui_rankings.c:283: warning: expression with no effect elided
../../../code/q3_ui/ui_rankings.c:283: syntax error; found `status' expecting `;'
../../../code/q3_ui/ui_rankings.c:283: undeclared identifier `status'
../../../code/q3_ui/ui_rankings.c:283: warning: expression with no effect elided
../../../code/q3_ui/ui_rankings.c:284: illegal statement termination
../../../code/q3_ui/ui_rankings.c:284: skipping `int'
../../../code/q3_ui/ui_rankings.c:284: undeclared identifier `y'
../../../code/q3_ui/ui_rankings.c:284: warning: expression with no effect elided
../../../code/q3_ui/ui_rankings.c:368: syntax error; found `trap_Cvar_VariableValue' expecting `;'
../../../code/q3_ui/ui_rankings.c:369: undeclared identifier `QGR_STATUS_NEW'
../../../code/q3_ui/ui_rankings.c:369: undeclared identifier `QGR_STATUS_SPECTATOR'
../../../code/q3_ui/ui_rankings.c:378: undeclared identifier `QGR_STATUS_VALIDATING'
../../../code/q3_ui/ui_rankings.c:379: undeclared identifier `QGR_STATUS_PENDING'
../../../code/q3_ui/ui_rankings.c:380: undeclared identifier `QGR_STATUS_LEAVING'


Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on November 21, 2009, 10:48:56 am
When trying to compile the SVN build, I obtain this:
How do you compile? System? Scripts?


Title: Re: Open Arena Expanded Beta 44
Post by: fromhell on November 21, 2009, 12:10:50 pm
Can you put my graphics crap in there pleaeese?


Title: Re: Open Arena Expanded Beta 44
Post by: Neon_Knight on November 21, 2009, 12:13:43 pm
When trying to compile the SVN build, I obtain this:
How do you compile? System? Scripts?
I've ran the bat file for both cgame, game and ui.


Title: Re: Open Arena Expanded Beta 44
Post by: SharpestTool on November 21, 2009, 12:57:49 pm
Neon are you trying to build on windows?

"ui_rankings.c" should not be in the batch file...but somehow it is, oh well not a big issue...There are two steps to the batch file.   

The first, which this issue comes from is "LCC" compiling to assembly code...it does this for each individual code file.  When "LCC" tries to compile "ui_rankings.c" it will come across several variables, functions, etc which are undefined.  Blah...no biggie...

The second step, is when "q3asm" takes all those files of "assembly code" and puts em together to form the QVM file. 
If you get an error relating to "ui_rankings.c" here, that means it was unfortunately included in the build script. 

To check and make sure the build was successful, look into the windows/baseoa directory (for the svn source), if the file "ui.qvm" is present your build was successful.


Title: Re: Open Arena Expanded Beta 44
Post by: Neon_Knight on November 21, 2009, 01:13:11 pm
Yep, I'm compiling from Windows. And yep, ui was compiled succesfully, but I didn't tested it yet.
Just pointed those errors. :P


Title: Re: Open Arena Expanded Beta 44
Post by: SharpestTool on November 24, 2009, 12:30:07 am
This is my screw-up Neon. 

It's like one of those obvious things people are just supposed to do but somehow screw up lol.

I've got a version of those batch files that won't throw those errors in my local copy of the source.  I just never thought to commit it to the OAX SVN, because every release that's ever been done, Sago has built under linux and not windows.

I should probably get around to doing that...


Title: Re: Open Arena Expanded Beta 44
Post by: Cacatoes on December 25, 2009, 02:37:01 pm
A very little thing to improve, not sure it's in QVM: we have to wait 5 seconds to switch team, sometimes I make the mistake to select a team I'm already in, and I have to wait for another 5 seconds :D so ... if the player is making a mistake selecting a team he's already in he shouldn't have to wait ;) (or maybe our own team could be a grayed option)

There are details like that ... lol

---

While I'm at it, another little feature request: ability to mute someone (as a player), I've seen it's being implented admin-side but better if anyone can do that. Sorry if it's already done.

Other thing, make "autoswitch weapons" off by default, I somehow feel embarassed when I see some beginner play OA and switch weapon as soon as he gets one :D. I wonder if this feature ever had any use, I think most people disable it. After all it's still a good point if you can start OA and start playing without even having to change anything.

I also thought about some way to calculate score on a CTF match, making the score depend on how far the player is from his own flag when he frags. That would mean staying near our own spawn points or near our own flag would bring less points, whereas killing someone when being near the ennemy flag would bring more. I fear however it wouldn't solve every situation, I tend to think it should be more rewarding to take the risk to cross the map (attacking then) than staying in defense, maybe this isn't an issue for every CTF map. Was Just an idea, sorry for being a bit offtopic ;)


Title: Re: Open Arena Expanded Beta 44
Post by: Neon_Knight on January 02, 2010, 10:25:37 pm
Could I ask for something? To replace the name of cvar fairflags to a more generic and neutral name, such as sv_advancedflags or sv_restrictedflags.


Title: Re: Open Arena Expanded Beta 44
Post by: Falkland on January 12, 2010, 10:14:41 am
I've seen that OAX includes (r192) now "/clients" command to properly display clients connected by slot :

Why not renaming it as in OSP/CPMA like "/players" ?

Why not adding the same other useful information that /players gives in OSP/CPMA ( rate/snaps/cl_maxpackets ) ?

Code:
 slot score ping name rate snaps maxpkts
  ---- ----- ---- ---- ---- ----- -------
....

EDIT : and /or also delag and timenudge , IP ?

Code:
 slot score ping name rate snaps maxpkts delag timenudge IP
  ---- ----- ---- ---- ---- ----- ------- ----- --------- --
....

The thing could be regulated by another cvar that should establish which kind of infos are diplayed : basic or extended

basic : slot , score , ping , name
extended : rate , snaps , maxpkts , delag , timenudge , IP

Or the cvar could assume a bitmask value to establish which players ' infos should be diplayed ( default is basic infos )






Title: Re: Open Arena Expanded Beta 44
Post by: sago007 on January 12, 2010, 11:48:32 am
I've seen that OAX includes (r192) now "/clients" command to properly display clients connected by slot :

Why not renaming it as in OSP/CPMA like "/players" ?

Why not adding the same other useful information that /players gives in OSP/CPMA ( rate/snaps/cl_maxpackets ) ?
I didn't know about "/players". Never played CPMA. I might have auto downloaded OSP for ET at some point but never entered a single console command.

My only idea with /clients was to get clientnumbers and the reason scores are printed too is to separate players that are hard to separate by name. I get the information from the scores list so scores are given for free without having to contact the server.

I did consider sending the request to the server, so the server could send even more information, but it seemed a waste at the time.

Main problem with checking the scoreboard is that the scoreboard is not available until the first kill/death. But it is early in the match to call a clientkick.


Title: Re: Open Arena Expanded Beta 44
Post by: madghost on February 23, 2010, 07:43:10 pm
has the demo problem been fixed yet in 0.8.5?? all of the i remember getting the rc and tried watching demos and i get a registered items error ( i dont remember the exact words) but since this new release for 0.8.5 came out, has it been fixed, id download and try, but my connection makes that difficult.


Title: Re: Open Arena Expanded Beta 45
Post by: sago007 on May 11, 2010, 11:09:32 am
Beta 45 is up.

Change log:
Quote
New in Beta 45:
* Fixed TEAMMATE kill message bug.
* Added g_autonextmap that automatically changes maps on game end
* Added g_autonextmap to the start server menu. Added to the map select place as the gui is rather full at the moment.
* motd.cfg can now be configured to look for a different file with g_motdfile
* elimination_roundtime 0 does no longer stop matches imidiently.
* stopped some broadcasts during intermission. Hopefully reduced the risk of a netchan error.
* Workaround for Kamikaze bug
* No longer asks the user before quitting from the menu

Mostly bug fixes with g_autonextmap as a big exception.


Title: Re: Open Arena Expanded Beta 45
Post by: Cacatoes on May 29, 2010, 08:32:50 am
Yo,

  * What you did to g_admin, to select a different file in the hard drive, is it a good idea to do the same for g_vote ? Note: problem solved when using a different mod.
  * Only 8 slots for custom votes, no way to list some more like you did with callvotable maps ? This may not be necessary if new UI in future versions solve the problem...


Title: Re: Open Arena Expanded Beta 45
Post by: sago007 on May 29, 2010, 10:01:37 am
I have added a g_motdfile. Originally I removed a lot of them from patches because there was a low cvar limit. But newer engines solves that problem so I have started to add them again.

It was SharpestTool that added g_admin. I believe that it is originally a workaround for an autodownload bug in Enemy Territory. You could autodownload any files except the main configuration file if you knew the filename, so the main file contained a lot of randomized filenames for all sub files.

I find that my solution for selecting multiple maps in the vote menu has some problems online. I have a feeling that the engine drops "unnecessary" packets but I am not sure about the criteria used.


Title: Re: Open Arena Expanded Beta 45
Post by: Gig on July 02, 2010, 02:52:45 am
I tested the new behavior of \elimination_roundtime 0.
Nice, thank you very much! :)

But I suggest to make it behive the old way when using LMS mode with Overtime activated. Before, it went immediately to Overtime mode (substracting health as time passes), allowing for very quick matches. Now (remember: I'm talking about elimination_roundtime 0) the two "score options" with overtime work exactly like the two without overtime: it never goes to overtime mode and you play until there is only one player alive.

You can find my suggestion in the table I prepared (http://openarena.wikia.com/wiki/Talk:Elimination#Roundtime) when I proposed the modify... it is more clear there.

What do you think about it?

I'll end with a couple of suggestions:
- I've heard that managing these menus is very hard... anyway, could you try do add the elimination_roundtime to the GUI? Also an option for enabling g_elimination when using other gametypes would be nice (like there is for enabling "all rockets" or "instagib")... I suppose many people would like g_elimination, if only they know about its existence...
- The new function to automatically switch maps is nice, but I think it would be better, in the skirmish menu, to have the "gametype selector" below the map screenshots, as ever been. I suggest to put the auto map switch option above and the gametype below.


Title: Re: Open Arena Expanded Beta 45
Post by: sago007 on July 07, 2010, 12:17:59 pm
But I suggest to make it behive the old way when using LMS mode with Overtime activated. Before, it went immediately to Overtime mode (substracting health as time passes), allowing for very quick matches. Now (remember: I'm talking about elimination_roundtime 0) the two "score options" with overtime work exactly like the two without overtime: it never goes to overtime mode and you play until there is only one player alive.

You can find my suggestion in the table I prepared (http://openarena.wikia.com/wiki/Talk:Elimination#Roundtime) when I proposed the modify... it is more clear there.

What do you think about it?
I read the suggestions and I can see the point.

Making 0 count as unlimited is a special case. Adding the old behavior in Overtime mode would be another special case. Special cases makes the code harder to manage. One could just set the time to 1 second. Like one could just set the time to 3600 seconds before.

I'll end with a couple of suggestions:
- I've heard that managing these menus is very hard... anyway, could you try do add the elimination_roundtime to the GUI? Also an option for enabling g_elimination when using other gametypes would be nice (like there is for enabling "all rockets" or "instagib")... I suppose many people would like g_elimination, if only they know about its existence...
- The new function to automatically switch maps is nice, but I think it would be better, in the skirmish menu, to have the "gametype selector" below the map screenshots, as ever been. I suggest to put the auto map switch option above and the gametype below.
- g_elimination would make even more sense if there was a page for changing the elimination_* cvars
- I stated by adding the auto change map in the top. It felt wrong. The flow became weird having to start in the middle by selecting gametype going up to select map, going further up to consider autochange and finally go to the buttom to start the game.

Time has been a limited resource lately. Hopefully the good times will return. I might just upload the current progress in a few hours to get the latest progress displayed for the people that does not compile from svn.


Title: Re: Open Arena Expanded Beta 45
Post by: sago007 on July 07, 2010, 01:44:45 pm
Beta 46 is up

Changelog
Quote
New in Beta 46:
* Added note to handicap option in menu
* Added g_maxvotes to allow the server admin to pick a value.
* Added g_spawnprotect - milliseconds of invulnerability after spawning.
* Added replace_* cvars like disable_*. Can be used like "set replace_weapon_shotgun weapon_bfg" for replacing shutgun by BFG.
* Added Evil.HD.unOA's accuracy display although it cannot be bound in the menu.
* PlayerStore now records time and accuracy
* You can now use black charecters in your name provided that there is at least one non-black alphanumeric charecter
* Now uses FFA spawnpoints in domination
* Sort by human players in the menu is now remembered and recovered upon return
* Added option for changing some files: g_votemapsfile and g_votecustomfile
* Some code cleanup


Title: Re: Open Arena Expanded Beta 45
Post by: Gig on July 08, 2010, 02:40:19 am
But I suggest to make it behive the old way when using LMS mode with Overtime activated. Before, it went immediately to Overtime mode (substracting health as time passes), allowing for very quick matches. Now (remember: I'm talking about elimination_roundtime 0) the two "score options" with overtime work exactly like the two without overtime: it never goes to overtime mode and you play until there is only one player alive.

You can find my suggestion in the table I prepared (http://openarena.wikia.com/wiki/Talk:Elimination#Roundtime) when I proposed the modify... it is more clear there.

What do you think about it?
I read the suggestions and I can see the point.

Making 0 count as unlimited is a special case. Adding the old behavior in Overtime mode would be another special case. Special cases makes the code harder to manage. One could just set the time to 1 second. Like one could just set the time to 3600 seconds before.
I understand. This makes me a little sad, but it's ok. Inform me if you change your mind. If the things will remain this way, when I will update the Elimination help page when 0.8.6 will come out, I'll have to remember to specify that with that time 0, LMS with and without overtime will work the same way, and if one wants immediate overtime can set the time to 1 second.

I had another proposal about Elimination mode, that needed another CVAR... do you want to hear it? It is not related to the "roundtime"...

Quote from: sago007
- g_elimination would make even more sense if there was a page for changing the elimination_* cvars
It would be really a nice idea... but you told me that managing these menus is very difficult, right? If you think you can use your time to create a whole new page in the menu for them (maybe putting inside it also the "disable (http://openarena.ws/board/index.php?topic=3460.msg33562#msg33562)" and "replace" settings), you have my approval, but I'm sorry I can't help you with nothing but ideas... :(


Title: Re: Open Arena Expanded Beta 45
Post by: sago007 on July 08, 2010, 09:33:18 am
I had another proposal about Elimination mode, that needed another CVAR... do you want to hear it? It is not related to the "roundtime"...

Quote from: sago007
- g_elimination would make even more sense if there was a page for changing the elimination_* cvars
It would be really a nice idea... but you told me that managing these menus is very difficult, right? If you think you can use your time to create a whole new page in the menu for them (maybe putting inside it also the "disable (http://openarena.ws/board/index.php?topic=3460.msg33562#msg33562)" and "replace" settings), you have my approval, but I'm sorry I can't help you with nothing but ideas... :(
You are always welcome to come with ideas.

Yes managing menues are hard... and that is why making that system easier would be something that should be done first. At one point I looked into the possibility to use mp-menu files for submenues in settings, they did not use the push and pop system from the classic UI, so combining them would be non-trivial. However it would open for a lot more configurable options and the settings pages would be a great place to start.


Title: Re: Open Arena Expanded Beta 45
Post by: Gig on July 08, 2010, 09:57:16 am
You are always welcome to come with ideas.

Ok. Elimination mode needs that a team has two points of difference, to win, else the game will continue until this gap is reached, even if the timelimit or capturelimit has been hit various rounds before. I never noticed a similar rule in OSP CA (I don't even remember, if the timelimit was hit, if a match could end with a draw or not), anyway this is OpenArena Elimination and does not need to be exactly the same as OSP CA... but the problem is that, with this rule and teams with similar skills, a match could continue for a long time (for example, could end at 16-14 when the initial capturelimit was 8.... you stay at the PC much more time than you foreseen and your mother/girlfriend/wife gets angry), virtually infinite.

Okay, nowadays Elimination mode has almost no public servers online and thus probably there are not many OpenArena Clans that play it, but in the future it could became more popular (I hope OpenArena will became more popular), it has the potential to do it. So, in the future, we can imagine two clans with the same skill that fight the same match for hours... Like some Tennis matches.

I suggest to create a variable to give the opportunity to disable the need of two rounds of gap to win, in order to prevent this possible problem. The variable could be boolean (enable or disable the gap of two), or numeric, specifying the gap requested to win... 1, 2, 3... maybe with 0 a match could even end in a draw when the timelimit is hit, it's just an idea (obviously, 2 could remain the default value). What do you think about it?



Title: Re: Open Arena Expanded Beta 46
Post by: Gig on July 28, 2010, 01:19:32 pm
Sago, no answer?  ???


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on July 28, 2010, 02:15:08 pm
Sago, no answer?  ???
I did not have anything insightful to say.

I might make a spawn cvar to controll it, so only one is required by default but map makers can force the demand for winning by 2 if the map design suggests it.


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on July 28, 2010, 02:22:21 pm
Uhm... controlled by the map designer? I supposed a similar thing was more adapt to be controlled by the server admin...


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on July 28, 2010, 02:44:26 pm
Uhm... controlled by the map designer? I supposed a similar thing was more adapt to be controlled by the server admin...
When I originally designed Elimination many years ago my plan was that it was supposed to be played on completly unfair maps where one team had an extreme advantage. That is why Elimination uses team spawnpoints if they exist and it is the reason the teams switch sides every round. The win by 2 was created to ensure that the winning team wont simply be the team that happens to be playing the advantage round first.

I never got around to make my proof of concepts maps and therefore they do not exist. So there are really no maps that need the winning by two and if they are ever designed the map designer will know.


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on July 28, 2010, 03:22:37 pm
I understand. It would be nice to have a pair of maps created that way...

So, since there are no maps designed this way, your idea is to make the "winning gap" to 1 instead of 2 like it is now? And giving the map designers the ability to change that limit... I suppose it would be good to add explainations on the Wiki, so if someone wants to create such kind of map can change that limit (obviously, if you will add the feature).... I suppose there aren't many mapping guys around that know about your (nice) old idea about the "unbalanced" Elimination maps...

It could be nice, also if it's not what I thought.... but I didn't imagine the "source" of the gap of 2... I thought it was simply to be sure that a team doesn't win only for luck...

I don't know what is the best thing to to... If someone else could come here (this thread isn't very popular) and tell us his opinion...


Title: Re: Open Arena Expanded Beta 46
Post by: GrosBedo on August 12, 2010, 01:22:33 am
Bug report, tested with the OAX version supplied in OA 085 (so maybe it's already fixed) :

1- When killed by CHAINGUN, the game reports that player was killed by MOD_MACHINEGUN instead of MOD_CHAINGUN.

2- The ammo regen rune doesn't work on machinegun nor chaingun.


Title: Re: Open Arena Expanded Beta 46
Post by: Cacatoes on August 14, 2010, 01:50:39 pm
Something changed on latest OAX with customvotes.
It doesn't parse take into account votecustom.cfg file. It should find it because when I remove oax.pk3 custom votes work back.
Is it mandatory to specify a vote file or is there a default one chosen ? I tried to specify one but had no success.


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 14, 2010, 01:55:02 pm
Bug report, tested with the OAX version supplied in OA 085 (so maybe it's already fixed) :

1- When killed by CHAINGUN, the game reports that player was killed by MOD_MACHINEGUN instead of MOD_CHAINGUN.

2- The ammo regen rune doesn't work on machinegun nor chaingun.

1. there has always been problems but I thought I fixed them.

2. sounds like a bug, I believe both should regenerate to 100 shots.

Something changed on latest OAX with customvotes.
It doesn't parse take into account votecustom.cfg file. It should find it because when I remove oax.pk3 custom votes work back.
Is it mandatory to specify a vote file or is there a default one chosen ? I tried to specify one but had no success.

It should just work... must be a bug introduced then allowing to change the filename.


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 16, 2010, 08:59:57 am
2- The ammo regen rune doesn't work on machinegun nor chaingun.

Tested (using the stuff provided with OpenArena 0.8.5, not any new OAX or executable version) under "the mission pack", and tried it in map czest3ctf. It brings machinegun ammo up to 50 and chaingun ammo up to 100, I suppose correctly.

I'd like to test it under "basea", but I don't know what maps contain it. And \give ammoregen does not work, I don't know what's the name of this rune for the "give" cheat...


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 16, 2010, 09:56:38 am
I'd like to test it under "basea", but I don't know what maps contain it. And \give ammoregen does not work, I don't know what's the name of this rune for the "give" cheat...

The same maps as in missionpack if g_runes is 1 (unless the map explicitly disabled them for baseoa by using the notq3a flag). oasago1f1 and islandctf4a3 have them, they are both found in the map thread


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 16, 2010, 11:55:57 am
I'd like to test it under "baseoa", but I don't know what maps contain it. And \give ammoregen does not work, I don't know what's the name of this rune for the "give" cheat...

The same maps as in missionpack if g_runes is 1 (unless the map explicitly disabled them for baseoa by using the notq3a flag). oasago1f1 and islandctf4a3 have them, they are both found in the map thread
Ops... I did not remember that map was available also in baseoa... I'm sorry. (But you mean that every missionpack map is available also in baseoa? I never checked this, I thought that some maps were included only in the addon pack.)

Anyway, testing from Baseoa, it seems to work with OA 0.8.5... and also withOAX B46.
Grosbedo, can you do some more tests and confirm you experience the bug?


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 17, 2010, 12:22:00 pm
I have been unable to reproduce the ammoregen bug too.

About the "votecustom.cfg" I found the problem. The default filename was "votecustomfile.cfg" and then changed ingame it did not reload the file. The cvar is not an archive cvar, so it must be set each time. I'll change the default value to votecustom.cfg for backward compatibility. I might try to see if I can reload it then changed ingame too.


Title: Re: Open Arena Expanded Beta 46
Post by: MyLittlePwny on August 17, 2010, 08:12:17 pm
For some reason running the OAX mod makes all sound in the game go away. (Sound still works fine in regular OA though.)

I suppose that it could be that I have a setting wrong somehow, or it could just be related to Win7. (Trying to remember if I'm using the OEM WinXP drivers or the generic Win7 sound drivers, though...?)

Is there a log file I should check for specific error messages or anything?


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 18, 2010, 01:07:51 am
Are you sure this happens with OAX mod only, and not with any mod?

I know there is a problem that causes the sound stop working with any mod, when using the SDL (standard) audio system. I wrote a FAQ about it here (http://openarena.wikia.com/wiki/FAQ#When_I_launch_a_Mod.2C_the_sound_stops_working).

I found two workarounds:
- launch the mod from command line (openarena.exe +set fs_game modfolder)
or
- install and enable OpenAL sound library.

I don't know if this problem is specific for OpenArena or affects also other games that use the ioquake3 engine. I don't even know if it affects only OA 0.8.5 or also previous versions of the game.

I pointed out this problem before, but I don't know if some developer has already checked and found it cause or not...


Title: Re: Open Arena Expanded Beta 46
Post by: MyLittlePwny on August 18, 2010, 09:01:27 am
Oops. Looks like launching it from the command line fixed it. Sorry about that. ^_^;;

(I wonder why I don't have that problem when I go on the ScrewOA Corkscrew server then? Doesn't it load that mod when I connect there?)

Also, this may or may not be relevant to what triggers it, but I tried a few things just to see what would happen.

- Loading OAX from the OA "Mods" menu - sound goes away.
- Loading regular OA from the "Mods" menu in OAX - the sound stays gone
- Loading the regular OA from the regular OA "Mods" menu (without loading OAX first) - sound stays okay.


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 19, 2010, 01:36:48 am
(I wonder why I don't have that problem when I go on the ScrewOA Corkscrew server then? Doesn't it load that mod when I connect there?)
I don't know (I'm not a developer)... but maybe the problem is caused by (or someway connected to) the "mods" menu, and if you connect to a server from the server broser of "baseoa", and that server uses a mod, your game switches from baseoa to the mod without pass through the "mods" menu, getting around from the bug. It is just an idea...

Fromhell, Sago007... could you please take a look to this problem?


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 19, 2010, 08:35:54 am
I think the sound problem is a race condition in the sound system where the the new mod tries to start the sound system before the old mod has fully released it. It does not trigger while joining a server because the process of joining takes ressources too.

That is just a guess. Race conditions are random in nature and can be very timing and OS dependent. I do not experience the problem


Title: Re: Open Arena Expanded Beta 46
Post by: Falkland on August 19, 2010, 10:02:02 am
I also don't have/did not experiment this problem , but I should say I don't even have openal support compiled in my binaries.


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 19, 2010, 10:17:51 am
Race conditions are random in nature and can be very timing and OS dependent. I do not experience the problem

I experienced this with at least 2 PC with WindowsXP, and MyLittlePwny with Windows7.
For your test, are you sure you disabled OpenAL (\s_useopenal 0) in both baseoa and the mod's configuration, closed OpenArena and tried again?

Do you have the standard openarena.exe (and SDL.dll) as provided with OA 0.8.5?
I did not test with the latest test executable yet...
UPDATE: I just tried with openarena.x86.exe included in openarena-engine-bin-0.8.x-16.zip.... Same problem.


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 19, 2010, 10:44:15 am
Do you have the standard openarena.exe (and SDL.dll) as provided with OA 0.8.5?
I shall admit that I used openarena.x86_64 binary and have not yet tried to change mods under Windows.


Title: Re: Open Arena Expanded Beta 46
Post by: MyLittlePwny on August 19, 2010, 12:31:49 pm
I suppose the quick-and-dirty workaround would be to have a helper program, where all it does is wait for OA to fully close, them launch it again with the specified mod. Basically, it'd work like this:

- You select a mod in the mods menu.
- OA launches the helper program, specifying the mod selected.
- OA closes itself.
- The helper program waits until OA is fully closed.
- The helper program launches OA with the proper mod specified.
- The helper program closes itself.

A batch file similar to the helper program might resemble this:
Code:
@echo off
REM Wait for OA to fully close
pause (Yes, not quite the same, but the closest equivalent...)
REM Load the mod
openarena.exe +set fs_game %1
REM close dos window
exit


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on August 19, 2010, 12:34:53 pm
I looked at libsdl.org. A possible cause is that the video and sound subsystem must be loaded in a specific order in Windows. If the video system is restarted the sound system must be restarted as well, other operationg systems does not need that. Still I think the likely solution is to include openal.dll


Title: Re: Open Arena Expanded Beta 46
Post by: MyLittlePwny on August 19, 2010, 01:00:07 pm
A possible cause is that the video and sound subsystem must be loaded in a specific order in Windows. If the video system is restarted the sound system must be restarted as well.
I just tried testing for that, here's what I tried, and what happened:

- Load plain OA. Sound is fine.
- Load Corkscrew from the Mods menu.
- Sound is now dead.
- Run snd_restart from the console.
- Appears to restart the whole game? Corkscrew is still loaded afterwards though.
- Sound is working, in Corkscrew, using the mods menu for it rather than loading it from the command line or loading it connecting to a server.

Looks like you may be right about load order. Any way to automate forcing it to snd_restart after loading a mod from the menu?


Title: Re: Open Arena Expanded Beta 46
Post by: Gig on August 19, 2010, 01:34:55 pm
I tried with another mod... I can confirm that a \snd_restart makes the audio return.
In the next realease, I suppose it should be automated somehow...

Maybe a look to the original Q3A source code... It does not have this problem... (but I don't know if it uses SDL or another different sound system)

In the meanwhile, I've updated the FAQ on the wiki...


Title: Re: Open Arena Expanded Beta 46
Post by: fromhell on September 08, 2010, 06:37:40 am
Holy crap, it's a renderer patch!



- Adds r_envmode which
      0 - old original environment mapping
      1 - slightly enhanced environment mapping (uses origin and axis now) (DEFAULT)
      2 - reflection mapping i.e. Odin's tremulous patch

- Adds r_specmode which
      0 - old "broken" specular
      1 - new specular that reflects from nearest light (fix nicked from zeq2 lite, thanks to them) (this also allows weapon models to have specular shaders) (DEFAULT)

- Adds r_flaresDlight which puts flares on any dynamic light. It's broken in some parts (i.e. model occlusion)

- flares now take a radius parameter internally

- r_flares 1337 softens the fadeoff to make r_flaresDlight a bit more tolerable

- r_lensReflections1 is default to 0

- r_flaresSurfradii is supposed to make surface flares bigger depending on the size of their surface, but this is broken

- commented out ambitious r_waveMode stuff (make deformVertices wave dynamic rippling of any entities in it like water. I was going to do this from mangling Scorched3D files, but... didn't. Dunno why it's in this patch. It's only a cvar space for now)


I diffed the working folder I had, so the patch includes stuff I didn't do (bloom)


Title: Re: Open Arena Expanded Beta 47
Post by: sago007 on September 17, 2010, 01:55:58 pm
Well changes has accumulated over time.

Beta 47 is up, based on OAX r238.

Changelog:
Code:
New in Beta 47:
* Prevent team changing and disconnect from changing team score in Team Deathmatch
* Don't lake vampire resurrect dead players.
* Sets sv_dorestart in case players wants to change variables in game.
* Now only loads the important things if g_elimination or g_instangib is set (no pickups)
* Changed default customvotefile to customvote.cfg
* Added the possibility for spawning in waves. The cvar g_respawntime says how often players should spawn.
* Added a CVAR g_voteBan X - bans a player for X minutes using the KK-admin system
* Handicap is reset to 100 once returned to the main menu
* Added g_gravityModifier (default 1.0) that modifies g_gravity relatively to the value set by the map

The voting system must properly be changed to prevent accidents when players that is being vote kicked leaves before the vote ends. This has always been a problem but gets worse with g_voteBan that bans players for some minutes if they have been kicked by voting.

Note that sv_dorestart requires new binaries (-17 or newer). It caused all items to be reloaded upon map_restart. Use "map MAPNAME" instead if you use an older engine.


Title: Re: Open Arena Expanded Beta 46
Post by: sago007 on September 17, 2010, 02:58:49 pm
Holy crap, it's a renderer patch!
I have some problems applying the patch:
Code:
patch --dry-run -p0 < newrenderer.patch
(Stripping trailing CRs from patch.)
patching file tr_backend.c
Hunk #1 FAILED at 944.
Hunk #2 FAILED at 1119.
Hunk #3 FAILED at 1147.
Hunk #4 FAILED at 1156.
4 out of 4 hunks FAILED -- saving rejects to file tr_backend.c.rej
(Stripping trailing CRs from patch.)
patching file tr_bloom.c
(Stripping trailing CRs from patch.)
patching file tr_flares.c
Hunk #1 FAILED at 77.
Hunk #2 FAILED at 112.
Hunk #3 FAILED at 196.
Hunk #4 FAILED at 241.
Hunk #5 FAILED at 283.
Hunk #6 FAILED at 314.
Hunk #7 FAILED at 323.
Hunk #8 FAILED at 371.
Hunk #9 FAILED at 413.
Hunk #10 FAILED at 464.
10 out of 10 hunks FAILED -- saving rejects to file tr_flares.c.rej
(Stripping trailing CRs from patch.)
patching file tr_init.c
Hunk #1 FAILED at 161.
Hunk #2 FAILED at 709.
Hunk #3 FAILED at 1013.
Hunk #4 FAILED at 1088.
4 out of 4 hunks FAILED -- saving rejects to file tr_init.c.rej
(Stripping trailing CRs from patch.)
patching file tr_local.h
Hunk #1 FAILED at 871.
Hunk #2 FAILED at 1118.
Hunk #3 FAILED at 1331.
Hunk #4 FAILED at 1370.
Hunk #5 FAILED at 1521.
Hunk #6 FAILED at 1538.
Hunk #7 FAILED at 1711.
7 out of 7 hunks FAILED -- saving rejects to file tr_local.h.rej
(Stripping trailing CRs from patch.)
patching file tr_shade.c
Hunk #1 FAILED at 885.
Hunk #2 FAILED at 1015.
Hunk #3 FAILED at 1130.
3 out of 3 hunks FAILED -- saving rejects to file tr_shade.c.rej
(Stripping trailing CRs from patch.)
patching file tr_shade_calc.c
Hunk #1 FAILED at 914.
Hunk #2 FAILED at 1092.
2 out of 2 hunks FAILED -- saving rejects to file tr_shade_calc.c.rej
(Stripping trailing CRs from patch.)
patching file tr_surface.c
Hunk #1 FAILED at 1216.
1 out of 1 hunk FAILED -- saving rejects to file tr_surface.c.rej


Title: Re: Open Arena Expanded Beta 47
Post by: fromhell on September 20, 2010, 11:35:17 am
I think the patch is to apply on ioquake3 rather than the changed OA files themselves.


Title: Re: Open Arena Expanded Beta 47
Post by: Gig on September 20, 2010, 12:37:43 pm
Beta 47 is up, based on OAX r238.
New in Beta 47:
* Prevent team changing and disconnect from changing team score in Team Deathmatch
Tested. The description is not exact, since it does change the score (the old teams gets -1 instead of +1 like before... I think it's correct since its the Q3 behavior.)
Quote
* Added g_gravityModifier (default 1.0) that modifies g_gravity relatively to the value set by the map
Tested. This allows to change the gravity without having it resetted after a map restart. Good work, man!
Quote
* Handicap is reset to 100 once returned to the main menu
Tested, but I'm not sure I like it. I like to set an option and to have it stay like I want it. Maybe placing a message somewhere, like "Warning: you have Handicap enabled. Are you sure?/Please check", would be better from this aspect....


Title: Re: Open Arena Expanded Beta 47
Post by: SharpestTool on September 20, 2010, 04:56:34 pm
Sorry I have been awol...

I'm not sure there was ever a deal about the admin system being linked to http downloading.   Keep in mind if it has anything to do with ET it's because the original author of the code (code which I adapted from tremulous a gpl project) first implemented it in ETPub. 

I'll do some feature  work here and there with it for ya'll but overall it was meant for kicking (temp banning), banning, muting, warning to give admins various levels of privledged control over what they can and can't do. 

The changing teams message when changing to your own team by accident I think can be changed.  A simple check from the command's trap_argv to the player's team in session, before the time limit check prompting an early out of the code would suffice.

Also, the killing sprees and multikills were meant to allow servers to create their own content pk3's and customize their own player experience.  It should be turned off by default AND the default spree config file was only meant to serve as an example. 

I think the vote to temp ban should work if theres a default admin passed to the command.  I haven't seen the source to see how its implemented but the admin code for the ban I believe checks for the permission and the duration of the ban.

I'm not sure I comitted this change before I went awol BUT
there was a nasty lag bug from the spree code where it would cause the client to lag as the  server indexed the sounds the first time they were played and sent to the client.  I fixed that by having the sounds indexed as they were parsed from the config file. 

Man I've been away a long time.  oh well I'm back for now...

BTW Sago, ET's entire source was gpl'd.  We should look at the stats handling code in it that was originally written by the OSP team.  After my bug fixing of course.  :P


Title: Re: Open Arena Expanded Beta 47
Post by: sago007 on September 21, 2010, 08:07:47 am
* Handicap is reset to 100 once returned to the main menu
Tested, but I'm not sure I like it. I like to set an option and to have it stay like I want it. Maybe placing a message somewhere, like "Warning: you have Handicap enabled. Are you sure?/Please check", would be better from this aspect....
If you are good enough to use handicap you should bind it. Even if you use it the setting will always depend on who you play against.


Title: Re: Open Arena Expanded Beta 47
Post by: sago007 on September 21, 2010, 08:11:54 am
Also, the killing sprees and multikills were meant to allow servers to create their own content pk3's and customize their own player experience.  It should be turned off by default AND the default spree config file was only meant to serve as an example. 
Well that cannot be changed now until 0.9.0. It is included.

Quote
I think the vote to temp ban should work if theres a default admin passed to the command.  I haven't seen the source to see how its implemented but the admin code for the ban I believe checks for the permission and the duration of the ban.
The "console" admin has unlimited rights. It is the console admin that temp bans players then votekicked. And it works.


Title: Re: Open Arena Expanded Beta 47
Post by: Gig on September 21, 2010, 02:41:42 pm
* Handicap is reset to 100 once returned to the main menu
Tested, but I'm not sure I like it. I like to set an option and to have it stay like I want it. Maybe placing a message somewhere, like "Warning: you have Handicap enabled. Are you sure?/Please check", would be better from this aspect....
If you are good enough to use handicap you should bind it. Even if you use it the setting will always depend on who you play against.
It is true that it depens from who I am against. But if, for example, I'm playing with my clan (or with my friends over LAN), probably I will want to have it the same for the next hours, even if I disconnect and reconnect to the server. But I understand that it is a not-so-common situation. A question: does it reset the value only when I come back to the main menu after I was effectively playing, or also if I disconnect when I still was connecting (ex: automatic download not started or interrupted, or a network problem)?


Title: Re: Open Arena Expanded Beta 47
Post by: Gig on September 22, 2010, 03:12:55 am
A question about a thing added in OAXB45 (two betas ago)..
Quote
* No longer asks the user before quitting from the menu
Why this?  ???


Title: Re: Open Arena Expanded Beta 47
Post by: sago007 on September 22, 2010, 09:12:00 am
A question about a thing added in OAXB45 (two betas ago)..
Quote
* No longer asks the user before quitting from the menu
Why this?  ???
Why would the user choose exit if the intention wasn't to leave the game? The dialog could as well say "You have chosen Quit. Is that because you want to leave the game". It takes just a few seconds to start the game again anyway. 

Choosing Leave game while ingame does not ask at all even though the effect are much more serious. Potentially you cannot rejoin.


Title: Re: Open Arena Expanded Beta 47
Post by: Cacatoes on December 03, 2010, 06:14:04 am
Suggestion I think I mentionned long ago:
- make time during which a player joined a game persistent. Right now, only frag count is persistent and kept even when changing team. The score table isn't as much relevant as before if times are not properly given.


Title: Re: Open Arena Expanded Beta 47
Post by: sago007 on December 03, 2010, 01:44:19 pm
- make time during which a player joined a game persistent.
It was implemented in revision 218.


Title: Re: Open Arena Expanded Beta 48
Post by: sago007 on February 24, 2011, 12:48:28 pm
A small update is out. Mainly with some enhancements to make it more logging friendly.

Changelog:
Quote
New in Beta 48:
Remove the "Click to respawn" message if you are spectator or if the gametype is Elimination,CTF Elimination or LMS
sessionTeam is now set for bots. this should stop them from doing stupid things
Added a "!gametpe" flag parrallel to "gametype", so map makers can disable items in given gametypes without affecting all furture gametypes
Changes to logging to make it possible to get more information. This includes log messages for most gamestype events except LMS.


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on February 24, 2011, 12:56:19 pm
Would it be possible to get a new OA patch out of this?


Title: Re: Open Arena Expanded Beta 48
Post by: Gig on February 24, 2011, 01:43:50 pm
Interesting. Not tested yet, but sounds very good, Sago! :-) Anyway I think that, before a new release, it would be good to see if it is possible to fix some more of the other bugs... I understand it's not possible to fix them all, but maybe some of them...
http://openarena.wikia.com/wiki/Bugs


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on February 25, 2011, 08:48:56 am
I'll be taking care of the map-specific bugs.


Title: Re: Open Arena Expanded Beta 48
Post by: sago007 on February 25, 2011, 10:33:57 am
but maybe some of them...
Not all of the bugs are connected to game logic and a few are design choices.

However the must important bugs related to OAX are (in order of importance):
Vote abuse
Tourney queue
Fire from dead body


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on February 25, 2011, 01:28:48 pm
BTW, would be a good idea to have a document with every command and cvar documented... at this point there's a lot of commands and cvars that a lot of people don't know which cvars serve for which thing.


Title: Re: Open Arena Expanded Beta 48
Post by: Cacatoes on February 25, 2011, 04:02:36 pm
- vote abuse, you mean the issue mentionned by assrape ? I don't see it mentionned in the wiki bug list.
- cvar list, vindimy did some work about it, I don't know about its state.


Title: Re: Open Arena Expanded Beta 48
Post by: Gig on February 25, 2011, 04:29:01 pm
BTW, would be a good idea to have a document with every command and cvar documented... at this point there's a lot of commands and cvars that a lot of people don't know which cvars serve for which thing.
This is hard (but would be very good).
At the moment we have some info here:
http://openarena.wikia.com/wiki/Command_console
http://openarena.wikia.com/wiki/Manual/Console_Commands

plus other commands explained in specific pages, obviously;
for example:
http://openarena.wikia.com/wiki/Manual/Graphic_options
http://openarena.wikia.com/wiki/Special_game_options
http://openarena.wikia.com/wiki/Manual%2FMultiplayer#Commands


Some Quake3-related pages are linked here (http://openarena.wikia.com/wiki/Command_console#External_links)... mainly this one (http://joz3d.net/html/q3console.html).


Title: Re: Open Arena Expanded Beta 48
Post by: fromhell on February 26, 2011, 07:54:45 pm
Tried the 2-24 version. What's with the shotgun sparks?

Which inspires me to try and put some improvements into explosions...

I also want to clone CG_SmokePuff to have air friction so the smoke emitting from bullet impacts could stop and hover upward.

The respawn countdown is really cool

By the way, i've tried to do cosine-based view bobbing (cg_view.c, doing it like this (http://www.youtube.com/watch?v=ykZzhkketg4)) and all I got from it was stutter.


Title: Re: Open Arena Expanded Beta 48
Post by: Gatos on March 01, 2011, 08:36:04 am
BTW, would be a good idea to have a document with every command and cvar documented... at this point there's a lot of commands and cvars that a lot of people don't know which cvars serve for which thing.

Here is vindimy's list:

http://oa.thedimi.net/ look under 10/25/2009 - Compiled a neat and informative list of Openarena settings. PDF, Excel, XML.

and I am attaching my attempt of a simpler version, in order to fit them in a printable page (well, actually 5 of them...



Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on March 01, 2011, 03:00:40 pm
Great, I'll check that. :D

BTW, Sago, can it be possible to report in the console which stuff is missing? Such as textures, models, etc.


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on March 02, 2011, 05:27:12 pm
I was thinking, I don't know if OAX in GC can be branched, but... could it be possible to have a branch for 0.9.0 stuff (the "big projects") and another for 0.8.6/7 stuff?


Title: Re: Open Arena Expanded Beta 48
Post by: sago007 on March 02, 2011, 05:35:25 pm
I was thinking, I don't know if OAX in GC can be branched, but... could it be possible to have a branch for 0.9.0 stuff (the "big projects") and another for 0.8.6/7 stuff?
Branches have a tendency to get hopelessly out of date. Until an actual date exist branching is likely done too early.


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on March 02, 2011, 05:36:28 pm
As in, changes in one branch can't affect the others?


Title: Re: Open Arena Expanded Beta 48
Post by: Neon_Knight on March 08, 2011, 12:18:27 pm
If this is of some help, this is the output of a SVN build, rev 250:
Code:
~/dev/oax$ make

Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found
Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found
Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found
make[1]: se ingresa al directorio «/home/luciano/dev/oax»
Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found

Building ioquake3 in build/release-linux-i386:
  PLATFORM: linux
  ARCH: i386
  VERSION: 1.36_SVN250M
  COMPILE_PLATFORM: linux
  COMPILE_ARCH: i386
  CC: cc

  CFLAGS:
    -MMD
    -Wall
    -fno-strict-aliasing
    -Wimplicit
    -Wstrict-prototypes
    -pipe
    -DUSE_ICON
    -DUSE_OPENAL
    -DUSE_CURL
    -DUSE_CURL_DLOPEN
    -Icode/SDL12/include
    -m32
    -DUSE_MUMBLE
    -DUSE_VOIP
    -DFLOATING_POINT
    -DUSE_ALLOCA
    -Icode/libspeex/include
    -DUSE_LOCAL_HEADERS
    -DSTANDALONE
    -DPRODUCT_VERSION="1.36_SVN250M"
    -DNDEBUG
    -O3
    -march=i586
    -fomit-frame-pointer
    -ffast-math
    -funroll-loops
    -falign-loops=2
    -falign-jumps=2
    -falign-functions=2
    -fstrength-reduce

  LDFLAGS:

  LIBS:
    -ldl
    -lm

  CLIENT_LIBS:
    -lGL
    -lopenal
    -lrt

  Output:
    build/release-linux-i386/baseq3/cgamei386.so
    build/release-linux-i386/baseq3/qagamei386.so
    build/release-linux-i386/baseq3/uii386.so
    build/release-linux-i386/missionpack/cgamei386.so
    build/release-linux-i386/missionpack/qagamei386.so
    build/release-linux-i386/missionpack/uii386.so
    build/release-linux-i386/baseq3/vm/cgame.qvm
    build/release-linux-i386/baseq3/vm/qagame.qvm
    build/release-linux-i386/baseq3/vm/ui.qvm
    build/release-linux-i386/missionpack/vm/qagame.qvm
    build/release-linux-i386/missionpack/vm/cgame.qvm
    build/release-linux-i386/missionpack/vm/ui.qvm

Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sdl' found
make[2]: se ingresa al directorio «/home/luciano/dev/oax»
CGAME_CC code/cgame/cg_event.c
CGAME_CC code/cgame/cg_scoreboard.c
LD build/release-linux-i386/baseq3/cgamei386.so
GAME_CC code/game/g_main.c
code/game/g_main.c:671: warning: function declaration isn’t a prototype
code/game/g_main.c: In function ‘ExitLevel’:
code/game/g_main.c:1519: warning: unused variable ‘len’
GAME_CC code/game/ai_chat.c
GAME_CC code/game/ai_dmq3.c
GAME_CC code/game/g_arenas.c
GAME_CC code/game/g_cmds.c
code/game/g_cmds.c: In function ‘SetTeam’:
code/game/g_cmds.c:813: warning: ‘teamscore’ may be used uninitialized in this function
GAME_CC code/game/g_items.c
GAME_CC code/game/g_spawn.c
GAME_CC code/game/g_team.c
LD build/release-linux-i386/baseq3/qagamei386.so
UI_CC code/q3_ui/ui_menu.c
LD build/release-linux-i386/baseq3/uii386.so
CGAME_CC_MISSIONPACK code/cgame/cg_event.c
CGAME_CC_MISSIONPACK code/cgame/cg_scoreboard.c
LD build/release-linux-i386/missionpack/cgamei386.so
GAME_CC_MISSIONPACK code/game/g_main.c
code/game/g_main.c:671: warning: function declaration isn’t a prototype
code/game/g_main.c: In function ‘ExitLevel’:
code/game/g_main.c:1519: warning: unused variable ‘len’
GAME_CC_MISSIONPACK code/game/ai_chat.c
GAME_CC_MISSIONPACK code/game/ai_dmq3.c
GAME_CC_MISSIONPACK code/game/g_arenas.c
GAME_CC_MISSIONPACK code/game/g_cmds.c
code/game/g_cmds.c: In function ‘SetTeam’:
code/game/g_cmds.c:813: warning: ‘teamscore’ may be used uninitialized in this function
GAME_CC_MISSIONPACK code/game/g_items.c
GAME_CC_MISSIONPACK code/game/g_spawn.c
GAME_CC_MISSIONPACK code/game/g_team.c
LD build/release-linux-i386/missionpack/qagamei386.so
make[2]: «build/release-linux-i386/missionpack/uii386.so» está actualizado.
CGAME_Q3LCC code/cgame/cg_event.c
CGAME_Q3LCC code/cgame/cg_scoreboard.c
Q3ASM build/release-linux-i386/baseq3/vm/cgame.qvm
GAME_Q3LCC code/game/g_main.c
GAME_Q3LCC code/game/ai_chat.c
GAME_Q3LCC code/game/ai_dmq3.c
GAME_Q3LCC code/game/g_arenas.c
GAME_Q3LCC code/game/g_cmds.c
GAME_Q3LCC code/game/g_items.c
GAME_Q3LCC code/game/g_spawn.c
GAME_Q3LCC code/game/g_team.c
Q3ASM build/release-linux-i386/baseq3/vm/qagame.qvm
UI_Q3LCC code/q3_ui/ui_menu.c
Q3ASM build/release-linux-i386/baseq3/vm/ui.qvm
GAME_Q3LCC_MISSIONPACK code/game/g_main.c
GAME_Q3LCC_MISSIONPACK code/game/ai_chat.c
GAME_Q3LCC_MISSIONPACK code/game/ai_dmq3.c
GAME_Q3LCC_MISSIONPACK code/game/g_arenas.c
GAME_Q3LCC_MISSIONPACK code/game/g_cmds.c
GAME_Q3LCC_MISSIONPACK code/game/g_items.c
GAME_Q3LCC_MISSIONPACK code/game/g_spawn.c
GAME_Q3LCC_MISSIONPACK code/game/g_team.c
Q3ASM build/release-linux-i386/missionpack/vm/qagame.qvm
CGAME_Q3LCC_MISSIONPACK code/cgame/cg_event.c
CGAME_Q3LCC_MISSIONPACK code/cgame/cg_scoreboard.c
Q3ASM build/release-linux-i386/missionpack/vm/cgame.qvm
make[2]: «build/release-linux-i386/missionpack/vm/ui.qvm» está actualizado.
make[2]: se sale del directorio «/home/luciano/dev/oax»
make[1]: se sale del directorio «/home/luciano/dev/oax»

It compiled, but for some reason I suspect I dod something wrong...


Title: Re: Open Arena Expanded Beta 48
Post by: Cacatoes on March 08, 2011, 02:51:57 pm
You likely miss some libsdl*-dev packages.
Did you check the requirements for building oax ?


Title: Re: Open Arena Expanded Beta 48
Post by: sago007 on March 09, 2011, 11:48:08 am
Technically libsdl should not be needed but since I always have it installed I may not have discovered that the make file checked it.


Title: Re: Open Arena Expanded Beta 48
Post by: Gig on May 30, 2011, 04:28:10 pm
I've done few tests with g_gravitymodifer. I feel it should really have limits for allowed values, since it is easy to mess up (or maybe even "crash") the game using even not-so-high values. Try setting it to 0, to -1, to 10... and then try to jump on a jump-pad.
The game should accept only a specific range of values for this variable.
Bye!


Title: Re: Open Arena Expanded Beta 48
Post by: Cacatoes on May 31, 2011, 11:35:50 am
I've done few tests with g_gravitymodifer. I feel it should really have limits for allowed values, since it is easy to mess up (or maybe even "crash") the game using even not-so-high values. Try setting it to 0, to -1, to 10... and then try to jump on a jump-pad.
The game should accept only a specific range of values for this variable.
Bye!

I got a question for you, are you for flexibility (to allow guys to have use of your software in ways you didn't think of) or user-friendliness (restraining the user choice to a few predefined values, while bothering those who eventually wanted other values) ?


Title: Re: Open Arena Expanded Beta 48
Post by: Gig on May 31, 2011, 03:27:40 pm
I'm for avoiding programs from crashing. Anyway, IMHO the answer to your question is to find the right mix of flexibility and user-friendliness case by case...


Title: Re: Open Arena Expanded Beta 48
Post by: Cacatoes on June 01, 2011, 04:55:46 am
Crash in a figurative way from what I've guessed in this case.
Saying "case by case" is not really an answer, you have to give some hints in order to allow people to select either this or that option, imagine you're away while you have to help them, on what does it depend you will chose one or the other ?
Moreover it's likely you won't achieve consistency if you really choose case by case.
Do you know what flexibility means ? Is -100 to +100 a flexible value for g_gravitymodifier ?


Title: Re: Open Arena Expanded Beta 48
Post by: Gig on June 01, 2011, 07:52:02 am
Try setting it to 0, to -1, to 10... and then try to jump on a jump-pad.

Have you tried?
Also try to bring down the console when you are stuck on the jump-pad, in one on my tests it appered like how you see the world when you "noclip" out of the borders of the map (I don't remeber in which case now, I only did a quick test!). In such quick tests (with values much smaller than 100, I have to try that yet!), the program did not literally "crash", but strange things ("glitches") were shown on the screen and it was almost impossible to control the character.

Anyway, I simply pointed out that, using that variable, problems can happen. They will be Sago or Fromhell to decide if that behavior needs a fix or not.... as an (unofficial) tester, I point out possible trobles.


Title: Re: Open Arena Expanded Beta 48
Post by: Cacatoes on June 29, 2011, 06:48:25 am
Reminder:
- the !mute admin command doesn't seem to work.
I'd suggest a less authoritarian feature so that players are able to mute locally, like in IRC or most chats.

(already briefly mentionned this issue here (http://openarena.ws/board/index.php?topic=3987.msg36225#msg36225))


Title: Re: Open Arena Expanded Beta 49
Post by: sago007 on August 23, 2011, 10:45:18 am
Beta 49 is up.

Changes:
Quote
New in Beta 49:
Challenges are now logged
Last man stading event are now logged
Fixed ammobar for 3 different weaponbar styles (grapple)
Fromhell's changes ( http://openarena.ws/board/index.php?topic=1933.msg39483#msg39483 )
You can now see how much health the obelisk have left in Overload
Fixed a crash when the obelisk was damaged while using native cgame. (Thanks to jackmcbarn for the patch)
Autoswitch weapon can now be set toonly change to better or new weapons. (The default is set in the binaries)
Votekick is now cancelled if the player in question leaves.


Title: Re: Open Arena Expanded Beta 49
Post by: fromhell on August 25, 2011, 08:40:14 am
I have no idea where the HUGE shotgun impact sparks come from, though they're out of place obviously


Title: Re: Open Arena Expanded Beta 49
Post by: sago007 on August 25, 2011, 09:19:36 am
Hmmm....

It looks like something went wrong in the release script. The end result does not look like the development version.


Title: Re: Open Arena Expanded Beta 49
Post by: sago007 on August 25, 2011, 10:44:52 am
I have just attempted a second compile and it appears that the release script has done its part correctly. However I do not use cg_leiEnchancments in my development build, so I did not discover it.

I don't know where they come from.


Title: Re: Open Arena Expanded Beta 49
Post by: 7 on August 25, 2011, 11:29:09 am
diff speaks of major differences in function CG_ShotgunFire (in cg_weapons.c) between B48 and B49

Edit:
Also there is a 'oax'  subdirectory in the tree now, with a complete version of the tree copied into it. The only difference between the build-tree and the tree in the oax directory is the change in CG_ShotgunFire mentioned above.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 15, 2011, 12:03:27 pm
Beta 50 is out. Mainly with a fast hotfix.

Quote
New in Beta 50:
Removed some problematic code that caused some problems in B49
Added new dmflags:
* 64 = instant weapon change (weapon change is instant, weapons still need to reload)
* 128 = no bunny (disables Q2-style jumping and uses realism jumping instead, breaks most maps)
* 256 = no invisible skin (invisible players are completly invisible)
* 512 = allows non majority vote, was default in 0.8.5


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 15, 2011, 02:41:12 pm
Dmflags sound interesting. Where can I find a comprehensive list of them all? And maybe some info about how to use them...


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on September 15, 2011, 02:54:37 pm
8 - No Falling (disables falling damage?)
16 - Fixed FOV (disables FOV change during the match, a la Q2?)
32 - No Footsteps (disables footstep sounds?)

Obtained those looking at the code. Don't know what the values for 1, 2 and 4 do.


Title: Re: Open Arena Expanded Beta 50
Post by: 7 on September 16, 2011, 04:04:54 am
Code:
// g_dmflags->integer flags
#define DF_NO_FALLING                   8
#define DF_FIXED_FOV                    16
#define DF_NO_FOOTSTEPS                 32
#define DF_INSTANT_WEAPON_CHANGE        64
#define DF_NO_BUNNY                     128
#define DF_INVIS                        256
#define DF_LIGHT_VOTING                 512

If it isn't defined, it probably won't do anything. (Probably because you can't give numerical flags another meaning without confusing the hell out of everyone so you can't reuse old bits for new functionality.)

The no-bunny flag works great by the way, the game is utterly horrible with it activated, the movement feels like being tied down by a 100 pound ball and chain ;) (An even more severe feeling of having your wings clipped than the change from QW/CPMA physics to vanilla Q3 physics.)


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on September 16, 2011, 04:37:09 am
Well, at least it's optional, (and I want to believe it isn't or will be a default physic) and I don't think anyone would play with it.

BTW, are there values for 1, 2 and 4?


Title: Re: Open Arena Expanded Beta 50
Post by: 7 on September 16, 2011, 05:05:20 am
BTW, are there values for 1, 2 and 4?

I assume they're not used because they aren't defined. dmflags is basically a leftover from the Q2 engine so I suppose flags 1, 2 and 4 had some function in the Q2 engine that has been removed in the Q3 engine. (I never played Q2.)


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on September 16, 2011, 05:10:56 am
I can confirm all the dmflags mentioned do work


Title: Re: Open Arena Expanded Beta 50
Post by: Cacatoes on September 16, 2011, 10:32:02 am
Great, instant switch was one of the thing I asked for ;)
I don't get the logic of why it's put in dmflags but main point is it's available.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 16, 2011, 10:48:18 am
I tested dmflags 8, 16, 32, and they do work with Q3A, too.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 16, 2011, 11:22:21 am
I normally prefer a real cvar over dmflags. But dmflags has the advantage that it is easy to add new, the client automatically known about it and that it does not take extra space in the infostring.

While adding the weapon switch flag it was easy to add the no-bunny flag too. The code was right there. I know it is there so that mod makers that wants to make realism mods or mods with focus on other things than movement can enable it.

Placing DF_LIGHT_VOTING in the dmflags might be wrong because the client does not need to know about it. But I also consider it a good place for experimental features.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 16, 2011, 11:47:56 am
Okay. I added dmflags to the wiki, here (http://openarena.wikia.com/index.php?title=Special_game_options&action=historysubmit&diff=9027&oldid=8988). Please check if I did correctly.

I'm not sure about how the "Allows non majority vote" thing works (How does it work in oa 0.8.5? How does voting work in recent oax releses?)


PS: http://openarena.wikia.com/wiki/Manual/Techniques page should be expanded, at least listing the techniques! E.g. I'm usure about how to describe the difference between "bunny hopping" and "strafe jumping".


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 16, 2011, 11:58:43 am
I'm not sure about how the "Allows non majority vote" thing works (How does it work in oa 0.8.5? How does voting work in recent oax releses?)
Normally more than half the players that are allowed to vote needs to vote yes. If there are 12 player on a server and 6 votes yes and 1 no the vote fails. If lightvoting is enabled the vote would succeed because there are more yes-votes than no-votes and more than 30% of all voters voted yes and at least 2 players votes yes. The last system apparently has some bugs according to rumors but I have not been able to confirm it.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 16, 2011, 12:02:12 pm
I'm not sure about how the "Allows non majority vote" thing works (How does it work in oa 0.8.5? How does voting work in recent oax releses?)
Normally more than half the players that are allowed to vote needs to vote yes. If there are 12 player on a server and 6 votes yes and 1 no the vote fails. If lightvoting is enabled the vote would succeed because there are more yes-votes than no-votes and more than 30% of all voters voted yes and at least 2 players votes yes. The last system apparently has some bugs according to rumors but I have not been able to confirm it.
Which method do Quake 3, OA 0.8.5, and OAX B50 (this one with or without the dmflag) use, respectively?


Title: Re: Open Arena Expanded Beta 50
Post by: 7 on September 16, 2011, 12:49:28 pm
E.g. I'm usure about how to describe the difference between "bunny hopping" and "strafe jumping".

Bunnyhopping is a technique for gaining speed while doing corners or zig-zagging, strafejumping is a technique for gaining speed while going -more or less- forwards (or backwards).

Bunnyhopping doesn't work in vanilla Q3 physics (you need a mod like CPMA), strafejumping does work in VQ3.

While bunnyhopping you only press a strafe key while moving the mouse, while strafejumping you press both the forward key (or the back key) and a strafe key while moving the mouse.

Demos with keypresses: bunnyhopping in Q1 (http://www.youtube.com/watch?v=v6jm9iGW2Co) and strafejumping in QL (http://www.youtube.com/watch?v=gfb_kwvhQ9c) (notice the forward key).


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 16, 2011, 08:18:28 pm
Okay, then I always do strafe jumping (I played with CPM physics only few times in my life), as I ever called what I did.

But if bunny hopping is only possible with mods, then the name of the new dmflag Sago put in VanillaOA is misleading: it should indicate it disables "strafe jumping" instead of "bunny hopping". Sago, can you change its name?

PS: about strafe jumping, this tutorial seems nice:
http://youtube.com/watch?v=TOffE5_k2f0&NR=1&feature=fvwp
Do you think we could link it from the Manual\Techniques page?


Title: Re: Open Arena Expanded Beta 50
Post by: PopeJo on September 17, 2011, 02:05:20 am
PS: about strafe jumping, this tutorial seems nice:
youtube.com/watch?v=TOffE5_k2f0&NR=1&feature=fvwp
Do you think we could link it from the Manual\Techniques page?

its ql, physics are similar, but different. so it shouldn't be linked

here is one of the classical beginners guide to tricking in q3
http://www.quakeunity.com/file=2170




Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 17, 2011, 04:22:08 am
Sago, can you change its name?
It does not have a name except in the code, its just a number. Besides calling it "non-accelerated jumping" would be more correct. Strafejumping is just a side effect of the Q2 physics, Q3's alternative physics was designed to remove any speed exploit in the jumps.

Which method do Quake 3, OA 0.8.5, and OAX B50 (this one with or without the dmflag) use, respectively?
Quake 3, OA 0.8.1 and OAX B50 requires more than 50 percent of all voters to vote yes. Not voting is the same as voting "no".
OA 0.8.5 and OAX B50 (with dmflag) uses the other.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 17, 2011, 06:41:01 am
It does not have a name except in the code, its just a number. Besides calling it "non-accelerated jumping" would be more correct. Strafejumping is just a side effect of the Q2 physics, Q3's alternative physics was designed to remove any speed exploit in the jumps.
Do you mean that id software put both Q2-style phisics and a more realistic physics style into quake 3 code, and then decided to keep only the one that allowed more tricks (very good choice, IMHO), completely disabling the other? Did you only re-enabled that hidden code, allowing a method for turning it on?

Another question: does the method used by dmflags to store more "0-1" options inside a single variable, using the properties of binary digits scale, have a specific name? I'd like to see if there is some simple tool that allows to type a decimal value and then breaks down it (e.g. you type 24 and it tells you 16+8).

PS: "Non-accelerated jumping" description could be good.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 17, 2011, 06:44:38 am
Do you mean that id software put both Q2-style phisics and a more realistic physics style into quake 3 code, and then decided to keep only the one that allowed more tricks (very good choice, IMHO), completely disabling the other? You you only re-enabled that hidden code, allowing a method for turning it on?
Yes. I guess the code was left there to help mod makers.
Another question: does the method used by dmflags to store more "0-1" options inside a single variable, using the properties of binary digits scale, have a specific name? I'd like to see if there is some simple tool that allows to type a decimal value and then breaks down it (e.g. you type 24 and it tells you 16+8).
bit field (http://en.wikipedia.org/wiki/Bit_field)


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 17, 2011, 06:51:47 am
Thank you. But I don't get the difference between Bit field (http://en.wikipedia.org/wiki/Bit_field) and Bit array (http://en.wikipedia.org/wiki/Bit_array)...


Title: Re: Open Arena Expanded Beta 50
Post by: 7 on September 17, 2011, 08:38:17 am
Thank you. But I don't get the difference between Bit field (http://en.wikipedia.org/wiki/Bit_field) and Bit array (http://en.wikipedia.org/wiki/Bit_array)...

Its on the wiki page you linked :)

Quote
A bit field is distinguished from a bit array in that the latter is used to store a large set of bits indexed by integers and is often wider than any integral type supported by the language. Bit fields, on the other hand, typically fit within a machine word, and the denotation of bits is independent of their numerical index.

So basically a bit field is an integer variable where you address individual bits by logical AND an OR operations, while a bit array is a sequence of integer variables where you addess individual bits by an array index.

Example in C++
Code:
// bit field
short bitfield = 0; // initialize a bit field of 16 bits
bitfield |= 4; // set the 3rd bit by a logical OR
if ( bitfield & 16 ) { ... } // test if the 5th bit is set by a logical AND

// bit array
std::bit_vector bitarray(1024); // initialize a bit array of 1024 bits
bitarray[2] = true; // set the 3rd bit by index (indexes start with 0)
if ( bitarray[4] ) { ... } // test if the 5th bit is set by index


Title: Re: Open Arena Expanded Beta 50
Post by: Cacatoes on September 18, 2011, 09:16:04 am
To clarify about the vote issue,

Here is a FICTIVE scenario with the purpose to illustrate what happens:

- someone calls a vote ...
- some players start voting ... =>
- yes 1 / no 0
- yes 2 / no 0
- yes 2 / no 1 // seems to go normal for now
- yes 1 / no 1 // then some of the value decreases, while no player left (nor went spec)
- yes 0 / no 1 // we sometimes end up with a result being the contrary of what we expected (first tendancy was: 'yes' were going to be the winners)

So nobody gets the logic, it's like every one voted, but nobody understands why vote sums are like near 0.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 18, 2011, 09:21:11 am
So that was the problem... that does make a rather large difference.

A vote should not disapear. A vote should only decreased if the player leaves/spectates or changes its vote.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 18, 2011, 04:16:23 pm
Well, if you will be able to identify and fix the bug, maybe you could make the new voting system default again, and reverse the dmflag to make the old type available again for server admins. But it's your choice.

A question: do dmflags settings work at engine level, or at qvm level? I mean, the new values apply also to old mods or not? I suppose not... but I might guess wrong.
And similar... Does OA 0.8.5 voting style work with baseoa/recent mods only, or with old mods, too?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 18, 2011, 04:21:39 pm
Well, if you will be able to identify and fix the bug, maybe you could make the new voting system default again, and reverse the dmflag to make the old type available again for server admins. But it's your choice.

A question: do dmflags settings work at engine level, or a qvm level? I mean, the new values apply also to old mods or not? I suppose not... but I might guess wrong.
And similar... Does OA 0.8.5 voting style work with baseoa/recent mods only, or with old mods, too?
Everything is in the qvm.


Title: Re: Open Arena Expanded Beta 50
Post by: Cacatoes on October 23, 2011, 01:50:15 pm
While I'm at it, about the votes:
Some other wrong thing which happens is the "vote message" isn't always displayed, so we don't know what the vote is for.
It's been like this for some very long time (even prior to the new voting system). I don't know what causes this.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 06, 2011, 05:29:10 pm
Just wondering... is there the time to put in a command to disable chat sound (http://openarena.ws/board/index.php?topic=4338) or to hide chat text from a specified player, before 0.8.8? I play online too few to feel a such needing, but I see that now and then people here ask for such features...

Bye!


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 06, 2011, 05:53:09 pm
It should be as simple as a little 'if' cvar check before the sound builtin, in cgame..... I propose cg_noChatBeep.

Muting a specific player would be harder though


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 07, 2011, 01:11:21 am
It should be as simple as a little 'if' cvar check before the sound builtin, in cgame..... I propose cg_noChatBeep.
It's okay for me. I don't know if people would like to apply it only to generic chat, to team chat too or also to all kind of on-screen console notifies... maybe we should ask to some of those users that need the feature (like Peter Sillie...).

Do you think it would take too long to make it support more values?
Example:
0 = Always beep. Default.
1 = Do not beep for generic chat
2 = Do not beep for generic and team chat
3 = Do not beep for generic chat, team chat and other console notifies.


Title: Re: Open Arena Expanded Beta 50
Post by: RMF on November 07, 2011, 02:27:44 am
I prefer /mute, but this would already be great.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 07, 2011, 03:19:20 am
A question: gc_noChatBeep or s_noChatBeep?


Title: Re: Open Arena Expanded Beta 50
Post by: **HD on November 07, 2011, 05:51:14 am
If you want to keep compatibility with QuakeLive you should call it cg_chatBeep and cg_teamChatBeep (most former Q3/QL players use their old configs when trying out OA).

Both cvars are already in AS, if someone wants to copy & paste them, here are the diffs:

http://code.google.com/p/oaunofficial/source/detail?r=163 (http://code.google.com/p/oaunofficial/source/detail?r=163)

Just ignore the g_allowKill log message, this should have been the log message for the previous revision r162


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 07, 2011, 06:21:22 am
Well, using a single new variable instead of two would be more efficient... but also staying "near" to a mod that many people use sounds right, too... I don't know what would be better.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 08, 2011, 04:12:32 pm
Sago, Fromhell... what about that muting beep sound, then?


And another thing, I noticed it testing OA 0.8.8 beta 11117 (based upon OAX B50): entering the SYSTEM menu from a clean configuration, resolution is set to 640x480, but the"aspect ratio" line says 5:4 instead of 4:3 for some reason. Could you please take a look? Thank you!


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 16, 2011, 12:49:00 pm
Hi! I took a look to the OAX changelog.
http://code.google.com/p/oax/updates/list
And I noticed that r279 added chat beep variables like AS. Seems good, but why you didn't tell us? :)

I also read that r276  "Added dmflag 1024. No self damage (from plasma, rockets, granades and BFG)"... interesting. Reminder: falling damage is controlled by dmflags 8, instead.
Question: in case of dmflags and "elimination_selfdamage" with different settings, who "wins"?

PS: I checked about the "5:4" 640x480 (default in clean config) strange thing mentioned in the post above this one: it happens in OA 0.8.5, too. Not a real problem, simply a strange thing!


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 16, 2011, 02:12:38 pm
And I noticed that r279 added chat beep variables like AS. Seems good, but why you didn't tell us? :)
It is not in B50. It is in the 0.8.8 branch though.
I also read that r276  "Added dmflag 1024. No self damage (from plasma, rockets, granades and BFG)"... interesting. Reminder: falling damage is controlled by dmflags 8, instead.
Question: in case of dmflags and "elimination_selfdamage" with different settings, who "wins"?
dmflags are stronger. elimination_selfdamage cannot enable selfdamage if dmflags forbids it. 
PS: I checked about the "5:4" 640x480 (default in clean config) strange thing mentioned in the post above this one: it happens in OA 0.8.5, too. Not a real problem, simply a strange thing!
I don't know why I think its because r_mode -1 is not used in a clean config.


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 17, 2011, 07:20:06 am
In addition to the GLSL zip file in this post (http://openarena.ws/board/index.php?topic=4314.msg41028#msg41028), these contain my changes to the renderer

Of note:
- tcpp's bloom cascade
- my bloom reflection
- monolightmaps
- possibility of texturebits 6, 12, and 15 (this cvar is designed for really old hardware, i.e. Voodoo2, RIVA128)
- r_ext_compressed_textures now compresses alpha textures to DXT5 (not thoroughly tested)
- environment map mode and specularity mode (tried a diff calc that still didn't work)


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 17, 2011, 01:25:51 pm
In addition to the GLSL zip file in this post (http://openarena.ws/board/index.php?topic=4314.msg41028#msg41028), these contain my changes to the renderer
I'll create a engine from this later this evening.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on November 17, 2011, 01:44:17 pm
The skulls doesn't appear in Harvester. :S
The entire mode is rendered senseless without the skulls.

Tried in many maps, and nothing happened.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on November 17, 2011, 03:52:25 pm
VM files (compiled from OAXr284 branch oa-0.8.8).
http://files.poulsander.com/~poul19/public_files/oa/dev088/vm-0.8.8-2.zip

Only qagame.qvm has actually been updated.

Fixes:
Skulls and persistent powerups are dropped again.
Whoa, that was fast.
Thank you Sago!


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on May 14, 2012, 09:44:58 am
I cannot change the first post anymore so here is an update. No visible changes except for the stretched background on wide screen displays.

http://files.poulsander.com/~poul19/public_files/eliminationSource/openArenaExpansionB51.tar.bz2
http://files.poulsander.com/~poul19/public_files/eliminationSource/oaxB51.zip

Change log:
Quote
New in Beta 51:
All changes from 0.8.8
Added command "ui_writemappools". If the arena files are loaded this command will dump the gamelists so they can be used by g_autonextmap (should be used to generate new gamelists for new versions)
Server will now execute "gametype_GAMETYPENUMBER.cfg" on gametype change
Server executes "mapscripts/g_MAPNAME.cfg" and "mapscripts/g_MAPNAME_GAMETYPENUMBER.cfg" then changing map. It will fallback to "mapscripts/g_default.cfg" and/or "mapscripts/g_default_GAMETYPENUMBER.cfg" if any or both or the scripts are missing.
Moved STAT_PERSISTANT_POWERUP to last so that STAT_* are numbered as in 0.8.1
Weapon accuracy are now written to the logfile. The stats are written at the end of the game or then a player leaves
Teams can now have separate spawn points in Domination
The background are now stretched on wide screen displays


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 14, 2012, 04:40:55 pm
Hi! I haven't tried this yet... does it include the "standing over rotating object fix TEST"? That would need extensive tests (including online with high pings), I suppose. About that, did I suggest to anyway provide a variable or dmflag to allow server admins to restore classic behavior?

About the change in domination spawn points (from using DM spawnpoints to Team spawn ponts), why did you do that? Cause of this thread? http://openarena.ws/board/index.php?topic=4476.0
I'm not sure it is a good idea. Other people here, what do tou think about that?
PS: for some reason I don't know, OA 0.8.8 changelog (http://openarena.ws/board/index.php?topic=4451.0 changelist that anyway contained some errors and missings) said "now uses FFA spawnpoints in Domination"... I thought it always worked that way... ???


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on May 15, 2012, 10:05:46 am
Hi! I haven't tried this yet... does it include the "standing over rotating object fix TEST"?
I forgot about that change but yes it does.

About the change in domination spawn points (from using DM spawnpoints to Team spawn ponts), why did you do that?
Domination uses its own spawnpoints but does fall back to deathmatch spawnpoints if they are missing (like all other gametypes). It does NOT use CTF spawnpoints. It will use info_player_dom_COLOR if they exists if not it will fall back to info_player_dom and then to info_player_deathmatch. All existing maps will keep there current behavior.

Double Domination does the same it just falls back from info_player_dd_COLOR > info_player_dd > info_player_deathmatch.

I have a small proof of concept map on how the new spawnpoints can be used but NetRadiant are semi-broken in Ubuntu 12.04.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 15, 2012, 04:08:05 pm
Excuse me, could you please check in http://openarena.wikia.com/wiki/Mapping_information_for_special_gametypes to see if it correctly reports the info for the current (0.8.8) version?
At the moment, for Domination it says it uses "deathmatch spawn ponts", and for Double Domination it says it uses "info_player_dd" or "info_payer_deathmatch" otherwise.

(Stupid?) idea: maybe one may already mention there the future behavior (specifying next release date is unknown), to.. so people may already begin designing maps with the new spawning points?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 17, 2012, 04:29:08 pm
Okay guys... we need some testing with the rotating fix. I created the little "rotate_test" map that you find attached here, with some platforms rotating at different speeds. It sucks, but it's simply for a tech test (weapons and flags included)!
It looks like the effect is really much better than the normal one (altough the platform itself continues to "vibrate")...
We need some testing, to check what happens when some object is over the platforms, or is blocking them... if it is easier or harder to hit (or be hitten by) someone over that rotating object (with hitscan weapons and not)... trying the same with standard game and OAXB51.
We should also do some tests online, possible also with high ping.

In the map attached (created with Q3radiant), you can find .bsp, .map and .aas (and the GPLv2 "copying" file), so you can do your own tests (e.g. adding platforms that rotate over X and Y planes... at the moment I only used platform rotating over the default Z plane).

PS: Sago, have you read my previous post?

PPS: What about a switch to enable or disable the fix? That would also make tests quicker...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on May 18, 2012, 09:16:24 am
At the moment, for Domination it says it uses "deathmatch spawn ponts", and for Double Domination it says it uses "info_player_dd" or "info_payer_deathmatch" otherwise.
Under general it says:
Quote
Double Domination has specific spawnpoints (info_player_dd, info_player_dd_blue and info_player_dd_red).
I will look through them to see if I can clarify some of the things.

About the rotation fix. I would not trust it in game play for the time being, it is really just making an optimistic guess for something that could be calculated exactly.   


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 18, 2012, 04:38:30 pm
Thank you for the fix in the wiki.

About the rotation fix, instead...
I don't know how the fix works... what was already there -and disabled for some reason- by iD Software and what you did/changed, instead... (OAX r287, right?)
If you wanna sum up what's its problem, what could be done to address it... and what are you planning to do about it (e.g. for the moment, to keep it but disabled by default)...

Ps: could you please explain to me what's that "dmflags enabled overlays" of r277?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on May 19, 2012, 02:36:36 am
Throwing resources after something that isn't used are not worth anything. That is likely the reason nothing was done about rotating.

Rotation still works at is have always done it just looks different for the client standing on a rotating platform. The new view is predicted by assuming it moves in the same direction as the last time. This is never true but for small time intervals it is close and the engine can compensate for small prediction errors (they happen every time you press a key). A little extra vector calculations could make it better.

dmflags enabled overlays are shaders placed on all players. It is not present in OpenArena, the code is for reference only.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 19, 2012, 10:35:06 am
Do you think that viewer's aim will be affected? With the old behavior, aiming while being on a rotating object was difficult due to the scrolling effect... but with the new behavior, is there the risk to miss anyway because the direction you see you are aiming at is not exactly the same the game is effectively aiming?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on May 19, 2012, 12:13:48 pm
Do you think that viewer's aim will be affected? With the old behavior, aiming while being on a rotating object was difficult due to the scrolling effect... but with the new behavior, is there the risk to miss anyway because the direction you see you are aiming at is not exactly the same the game is effectively aiming?
The angle you see now while standing on a rotating platform is much closer to the effective angle than before.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on May 20, 2012, 04:20:10 am
Good, then. :)

So, any ideas about the reason why iD software left this algorithm disabled? You said that it may have been made better (more accurate), but that anyway it's better than the behavior they placed in the actual game (and you say it should not have real counter-indications, right?)... why did they left it out, then? Framerate drop, maybe?

And I haven't understood yet if you plan to set some kind of switch to enable and disable it... and in that case, if it would be on or off by default, if it would be enabled or disabled for all players by the admin, or if the players would be able to select independently (or maybe locked by videoflags?)...

PS: sorry for annoying you... :)

PS: in any way, I would suggest map makers to do not make excessive use of rotating platforms anyway (altough some more than before may be used), thinking to all old mods that cannot use the fix.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on July 08, 2013, 05:33:18 pm
It's practically a year since the last report, so I'm sending here some stuff by Gig, regarding the grapple:
Bad news about the offhand grapple (http://openarena.wikia.com/wiki/Manual/Weapons#Offhand_grapple). Being a "cut off" q3 feature, it seems that id software left in some bugs in bots a.i. (this explains why bot_grapple variable is disabled by default).
Making some tests, I noticed that if the bot has not collected the grapple yet, but it needs to go to a place that it would reach with the grapple if it had one... it starts pointlessly firing with normal weapons (standing still) aiming to the wall where it would have fired the grapple if it had it. This means that currently, it is not advisable to enable bot_grapple variable, except for tests (e.g. one might use it with elimination_grapple option).

(...)
I don't know if the cause of the bug is in gamecode, or in BSPC, or both... but I can guess it should be possible to fix it with gamecode updates.
1) Bots still have some problems using it (I've seen them missing an edge by a few centimeters when firing the grapple, but repeating the same exact launch various times without correcting the trajectory). A gamecode update would be necessary to have fully working bots with grapple. (...)
2) In current OA, bot_grapple variable is disabled by default. Of course, we may temporarily enable it in the map rotation script we may include with OACMP01, but how many pepole will actually use those scripts? And more, if one breaks the scripts and then loads another map compiled with -grapplereach option without disabling bot_grapple? In that case, bots would pointlessly shoot with standard weapons where they would shoot with the grapple, if they do not have it.
2.1) If and when bot behavior in gamecode will be fixed, I think that it would be safer to change the name of the bot_grapple variable, trying to avoid people finding bot grapple support enabled when playing with any old mod or old OA version, where bot_grapple support will remain buggy forever. But then a map rotation script with bot_grapple option would be outdated!


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on July 08, 2013, 09:32:26 pm
I don't know why there's suddenly a priority of interest for wanting the grapple as a standard weapon.  It might be an overly large feat to attempt to fix what was broken and not figured out by Mr Elusive himself and would probably require changes in the AAS format, like calculating potential grappling areas.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on July 08, 2013, 11:49:52 pm
I don't know why there's suddenly a priority of interest for wanting the grapple as a standard weapon.  It might be an overly large feat to attempt to fix what was broken and not figured out by Mr Elusive himself and would probably require changes in the AAS format, like calculating potential grappling areas.
AFAIK, BSPC can already calculate potential grappling areas, if you compile the map with -grapplereach option. If then you enable bot_grapple in-game, you can see bots use it as shortcut to reach higher places (at specific spots). They are not able to arbitrarily attach on any wall like humans would do (if you order a bot to follow you and attach to the ceiling, he would not be able to do the same)... but howerver also their shortcut mode could be nice to see (once a few bugs in their a.i. have been fixed).


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on July 17, 2013, 10:23:05 am
Can I suggest two new commands?

autoscreenshot <integer> (default 0)
Takes a screenshot every <integer> minutes on the match. Outputs TGA file.
autoscreenshotJPEG <integer> (default 0)
Takes a screenshot every <integer> minutes on the match. Outputs JPG file.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on July 23, 2013, 03:06:07 am
Can I suggest two new commands?

autoscreenshot <integer> (default 0)
Takes a screenshot every <integer> minutes on the match. Outputs TGA file.
autoscreenshotJPEG <integer> (default 0)
Takes a screenshot every <integer> minutes on the match. Outputs JPG file.

Uh? What's the use for a such thing?  ???


Title: Re: Open Arena Expanded Beta 50
Post by: grey matter on July 25, 2013, 10:24:40 am
The only useful autoscreenshot command I've seen is of the scoreboard at the end of the round. For any other case autorecorddemo should suffice.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 01, 2013, 01:34:59 am
I think this stuff is something we should look into:

Any idea about the reason why the bots specified in the .arena file are actually used only in some gametypes, and not in others?
Bots in the arena-files are limited to FFA-gametypes only. It has always been like that. Of course that could be changed in the future.
Considering most OA gametypes are team-based, I suppose we may consider the ability to specify the bots to play on them (we have a lot of maps and a lot of gametypes, but lazy players will always play them with the same bots).
But how to implement a such thing, and keep backwards compatibility?
- Should just use the same bots specified for FFA mode, removing the last one if necessary to make the total number of players balanced?
-- But if the bots specified for FFA mode are very few (e.g. one or two), there would be too few players for actually playing a CTF game, isn't it?
-- Maybe one may allow an option "word" in the .arena (fake comment, for compatibility?), to tell the game to use the bots specified by map creator... and if that word is missing, just using the classic default bots (or the opposite)?
- Should we allow to specify a separate list of bots to be used for team-based modes?
--This would allow more flexibility, but at the cost of making the .arena file bigger (and I don't know exactly, but I think that arenas.txt has got some size limits -that already forced some maps to be "dummied out" from the maplist in the GUI-... should the game allow bigger arenas.txt files then?)
--Again, compatibilty with older versions/previous mods should be preserved (I can guess they would continue proposing the default bots, but the important thing it that they will not completely fail interpreting the .arena file). Fake comment again? Do "comments" count for the size limits of .arena file?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 01, 2013, 09:28:08 am
Comments does count for the size limit. The size limit cannot be increased without breaking compatibility.

I imagined that one could create a "MAPNAME.info" for each map with content like:
Code:
{
minPlayers "3"
maxPlayers "10"
recommentedPlayers "5"
minTeamSize "2"
maxTeamSize "6"
mpBots "sarge, penguin, jenny" #bot pool to use for multiplayer
auther "The maps auther goes here instead of in the long txt"
description "Once open a time... bla bla bla... map history"
}

{
gametype "11"
minTeamSize "3" #Overrule minTeamSize for DD
}

{
gametype "10"
maxPlayers "6" #Overrule maxPlayers for LMS
}
The game should ignore keys it does not know about, so that more may be added later.

If a key is missing just use default.

This would allow better map desciption in the GUI and allow a smarter bot_auto_minPlayers.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 01, 2013, 09:43:34 am
I support the idea of Mapname.info, at least for official OA releases. That should allow us to keep arenas.txt at a minimum (map, longname, gametype) and fill the remaining fields into mapname.info.

These files can even be included into the maps/ or scripts/ folder, like it's done on Nexuiz.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 01, 2013, 10:31:09 am
A such thing sounds veeery interesting...  :)

I would write more, but I'm late and I have to go now. Bye!

PS: Maybe the "gametype" key may use the same values of arenas.txt, instead of the number.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 01, 2013, 11:13:57 am
Oh, never noticed that it can allow custom rules. That's even cooler! Especially for Harvester, which has a different capturelimit than other CTF-based gametypes.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 07, 2013, 08:27:19 am
Well, maybe it may be useful also for Harvester, but most notably, I would mention Domination!
Oh, well... starting Domination match from the GUI, already proposes a capturelimit of 400 (instead of 0 like many other demos)...
This makes me wonder... why CTF mode proposes a capturelimit of 8 and other team-based games propose a capturelimit of 0?
However, a gametype AND map specific values may be nice.

----------------------------

An important thing is that this "extra map infos" system may work like arenas.txt and .arena files work: a main file (to be supplied and replaced with new official OA releases), plus "additional" files (to be added with each map or mappack).
Considering that could contain a lot of text (e.g. Sago mentioned map description), permitted file size should be a lot bigger than arenas.txt (at least 100x bigger? I don't know exactly.)

Hey, I can imagine a similar thing (brand-new optional files that contain extra infos, foreseeing the ability to add further tags in the future. Of course "developer" -detailed- console output may report parsing problems also for unrecognized tags.) may also be used for characters. For OA3 UI, Fromhell tested a "Biography" menu: http://openarena.ws/board/index.php?topic=4780.msg47385#msg47385 (http://openarena.ws/board/index.php?topic=4780.msg47385#msg47385). I suppose also third party bots may get their own biographies, if a "description text file + character drawing file" system is provided, instead of hard-coding that part into game sources...




Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 07, 2013, 11:00:08 am
Yeah, I can't see why such implementation would be a bad thing for OA.

I was wondering as well... does current OA or OAX support .ent files? As in, special support for entity (ammo/weapon/even giving newer gaetype support) modifications to older (made for Q3) maps without altering any file from the PK3 archives of said maps.

How much will break OA to implement this? I know that Darkplaces and Q2 have such support.


Title: Re: Open Arena Expanded Beta 50
Post by: grey matter on August 08, 2013, 05:50:05 am
I was wondering as well... does current OA or OAX support .ent files? As in, special support for entity (ammo/weapon/even giving newer gaetype support) modifications to older (made for Q3) maps without altering any file from the PK3 archives of said maps.

How much will break OA to implement this? I know that Darkplaces and Q2 have such support.

That's an addition of maybe 20 lines of code, not sure what you mean by "break OA"?


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 08, 2013, 07:48:00 am
I was talking if it risks any kind of compatibility, thus defeating a main objective of OA.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 08, 2013, 08:26:30 am
Uhm... for compatibilty, I can guess that old mods would just continue to show the original items of the map, and not the "patched" ones (they would not read .ent file at all. But continue reading... I have some fears about bots).
This makes me think... Maybe one may also provide a cvar to ignore such .ent patches, and restore original item placement?

A thing I have not understood: would that system work in a way similar to the current "Entities-only editing (http://openarena.wikia.com/wiki/Entities-only_editing)" working mode, with the need to perform "q3map2 -onlyents yourmap.ent" and "bspc -reach yourmap.bsp" commands, or not? From what I can guess, your idea is precisely to make the trick work skipping those two recompiling passages? In case at least .aas recompiling would still be required... well this may really be a compatibilty problem with old mods... maybe complete "entities-only editing" procedure may be used instead -well, an alternate idea is at 5)-

However, "risks" that randomly come in my mind could be:
1) How would bots navigate a map where some entities (or theoretically even all of them) are placed differently from their location when the .aas file was created? Well, I can see that bots are already able to grab TA weapons even in maps compiled from not-TA-aware Q3Radiant... but maybe this stuff may be a little different (at least because there was an entity there at the moment of bspc compile, although the editor did not know that entity effects). I'm not enough inside such deep in-game mechanics to tell.

2) The system may bring to have a map's ".bsp" and its ".ent" patch in different pk3 files. Modifying only one of the two ("paring" the wrong versions of them, for whatever reason... e.g. You create the .ent file for OA 0.8.1 am_galmevish, but OA 0.9.0 will have a noticeably reworked am_galmevish... what would happen in that case?) may bring to some problems (e.g. entities placed in the outer void).
2.1) In some way (I don't know how), the game "checks" that an .aas file corresponds with specific .bsp version, right? I mean, if you re-compile a map, you will not be able to add bots at all (although the old .aas file was still there), until you recompile the .aas, too. Is it so? If there is some kind of "build version" or similar reference in .bsp files, maybe the user may identify it, and somehow write it in the .ent file, to "validate" the link between the two files? In that case, the game could ignore the .ent file, if it does not correspond to the .bsp build in use.

3) Are we sure this would be a comfortable way to work? Manually placing entities by specifying their coordinates in a text editor, does not seem very comfortable to me. Ok, if you don't have the .map file, you have not many choices... but is it really so common to modify third-party non-GPL'd maps?

4) Maybe should this be advertised as a "last resort" operative mode only, for maps where the .map file is not available? If the source is available, modifying it would probably a better practice.

5) In case one updated .aas file is required when using the .ent file, I can guess the solution may be to (manually) rename the new .aas file to something similar (.aa2, for example?), and make the game to load that file instead of the original one, in case it is going to use the .ent (if .ent feature is disabled, load .bsp+aas... if .ent feature is enabled, load .bsp+.ent+.aa2). But wait... maybe just making the "complete" entities-only editing procedure would have more sense... Also, I have no idea about how to create the updated bot navigation file without updating the .bsp first.

PS: Vaguely related, I added this tip (http://openarena.wikia.com/index.php?title=Entities-only_editing&diff=14527&oldid=13420) in the wiki. Is it ok?
PPS: In that page, lights are mentioned as entities. But does modifying lights entities do anything, if you do not compile (e.g. relight) the map with lights option?


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on April 15, 2014, 12:21:07 am
Some of my later experimental changes (https://github.com/OpenArena/leixperimental)


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on May 20, 2014, 11:15:17 am
Compiling from https://github.com/OpenArena/gamecode.git

Where do I get yacc?

EDIT: Forget it, I haven't installed build-essential and byacc. -.-


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on June 17, 2016, 11:37:23 am
I have created a nightly build for the gamecode:

http://files.poulsander.com/~poul19/public_files/oa/dev088/gamecode_nightly/

This always features the latest master branch from Github: https://github.com/OpenArena/gamecode

The build machine is this Docker image: https://hub.docker.com/r/sago007/docker_openarena_gamecode_builder/


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 17, 2016, 12:15:13 pm
Ohhh... great! I hope to find some time to try it in the next few days, because then I will go for some holidays and will be mostly offline. In that case, I will have to test around half of July.

Is there a comfortable changelist to know what to check?

I see a file for the Missionpack, too? I thougt that was abandoned...

Is this OAX B52?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on June 17, 2016, 03:26:10 pm
Is there a comfortable changelist to know what to check?
The list here shows most things:
https://github.com/OpenArena/gamecode/commits/master
It does include things like "Updated README".
There was a patch to the vote menu.
The game should also not crash anymore if a player spawn point is missing in the map.

I see a file for the Missionpack, too? I thougt that was abandoned...
I choose to compile it as long as it compiles. If it is missing then it is because the compile was broken.

Is this OAX B52?
Nightly builds are a bit different. Every day GitHub will be checked for new commits and if they exists then a new version will be compiled.
You properly do not want to look at it every day but it is good to know that progress is accessible to everyone that has any interest in it without having to wait for someone to create a B52.

The gamecode does not contain a large amount of changes at the moment but an automatic compile every night makes it easier to follow.

If the leixperimental changes can be merged into gamecode they will now be much easier accessible. 


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 18, 2016, 03:14:26 am
I got it. So, everytime you will make some changes, the next day there will be one more file in that folder. In case you did more changes in one day, they all will be in one new file only, right?

Very interesting!
I can guess we should update http://openarena.wikia.com/wiki/OAX page now. That page also still mentions "svn repository", while it's a "git" repository now...
Also, giving a quick look to the git commits page, I don't see progressive number for revisions anymore. How to mention a specific revision, when talking?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 21, 2016, 04:55:08 am
Excuse me Sago, I was trying some features you mentioned here:
http://openarena.ws/board/index.php?topic=1908.msg44498#msg44498
And I noticed one thing (which is the same also in OA 0.8.8, hence it's not related with those new features)...

Is it expected that, after you change gametype, current map rotation script stops working? After changing gametype, I find "nextmap" cvar is set to "map_restart 0" instead of something like "vstr d2". So, a "Callvote Nextmap" then just restarts the current map. Is this a bug?

Update: It looks like also the original Q3 does behave in a similar way. While maybe it may have some sense by implying that different gamemodes need different maps? But how then restart any kind of rotation, then (unless the server having an OA-specific custom vote which would do something like "exec rotscript.cfg")? Well, using the new feature of OAX B51 one may do a specific script executed when entering each gametype, with a different rotation, but...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on June 21, 2016, 10:00:26 am
The g_autochangemap that is available in 0.8.8 should work even if changing gametype. It should use the rotation of the new gametype. It was designed to "just work".

I got it. So, everytime you will make some changes, the next day there will be one more file in that folder. In case you did more changes in one day, they all will be in one new file only, right?
That is correct.

Very interesting!
I can guess we should update http://openarena.wikia.com/wiki/OAX page now. That page also still mentions "svn repository", while it's a "git" repository now...
Also, giving a quick look to the git commits page, I don't see progressive number for revisions anymore. How to mention a specific revision, when talking?
It is a problem in git. The individual commits is given a hash like "b767acae0de31968331f9182c6afbab1376954b8" or "b767aca" for short. There is no incrementing revision number, not even after merging into master.
The timestamps cannot be trusted either. They mark the day the code was developed (git commit). NOT the day they where made available (git push). In Subversion commit+push was just called "commit".


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 21, 2016, 10:15:56 am
The g_autochangemap that is available in 0.8.8 should work even if changing gametype. It should use the rotation of the new gametype. It was designed to "just work".
You made me remember a thing I wanted to ask you since a long time, when I was making tests for autochangemap files for oacmp volume 1 (v4 IIRC, still unreleased). The question is: does a "duel/tournament/1v1/gametype 1" (call it as you prefer) match ever "end"? When fraglimit is reached, loser is replaced by a spectator, and frag count restarts from 0, in the same map. The only ways to change map are callvoting another map or callvoting nextmap, right? There isn't a "final" winner of the tournament after everyone as fought at least once, right?

Quote
It is a problem in git. The individual commits is given a hash like "b767acae0de31968331f9182c6afbab1376954b8" or "b767aca" for short. There is no incrementing revision number, not even after merging into master.
The timestamps cannot be trusted either. They mark the day the code was developed (git commit). NOT the day they where made available (git push). In Subversion commit+push was just called "commit".
Uhm... I don't wanna say it's a serious issue, but however I would consider it at least a medium issue. If almost everyone switched to github in the past years, it must have something really good.... but this lack of human-readable version numbering sounds awkward...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on June 21, 2016, 11:11:35 am
The only ways to change map are callvoting another map or callvoting nextmap, right? There isn't a "final" winner of the tournament after everyone as fought at least once, right?
I have not played it for years. I thought there was an overall time limit.

Uhm... I don't wanna say it's a serious issue, but however I would consider it at least a medium issue. If almost everyone switched to github in the past years, it must have something really good.... but this lack of human-readable version numbering sounds awkward...
It is one of git's many, many, many weaknesses. It was the reason I originally was reluctant about using git. But now I understand that git has some much more severe weaknesses and massive data loses are common. But I still prefer git to other modern alternatives like Mercurial or Bazaar. Git wins in both speed an popularity.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 21, 2016, 03:02:37 pm
and massive data loses are common.

 :o :o :o :o

I usually don't like smiley-only posts, but in this case, it is my reaction...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 22, 2016, 02:57:00 am
I tried to update OAX wiki page (http://openarena.wikia.com/wiki/OpenArena_eXpanded) with the infos due to Github and Nightly Builds as I could (see diff (http://openarena.wikia.com/index.php?title=OpenArena_eXpanded&diff=17370&oldid=16945)).
Feel free to correct anything I was wrong.  :)


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on June 22, 2016, 12:18:27 pm
I usually don't like smiley-only posts, but in this case, it is my reaction...
It is not as bad as it used to be. However if you are used to Subversion you can get some nasty surprises. I have seen first hand how three complete branches got destroyed, just hour after deploying git and worse it took 14 days before anyone noticed. History looked good. But history in git is not trustworthy by default, it can be rewritten.

You can protect it by hooks but it was only recently this option was added to Github (called "Protected branches" in Github).

Feel free to correct anything I was wrong.  :)
It is not wrong. At one point the page should properly be simplified. Even I find it intimidating and I written large parts of it.

I need to move compile instructions to git. It is there that information belongs.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on June 23, 2016, 07:56:36 am
I just moved a few lines which talk about the repository from "what is oax?" section to a "where are the sources?" section, to be more easily "skippable" by who's not not interested into such suff.

http://openarena.wikia.com/index.php?title=OpenArena_eXpanded&diff=17374&oldid=17373


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 06, 2016, 10:21:01 am
Many years ago I talked about adding an .info file: http://openarena.ws/board/index.php?topic=1908.msg47956#msg47956

I did actually add it a long time ago. Now I have added a couple of things that are actually used.

A "maps/oasago2.info" could look like this:
Code:
auther Sago007
description "After the of the first castle. Sago's second castle was redesigned with multiple layers of defence. After getting past the outer wall the attackers would have little defence. It was hoped that no one would even dare to attack. That turned out to not be the case."
captureLimit 8
maxTeamSize 6
minTeamSize 2
support_dm no
support_team no
support_tourney no
support_ctf yes
support_1fctf yes
support_obelisk yes
support_harvester yes
support_elimination yes
support_ctfelim yes
support_lms no
support_dd yes
support_dom no
support_pos no
gametype 1fctf
captureLimit 5
minPlayers 5
minTeamSize 5
gametype dom
capturelimit 500

Values after "gametype dom" only applies to Domination until it sees another "gametype GAMETYPE" or "gametype *"
Not all values are used at this time. However the "support_GAMETYPE" works. They accept "yes" or "no". If they are defined then they take precedence over the arena files.
The file is limited to 4*1024 bytes.
Unknown keys are ignored, so it is possible to add more.

While the arena-parsing is performed in the UI-layer and cannot expose its values elsewhere the info files are common. Both ui, game and cgame can read the values.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 06, 2016, 02:25:51 pm
Excuse me, do you mean it may also override arenas.txt, or only .arena files?

PS: I will be away for vacation for about 3 weeks, with only the telephone and no wifi... I will not be able to test anything...


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 06, 2016, 02:35:22 pm
Cool! Like Nexuiz/Xonotic's .mapinfo files.
arenas.txt could very well have the minimal info for compatibility, while the .info files may contain the extended info, then the UI may read these values, isn't it?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 06, 2016, 03:46:52 pm
Excuse me, do you mean it may also override arenas.txt, or only .arena files?
It will also override arenas.txt. It is just a special .arena file.

The map must still be mentioned in an arena-file because the maps are still sorted based on the arena files.

I should still stress that only the "support_GAMETYPE yes/no" works at the moment. It has been prioritized to be able to support Possession.

The UI was not the primary focus while I implemented it (the user can still set there own values).
I hope to add something like "g_use_auto_settings" that works like "bot_autominplayers" just for other settings. I primarily need it for the map pool functionality.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 06, 2016, 04:14:46 pm
I was talking about the OA3 UI which uses the Missionpack UI system, so it should be a straightforward process to take info from the file and display it in the GUI.

BTW, is there a list of accepted variables for the file? I'm interested in implementing this in the different maps we have.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 15, 2016, 11:45:10 am
I have added new Beta 52 for people who do not use nightly releases.

It can be found here: https://github.com/OpenArena/gamecode/releases/tag/oaxB52


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 17, 2016, 03:50:50 pm
Good, so it comes with some easy to read changelog.  :)

However, for the changes against B51, I suppose it also contains cg_oldrail 2 & 3, and probably also some other Fromhell's tweaks that I don't know how to enable, right?

Also, maybe the changelog may contain (or link forum posts with) infos about how to actually use the new features (e.g. how to make the script for empty server etc.)...

PS: excuse me, I noticed in the description of this diff https://github.com/OpenArena/gamecode/commit/5e309c9b9dd3e16a1a7c86187e13a23a22bfee52
"targetname is now case sensitive". Is that something only related with the elimination-special doors or what? Because it sounds like something capable of breaking potentially many existing maps...


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 17, 2016, 04:18:14 pm
PS: excuse me, I noticed in the description of this diff https://github.com/OpenArena/gamecode/commit/5e309c9b9dd3e16a1a7c86187e13a23a22bfee52
"targetname is now case sensitive". Is that something only related with the elimination-special doors or what? Because it sounds like something capable of breaking potentially many existing maps...
Hmmm, if that's the case, then I share Gig's worry about that. Why the change?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 18, 2016, 12:33:14 am
However, for the changes against B51, I suppose it also contains cg_oldrail 2 & 3, and probably also some other Fromhell's tweaks that I don't know how to enable, right?
Possible, but I only have the git commit log to make the list from.

Also, maybe the changelog may contain (or link forum posts with) infos about how to actually use the new features (e.g. how to make the script for empty server etc.)...
It will take some time. Some of the features I don't remember implementing.

PS: excuse me, I noticed in the description of this diff https://github.com/OpenArena/gamecode/commit/5e309c9b9dd3e16a1a7c86187e13a23a22bfee52
"targetname is now case sensitive". Is that something only related with the elimination-special doors or what? Because it sounds like something capable of breaking potentially many existing maps...
It is only the new name so it will not break anything existing.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 18, 2016, 03:16:35 pm
It looks like we really need some way to keep trace of new features as long as they are implemented, otherwise OA3 will contain a lot of cool things which noone will use because noone will know about their usage or even about their existence...

Ideas are welcome... maybe something like Fromhell did here?
 http://openarena.wikia.com/wiki/New_shader_commands

Or maybe just using the wishlist page? http://openarena.wikia.com/wiki/Wishlist ? But that does not seem the right place to explain how to use a feature... but only to link the explainations from elsewhere...


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on August 18, 2016, 04:27:53 pm
 relying on Wikia for information on them isn't a good idea either.  The OA wikia is already filled with clutter causing it to not be easy to read


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 19, 2016, 01:14:35 am
Some ideas?

Just writing them on this thread as soon as Sago does them, while a good thing, has got two drawbacks: naming here things which are not yet in OAX "B" version (one may write them in the nightly builds thread instead?) and some difficulty to sum them up when needed due to many other posts in the middle.

A dedicated thread with the changes always mentioned in the first post? But posts become locked after a few days (Sago cannot update the first post of this thread, as example)...

A dedicated thread locked in a way that only Fromhell and Sago can write in it?

A plain text file in Sago's own computer? But what about Fromhell's changes?

Some kind of page on Github, where Sago and Fromhell can both write?

A dedicated page on wikia?

Other?

PS: just relying on Github changes, other than hard to follow, can sometimes also be misleading (as in the "case sensitive" thing from yesterday)...


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on August 19, 2016, 04:12:17 am
I think we should talk about the wiki in the respective thread, so this doesn't end in the derailing of the thread.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 19, 2016, 12:14:59 pm
I think we should talk about the wiki in the respective thread, so this doesn't end in the derailing of the thread.
Well, it's not exactly "about the wiki", it's about "how to keep a changelog which does list all the (notable) changes (to allow a good public OA3.0.0 changelog at the very end), and to allow to find the infos required to actually use the new features?"... which may bring to using the wiki, or to using another medium... we don't know yet.

It's not nice to see "New version: new features are A, B and IDK... Instructions to use them are I don't remember...".
No offence to Sago at all, just trying to find a way to help him.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on August 19, 2016, 01:59:03 pm
The commit comments will always be short. They will be hard to understand but they will be there. Any other form of running documentation will miss stuff (I have seen that). They serve as a reminder for me so that I can remember that I did and when I did it.

I may not be able to remember how "Added ability to execute a script when the server is empty." was implemented but I know that it was implemented and I can relatively quickly tell how it works if someone needs to know.
I can look at https://github.com/OpenArena/gamecode/commit/5e309c9b9dd3e16a1a7c86187e13a23a22bfee52 and see right away I would omit that from a change log.

I am not going to squash my commits to give cleaner commit messages. It is highly destructive to my work flow.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on August 20, 2016, 01:16:40 am
Wait, I did not want to tell you to change your commit shedule. I was just trying to think about a place to write down notable changes in a way you and others could find them more easily. If you think it's not necessary/suitable, it's okay anyway.  :)

Can I however suggest to try to briefly mention related filenames/cvars/key-values in oax changelogs like this? https://github.com/OpenArena/gamecode/releases/tag/oaxB52
E.g. what's the filename of the script file which will be executed when everyone will leave the server?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 01, 2016, 03:43:51 am
Many years ago I talked about adding an .info file: http://openarena.ws/board/index.php?topic=1908.msg47956#msg47956
A "maps/oasago2.info" could look like this:
Code:
auther Sago007
description "After the of the first castle. Sago's second castle was redesigned with multiple layers of defence. After getting past the outer wall the attackers would have little defence. It was hoped that no one would even dare to attack. That turned out to not be the case."

Excuse me Sago, why "auther" instead of "author"? I thought it was just a typo in that specific example, but I see you used "auther" also in this other example (http://openarena.ws/board/index.php?topic=1809.msg54100#msg54100)...

And what's the filename of the script file which will be executed when everyone will leave the server?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 01, 2016, 10:21:10 am
Excuse me Sago, why "auther" inestad of "author"? I thought it was just a typo in that specific example
It was a typo that just got copied around. It will be fixed.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 02, 2016, 03:25:53 am
Excuse me, another question. I just noticed this line:
Quote
If you include an info_player_deathmatch entity in a CTF map, players from both teams can respawn at that location. Great for placing respawn spots in contested central battleground areas.
in our mapping manual (http://openarena.wikia.com/wiki/Mapping_manual/Additional_gametype_support#info_player_deathmatch), which has been taken from here: http://icculus.org/gtkradiant/documentation/q3radiant_manual/appndx/appn_b_4.htm

Is this true? Is it still this way in current OAX? In all team-based gametypes? Has it been changed at some point (e.g. being true for baseq3 and old mods only)?
I haven't done specific tests yet... I ever thought that, if there was at least one team-dedicated spawn point, in CTF (and similar) modes, all deathmatch spawn points would have been ignored. But that phrase tells the opposite (almost the opposite... tells that both team-based and team-free spawn points would be used). Thus, the risk of making player of a team spawn in the enemy base?


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on September 02, 2016, 08:23:39 am
Hmmmm, if the map already contains info_player_deathmatch inside of the bases (and plenty of maps do this because, for some reason, Deathmatch is played on CTF maps) that means a blue player may spawn inside of the red base and viceversa. I'm not sure if I agree with that feature.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 02, 2016, 12:42:21 pm
The manual is incomplete. info_player_deathmatch is only used if there are no other alternatives. Omitting "team_CTF_*player" causes all players to spawn at random places on the map on map start (but not on respawn).
If designing a Elimination map you can easily rely on info_player_deathmatch for the initial spawn because all players will respawn at least once before the game starts.

info_player_deathmatch is the fallback spawnpoints. They will only be used if there are no other spawnpoints. This behavior is unmodified.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on September 02, 2016, 08:25:03 pm
The CTF flags don't hide in Deathmatch even when they have "notffa" set to "1".


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 06, 2016, 10:06:07 am
The CTF flags don't hide in Deathmatch even when they have "notffa" set to "1".
Wasn't that supposed to be "notfree/1" key/value pair? With "notfree", it looks like it works for me...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 06, 2016, 11:05:35 am
The manual is incomplete. info_player_deathmatch is only used if there are no other alternatives. Omitting "team_CTF_*player" causes all players to spawn at random places on the map on map start (but not on respawn).
If designing a Elimination map you can easily rely on info_player_deathmatch for the initial spawn because all players will respawn at least once before the game starts.

info_player_deathmatch is the fallback spawnpoints. They will only be used if there are no other spawnpoints. This behavior is unmodified.

I had to do some tests to fully understand what you meant (not due to your fault, but due to my inexperience in making CTF maps)... I think now I got it.

I did this try with a small box map. I loaded the map in CTF mode (g_gametype 4), using recent gamecode nightly builds (and of August 2016/first of September 2016. I don't think anything player-spawn related changed the last two weeks, right?).


Test 1:
I placed only ONE info_player_deathmatch (no spawnflags) and ONE team_ctf_redplayer there... there is some item and trigger due to some other test, but no more player related spawn spoint.
I joined the game as BLUE player. It spawned at info_player_deathmatch. I used "/kill" to suicide several times; it respawned always in the same place. As expected.
I joined the game as RED player. It spawned at team_ctf_redplayer only the first time. I used "/kill" to suicide several times; it respawned always in the info_player_deathmatch then. A mapper would probably not want this result.

Test 2:
I placed only ONE info_player_deathmatch (no spawnflags) and ONE team_ctf_redspawn there... there is some item and trigger due to some other test, but no more player related spawn spoint.
I joined the game as BLUE player. It spawned at info_player_deathmatch. I used "/kill" to suicide several times; it respawned always in the same place. As expected.
I joined the game as RED player. It spawned at info_player_deathmatch only the first time. I used "/kill" to suicide several times; it respawned always in the team_ctf_redspawn then. A mapper would probably not want this result.

Test 3:
I placed only ONE info_player_deathmatch (no spawnflags), ONE team_ctf_redplayer and ONE team_ctf_redspawn there... there is some item and trigger due to some other test, but no more player related spawn spoint.
I joined the game as BLUE player. It spawned at info_player_deathmatch. I used "/kill" to suicide several times; it respawned always in the same place. As expected.
I joined the game as RED player. It spawned at team_ctf_redplayer only the first time. I used "/kill" to suicide several times; it respawned always in the team_ctf_redspawn then. As expected.

I repeated the three tests adding spawnflags 1 to info_player_deathmatch.
Adding "spawnflags/1" (meaning "initial") to info_player_deathmatch does not seem to change anything in this particular environment (maybe due to the fact I have only one spawn point of that kind); team_ctf_redplayer and team_ctf_redspawn seem not to be listed as support such spawnfliag, probably because definition of the spawn point itself is "initial" ("...player") or "not" ("...spawn").

Note: for time reasons, I haven't checked with more than one player, or with bots in the arena. Also, I have tried in plain old CTF mode only, and with only one spawn point of each mentioned kind.

To sum up, it looks like if you want to make a CTF map, you must place both team_ctf_redplayer and team_ctf_redspawn, otherwise players would spawn at deathmatch spawn points, at re-spawns or at initial spawn depending from the team spawn point kind missing.
And it also looks like that when the Radiant manual suggests that deathmatch spawn points can be used to make characters sometimes spawn in the middle of the map while also continuing to spawn in their "right" bases, it's wrong.

Do you think I'm right?

I never did a CTF map... previously, I thought the team "player" and "spawn" points were one the fallback of the other, if one of the two was not used... while instead the fallback is directly the deatchmatch one!


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 06, 2016, 11:30:11 am
Good explanation Gig. It was what I meant but it is hard to explain. Your examples shows it well.

Note: for time reasons, I haven't checked with more than one player, or with bots in the arena. Also, I have tried in plain old CTF mode only, and with only one spawn point of each mentioned kind.
It is the same for Overload and Harvester. Theoretically also for Elimination and CTF Elimination although everyone are moved to the respawn points during warmup (although now that I think about it, there might be a problem if a player joins during the warmup but after the respawn). Domination and Double Domination uses completly different spawn points and does not have this behavior.

I think I remember one of the original VQ3 maps (or perhaps another custom map) used the case from "Test 2". That way all players spawned in an offensive position. It could potentially be what you want.

Do you think I'm right?
Yes

That being said rather no team_ctf_redplayer/blueplayer than too few team_ctf_redplayer/blueplayer or you would experience a lot of telefragging.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 07, 2016, 12:46:24 am
And it also looks like that when the Radiant manual suggests that deathmatch spawn points can be used to make characters sometimes spawn in the middle of the map while also continuing to spawn in their "right" bases, it's wrong.

Uhm... reading again that passage:
Quote
If you include an info_player_deathmatch entity in a CTF map, players from both teams can respawn at that location. Great for placing respawn spots in contested central battleground areas.
Now that I know the behavior, it looks like to me that they meant the possibility of making an "unconventional" ctf map where all players from both teams would always (re)spawn in the middle of the map, instead of in/near their own base (using only info_player_deathmatch instead of using team_ctf_*player and team_ctf*spawn). Do you think they meant that?

In our wiki page, should I simply remove that sentence, or should I modify it to mention the possibility of the unconventional ctf map, as I wrote here?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 07, 2016, 12:58:28 am
Theoretically also for Elimination and CTF Elimination although everyone are moved to the respawn points during warmup (although now that I think about it, there might be a problem if a player joins during the warmup but after the respawn).
In case you think about making some tweak to Elimination spawn procedure, maybe you may also find the right trick to fix that bug that sometimes casuses half players initially spawning dead in warmup?

Quoting from http://openarena.wikia.com/wiki/Bugs page:
Quote
* In Elimination mode, during the "inactive" elimination warmup, players of one of the two teams spawn in a place where there should not be spawn points (e.g. in a wall), '''and immediately die'''; then they can only spectate other players, until the "active" warmup time begins (at that time, they spawn again and take control of their character). Related post (http://openarena.ws/board/index.php?topic=4452.msg43480#msg43480)
** If also g_dowarmup (generic warmup) is active, they will experience the instant death two times: the first at the beginning og the g_dowarmup time, and the second at the beginning of the "inactive" elimination warmup. It seems to affect Elimination (gametype 8) and CTF Elimination (gametype 9), but not Last Man Standing (gametype 10, similar but without teams) mode.
** Also related to the above, in ''Elimination'' and ''CTF Elimination'', just after ''initial'' map loading, you can see the arena from an unexpected point of view, for a few moments. This is due to the fact that the spawn-routine is disabled until the warm-up begins, and thus you will see the map from 0,0,0 (facing 360) coordinates for a while. It's not a major problem (you will correctly spawn soon: this time depends from the difference between elimination_warmup and elimination_activewarmup variables), but anyway, the case 0,0,0 may be the external void or inside a wall. It can be noticed in few situations only, e.g. while starting the map from the Skirmish menu. Mentioned in Sago's reply to this post (http://openarena.ws/board/index.php?topic=4679.msg46733#msg46733).
Note: I haven't re-checked this with nightly gamecode builds, but I don't remember you mentioning fixing it, or noticed a such thing in git changes history.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on September 07, 2016, 09:31:52 am
Oh, it's "notfree" I don't know why I used "notffa". I'll change that when I come back to home.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 08, 2016, 02:07:42 am
Excuse me Sago, two things:
The first one is probably not worth spending time... however, after doing the tests mentioned above (http://openarena.ws/board/index.php?topic=1908.msg54229#msg54229), I did left the map with no deathmatch spawn points, so while testing another thing, the player spawned at 0, 0, 0 coordinates (okay, it's a new OAX feature), but when I did a /map_restart, if the player was still in the area near 0,0,0, the character auto-telefragged itself!
I don't think it's worth losing your time, as it looks like this only happens in this "extreme" scenery, however you know that I point out what I find!

The second one is a small thing, but it's annoying me since Q3A.
The gametype mentoined while waiting for a map restart is wrong, if the gametype is going to be changed.
When there is the countdown for a map restart, it says the name of the gametype (e.g. "Capture the flag will start in 5... 4... 3... 2... 1...")... but if the gametype is scheduled to be changed (if you check g_gametype, the console mentions the new value as "latched: n"), the message is wrong, because it still mentions the old gametype. If that's an easy thing and you think it has no backfiring risks, it would be a nice to fix it. Thank you.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 08, 2016, 05:18:35 am
I did some small change to our wiki page about gametype support, according to what it seems from the posts above.
If you wish to take a look to those changes... http://openarena.wikia.com/index.php?title=Mapping_manual%2FAdditional_gametype_support&diff=17637&oldid=17567


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 13, 2016, 09:19:20 am
Sago, any further thoughts about what was said in the posts above?

Also, still about spawn points:
I noticed this edit (http://openarena.wikia.com/index.php?title=Mapping_manual%2FAdditional_gametype_support&diff=17638&oldid=17637) of yours. Okay, but is there some reason you mentioned "info_player_start" (which I thought was "deprecated") instead of "info_player_deathmatch"?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 13, 2016, 12:06:41 pm
There is one and only one reason why I fallback to 0,0,0 and that is to prevent the game from crashing. The game should really crash if devmap was used so the mapper may notice that the map is flawed.

The game cannot reliably know witch gametype you are changing to. It can check g_egs witch will be set to one if g_gametype has changed but it will not know which gametype we are changing to (as far as I know the qvm cannot see the future value of a latched cvar). It can also have false positives (0 changed to 1 and back to 0). It will also need to be transported to the client witch is never a good thing.

The changes to gametype support seems fine.

Quote
Okay, but is there some reason you mentioned "info_player_start" (which I thought was "deprecated") instead of "info_player_deathmatch"?
Pure oversight from my side.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 15, 2016, 01:04:18 am
The game should really crash if devmap was used so the mapper may notice that the map is flawed.
Do you mean you already did it this way, or that you should modify it to make it this way? Because I just did a try (with a recent nightly build, although not the latest one), and even if I loaded the map with devmap, it spawned at 0,0,0 without crashing.

Quote
The game cannot reliably know witch gametype you are changing to. It can check g_egs witch will be set to one if g_gametype has changed but it will not know which gametype we are changing to (as far as I know the qvm cannot see the future value of a latched cvar). It can also have false positives (0 changed to 1 and back to 0). It will also need to be transported to the client witch is never a good thing.
Oh. It's a bit sad due to it being an awkward thing; however if implementing it would be against "good practices", oh well... patience...

By the way, it's also a bit odd the fact that the user interface does not even show the gametype you are currently playing, except during the countdown for a map restart and during the warmup (it's also shown in the map loading screen, but today's PCs and SSDs speeds make it hard to read). Maybe OA3 user interface may show it somewhere, e.g. in the score table?

PS: I was trying to understand if in Elimination, team_ctf_*player are ever used, as in this table (http://openarena.wikia.com/wiki/Mapping_manual/Additional_gametype_support#Per-gametype_entity_support) they are currently listed as not needed at all in such mode. But I'm not so sure about my tests, maybe they are used the very first time only (more or less as one might expect, in the end)?
More, I have some doubt about the difference of inactive and active warmup (other than in the inactive one is possible to fall in the bug which makes you spawn dead (http://openarena.ws/board/index.php?topic=1908.msg54233#msg54233)), could you please tell me what was this difference meant for?

Thank you, and sorry if annoying you!


PPS (but probably this is more for Fromhell): any news about OA3 interface (based upont TA-ui) progress status? Just for curiosity...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 15, 2016, 05:06:13 am
Excuse me Sago, one more thing:
I have just done a few player spawning tests... and there is something strange about "nobots" and "nohumans" keys, which should be spawnpoint-specific keys (not meant for uses diffent than character spawn points, if I understood correctly).

I tried using them on an info_player_deathmatch, and it looks like they are capable of completely crashing the game (not shutting down with "couldn't find a spawn point", but really making the game completely freeze). I did a few tests, and things seems to vary...

A) It looks like the game crashes when it tries tries to make the player/bot spawn there (apparently, no problem for the spectator). It happens even if there is another info_player_deathmatch without any kind of limitation available in the map. So, it may not be at the first spawn, sometimes it may happen at a later spawn.
It almost seems like the spawn procedure does not ignore the spawn point as it should and picks it up anyway, but then it is unable to actually use it and hangs. But these are just my impressions, one should look at the code/debug to be sure what's happening.

B) In a few sceneries I had the impression it just ignored the key and used the spawn point (without crashing) although it should have ignored it[1].


Notes:
- "nobots" should not be confused with "notbot", which instead is meant for (pick-up-able) items, to make bots not be attracted by them.
- This seems to happen also in both current OAX and 0.8.8, so it has not been introduced when you did the recent 0,0,0 trick to prevent server shutdown, but it is older.
- Tried in the original Q3A game (without bots): problem A) [the worst one!] does not seem to happen there (it always spawns at the "right" info_player_deathmatch, the one without limitations, without crashing). Problem B) seem to happen also there (playing as blue in CTF without the dedicated "blue" spawn points, it always spawns at the deathmatch spawn point which has "nohumans/1", while in theory it should use the other one).
-- So, there may theoretically be some maps made for Q3A which work in Q3A but freeze OpenArena.
- Being a gamecode thing, even if you fix it for OA3 it would still affect older versions of the game, so maybe we should place some advice to avoid using such keys?
- I have tried using them only on info_player_deathmatch, NOT on any other kind of player spawn point.
- I have no info_player_intermission in the test map

[1] Scenery of this test: I do have 1 team_ctf_redplayer, 1 team_ctf_redspawn, 1 info_player_deathmatch (spawnflags 1) without any restriction and 1 info_player_deathmatch (spawnflags 1) with "nohumans/1". In g_gametype 4, as red player I spawn where expected (team_ctf_redplayer first time, then team_ctf_redspawn), while as blue player it ALWAYS spawns at the info_player_deathmatch with "nohumans/1" (while it never uses the one without "nohumans"). Of course, using deatchmatch spawn points in CTF is already a "fallback", however this is still strange.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 15, 2016, 01:29:29 pm
I have not done anything about 0,0,0 and devmap, it was just an idea.

The inactive warmup in Elimination gives some time for rockets and mines to be cleared. It also just feels better that the next round warmup does not start in the same moment the previous round is won. It gives a "spawned dead" effect.

I am a bit surprised about the nobots and nohumans bug. I knew that the freeze thing could happen (it happened for me in intooa) but I thought the bug had always existed. I created a small workaround to make intooa not freeze.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on September 15, 2016, 01:38:05 pm
I am very surprised that you got it working in VQ3 because the original VQ3 source defiantly has the nohumans bug.

It was fixed in ioquake3 2009-11-03: https://github.com/ioquake/ioq3/commit/f5d79ea066c1f742ff8c98dd5d9c484b9db122e3


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on September 16, 2016, 06:25:53 am
I have not done anything about 0,0,0 and devmap, it was just an idea.
It sounds like a good idea to me (for both "devmap" and "devspmap", of course).

Quote
The inactive warmup in Elimination gives some time for rockets and mines to be cleared. It also just feels better that the next round warmup does not start in the same moment the previous round is won. It gives a "spawned dead" effect.
The "spawned dead" thing is a bug, not a feature, isn't it? IIRC, it affects only half of the players...
WAIT, let me make a couple of tests...

Oh, now I finally got it! You are not telling about the problem which happens in some maps at the very first spawn...
I finally understood what's the difference between between "inactive" warmup and "active" one: during inactive warmup, players who died in the previous round are simply not yet revived! So, if you survived the match, you do not notice differences between inactive and active warmup behavior (unless the gap between the two warmups is enough that you can notice there are no enemies around).... but if you did not survive the previous round, you just continue spectating until the "active" part begins, and this is not a bug. Okay!

Quote
I am a bit surprised about the nobots and nohumans bug. I knew that the freeze thing could happen (it happened for me in intooa) but I thought the bug had always existed. I created a small workaround to make intooa not freeze.
I had to do a search to find out what "intooa" was: it is a version of yours of an introduction/tutorial map, right? http://openarena.ws/board/index.php?topic=3999.msg36421#msg36421

I have no idea about the reason why the tutorial maps from Neon Knight (the first one being in this thread (http://openarena.ws/board/index.php?topic=3999.0), and the one thought for OA3 in this other one (http://openarena.ws/board/index.php?topic=5265.0)) do not freeze. Maybe the presence of one spawn point with "nobots/1" is not alone enough to trigger the bug, but there must be some other thing interacting (e.g. that spawn point being the one the game chooses as "default" one for that gametype? I don't know)? Or maybe the fact that NK also placed other keys ("gametype/single" and "target/target_give1") to that entity somehow prevented the bug from happening? I have no idea.

Also, is your fix meant to only fix the crash (problem "A" in that previous post (http://openarena.ws/board/index.php?topic=1908.msg54263#msg54263)), or also problem "B" (not fatal, but existing)?

I am very surprised that you got it working in VQ3 because the original VQ3 source defiantly has the nohumans bug.
I really don't know what to think.
Attached, you can find a "testbox" map pk3, so you can try with your own copies of OA, Q3A and ioquake3 if you wish. It's a small box, with some absolutely unrelated things as it's just a box where I do tests.. don't care for them. Just try (re)spawning. Source .map included.
It should be the scenery described in the note "[1]" of the previous post, so it should be good also to test problem "B" if you wish. However, about problem "A", if you launch the map in g_gametype 0, at first you spawn in the correct place (the deathmatch spawn point on the left -on "north" side in the editor-, which has NOT the "nohumans/1" key), but if you suicide yourself (/kill), the game hangs.

I tried this map in OpenArena, and it CRASHES (at second spawn in ffa) in both 0.8.8 and recent oax. I also tried it with the old "Alternate Fire (http://openarena.wikia.com/wiki/ModCompat/Alternate_Fire)" Q3A mod, and it does NOT crash there.
Then I tried it in Q3A 1.32c (I haven't tried it with ioquake3): it does NOT crash in baseq3 and does NOT crash in alternate fire mod. My Q3A install is somewhat a mess, but however I don't know how's possible it works there without crashing, if you say Q3A had the bug. Maybe something changed between Q3A and OA and thus the bug happens under different circumstances? I haven't tried NK OA3 tutorial map in Q3A yet...

Quote
It was fixed in ioquake3 2009-11-03: https://github.com/ioquake/ioq3/commit/f5d79ea066c1f742ff8c98dd5d9c484b9db122e3
I don't know that to think...
Does ioquake3 also do changes to gamecode, other than engine? How's possible that bugfixes made in ioquake3 have not been ported to OpenArena? Do you think that there may be many more of them?
Are you sure that the bug was there since Q3A and it wasn't introduced by ioquake3 instead, with OpenArena inheriting it from ioquake3? I don't know how a such thing may have happened, but that would explain why my testbox map crashes in OpenArena, but not in Q3A...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on October 14, 2016, 03:29:04 am
Hello Sago, how are you?
Did you discover something about the things we were discussing before, e.g. which are the Q3A/ioq3/OA versions which may freeze if "nobots" and "nohumans" are used in player spawn points?

Also:
- Do you think everything should work fine, with latest nightly builds, or some bugs are still there (IIRC under some of the previous tests, the game did not freeze but those spawn points were used even if in theory they should have been ignored)?
- Also, are those keys working for all kinds of player spawn points or only for some of them?

Different topics:
- I see in this diff (https://github.com/OpenArena/gamecode/commit/f06aa8b2628e53426599e53c1f4fec95da54311b) that you added a dmflags (4096) to move much faster underwater... I haven't tested it yet, but I see there is also another "new" dmflag (DF_PLAYER_OVERLAY, 2048): what's that?

- I have tested g_respawntime (a 0.8.8 cvar), and I have written about it on the wiki (http://openarena.wikia.com/wiki/Special_game_options#Respawning_in_waves) based on my own tests (diff (http://openarena.wikia.com/index.php?title=Special_game_options&diff=17694&oldid=17679)). Could you please confirm I correctly understood its behavior? I tested it all alone, without other players or bots...



Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on October 14, 2016, 11:55:41 am
Hello Sago, how are you?
Did you discover something about the things we were discussing before, e.g. which are the Q3A/ioq3/OA versions which may freeze if "nobots" and "nohumans" are used in player spawn points?
I think the reason that it worked in VQ3 was due to another bug that canceled it out.

Also:
- Do you think everything should work fine, with latest nightly builds, or some bugs are still there (IIRC under some of the previous tests, the game did not freeze but those spawn points were used even if in theory they should have been ignored)?
- Also, are those keys working for all kinds of player spawn points or only for some of them?
They only work for deathmatch spawnpoints, all freezing should be fixed and it should not allow the engine to use illegal spawnpoints.

Different topics:
- I see in this diff (https://github.com/OpenArena/gamecode/commit/f06aa8b2628e53426599e53c1f4fec95da54311b) that you added a dmflags (4096) to move much faster underwater... I haven't tested it yet, but I see there is also another "new" dmflag (DF_PLAYER_OVERLAY, 2048): what's that?
DF_PLAYER_OVERLAY does not work. It required shaders that are not included. You may be able to find them in old OAX releases.
The underwater thing does not work that well either. It should allow much faster movement underwater but it only makes it twice as fast as before at the moment.
Both if them are mainly meant to test ideas for mods.

- I have tested g_respawntime (a 0.8.8 cvar), and I have written about it on the wiki (http://openarena.wikia.com/wiki/Special_game_options#Respawning_in_waves) based on my own tests (diff (http://openarena.wikia.com/index.php?title=Special_game_options&diff=17694&oldid=17679)). Could you please confirm I correctly understood its behavior? I tested it all alone, without other players or bots...
It is supposed to work like you described it.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on October 20, 2016, 09:37:33 am
They only work for deathmatch spawnpoints, all freezing should be fixed and it should not allow the engine to use illegal spawnpoints.
Are you sure? I have just done a test with oax nightly "2016-10-11", and while it did not crash (good), it still happened that it picked the "wrong" spawn point in that (odd) test of mine described here:
[...]
B) In a few sceneries I had the impression it just ignored the key and used the spawn point (without crashing) although it should have ignored it.
[...]
Scenery of this test: I do have 1 team_ctf_redplayer, 1 team_ctf_redspawn, 1 info_player_deathmatch (spawnflags 1) without any restriction and 1 info_player_deathmatch (spawnflags 1) with "nohumans/1". In g_gametype 4, as red player I spawn where expected (team_ctf_redplayer first time, then team_ctf_redspawn), while as blue player it ALWAYS spawns at the info_player_deathmatch with "nohumans/1" (while it never uses the one without "nohumans"). Of course, using deatchmatch spawn points in CTF is already a "fallback", however this is still strange.
You can simply test it using my "testbox" map I attached to this previous post (http://openarena.ws/board/index.php?topic=1908.msg54266#msg54266), joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.

Quote from: Sago007
DF_PLAYER_OVERLAY does not work. It required shaders that are not included. You may be able to find them in old OAX releases.
Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?

Quote
The underwater thing does not work that well either. It should allow much faster movement underwater but it only makes it twice as fast as before at the moment.
I did a quick try, it looks to me it allows to swim in water at the same speed of standard "running" on the ground (without strafejumping... about 320ups), right? In that case, it looks to me a good speed, if one wants to actually use the feature because finds the standard swimming speed annoying.

Of course, a mod author could re-use that code as base for a "sea being" class of character which would swim faster than run... probably he would not use the dmflag itself, but would adapt it for the class-based thing, and then may use a new "multiplier" constant with an higher value than the one of the dmflag, to obtain higher speeds... isn't it?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on October 20, 2016, 11:04:09 am
You can simply test it using my "testbox" map I attached to this previous post (http://openarena.ws/board/index.php?topic=1908.msg54266#msg54266), joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.
There should be no check for nohumans/nobots while doing fallback.

Quote
Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?
I don't remember. It was used to create this screen shot:
http://openarena.ws/board/index.php?topic=4324.msg40500#msg40500
As far as I remember it was just the hazard suit shader with blue and red colors.

Quote
but would adapt to it for the class-based thing
Exactly!


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on October 20, 2016, 08:08:51 pm
oh so like an oaverw*tch?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on October 21, 2016, 01:09:11 am
You can simply test it using my "testbox" map I attached to this previous post (http://openarena.ws/board/index.php?topic=1908.msg54266#msg54266), joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.
There should be no check for nohumans/nobots while doing fallback.
If that's intended, then okay.  :)

Quote
Quote
Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?
I don't remember. It was used to create this screen shot:
http://openarena.ws/board/index.php?topic=4324.msg40500#msg40500
As far as I remember it was just the hazard suit shader with blue and red colors.
"Brightskins"-like shaders, eh? May be an interesting thing which may be worth looking into. A few considerations:
- At the time, Fromhell said she wanted "pro" stuff (which she does not like) in a separate "pro" folder; I think she was referring to a sort of "stock-included" mod (like the "Missionpack"), but I'm not sure. Personally, I have no problem in having them in baseoa, as long as they are a server-allowed thing disabled by default. What's her current opinion about that?
- A few of the OA 0.8.x player models do not work very well with the powerup shaders (e.g. battle suit shader), which you said were the base for your test. I hope all OA3 models will work well with those shaders.
- In case the idea is totally discarded, the dmflag 2048 may be reused for something different, to do not left an "empty space" in its allowed values. In case the idea is applied, this would be a feature so wanted by playerbase that it may even be worth of having a proper cvar to enable it, instead of just a dmflags value (just thoughts).
- I see that post is from 2011... does it mean that code is in 0.8.8, and if one places the right shaders in the right folder, it would be more or less working with 0.8.8?
- Just for completeness, I'm not a great "proskins" fan myself, although I used something of that kind (cg_enemymodel keel/green in the OSP mod, IIRC) in the old times I was in a Clan Arena OSP Q3 clan, something like 15 years ago...

oh so like an oaverw*tch?
What? :-/


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on October 21, 2016, 09:44:34 am
oh so like an oaverw*tch?
More like: Oaver Fortress Arena IV

Quote
- Just for completeness, I'm not a great "proskins" fan myself, although I used something of that kind (cg_enemymodel keel/green in the OSP mod, IIRC) in the old times I was in a Clan Arena OSP Q3 clan, something like 15 years ago...
Me neither but I must admit that even I had some problems with the lightning on the maps and being unable to see all player models clearly. This can be blamed on the maps but I did not consider it realistic to fix them, so I suggested an alternative solution.
At least the overlay solution still kept some of the charm of a large roaster.

The shaders needed are:
playeroverlays/playerSuit1_Neutral
playeroverlays/playerSuit1_Red
playeroverlays/playerSuit1_Blue

I found the shader and have attached it. In case someone wants to try it.


Title: Re: Open Arena Expanded Beta 50
Post by: Neon_Knight on October 23, 2016, 06:03:15 am
In all reality I fully agree that brightskins are just a workaround for the visibility problem found in maps. And we have already an example of a game which never needed brightskins and had a full-blown competitive scene: the first Unreal Tournament.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on October 24, 2016, 12:36:10 am
Tried it. Is looks like it works quite well.  :)
Attached to this post, you can find z_playeroverlays_test.pk3, which contains the same shader file from Sago's post above, but packaged to be tested more easily. Just place it into your baseoa folder, start OpenArena (you don't even need OAX, since OA 0.8.8 already contains the required gamecode), set dmflags 2048 and play.

As you can see, it currently adds a yellow/orange layer in non-team-based modes, and red or blue layer in team-based modes.
I also attach an image with the most "fragile" situation, having it and powerups at the same time. It is non-exhaustive, but still gives the idea. Maybe some kind of tweaking from someone who knows shaders may produce even better results.

I don't know how to calculate how much the feature may affect framerate...


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on October 31, 2016, 12:14:35 pm
I don't know where exactly I could post these questions so I'll post it here...
Is this topic preferred way of discussing gamecode changes as there seems to be nothing on github issues page?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on October 31, 2016, 12:51:01 pm
Is this topic preferred way of discussing gamecode changes as there seems to be nothing on github issues page?
You are welcome to open an issue on Github (https://github.com/OpenArena/gamecode/issues). I personally prefer it although I don't know how many people here have an account and follows the repository. I do.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 01, 2016, 11:25:37 am
I haven't a github account (at least, not yet). Not being a developer, I would not use it for anything else that posting issues.

On one hand, handling open/closed issues with a proper managing system would be more efficient than the current way of just using forum threads plus trying to somehow update the Bugs wiki page (http://openarena.wikia.com/wiki/Bugs) (and the Wishlist one (http://openarena.wikia.com/wiki/Wishlist)) as recap...

On the other hand, using the forums allows for some more visibility and potentially some more brainstorming about possible improvements...


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 02, 2016, 06:02:49 am
I haven't a github account (at least, not yet). Not being a developer, I would not use it for anything else that posting issues.

On one hand, handling open/closed issues with a proper managing system would be more efficient than the current way of just using forum threads plus trying to somehow update the Bugs wiki page (http://openarena.wikia.com/wiki/Bugs) (and the Wishlist one (http://openarena.wikia.com/wiki/Wishlist)) as recap...

I agree. Github should only be for bug tracking and people who work with code.

On the other hand, using the forums allows for some more visibility and potentially some more brainstorming about possible improvements...

We can also talk in realtime on discord for brainstorming ideas, etc. I could set up a #dev or #oax channel.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 03, 2016, 01:17:02 am
Back to "nobots/nohuman", I have noticed a curious thing:
I was searching in Changes (http://openarena.wikia.com/wiki/Changes) wiki page trying to find out which OpenArena version added Spawn protection (http://openarena.wikia.com/wiki/Spawn_protection) to baseoa (and I haven't been able to find it)... and so I noticed a line in the forum post about 0.8.5 changelog (http://openarena.ws/board/index.php?topic=3548.msg30774#msg30774):
- Changed the way the game picks the spawn point to prevent maps with few spawnpoints that are marked with nobot or nohuman from hanging the game.
It looks like something went wrong back then...


PS: About the spawn protection, I found it, it's from OAX Beta 47: http://openarena.ws/board/index.php?topic=1908.msg33556#msg33556
That post is from July 2010, so it's a 0.8.8 feature (0.8.5 was from February 2010).



Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 03, 2016, 04:04:01 pm
1pixel, are you the "Idrone" who is doing some test with a gamecode fork in these days?

Uhm... if some discussion is going to happen also on github, it looks like I will have to register also there...

Do you think you can run away from my boring posts?  >:D


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 04, 2016, 06:17:07 am
1pixel, are you the "Idrone" who is doing some test with a gamecode fork in these days?

Uhm... if some discussion is going to happen also on github, it looks like I will have to register also there...

Do you think you can run away from my boring posts?  >:D

I have to upload my "code suggestions" somewhere.  :)

But we can discuss the rest here. I'll try to follow both places.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 04, 2016, 07:05:50 am
It was just to be sure I was talking with the same person.  :)

Okay, now I'm "The-Gig" on github ("Gig" and "TheGig" were already taken by someone else). So you may find comments from mine on the "issues" there (e.g. I added a comment here (https://github.com/OpenArena/gamecode/issues/7) and here (https://github.com/OpenArena/gamecode/issues/8)).


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 05, 2016, 04:31:09 am
Excuse me Sago... back to the fast swim dmflag, I wass giving another look to the source code... just for curiosity.

While for me the result of swimming at the same speed of running is ok, I do not understand how it works.
https://github.com/OpenArena/gamecode/commit/f06aa8b2628e53426599e53c1f4fec95da54311b
It looks to me that if the dmflag is active, you change a multiplier from 0.5 to 5.0... so I would have expected a result 10 times faster... why does this do not happen?
I don't think swimming five times faster than running is required at all, I was just curious...
I'm not accustomed to C, so I don't know what the "f" in 5.0f stands for, or what "->" does...


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 05, 2016, 07:10:17 pm
f means float


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 06, 2016, 04:37:47 am
Okay, I don't know why the variables initialized here https://github.com/ldrone/gamecode/commit/02d6b156553d746675e992c0c0829a9489718b9f do not seem to be marked as float despite having decimal parts...
But it looks like they are two different kinds of initalization (the code seems different)... maybe some are local and other are global variables, I don't know. It doesn't really matter, it's just that giving a quick look to the code changes, even if with a very limited understanding of it, seems interesting. :)

Back to school times, I used a little of Pascal and Clipper programming languages... not that I may be capable of writing something after all these years (at maximum I did some simple AutoIt scripts in the past years)... just to say that I had a few programming bases back then...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 07, 2016, 12:21:45 pm
It looks to me that if the dmflag is active, you change a multiplier from 0.5 to 5.0... so I would have expected a result 10 times faster... why does this do not happen?
I guess that it is capped at some other place. I just haven't found it yet.

Regarding types:
5.0f -> single precision floating point (32 bit)
5 -> integer
5.0 -> double precision floating point (64 bit)
"5.0" -> string
"5" -> also a string

In games float is often preferred over double for storage but double is still often used in calculations.
The rules for converting between them can be weird in C.

CVARs are always strings on the disc.
Unlike C a floating point value in a CVAR is always a float. ( Example: "cg_some_cvar.value" is a float )
The two rules above means that declaring cg_kickScale as "1" (string on disc) and accessing them with "cg_kickScale.value" is perfectly valid.

I "->" in the code is a pointer dereference. It is short for following the pointer and then accessing its member. If p_pickScale is a pointer to a CVAR you would write: "p_kickScale->value"


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 07, 2016, 12:37:58 pm
Thank Sago, your explanation is very appreciated!  :)

Ps: So, you can't store a double precision float in a cvar, right?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 10, 2016, 03:11:42 am
Hello everyone.
I tried to make a test to see how much the "player overlay" thing would have slowed down rendering. To my surprise, it seems to allow even faster rendering!  ???
Maybe there is some problem with the way I did the test?
I recorded two demos with many bots (and no forcemodel) with dmflags 2048: one spectating to see all players at once (to simulate the "worse scenery"), and one playing (to simulate a more common scenery).
Then I used "timedemo 1 (http://openarena.wikia.com/wiki/Timedemo)" and then played the demos, looking at the console result at the end. Then I removed the required shaders test pk3 (http://openarena.ws/board/index.php?topic=1908.msg54331#msg54331) from baseoa and played the same timedemos again. Then I copied the files to another pc and ran the same timedemos also there.

Here there are the results:
First demo (spectating in wrackdm17, with 16 bots):
High end PC: 126.6 fps (overlay) - 111.1 (without the pk3)
Low end PC (lower resolution): 33.4 fps (overlay) - 29.4 (without the pk3)

Second demo (actually playing in mlca1, with 16 bots):
High end pc: 222.8 (overlay) - 200.2 (without the pk3)
Low end PC (lower resolution): 69.1 fps (overlay) - 64.5 (without the pk3)

Note: every time I run the timedemo, the result framerate isn't perfectly identical, it may vary by a fraction of fps to a couple of fps... but the difference between "overlay" and "without" is bigger than the simple test-by-test-variation.

The only explaination I can think is the feature being implemented in a way that, even if it doesn't find the required shader, it still does most of the computing related to it (e.g. creating an invisible shell of polygons around the character). If that's the case, then I don't know how to make proper performance tests with it...

Sago, Fromhell... what do you think about this stuff?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 10, 2016, 03:13:54 am
WRONG POST, PLEASE DELETE THIS.
Thanks.

(Read the one above, instead).


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 10, 2016, 12:43:57 pm
Sago, Fromhell... what do you think about this stuff?
It might be the missing shaders that are making it slow.

Ps: So, you can't store a double precision float in a cvar, right?
You could convert it to and from string manually but it would be very inefficient. There are better options.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 16, 2016, 02:48:00 am
I did another try to make some benchmarking about player overlays feature.
This time, results do have more sense (the feature somewhat slows down rendering, it seems), but the limits of the test do not allow to simulate "real" usage...

This time I did do the test with the overlay shader pk3 installed the whole time.
I loaded a map having dmflags 2048, set cg_thirperson 1, and recorded a short demo showing only myself, standing still.
Then I stopped recording, set dmflags 0 (overlay immediately disappeared) and started recording again, still standing still, without touching anything else.

Then I set timedemo 1 and played back the two demos (still setting cg_thirdperson 1 before launching playback).

Here's the results:
High end pc
first demo: player overlays 759.2 fps
second demo: without player overlay 793.1 fps

Low end pc
first demo: overlay 254.8 fps
second demo: without player overlay 272.2 fps

This time, it looks like the feature actually slowed down rendering a little.
So, trying to get some percentages:
759.2:793.1=x:100
x= (759.2 * 100) / 793.1
x= 94,84
100 - 94,84 = 5,16 % slowdown

254.8:272.2=x:100
x= (254.8 * 100) / 272.2
x= 93.60
100 - 93.60 = 6,48 % slowdown

But here there are the limits of this test:
- They are not the same exact demo. They should be extremely similar, as I was alone and I did not move at all, but they are not actually the same one. As a further test, I recorded three similar "stand still for a few seconds" demos without changing settings and I played them: they had a change of less than 10 fps each other on the high-end pc. So I can guess the larger fps change in the "overlay/without" demos should be related with the dmflags value change.
- I was completely alone. So, it cannot really be representative of the framerate change during actual gameplay. One might expect something like a 6 % more slowdown for each additional player rendered? E.g. if you have one player, enabling the feature slows down by around 6%; if you have 5 players, enabling the feature slows down by around 30%? I suppose things could be more complicated than this (e.g. players are just a part of the rendering).
- Player models differ, so I can guess that also their "shells" polycount would differ.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 16, 2016, 03:21:21 am
I modified the test trying to make it a little more representative.
This time, I did it in TDM mode, added four bots to my team, and ordered them to "camp here".
They do stand still, although they look around...
So, I did take a first demo with dmflags 2048 and then a second demo with dmflags 0...

High end pc
player overlays 277.3
without player overlay 310.7

Low end pc
overlay 79.7
without player overlay 94.8

So...
x= 277.3 * 100 / 310.7
x= 89,25
100 - 89,25 = 10,75 % slowdown.

x = 79.7 * 100 / 94.8
x= 84,07
100 - 84,07 = 15,93 % slowdown

Not as bad as feared...  :)

It's possible that during the test some items which were previously taken by the bots respawned, hence making the framerate of the initial part of the test somewhat faster than the second part!

So, I did another test (same number of bots, although some were not the same models), this time making more time pass before starting recording, and recording without overlays first, then enabling them:

high end pc
295 against 267 fps
x= 90.50
100 - 90.50= 9.5 % slowdown

low end pc
91 fps against 75 fps
x= 82.41
100 - 82.41 = 17.59 % slowdown

Results seem to be quite similar to the previous ones...
It can be noticed that low-end hardware seems to be more affected than high-end hardware, in percentage...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 17, 2016, 02:36:50 am
Hello, I'm here again.
I know I may become boring, however I did another test. It's just like the previous one, but this time with 20 characters (me + 19 bots camping).... this should give a better idea about real use performances.

high end pc
no overlay 128 fps
overlay 110 fps
x=85,94
100-85,94=14,06 % slowdown


low end pc
no overlay 34.6 fps
overlay 26.5 fps
x=75.59
100-76,59=23,41 % slowdown

Considering this happens with 20 characters in the map, IMHO it's acceptable (hey, we are applying to 20 characters some effects which where thought for being applied to one or two characters at the same time). Don't you think so?


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 17, 2016, 10:26:50 am
well imho it's unacceptable

That's a LOT of cpu being churned out to make two whole teams of players appear red/blue


I think having maps designed for balanced light levels and decent team skins (NOT brightskins) would do a better more efficient job and that's what i'm having in mind in oa3's design

(also FYI the latest OA engine does have a speedup for bulge deformvertxees adapted from Jedi Outcast, which would be involved with this effect)


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 17, 2016, 10:46:55 am
well imho it's unacceptable
That's a LOT of cpu being churned out to make two whole teams of players appear red/blue
I do wonder if there may be a different way to apply a such thing, consuming less CPU.... I don't know if it may be possible to apply a shader to change the "tint" of models to make them more blue-ish/red-ish by acting directly on the skin, without having to create a shell of poygons around the model. It would much probably be possible to force a generic colored shader in the place of all shaders/texutres used by the model (similarily for the missing texture placeholders)... but I can guess the result may be uglier than this one.

Quote
I think having maps designed for balanced light levels and decent team skins (NOT brightskins) would do a better more efficient job and that's what i'm having in mind in oa3's design
Third party models (not very used online, I guess) and third party maps (which may be very used also online), which simply are out of our control, would still be an issue...
Of course, including maps and models with better visibility with the game is a good thing anyway!

Quote
(also FYI the latest OA engine does have a speedup for bulge deformvertxees adapted from Jedi Outcast, which would be involved with this effect)
This sounds interesting. I might do a comparison with OA 0.8.8 binaries and latest nightly builds binaries, then. Is some setting needed to enable the speedup?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 17, 2016, 11:20:45 am
(also FYI the latest OA engine does have a speedup for bulge deformvertxees adapted from Jedi Outcast, which would be involved with this effect)

This morning's test (0.8.8 binaries)
20 characters

high end pc
no overlay 128 fps
overlay 110 fps
x=85,94
100-85,94=14,06 % slowdown

low end pc
no overlay 34.6 fps
overlay 26.5 fps
x=75.59
100-76,59=23,41 % slowdown

Played the same two demos using current engine nightly build (2016-11-16).

high end pc
no overlay 140
overlay 119
x=85
100-85=15% slowdown

low end pc: I got more or less the same results that I had with the old binaries... maybe 1 more fps...

It looks like new binaries have got a somewhat better framerate on high end pc....
no overlay 128:140=100:x, x=109,38 (9,38% faster with latest binaries)
overlay 109:119=100:x, x= 109,17 (9,17% faster with latest binaries)...


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 19, 2016, 12:47:24 pm
I still don't know how get UI3 fonts into Linux build, that will take me some time to figure out.

The screenshots for frag (obituary) messages.

The last one with the skulls is when the attacker is known, I don't know how much sense it has in that form, i.e. will people understand what it's about.

We could also add another icon for the skull, gray/white, and maybe different icon for the last image case, something like Gig suggested,
if you all agreed on doing this.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 19, 2016, 01:14:12 pm
I prefer the last one. If the player is killed by another player the attackers name should be there even if it was not a direct kill.
This also matches how the messages are printed in 0.8.8


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 19, 2016, 04:00:26 pm
I don't see why "x skull y" may be difficult to understand...

However, to give some more infos about this stuff (known as "iconographic"), here's the link with the discussion about it on github:
https://github.com/OpenArena/gamecode/issues/8
(which ALSO talks about a different matter, optionally disabling kills output to console)

Also people without a github account are invited to express their opinions here on the forum, of course.

I also propose a cvar to control the feature... e.g.
0) iconographic kills, separed from chat/warnings (default?)
1) text kills, separed from chat/warnings
2) text kills, together with chat/warnings (aka classic behavior)
3) iconographic kills, together with chat/warnings (maybe not really necessary, however mentioned here in case one wants to cover all possible cases)
(Options numbers are just an example.)

PS: what are those "entity used itself" warnings in the first screenshot? :-/


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 19, 2016, 04:35:11 pm
Quote
PS: what are those "entity used itseft" warnings in the first screenshot? :-/

I think it has something to do with a small map, lots of players/bots and too little spawns.
Not related to my changes, as it happens without them, but I didn't look into the problem itself.


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 20, 2016, 09:49:06 am
II also propose a cvar to control the feature... e.g.
0) iconographic kills, separed from chat/warnings (default?)
1) text kills, separed from chat/warnings
2) text kills, together with chat/warnings (aka classic behavior)
3) iconographic kills, together with chat/warnings (maybe not really necessary, however mentioned here in case one wants to cover all possible cases)
(Options numbers are just an example.)

The missing options are when someone wants to disable HUD or both HUD and console output.
It may go something like this:
0) no message
1) console (old style)
2) text + console
3) icons
4) icons + console

Either 3) or 4) would be default.

However, if both the new HUD and console message is shown, we'd have to disable con_notify, so that the message doesn't appear twice on screen. That's a problem since con_notify (the top left screen section) displays other messages, e.g. flag captures.

I'd create separate HUD parts (so they can use icons) for other messages as well, and use con_notify for warnings only in debug mode.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 20, 2016, 11:23:59 am
0) no message
1) console
2) text + console (classic)
3) icons
4) icons + console
I think 3 should be default.
1 should not be an option. Do not mess with com_notify for this.
Printing to console implies that the text is written.


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 20, 2016, 03:41:26 pm
0) no message
1) console
2) text + console (classic)
3) icons
4) icons + console
I think 3 should be default.
1 should not be an option. Do not mess with com_notify for this.
Printing to console implies that the text is written.

My mistake, 1) is actually the classic/old style. There seems to be a lot of confusion. I'll make a pull request.so you can look into the code.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 21, 2016, 02:49:16 am
I'm sorry guys, I got lost with this stuff.

For the four options I supposed in my previous post (http://openarena.ws/board/index.php?topic=1908.msg54413#msg54413), I was just referring to the HUD obituary (a single variable for controlling having the obituary in the same "box" of the other notifications -classic way- or in a distinct box -modern way-, AND for controlling having the obituary shown as text only -classic way- or as iconographic -modern way-).

I was not referring to disabling obituary output to console (I thought about it as a different topic, worth of a distinct CVAR to control it. Of course, the console obituary variable should only be "on/off", as the console cannot be splitted and should not contain icons), and I was not thinking about a "no obituary output on HUD at all" because I just did not think about it (also I don't know if that would be useful, however as an additional option it should not be harmful to players).

I tried giving a look to the code, but that part is too complicated to me, due to my ignorance of C. Could you please have some patience with me and try to explain me again what do the various values do the way you implemented it at the moment?


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 21, 2016, 09:03:25 am
So far it goes like this:

cg_obituaryOutput 0 - old style, output only to console (and the top left screen which is console notification)
cg_obituaryOutput 1 - text output to lower left, no output to console
cg_obituaryOutput 2 - icon output to lower left, no output to console
cg_obituaryOutput [other values]  - no output, should this be an option?

If I leave the console output with 1 and 2, it would just show a duplicate message on screen (top left and lower left), that is, without messing with con_drawnotify or changing con_notifytime..

If text is too fast to keep track of, there is an alternative of having a variable to increase fade time and/or increase the number of lines that display the frag output on the HUD.


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 21, 2016, 11:11:17 am
Can there be a top-right iconograph obituary?  That's where Half-Life (and derivatives) put it, with a 4 line obituary buffer, bumping down the FPS counter/clock/speedometer


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 21, 2016, 11:11:54 am
Thank you, I think I got the situation now.
So, there is the big problem that you cannot write text to console output without also showing it in the upper left corner, unless modifying some low level fuction, right?

Are we sure it's really so hard/risky? Id software really did not foresee a level of "priority" (or a show/hide flag) for a message/warning to be shown in console only and not in the upper left? As example, those tons of text which are shown in console after an initialization (e.g. snd_restart, in_restart), are not shown to the end user only because he sees the map loading screen (instead of the game and its hud) during such initializations?

The combination which is not possible is really the one which should have been the better one...
Maybe it may be made a try to check how the result would feel with the "repeated" infos in the hud? Both text in upper left+icons in lower left. Just to test...


PS: changing topic a little.
I know I should have said this earlier. Forgive me.
This is just a question (I repeat: a question)...
Text obituary works this way (X dies, Y attacks):
X got Y's rocket (normal kill)
X cratered (normal suicide)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (normal suicide)

Or should it have been this way instead?
X <rocket icon> Y (normal kill)
X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.

Gg from cell phone (please forgive errors).


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 21, 2016, 01:18:14 pm
Can there be a top-right iconograph obituary?  That's where Half-Life (and derivatives) put it, with a 4 line obituary buffer, bumping down the FPS counter/clock/speedometer

In cgame/cg_draw function CG_DrawFragMessage( void ) i have (x, y) variables that set the coordinates, so it could be anywhere on the screen.
I set the fade time (which can also be modified) to 7 seconds, the number of seconds to display a single frag message.
And in cgame/cg_local.h, FRAGMSG_MAX controls the number of lines shown.

I'd have to look into the right text alignment, especially for top right text output (cg_obituaryOutput 1).

The function may be CG_DrawFragMessage(x, y, fade, msg_max), so that these four parameters could be controlled from ui files and changed to your liking.
I haven't yet looked into it.

So, there is the big problem that you cannot write text to console output without also showing it in the upper left corner, unless modifying some low level fuction, right?

As fromhell pointed out to me, this output is coded in openarena/engine (so the part about low level function trap function is deprecated info :)).

Are we sure it's really so hard/risky? Id software really did not foresee a level of "priority" (or a show/hide flag) for a message/warning to be shown in console only and not in the upper left? As example, those tons of text which are shown in console after an initialization (e.g. snd_restart, in_restart), are not shown to the end user only because he sees the map loading screen (instead of the game and its hud) during such initializations?

The combination which is not possible is really the one which should have been the better one...
Maybe it may be made a try to check how the result would feel with the "repeated" infos in the hud? Both text in upper left+icons in lower left. Just to test...

I can understand that historically all output, both warnings, info, and message relevant to the client were all displayed on the same output. This makes sense.
I took one part of what is relevant to the client and took it elsewhere. There are still other messages (player entered the game, flag dropped, etc.).

My idea is that any info relevant to the client should be coded/displayed separately, and controlled from the ui files,
and the top left corner is unnecessary and should be used only to display warnings in debug mode, maybe not even that.

You'd have to ask sago007 about how hard/risky it is. I do understand this may be hard to program without breaking the compatibility with older versions.

PS: changing topic a little.
I know I should have said this earlier. Forgive me.
This is just a question (I repeat: a question)...
Text obituary works this way (X dies, Y attacks):
X got Y's rocket (normal kill)
X cratered (normal suicide)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (normal suicide)

Or should it have been this way instead?
X <rocket icon> Y (normal kill)
X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.

Each of us has a different opinion on these things. Maybe we should make a poll out of our player base. ;D
I just got here a few weeks ago. I don't want to sound patronizing, but you need some way to settle/agree/have a plan on this thing.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 21, 2016, 02:31:14 pm
Quote
You'd have to ask sago007 about how hard/risky it is.
It is not that it is risky as in it can break something. However it increases the coupling between engine and gamecode. That violates the "low in coupling and high in cohesion" principle and makes the code more expensive to maintain. I simply don't think it is worth the price.

If you couple the engine and gamecode to allow a non-critical function then you are on your way to a messy code base.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 22, 2016, 04:57:44 am
Quote
You'd have to ask sago007 about how hard/risky it is.
It is not that it is risky as in it can break something. However it increases the coupling between engine and gamecode. That violates the "low in coupling and high in cohesion" principle and makes the code more expensive to maintain. I simply don't think it is worth the price.

If you couple the engine and gamecode to allow a non-critical function then you are on your way to a messy code base.
So the upper left is just a plain "console output" feedback... One may theoretically foresee some kind of flag to set certain messages as "hidden" in the upper left (which may then be used also for other things, not only obituaries), but that would rely on updated OA3 engine, and would not work (=showing those messages anyway, I guess) with older versions of the engine or with binaries from other ioquake3 branches...
And that would be against good programming practices... like the reason it's not possible to show the correct name of the next gametype when a new match is going to start (in case the gametype has been modified), because gamecode does not know about the future value of a "latched" variable and making an exception to pass it to gamecode in this specific case would be making things more complicated and specific-engine-dependent.

I can understand that historically all output, both warnings, info, and message relevant to the client were all displayed on the same output. This makes sense.
I took one part of what is relevant to the client and took it elsewhere. There are still other messages (player entered the game, flag dropped, etc.).

My idea is that any info relevant to the client should be coded/displayed separately, and controlled from the ui files,
and the top left corner is unnecessary and should be used only to display warnings in debug mode, maybe not even that.

Reading this, my first reaction, as an old times q3a gamer, was "Whaaaaatttt? ??? Why changing something which worked for 17 years?"
Then, I thought that it may be a "real" solution to the issue: completely replacing the upper left info area (from just a replica of the last few lines of the console) with a new "info box" (or series of "n" boxes) where the gamecode purposedly writes stuff. That would allow gamecode developers to fine-tune what has to be printed to console and what has to be printed to screen, without making big changes to the engine part. If one decides to follow a such path, the passage from OA 0.x to OA 3.x, with its UI overhaul, would be the best moment to do it (as if to say "now"?).
On the other hand, I fear that may mean a lot of work: someone should check the whole gamecode to find out all the text output generated by it[1], and modify the code around every single message to set it as "send to console only/send to infobox n only/send to console + infobox n". A lot of work.
There may also be a problem if there are some messages generated by the engine which we may want printed on the HUD for some reason, after the current upper left area is gone: if we don't want to modify the engine for this stuff, I fear such cases (if any) cannot be managed.
E.g.: now you may theoretically bind a CVAR name to a button, and the upper left area would tell you its current value (and its "latched" one, if any) every time you press the button. Try binding "g_gametype" or "name" to a key. I suppose that's the engine which does it.... after the changes, I fear that would not work anymore...

So, I ask... is this really worth it? One may just think "if it's not broken, don't fix it"...
Iconographic obituary is nice, but I don't like having to renounce to having kills list in console history for it... I lived many years without iconographic and I can continue...
PS: I still would like to try a test with the "double output" obituary (iconographic in lower left+text in upper left), just to see how it feels...

[1] Of course, things like "score table", "team overlay box", "health and armor meter" etc. are some kind of "output", too... but they are not related with this stuff at all! I mean to search for the output which currently goes to console.


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 22, 2016, 11:03:38 am
[Reading this, my first reaction, as an old times q3a gamer, was "Whaaaaatttt? ??? Why changing something which worked for 17 years?"
Then, I thought that it may be a "real" solution to the issue: completely replacing the upper left info area (from just a replica of the last few lines of the console) with a new "info box" (or series of "n" boxes) where the gamecode purposedly writes stuff. That would allow gamecode developers to fine-tune what has to be printed to console and what has to be printed to screen, without making big changes to the engine part. If one decides to follow a such path, the passage from OA 0.x to OA 3.x, with its UI overhaul, would be the best moment to do it (as if to say "now"?).

It worked for 17 years? Hm..., I don't see this display in modern games. As I've said, my first game would also look like that, having a simple text and just output every bit of info there.
Separating that output into multiple boxes would allow for more customization, of fonts, icons, placement on HUD, etc., than just a simple print on screen.

On the other hand, I fear that may mean a lot of work: someone should check the whole gamecode to find out all the text output generated by it[1], and modify the code around every single message to set it as "send to console only/send to infobox n only/send to console + infobox n". A lot of work.
There may also be a problem if there are some messages generated by the engine which we may want printed on the HUD for some reason, after the current upper left area is gone: if we don't want to modify the engine for this stuff, I fear such cases (if any) cannot be managed.
E.g.: now you may theoretically bind a CVAR name to a button, and the upper left area would tell you its current value (and its "latched" one, if any) every time you press the button. Try binding "g_gametype" or "name" to a key. I suppose that's the engine which does it.... after the changes, I fear that would not work anymore...

So, I ask... is this really worth it? One may just think "if it's not broken, don't fix it"...
Iconographic obituary is nice, but I don't like having to renounce to having kills list in console history for it... I lived many years without iconographic and I can continue...
PS: I still would like to try a test with the "double output" obituary (iconographic in lower left+text in upper left), just to see how it feels...

[1] Of course, things like "score table", "team overlay box", "health and armor meter" etc. are some kind of "output", too... but they are not related with this stuff at all! I mean to search for the output which currently goes to console.

Perhaps you misunderstood, my intention was never to disable the console output. I only suggested that for the frag messages since they tend to be spammy.
That was my original idea in the first place. And right now if they are not disabled in console, they are just printed twice on the screen, which looks ugly to me.
If the upper left notification, "the console output feedback" was disabled completely, we could return back the console frag messages (or to satisfy my idea, make a toggle variable cg_obituariesToConsole).

To reiterate, my idea is to disable "the console output feedback", not to disable console output, not to add bunch of code to engine to separate what goes into "the console output feedback" and what does not.

Having infos, warnings, and whatnot, all in the left corner, I doubt you had time to read them all with only a few lines displayed at the time. You'd probably have to look into the console anyway to see if you missed something.

PS: It would require a lot of work, to display all info that the player needs/wants to see on the HUD.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 22, 2016, 11:27:31 am
It worked for 17 years? Hm..., I don't see this display in modern games.
I meant Q3A + all of its mods, and OpenArena + all of its mods.

PS: I'm not used to modern games. Occasionally I watched some youtuber playing some modern games, but...

PPS: About the rest, I have to read your post (http://openarena.ws/board/index.php?topic=1908.msg54427#msg54427) more carefully, I have to go now. Bye!


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 22, 2016, 11:31:13 am
It's not exactly "modern games".  Half-Life had this way back in '98 and it was a great way to present information.  All Valve multiplayer games afterward did exactly the same., and moving vital game information off the console notify feed at the top also opens up some space for new hud elements in the top left and the top of the screen which can present information more clearly, like flag status, score, and maybe even a clear team overlay.

Quake Live eventually gained iconographic obituaries too FYI BTW.  Just because we've got some well-tuned-and-rather-timeless 17-year-old gameplay preserved doesn't mean we have to stick with 17-year-old presentation and keep the game looking old on the surface.  I remember trying to convince you that horizontal widescreen expansion was a commonly accepted thing

The HUD is a thing id really really skimped out on in Q3A and was noticably bare compared to the contemporaries of its day (i.e. UT, and the aforementioned HL).  Technically it had the least changes from when it was a 1998 prototype (https://tcrf.net/images/e/eb/Q3A-Pre-9811-quake18.jpg)


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 22, 2016, 01:37:55 pm
I'm not saying I don't like the iconographic thing, just that it comes with a "price" which may be worth or not... (due to being something not foreseen by original developers).
I don't want to keep OpenArena stuck in the past, while not forgetting its roots... I was trying to figure out possible ways to manage the console output problem.

There are some things that would be useful, but Sago doesn't like because they would overcomplicate things or would be against good coding practices in general (e.g. fixing the name of the next match gametype I mentioned earlier). I had the impression that Sago may be on the idea of "don't fix what is not broken" generally speaking... however generalizing I may be wrong.

About the widescreen thing... I don't remember the details, however probably I was mostly worried about being sure of not breaking view for non-wide screen users... Also, a few years passed since then, widescreens are even more diffused now (4:3 users should not be forgotten anyway).

There are some things I have to read again in 1pixel's posts (I thought in one he said the iconographic deaths were only the first step and he aimed to get rid of upper left console in hud, but later he said it's not exactly like that). I still have to completely understand his view... I have to read that again...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 22, 2016, 02:22:47 pm
"don't fix what is not broken"
Actually I really dislike that sentence. Because it is usually interpreted as "don't fix anything".


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 22, 2016, 02:54:14 pm
"don't fix what is not broken"
Actually I really dislike that sentence. Because it is usually interpreted as "don't fix anything".
I interpet it as "Don't overcomplicate things. If something already works, think twice before changing it, because you may break it or make it worse .". I don't think it as "don't fix anything" (of course, others could). In case I may use that phrase again the future, you know what I mean with it.

You know I'm for fixing things, especially bugs (by the way, did you notice this (http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419)?)..
I'm sorry I'm not capable of doing it myself...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 23, 2016, 03:12:42 am
After giving another read to 1pixel's posts...

So far it goes like this:

cg_obituaryOutput 0 - old style, output only to console (and the top left screen which is console notification)
cg_obituaryOutput 1 - text output to lower left, no output to console
cg_obituaryOutput 2 - icon output to lower left, no output to console
cg_obituaryOutput [other values]  - no output, should this be an option?

If I leave the console output with 1 and 2, it would just show a duplicate message on screen (top left and lower left), that is, without messing with con_drawnotify or changing con_notifytime..

If text is too fast to keep track of, there is an alternative of having a variable to increase fade time and/or increase the number of lines that display the frag output on the HUD.
I guess that list may be modified or expanded to:
- include a way to show icon output on upper right (as Fromhell suggested). I don't know if as an additional option or just moving the lower left to upper right.
- include an additional value to show both icon output (to lower left or upper right, for me it's the same) plus the old text in upper left/console log. (Yes, I'm still curious to test it this way. You may say that would be odd, but I would like to check it personally... :)).
- If a "no obituary output at all" option would exist (no console, no hud), maybe it should be the one related to value "0" of the cg_obituaryOutput cvar?

I took one part of what is relevant to the client and took it elsewhere. There are still other messages (player entered the game, flag dropped, etc.).

My idea is that any info relevant to the client should be coded/displayed separately, and controlled from the ui files,
and the top left corner is unnecessary and should be used only to display warnings in debug mode, maybe not even that.
This is what made me think that 1pixel's plan was to more or less completely get rid of upper left console notify area...
Perhaps you misunderstood, my intention was never to disable the console output. I only suggested that for the frag messages since they tend to be spammy.
Then, it was not so... or maybe I was talking about removing console notification area as it is now (thinking that was your final idea) and you understood I was talking about disabling console log?
With "was never to disable the console output", did you mean the "console log" or the "upper left area"? In the previous post, I thought you were talking about completely redoing the upper left area to became cgame controlled (to be able to decide what to print there and what not), while still keeping the "console log" unchanged as it ever worked... (apart from the optional ability to disable obituary to console log, which was your initial intention)

If the upper left notification, "the console output feedback" was disabled completely, we could return back the console frag messages (or to satisfy my idea, make a toggle variable cg_obituariesToConsole).

To reiterate, my idea is to disable "the console output feedback", not to disable console output, not to add bunch of code to engine to separate what goes into "the console output feedback" and what does not.
I got lost a bit here. With "console output feedback" do you mean "upper left notification" and with "console output" you mean "console log", or what?
In some parts of your posts, I had the impression you wanted to get rid of the "upper left notification area" as it is now, in other parts not...  ???

PS: changing topic a little.
I know I should have said this earlier. Forgive me.
This is just a question (I repeat: a question)...
Text obituary works this way (X dies, Y attacks):
X got Y's rocket (normal kill)
X cratered (normal suicide)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (normal suicide)

Or should it have been this way instead?
X <rocket icon> Y (normal kill)
X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.

Each of us has a different opinion on these things. Maybe we should make a poll out of our player base. ;D
I just got here a few weeks ago. I don't want to sound patronizing, but you need some way to settle/agree/have a plan on this thing.
I was just asking. As said, I'm not used with iconographic obituary. Fromhell's and Sago's opinions (as well as other people wanting to contribute) would be welcome.

PS: About that old widescreen discussion, maybe a question was something like "if you have the same cg_fov value and two different resolution ratios, does that mean that the world will look a bit distorted in one of the two?"?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 23, 2016, 11:42:47 am
I fully support the functionality as implemented in Pull Request #11 (https://github.com/OpenArena/gamecode/pull/11) right now. Aside from a few changes I have requested to the code I would like to merge that as soon as possible so that we have something real to talk about. I think we are in the "scope creep" phase right now. Everything we do will just make it worse.


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 23, 2016, 07:46:24 pm
I think I made all the changes requested. Correct me if I'm wrong.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 24, 2016, 01:06:12 am
Can I say that I find really hard to follow changes history on github? I only see a "pull request" from idrone, which lists only ONE commit... it says "Commits on Nov 22 2016 - committed 8 days ago" (today it's 24). Looking at the changes of the commit, it shows me the final version, including the fixes asked by Sago two days ago...
Where do I find the intemediate commits?  :-\

I remember Sago said that "github shows the date code was developed (git commit), not the date the code was made available (git push)"... but this is even worse, it's hard to figure out a pull request has been updated at all and with which changes from its previous version...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 24, 2016, 02:59:23 am
I fully support the functionality as implemented in Pull Request #11 (https://github.com/OpenArena/gamecode/pull/11) right now. Aside from a few changes I have requested to the code I would like to merge that as soon as possible so that we have something real to talk about. I think we are in the "scope creep" phase right now. Everything we do will just make it worse.
I had to search about the "scope creep" term: https://en.wikipedia.org/wiki/Scope_creep
You're right, we need to actually test the feature before deciding if it's okay or if needs further tuning...

However, I had a few minutes free, so I drew a few ideas about possible icons for specific kinds of death (apart from the usual "weapons" ones). I know that Fromhell said they are not really necessary and a skull can be enough, but considering that there will be no console output to see the details if one is interested, maybe some more specific icons may be welcome.
Just brainstorming a few ideas...
Note 1: "juiced" does not use the generic skull, it uses the prox mines icon (due to being the only weapon capable of doing it, IIRC), which may be enough. Hovewer an apposite icon would not harm noone.
Note 2: Probably I'm not good enough at drawing to make the actual icons, even if these are very simple...

(PS: I like so much now we have nightly builds! It's nice to view changes at the code and being able to actually test them the next day!).
PPS: I know this post is not the top of coherence... Please forgive me... :)


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 24, 2016, 11:25:42 am
I think I made all the changes requested. Correct me if I'm wrong.
You did not post a comment and I do not get notifications on code changes on pull requests. (Surprised me a bit because I thought that I would receive them).

It mostly looks good but the space indentation looks funny in Github:
(https://files.poulsander.com/~poul19/public_files/oa_indentation.png)
The rest of the code uses tabs and new code should match it.


Where do I find the intemediate commits?  :-\
They are gone. I asked 1pixel to squash the commits so that the entire working feature is in one commit in the history.

Sometimes the individual commits gives value in the history because they can show intent (especially if it is many small changes that makes sense individually).
I don't normally ask for squashing but in this case I found it a lot easier to read and understand as one commit.


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 24, 2016, 11:56:14 am
I've seen the gamecode use both tabs and spaces. I personally prefer spaces and would just remove tabs on the rest of the code.
What is the agreement, we use tabs from now on?

I should probably change to tabs on the rest of my code then as the difference is also seen.

Maybe you didn't get the notification because I used amend and force push.


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 24, 2016, 12:17:11 pm
I've seen the gamecode use both tabs and spaces. I personally prefer spaces and would just remove tabs on the rest of the code.
What is the agreement, we use tabs from now on?

In "game" there are 33967 lines with tabs vs 4273 with spaces.
In "cgame" it is 18146 vs 1203
(I only counted c-files)

Most of the spaces have been added by either me or karl.kuglin.
I have compared with ioq3 where the numbers are even stronger towards tabs.

I plan to convert all current lines with spaces to tabs and enforce it with Travis.
I'll also look into adding a editorconfig file to get the editors to change to the relevant style.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 26, 2016, 04:22:10 am
Due to real life, I need a couple of days before testing the feature.

In the meantime, I thought about a thing: what happens in case the game cannot find one of the icons specified? Crashes? Shows only playernames? Shows a black square in the place of the icon?
Do you think it should include a fallback mechanism to use generic skull icon in place of specified icon, in case the specified icon does not exist? Or is that (e.g. a mod author fault) a so remote possibility that there is no need to foresee a such countermeasure?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 26, 2016, 05:40:58 am
In the meantime, I thought about a thing: what happens in case the game cannot find one of the icons specified? Crashes? Shows only playernames? Shows a black square in the place of the icon?
Do you think it should include a fallback mechanism to use generic skull icon in place of specified icon, in case the specified icon does not exist? Or is that (e.g. a mod author fault) a so remote possibility that there is no need to foresee a such countermeasure?
All shaders must exist or it will fallback to the "missing texture" shader.
This is the expected behavior. A missing shader is a bug and must be fixed.

If a mod author adds a new kind of death and does not touch the kill rendering code it will default to the skull icon. The mod author is not required to provide a new icon. This can be considered a fallback.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 26, 2016, 07:29:21 am
Okay, then. I was not sure if the generic "missing shader" texture applied to 2d stuff, too. Okay.


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on November 26, 2016, 11:13:17 am
Speaking of invalid shaders, here's a shader file which points to a bunch of existing OA0 textures so the new particle effects can be rendered (with cg_leiEnhancement 1 and the new engine).  Wouldn't mind if this shader is part of OAX nightlies


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on November 27, 2016, 06:49:41 am
I have added the shader file to the nightly build (https://github.com/sago007/docker_openarena_gamecode_builder/commit/8b368d695f52a67792cdf83428a2ad9b36863d94).
It will be added in the next build.

I also added a fix to the engine to prevent the particles from crashing in Linux 64 bit.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 28, 2016, 02:48:14 am
Done a few tests with Nightly builds 2016-11-27 (both OAX and engine).
About cg_leienhancement 1: Cool rocket explosion! (See screenshots)
And what a bright blood!

However, a small thing I noticed: just like in 0.8.x, with the leienhancement option active, cg_oldplasma 0 does not work (its particles effects are not shown). Maybe it's intentional, maybe not...


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 28, 2016, 03:11:44 am
Finally tried the iconographic obituary.
I like it! Good job 1pixel!  :)

Things I noticed:
- The text seems semi-trasparent. I can guess it's made give less distraction, but considering the small size, it's not so comfortable to read. In the first screenshot, you can see this text compared with chat text above. Guys (and gals), what are your opinions about this?
- Line scrolling does not work exactly like the upper notification area. In the new area, new text appears in the lower line even if it's the only one, and scrolls one line up only when there is another line to show. I'm not saying this is a problem, I'm just saying I noticed it is a bit different.
- Lower left position is okay for me. The only problem I noticed is when the score table is shown (TAB key, dying or match end), as you can see in the second screenshot. Not sure about how to deal with it. Note: I also wanted to try this with UI3, but score table is not shown at all there yet, at least in FFA mode! UPDATE: Maybe it's some problem with my config... I will try later, after deleting my oax_m config... as some days ago I think I saw score table there, in a team-based mode...

Other random bits:
- I tried with all supported values cg_obituaryoutput from 0 to 3. As stated before (http://openarena.ws/board/index.php?topic=1908.msg54434#msg54434), maybe a "no obituary at all" option, if existing, would have more sense to be at value 0 instead of 3? And I would like an option to have both icons and console output: that would be useful for testing purposes, like 1pixel did in his second screenshot here (http://openarena.ws/board/index.php?topic=1908.msg54411#msg54411).
- Nobody said anything about those obituary icons ideas (http://openarena.ws/board/index.php?topic=1908.msg54440#msg54440)?


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 28, 2016, 04:09:24 am
- The text seems semi-trasparent. I can guess it's made give less distraction, but considering the small size, it's not so comfortable to read. In the first screenshot, you can see this text compared with chat text above. Guys (and gals), what are your opinions about this?

I agree it should have a shaded (if that's the correct term) box added in the background. I'll try adding it.

- Line scrolling does not work exactly like the upper notification area. In this area, new text appears in the lower line even if it's the only one, and scrolls one line up only when there is another line to show. I'm not saying this is a problem, I'm just saying I noticed it is a bit different.

Watching two random videos on YouTube, I see Quake Live and Xonotic use different ways. A minor issue, if the majority wants it the other way, I'll change it.

- Lower left position is okay for me. The only problem I noticed is when the score table is shown (TAB key, dying or match end), as you can see in the second screenshot. Not sure about how to deal with it. Note: I also wanted to try this with UI3, but score table is not shown at all there yet, at least in FFA mode!

Problem of overlapping persists with the UI3. I see the solution in either hiding it when the scoreboard is shown, or moving it by default to right top corner for the time being as Lei suggest (although in top right there is a timer, fps display in the way).
With starting an instant action match I can see the new score table.


- I tried with all supported values cg_obituaryoutput from 0 to 3. As stated before (http://openarena.ws/board/index.php?topic=1908.msg54434#msg54434), maybe a "no obituary at all" option, if existing, would have more sense to be at value 0 instead of 3? And I would like an option to have both icons and console output: that would be useful for testing purposes, like 1pixel did in his second screenshot here (http://openarena.ws/board/index.php?topic=1908.msg54411#msg54411).

I'll add this option, and move the no obituary to 0.

- Nobody said anything about those obituary icons ideas (http://openarena.ws/board/index.php?topic=1908.msg54440#msg54440)?

I like the water/lava/slime. But how would you distinguish between being pushed and falling into on your own. Two icons?
Juiced icons could after some artwork look fine.
Falling/teleport/crush could be a bit harder to display. These may be a bit too small to be seen what they're about.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 28, 2016, 04:53:05 am
I agree it should have a shaded (if that's the correct term) box added in the background. I'll try adding it.
Do you mean that HUD output looks this way (a little "grayed") by default, and there is no way to tell it to just use the brighter color tones it uses in console output?

Quote
But how would you distinguish between being pushed and falling into on your own. Two icons?
Just like all other kinds of "assisted suicides", I woud say...

Player y <splat icon> Player x = pushed
<splat icon> player x = falling by our own.

Isn't just like this? Am I missing something?

Quote
Falling/teleport/crush could be a bit harder to display. These may be a bit too small to be seen what they're about.
Uhm... maybe when using the iconographic output (not the text just moved to lower left) we could use a slightly bigger font size, to show also icons a bit bigger? Just an idea...


Title: Re: Open Arena Expanded Beta 50
Post by: 1pixel on November 28, 2016, 05:58:04 am
I agree it should have a shaded (if that's the correct term) box added in the background. I'll try adding it.
Do you mean that HUD output looks this way (a little "grayed") by default, and there is no way to tell it to just use the brighter color tones it uses in console output?

Okay, then it's just changing the font transparency. Got it.

Quote
But how would you distinguish between being pushed and falling into on your own. Two icons?
Just like all other kinds of "assisted suicides", I woud say...

Player y <splat icon> Player x = pushed
<splat icon> player x = falling by our own.

Isn't just like this? Am I missing something?

My mistake.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on November 28, 2016, 06:24:14 am
About UI3 missing score table, it's also missing many other things, if you change "hud style" from the GUI, at the moment... requiring using console to restore original behavior. Posted in the UI3 thread (http://openarena.ws/board/index.php?topic=5296.msg54456#msg54456).

PS:
I'll add this option,
Thank you very much.


Title: Some testing with cg_leiEnhancement
Post by: Gig on December 09, 2016, 03:46:34 am
Some feedback about cg_leiEnhancement (tried firing weapons):
1) Very cool.
2) Maybe the radius of the blasts (e.g. bfg explosion) is too big? Maybe it should not be so excessively larger than the actual damage radius?
3) Sometimes animation explosion (noticed with bfg explosion and maybe also with prox mines explosion) is played correctly, but at times it is not played at all, only the "inner part" is played or it looks played twice.
4) Maybe the smoke trail of the grenades does disturb your view a bit more than in standard view?
5) Very cool.

Note for testers: the OAX (OA3) version of cg_leiEnhancement requires nightly build binaries; enabling it with 0.8.8 binaries causes a crash with "bad cgame system trap" error.



Title: Bug with prox mines? Update: no, it's a feature!
Post by: Gig on December 09, 2016, 04:22:47 am
While doing the tests above (http://openarena.ws/board/index.php?topic=1908.msg54493#msg54493), I encountered a strange thing (not related with cg_leiEnhancement I was testing there), and I thought it was a bug.

Proximity mines in some places do last as expected (20 seconds, right?), while in other places do explode after 3 seconds only, with no apparent reason (update: see update at the end). And it seems to happen only if you are in the RED team.

I noticed this behavior while doing tests in my "sandbox" testbox.map. I attached it here, so you can compile it, start a team-based game, enter the red team, grab the prox mines launcher (I set 100 ammo) and attach mines on the walls. You can notice somewhere they will last long, somewhere they will last short.

I noticed it with OAX nightly build 2016-12-03, but then tested also with 0.8.8: the bug was already there.

In the screenshot attached, the mine on the left will explode much before than the other one, even if it has been launched later...

UPDATE: I got it... it's not a bug, it's a feature I didn't know/remember existed! If you throw prox mines near to your own flag, they will detonate after about three seconds! This is surely thought to avoid defensive mines abuse! My test map had a red flag, so it affected the red team!
Updated the wiki (http://openarena.wikia.com/wiki/Manual/Weapons#Prox_mine_launcher) accordingly...


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on December 09, 2016, 10:24:51 am
I have a problem at the moment. Sometimes the death animation does not play right (if I am dead, I am sometimes still running or sometimes other death players in my view are still running.). I don't know if it is related to deathcam or not.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 09, 2016, 11:43:28 am
I have a problem at the moment. Sometimes the death animation does not play right (if I am dead, I am sometimes still running or sometimes other death players in my view are still running.). I don't know if it is related to deathcam or not.
Do you think it may be somehow related with the "very strange" bug I posted a couple of screenshots here? http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on December 09, 2016, 02:01:43 pm
Do you think it may be somehow related with the "very strange" bug I posted a couple of screenshots here? http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419
Exactly like that. I don't login if I'm reading the forum from mobile, so I properly missed the screenshots.

I have tried looking in things that changed, for instance the animation system but I have not found anything that can explain it. It is the biggest problem I see in the code at the moment.


Title: Proximity mines side effect
Post by: Gig on December 16, 2016, 05:25:07 am
About the feature of proximity mines exploding after 3 seconds (http://openarena.ws/board/index.php?topic=1908.msg54494#msg54494) (instead of the usual 20) if you attach them near to your own team flag... I noticed that this comes with a "side effect" which maybe could be considered a "bug".

The "problem" is that this is applied also in team-based gametypes where the red and blue flags are useless, such as TDM and Elimination (note: in TDM the flags are shown, while in Elimination the flags are hidden... however both are affected). So throwing mines in a certain range near to your flag (I don't know exacly its range, but it's like several "meters") makes them explode early, with no "real" reason in such gametypes.

Removing the flag in such gametypes directly from the map (gametype or !gametype keys) seems to allow workarounding the problem, but however using gametype key is not considered a "best practice"...

At first, I thought that was a problem from Team Arena, with id software not thinking that CTF maps may be played in other gametypes such as Team Deathmatch... but I just tried in Q3 Team Arena and it looks like this "rule" does not exist there at all (I joined red team in CTF mode, shot mines to red flag, and they exploded after classic 20 seconds). So, it looks like it's an OpenArena-specific feature. Strange, I thought modifying default weapons behavior was "nottodo"... however I don't have any problem with this feature (it's probably a good addition which invites players to be a little more creative about where placing their mines), except for the "side effect" mentioned above.

I also did some tests with team_redobelisk: I think there isn't a similar anti-mines feature for it (for Overload it may not be so useful, since enemies do not need to touch the obelisk to attack it... for Harvester maybe... however probably one might score before mines detonate anyway)... although with the current implementation it "gives the sensation/result" like being applied also to it, due to (USUALLY!) the red flag being placed at the same place of the red obelisk.
So, we need a bit of thinking/planning before changing something about it...

What do you think?
Should I open an "issue" on github?
I do know it's not a major issue, however it's something which may be improved.

PS: I forgot to do tests with Domination.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 22, 2016, 05:40:20 am
I did some other test about the proximity mines side effect (http://openarena.ws/board/index.php?topic=1908.msg54515#msg54515).
In Double Domination, red team's mines explode early if thrown near to the "A" point, and blue mines explode early if thrown near to the "B" point (due to DD points automatically appearing in place of team_ctf_red/blue_flag).
Iin Domination mode, throwing mines in the area the CTF flag of your team is, mines explode early (with no "real" reason in that gametype); throwing mines near to a domination point, even if it's currently own by your team, does not trigger anticipate explosions.

Different problem: I also noticed that red and blue flags are NOT automatically hidden in Domination; I haven't checked with the neutral flag, but I can guess it may be the same. This may be a problem because if the mapper forgets to properly set "gametype/!gametype" keys on them, they do show up in the game, looking exactly like Domination points, while they are not Domination points instead; that would be a mapper's fault of course, but since we say that usage of "gametype and !gametype" is not recommended, that's a bit odd. Maybe you can't technically hide them "easily" because Dom points do share the same models with flags, and your "hiding trick" is model-based?

Back to the prox mines thing, let's try to think about which cases they should explode early if near to a certain entity (IMO... correct me if I'm wrong):
- 0, FFA: no (does not apply already, since players are never red or blue) - OK
- 1, 1v1: no (does not apply already, since players are never red or blue) - OK
- 2, Single: no (does not apply already, since players are never red or blue) - OK
- 3, TDM: no (but it does currently apply to red/blue flags locations) - NOT OK
- 4, CTF: should apply to red and blue flags (and currently does) - OK
- 5, Oneflag: should apply to red and blue flags (and currently does); maybe it may be applied also to neutral flag (for both teams), but I don't see this as necessary, and may be technically complicated since the flag isn't fixed and because you should pay attention to do not affect all other modes, including team-free ones. Note: placing mines on your own flag in this mode may even be counter-productive: your opponent may score before they explode, then use them to suicide and respawn in his own base, to quicky pass from offensive to defensive position. - PROBABLY OK
- 6, Overload: probably should be applied to red and blue obelisks? Currently it's applied to red/blue flags locations, which usually are the same of the obelisks... but in theory they may differ! Or should just not be applied, since you don't need to touch the obelisk to damage it, unless you are using gauntlet? - MAY BE REWORKED
- 7, Harvester: probably should be applied to red and blue obelisks (flag bases acting as skull receptacles)? Currently it's applied to red/blue flags locations, which usually are the same of the obelisks... but in theory they may differ! Or should just not be applied, since you probably can score before they can detonate (see the note about OneFlag)? Maybe it may be applied also to skull generator (for both teams), but I don't see this as necessary. - MAY BE REWORKED
- 8, Elimination: no (but it does currently apply to red/blue flags locations) - NOT OK
- 9, CTF Elimination: should apply to red and blue flags (and currently does). I can guess this is okay also for elimination_ctf_oneway... or not? - OK
- 10, LMS: no (does not apply already, since players are never red or blue) - OK
- 11, Double Dom: I don't know if it should be applied or not: in theory a DD point should be "neutral", but in case info_player_dd_red/blue spawn points are used, a team may spawn inside its own base (near to one of the two points) instead of randomly. (Currently applies to red and blue flags, which "always" -except gametype key usage- share locations with "A" and "B" DD points, respectively) - I DON'T KNOW
- 12, Domination: I can guess it should NOT be applied here at all, as DOM points should be "neutral" and placed around all the map (but it does currently apply to red/blue flags locations). Right? - NOT OK
- 13, Possession: no (does not apply already, since players are never red or blue) - OK


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 22, 2016, 12:06:13 pm
Hi Sago, I noticed this commit (https://github.com/OpenArena/gamecode/commit/02315f58ea232cdaa49e49e2887fb71355029f6f). Thank you, very efficient!  :)

However, are you sure about not applying the feature to red and blue skull receptacles in Overload?

I liked looking at the code, I more or less undersood that:
1) it tells mines they can be triggered by flags of their own color (red or blue only)
2) it checks for the gametypes GT_TEAM, GT_DOMINATION, GT_ELIMINATION, GT_DOUBLE_D and GT_HARVESTER: in these cases, it undoes what was set at 1).
3) if the gametype is GT_OBELISK (overload), then tell mines they can be triggered by obelisks of their own color (red or blue only)
4) determines if the flag has been dropped (not sure about this... if it is meant so dropped flags do not trigger mines; in-game test tells me that dropped flags do not trigger mines and that the flag spawn point triggers mines also when the flag has been dropped elsewhere)
5) determines the distance from the flag... it looks like the mine is triggered if the flag spawn point is less than 500 units far, right?

This also showed me that setting more than one entity at once to trigger the flag would require bigger changes, although not enormous. I don't feel the need for that anyway.

PS: just a stupid idea thrown in on-the-fly: what about a DMFLAGS value to disable the feature (hence restoring original TA behavior)?


Title: Re: Open Arena Expanded Beta 50
Post by: sago007 on December 22, 2016, 02:33:57 pm
4) determines if the flag has been dropped (not sure about this... if it is meant so dropped flags do not trigger mines; in-game test tells me that dropped flags do not trigger mines and that the flag spawn point triggers mines also when the flag has been dropped elsewhere)
The purpose of the code is the exact opposite. It checks if the flag it found is the base or just a randomly dropped flag. If it is the base it applies the rule. If it is a dropped flag then it keeps searching for the base. At least that is the idea. I don't know it could ever find a dropped flag before the base.

The feature was implemented based on observations in actual game play. It made any CTF game unplayable if it had prox mines. For harvester you can just sacrifice yourself to score and in Obelisk you don't have to get close (unless you want to use the gauntlet and the defense should be allowed to prevent you from doing that).


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 22, 2016, 03:29:55 pm
The feature was implemented based on observations in actual game play. It made any CTF game unplayable if it had prox mines.
Very well, then. :)
No need to make admins disable it, I got it. :)

Quote
For harvester you can just sacrifice yourself to score and in Obelisk you don't have to get close (unless you want to use the gauntlet and the defense should be allowed to prevent you from doing that).

But if I understood correctly the commit, you actually applied the feature to the obelisks in Overload, isn't it? So the defense has to find another way to prevent you from using gauntlet against obelisk... (as to say shooting at you... even mines of course)
Then I suppose you may also apply it to the skull receptacles (harvester), even if just to make things more coherent between gametypes (if it's your base and it's relevant for the gametype, then you cannot spam it of mines). Do I say wrong?


Note: I don't know why, but for some reason, re-reading this post of mine gives me a little bit of sensation of somehow being "provocative". I want to assure that is NOT its intended mood, absolutely. Maybe it's just that I need some sleep, if I find strange things even in my own posts...


Title: Re: Open Arena Expanded Beta 50
Post by: Dimek on December 27, 2016, 04:23:56 am
Hello! What about new version of Open Arena? With additional characters, new weapon models, and new announcer voice ? I can participate in the creation.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 27, 2016, 04:42:23 am
Hello! What about new version of Open Arena? With additional characters, new weapon models, and new announcer voice ? I can participate in the creation.
Hi!
This topic is about OAX, which is the gamecode development of OpenArena. It looks like you are more interested in helping in "art" (assets), right?
If you look the forums listings, you can see there are dedicated sections for Audio, Models, Graphics, Maps... you can use them.
Also, recently some OA3 talking (OA3 is the name of the WIP content-reboot version of OA) is happening on the Discord server (http://openarena.ws/board/index.php?topic=5287.0).

Project leader (Fromhell/Lei lei) is also currently the only one developing models: she may appreciate someone else still capable of creating MD3 characters...

See also:
http://openarena.wikia.com/wiki/OAX
http://openarena.wikia.com/wiki/OA3 (Warning: may be out-of-date)
http://openarena.wikia.com/wiki/DeveloperFAQ
http://openarena.wikia.com/wiki/NOTTODO
http://openarena.wikia.com/wiki/OA3/NOTTODO
http://openarena.wikia.com/wiki/GoodPractices


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 28, 2016, 02:52:26 am
Back to the prox mines thing, I did some testing with nightly build 2016-12-22.

It looks like it works as expected. Good!

Only, I still think that -apart from the different "objective entity"- OneFlag and Harvester have very similar game mechanics in this regard (you only have to reach the enemy base core, you can also die after that)... so it sounds very strange to me that the feature is applied to one of the two modes and not to the other one. Are you really sure it isn't better to apply it to both of them?

What about...?
Quote from: g_missile.c
// find the flag
   switch (ent->s.generic1) {
   case TEAM_RED:
      c = "team_CTF_redflag";
      break;
   case TEAM_BLUE:
      c = "team_CTF_blueflag";
      break;
   default:
      c = NULL;
   }
   
   if (g_gametype.integer == GT_TEAM || g_gametype.integer == GT_DOMINATION || g_gametype.integer == GT_ELIMINATION || g_gametype.integer == GT_DOUBLE_D
          || g_gametype.integer == GT_HARVESTER) {
      c = NULL;
   }
   
   if (g_gametype.integer == GT_OBELISK || g_gametype.integer == GT_HARVESTER) {
      switch (ent->s.generic1) {
      case TEAM_RED:
         c = "team_redobelisk";
         break;
      case TEAM_BLUE:
         c = "team_blueobelisk";
         break;
      default:
         c = NULL;
      }
}
(of course red=remove; green=add)

Considering the specific mechanics of OneFlag and Harvester, maybe disabling the feature in both of them may be feasible too... but I would suggest enabling it in both of them just to keep things more coherent between gametypes, as I said here (http://openarena.ws/board/index.php?topic=1908.msg54547#msg54547).

PS:
Different problem: I also noticed that red and blue flags are NOT automatically hidden in Domination; I haven't checked with the neutral flag, but I can guess it may be the same. This may be a problem because if the mapper forgets to properly set "gametype/!gametype" keys on them, they do show up in the game, looking exactly like Domination points, while they are not Domination points instead; that would be a mapper's fault of course, but since we say that usage of "gametype and !gametype" is not recommended, that's a bit odd. Maybe you can't technically hide them "easily" because Dom points do share the same models with flags, and your "hiding trick" is model-based?
Update: I tried with the white flag (team_ctf_neutralflag), without gametype restrictions, and it (unlike red and blue flags) is automatically hidden in Domination mode, despite looking the same of "neutral" Domination points. So I don't know what to think.


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 29, 2016, 03:28:59 am
Tried the new version of idrone/1pixel's iconographic obituary, with gamecode nightly build 2016-12-28.

The options have been reorganized.

cg_obituaryOutput:
- 0: no obituary output
- 1: console (text) only ("classic" behavior)
- 2: hud (text) only
- 3: hud (icons) only (new default)
- 4: hud (icons) + console (text)

It looks like values higher than 4 do work like 3 (I tried with 5). Maybe I did something wrong, I should try this again!

Now that it's not semi-trasparent anymore, it's more readable. :)
Looks good also with the UI3.
Good work 1pixel!

Just talking: Maybe the hud (iconographic) output may be made with bigger fonts, to also show bigger icons? A few icons do result less "clear" than others (e.g. the generic skull), and that may also help in case we will like to make more death-specific icons (http://openarena.ws/board/index.php?topic=1908.msg54440#msg54440)...

PS: What about adding the option to UI3 settings menu?


Title: Re: Open Arena Expanded Beta 50
Post by: fromhell on December 29, 2016, 12:06:50 pm
Skulls are enough for nonweapon deaths.  I don't want to bloat the video memory with overly-specific icons

(though, the functionality could be there and the specific shader itself would probably point to a skull texture)


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 30, 2016, 01:59:04 am
Skulls are enough for nonweapon deaths.  I don't want to bloat the video memory with overly-specific icons
Okay, then (although I don't know how much vram would take a fistful of small icons). However maybe a little bigger fonts/icons may still be useful for better visibility...
Quote
(though, the functionality could be there and the specific shader itself would probably point to a skull texture)
IIRC (and for the little I can understand!), the way it's currently implemented "loads" the skull "shader" only once, and when calculating the various death messages it picks the same shader (opposite to loading many shaders which would point to the same skull image file).

By the way, I think Fromhell and Sago never expressed their thoughts about this question:
PS: changing topic a little.
I know I should have said this earlier. Forgive me.
This is just a question (I repeat: a question)...
Text obituary works this way (X dies, Y attacks):
X got Y's rocket (normal kill)
X cratered (normal suicide)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (normal suicide)

Or should it have been this way instead?
X <rocket icon> Y (normal kill)
X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.
For example, how does Quake Live show that?


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on December 30, 2016, 02:37:01 am
PS: What about adding the option to UI3 settings menu?
Giving a quick look to the UI3 repository, it looks like it would need adding something like:

Code:
itemDef {
       name obituaryOutput
       text "Obituary Output"
type ITEM_TYPE_MULTI
cvar "cg_obituaryOutput"
cvarFloatList { "No output" 0 "Console txt only" 1 "HUD txt only" 2 "HUD icon only" 3 "HUD icon+Console txt" 4}
background MP_FATBUTTONBG
backcolor MP_BUTTONBGCOLOR
style 1
textstyle 6
       textscale 0.27
cvarTest "ui_menutab"
showCVar { "0" }
   rect 32 180 192 20
     textalignx 12
textaligny 17

forecolor MP_TEXTCOLOR
mouseEnter { setcvar ui_tip TIP_PREFS_OBITUARYOUTPUT fadein tooltip; } mouseExit { fadeout tooltip;}  
visible 1
}
in
UI3/ui/common/options.panel
and maybe also in
UI3/ui/common/console_options.panel

and
Code:
#define TIP_PREFS_OBITUARYOUTPUT "How character death messages are shown."
in UI3/ui/lang_english.h


Title: Re: Open Arena Expanded Beta 50
Post by: Gig on January 23, 2017, 05:05:39 am
Only, I still think that -apart from the different "objective entity"- OneFlag and Harvester have very similar game mechanics in this regard (you only have to reach the enemy base core, you can also die after that)... so it sounds very strange to me that the feature is applied to one of the two modes and not to the other one. Are you really sure it isn't better to apply it to both of them?
Update: now the "short fuse" feature is applied also in Harvester (where it searches for the obelisk/skull receptacle). OAX nightly build 2017-01-21.

Quote
PS:
Different problem: I also noticed that red and blue flags are NOT automatically hidden in Domination; I haven't checked with the neutral flag, but I can guess it may be the same. This may be a problem because if the mapper forgets to properly set "gametype/!gametype" keys on them, they do show up in the game, looking exactly like Domination points, while they are not Domination points instead; that would be a mapper's fault of course, but since we say that usage of "gametype and !gametype" is not recommended, that's a bit odd. Maybe you can't technically hide them "easily" because Dom points do share the same models with flags, and your "hiding trick" is model-based?
Update: I tried with the white flag (team_ctf_neutralflag), without gametype restrictions, and it (unlike red and blue flags) is automatically hidden in Domination mode, despite looking the same of "neutral" Domination points. So I don't know what to think.
I still don't know about this.

By the way, I think Fromhell and Sago never expressed their thoughts about this question:
PS: changing topic a little.
I know I should have said this earlier. Forgive me.
This is just a question (I repeat: a question)...
Text obituary works this way (X dies, Y attacks):
X got Y's rocket (normal kill)
X cratered (normal suicide)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (normal suicide)

Or should it have been this way instead?
X <rocket icon> Y (normal kill)
X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.
For example, how does Quake Live show that?
And about this.