Pages: 1 ... 17 18 [19]
  Print  
Author Topic: Open Arena Expanded Beta 50  (Read 265701 times)
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #450 on: December 09, 2016, 04:22:47 am »

While doing the tests above, 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 accordingly...
« Last Edit: December 09, 2016, 04:57:22 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 61
Posts: 1645


Open Arena Developer


WWW
« Reply #451 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.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #452 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
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 61
Posts: 1645


Open Arena Developer


WWW
« Reply #453 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.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #454 on: December 16, 2016, 05:25:07 am »

About the feature of proximity mines exploding after 3 seconds (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.
« Last Edit: December 16, 2016, 07:56:24 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #455 on: December 22, 2016, 05:40:20 am »

I did some other test about the proximity mines side effect.
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
« Last Edit: December 22, 2016, 02:27:31 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #456 on: December 22, 2016, 12:06:13 pm »

Hi Sago, I noticed this commit. Thank you, very efficient!  Smiley

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)?
« Last Edit: December 22, 2016, 02:18:22 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 61
Posts: 1645


Open Arena Developer


WWW
« Reply #457 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).
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #458 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. Smiley
No need to make admins disable it, I got it. Smiley

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...
« Last Edit: December 22, 2016, 04:35:16 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Dimek
Nub


Cakes 0
Posts: 12


« Reply #459 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.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #460 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.

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
« Last Edit: December 27, 2016, 06:20:08 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #461 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.

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.
« Last Edit: December 28, 2016, 03:57:25 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #462 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. Smiley
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...

PS: What about adding the option to UI3 settings menu?
« Last Edit: December 30, 2016, 03:54:27 pm by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14478



WWW
« Reply #463 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)
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #464 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?
« Last Edit: December 30, 2016, 05:20:09 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #465 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
« Last Edit: December 30, 2016, 02:45:42 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 48
Posts: 4223


WWW
« Reply #466 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.
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Pages: 1 ... 17 18 [19]
  Print  
 
Jump to: