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

Cakes 45
Posts: 4394


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 DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Weapons#Prox_mine_launcher]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 62
Posts: 1664


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 45
Posts: 4394


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 62
Posts: 1664


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 45
Posts: 4394


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 45
Posts: 4394


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 45
Posts: 4394


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 62
Posts: 1664


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 45
Posts: 4394


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 45
Posts: 4394


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:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/OAX
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/OA3 (Warning: may be out-of-date)
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/DeveloperFAQ
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/NOTTODO
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/OA3/NOTTODO
(DO NOT LINK) h t t p s : / / 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 45
Posts: 4394


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 45
Posts: 4394


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 35
Posts: 14520



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 45
Posts: 4394


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 45
Posts: 4394


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 45
Posts: 4394


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.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #467 on: January 18, 2019, 04:32:26 AM »

Hi! Just dropping here some small feedback after some OAX nightly builds testing:

- A recently added cvar is g_grapple, which gives the grapple to all users on spawn (that also replaces elimination_grapple, which would have been redundant then). It's nice, but it gave me the change to notice a problem happening with the grapple in am_galmevish2 map. Epilepsy warning! If you attach to the teleporter and keep holding the button, you get an infinite teleport loop, until you release the button. Bots seem to be however more or less capable to identify me and kill me. It doesn't seem to happen this way in oa_dm5, probably it's due to the position of the teleporters (when you exit the teleporter, the grapple is still attached to the same location it was before, so it tries to bring you there... and if the second teleporter is along that vector, you enter it, otherwise not), or less likely because in oa_dm5 the grapple can't attach to the proper teleporter, but only to its border. Maybe it's a case so rare it doesn't need any kind of fix, however I noticed this and reported it. A fix may be to force grapple to detach when entering a teleporter.

- Probably I was one of the few ones not already knowing it, however I just noticed a bug with the callvote map selection menu (in both 088 and OAX with the classic UI... I don't think UI3 has the corresponding feature yet). When you click on the arrow to scroll the pages of the map list, it may look like you cannot go past page2. In reality, it's just the UI which does not recognize your further clicks unless you move the mouse between them. The workaround is simply to move the mouse of at least one pixel between each click on the arrow button. Maybe not really relevant due to the moving from classic UI to UI3, however maybe someone may learn the workaround in the meanwhile by reading this, and find it useful.

- Doing a little of experiment with g_enableBreath (which is already supported in 088), I noticed that despite the "g_" prefix, also acts as a client-side cvar (so, each player can choose if to have it on or off, which makes sense actually being a graphic option, although one may notice it may give an hint that someone recently passed through a certain place). Okay, that's not a real problem, and it's id software who did that way. Also g_enableDust, g_enableFS and g_enableQ (the other cvars which are automatically set depending from the compaionion "worldspawn" keys in the map) seem client-side as well (they appear available in console from a client).
The odd thing (and the reason I'm talking about this) is about g_enableQ, which is currently in OAX: if I understood correctly, Fromhell said that, other than making your point of view a bit lower, it also makes your hitbox smaller. Does this mean that players setting it for themselves would get an advantage due to being a little harder to hit?
I know fromhell said maybe she may remove that feature as it did had some problems, however I thought about this detail and mentioned it in case the feature will be kept.

- By the way, if someone has not tried it yet: try g_harvesterFromBodies feature, it's a small but significant and nice variant for Harvester mode! Wink It allows for a faster and more "individual" gameplay... while the original TA way focuses more on teamplay and map control. Thanks Neon Knight for having done it!

PS: I had another small thing to mention, but I want do to some more testing before reporting it and this post already looks too big!
« Last Edit: January 20, 2019, 04:47:25 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 62
Posts: 1664


Open Arena Developer


WWW
« Reply #468 on: January 20, 2019, 07:34:02 AM »

Grapple is broken. It has always been. It is why it is not used.

Callvote. I always felt that there was something wrong but I could not pinpoint what it is. Based on your description of the problem I think it is caused by a new menu being loaded and the button loose focus.

g_enableDust and the rest are CVAR_SERVERINFO. They will be set by the server on map change but nothing prevents the client from overruling them at there own peril. If the server has enabled g_enableQ then ALL clients have lower hitboxes. If a client changes g_enableQ then the prediction may fail and the client may experience bad things. The server is always authoritative in this regard.
Why the clients could not just read g_enableDust and g_enableBreath settings from the map that I do not know.
Logged

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

Cakes 49
Posts: 3775


Trickster God.


« Reply #469 on: January 20, 2019, 08:32:23 AM »

Grapple: Then it's a map-specific problem and not a weapon-specific problem.

enableQ: I thought that was map-specific or at the very least match-specific. It's dangerous to have that feature as player-specific.
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #470 on: January 21, 2019, 11:00:56 AM »

Grapple: Then it's a map-specific problem and not a weapon-specific problem.
I would not expect maps to be tested with grapple and I would not want map makes to limit themself to grapple compatible maps.
I see the grapple more as a toy: It was not fully implemented but may be fun to play around with.

Quote
enableQ: I thought that was map-specific or at the very least match-specific. It's dangerous to have that feature as player-specific.
I guess it is not worse than sv_fps or dmflags which are also serverinfo cvars.
Logged

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

Cakes 49
Posts: 3775


Trickster God.


« Reply #471 on: January 21, 2019, 02:33:16 PM »

Grappling is an alternative to weaponjumping. Only it reaches far than RJ and doesn't involve taking damage. Still I agree that it's more of a bonus than a requirement. Which, of course, doesn't mean it should be entirely neglected as there may be servers that use it.
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #472 on: January 21, 2019, 05:51:59 PM »

About the grapple, while it's not part of the core gameplay, I think it can be a funny item. Wondering if programming it to auto-detach when entering a portal/teleporter could be hard or have some side effect...

About the enableQ, I don't think the problem is it being "serverinfo" (apart from consuming some characters from the size-limited info string), but that -unlike sv_fps, dmflags, or even gravity which is "map set" and "server customizable"- clients can customize it in their own (then, maybe it may be considered something similar to com_blood? But what that does client-side and server-side differs a bit.), potentially causing some kind of issue.
I don't know which are the problems with enableQ which caused Fromhell say she may completely remove the feature. Now I wonder if maybe they may be related to inconsistent values between server and clients? I don't know.
However, reading your posts suggested me a few other tests to do with those cvars...
« Last Edit: January 21, 2019, 05:55:05 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.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #473 on: January 22, 2019, 08:32:31 AM »

Well, that's one possibility, and the most viable one. Once the grapple reaches a trigger_teleporter, it stops working (i.e. comes back to its device). The same as if you throw it to a surface with surfaceparm sky.
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #474 on: January 22, 2019, 09:42:01 AM »

Well, that's one possibility, and the most viable one. Once the grapple reaches a trigger_teleporter, it stops working (i.e. comes back to its device). The same as if you throw it to a surface with surfaceparm sky.

So, you mean to make it impossible to attach to a trigger_teleporter at all? I can guess that may work too, although maybe detaching when actually entering the teleporter would change the gameplay less (at the moment often you can use the grapple as shortcut to reach teleporters, although it does not attach to some of them, depending from the shaders on brushes behind the trigger I guess) and might be more reliable (as you can enter a teleporter athough actually attaching to another brush, as your hitbox is larger than the grapple attach point).
But I can't tell which one is easier to implement.
« Last Edit: January 22, 2019, 10:30:50 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.
Pages: 1 ... 17 18 [19] 20
  Print  
 
Jump to: