Pages: 1 [2]
  Print  
Author Topic: Preventing users from commit suicide (disabling /kill command)?  (Read 5765 times)
sago007
Posts a lot
*

Cakes 61
Posts: 1639


Open Arena Developer


WWW
« Reply #25 on: November 03, 2016, 02:31:19 pm »

- How does g_awardpushing (2, and to a lesser likelihood, 1) deal with Kamikaze?
2 will likely award a point to the last attacker rather than subtracting one from the suicidal player.

1 will likely not award the attacker because the types of attacks that are counted is limited to: MOD_FALLING, MOD_LAVA, MOD_SLIME, MOD_TRIGGER_HURT and MOD_SUICIDE

I usually do consider using kill in a team game a valid tactic. I actually think it is a bit weird that it cannot be bound in the menu.
Logged

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

Cakes 48
Posts: 4195


WWW
« Reply #26 on: November 03, 2016, 02:45:57 pm »

I usually do consider using kill in a team game a valid tactic. I actually think it is a bit weird that it cannot be bound in the menu.
If you wish to add it to the gui, it's okay for me. It may be considered unfair that only those who know about key binding/console command can use it.

OT: By the way, any news about when it will be possible to have a test version of the OA3 ui?
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.
DILZNIK
Half-Nub


Cakes 3
Posts: 52


« Reply #27 on: November 03, 2016, 06:14:49 pm »

I don't like it because it allows the side using it to use brute-force respawning strategies instead, say, planning for failure in advance (balancing between attacking and defending your base) or having to find a RL to suicide.

In short, it makes CTF in particular much less sophisticated. While CTF is the most tactically complex of (widely used) game modes.

It sounds like you have a problem with campers/defenders.
Logged

cheb
Lesser Nub


Cakes 2
Posts: 103



WWW
« Reply #28 on: November 05, 2016, 11:59:53 am »

Quote
It sounds like you have a problem with campers/defenders.
Nope  Angry
If they camp, then they camp. Just be faster/trickier than them.  Cheesy
It's the switching between all-out offense and all-out defense that is the problem. They Zerg-rush your base, your champion goes on the offensive knowing their base is poorly defended... then BAM they see their offense failing and /kill right to their base as your champion reaches it.

To think of it it's *spamming* /kill that is really the problem.

I think a good idea is making /kill in CTF only to quickly switch to spectate then rejoin the team, with a limit on how often a player can change the team. Or simply add a 10 seconds cooldown.

Note that I have nothing to say for DM, it's fine in DM, except that it's often more practical to suicide by shooting a rocket at your feet, may also deal some "screw you" damage to your opponent.
Logged

Imma lazy dreamer. I achieved nothing.
Gig
In the year 3000
***

Cakes 48
Posts: 4195


WWW
« Reply #29 on: November 05, 2016, 01:45:00 pm »

It looks like it's not possible to make everyone happy about kill.
Someone thinks it is an important part of ctf tactics, and someone thinks it ruins ctf tactics.

While I think that the ability for server admins to enable a delay before the kill (forcedly switching to spectate temporarily sounds more complicated) may be a nice addition for OA3, I don't think automatically applying it to specific gametypes would be a good idea: server admins should have the control.
At maximum, maybe in some modes the GUI may propose the option already lit like (IIRC, I haven't checked) it happens for "friendly fire" when the GUI is used to start a TDM match only (since q3a). But I doubt internet servers use the GUI... and IMHO the default behavior should be the default anyway.
« Last Edit: November 05, 2016, 01:55:58 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: 4195


WWW
« Reply #30 on: November 19, 2016, 09:54:06 am »

Back to the aggressive award pushing (g_awardpushing 2)... I suppose that now would also reward in case of drowning, right? I was wondering... does that need a specific message in console?
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: 4195


WWW
« Reply #31 on: November 21, 2016, 04:55:12 am »

Back to the aggressive award pushing (g_awardpushing 2)... I suppose that now would also reward in case of drowning, right? I was wondering... does that need a specific message in console?

Thinking again about this, what do you think about adding something like this?
Code:
case MOD_WATER:
message = "was kept underwater by";
causeShader = cgs.media.skullShader;
break;
Of course the message can be different. I also already included the line for setting Idrone/1pixel's iconographic obituary icon.

Note 1: doing a test with an OAX nighly build from past week (in oa_dm5, a character out from the water, shooting at a character inside the water then waiting for him to drown), it looks like at the moment it writes "Player B was too eager against Player A", while I would have expected just "Player B was killed by Player A". Strange. Aren't "MOD_SUICIDE" and "MOD_WATER" two different things?

Note 2: doing the tests mentioned above, I found a very strange bug. When Player B died, blood was shown like he was gibbed, but his corpse did not disappear (an did not even fall to the ground with a death animation): it stayed there like a ghost. It was standing still (standing), on the floor of the pool, and I was able to shoot through it from the other player. It happened more than one time, and using different models. Maybe it's related with awardpushing 2, but I'm not sure about it (I don't see why it should... but when I did a try without awardpushing 2 the bug did not happen... it may be just a coincidence). See attached screenshots: that "ghost" character is already dead.

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

I actually did a test with kamikaze and g_awardpushing 2 (Player A shot B, and then B activated kamikaze) in an OAX nighly build of the past week.
I think something should be checked, because the output resulted as:
Quote
Player B was too eager against Player A
Player A was too eager against Player B
Strange.

and if Player B activated kamikaze without being shot first:
Quote
Player B goes out with a bang
Player A was too eager against Player B
Strange, too.

I suppose something is going wrong... I supposed the second line should have been the classic "Player A falls to Player B's Kamikaze blast" in both cases... why does the game consider Player A's death a kind of suicide instead?

PS: Maybe one may even customize the text of the first line of the first case with something like "Player B was forced to activate his/her/its explosive by Player A" or similar, it may be nice. However the problem with the second line is more important IMHO.

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

Looking in the code of cg_event.c for other "specific" kinds of deaths which may now happen with an attacker in awardpushing 2, I noticed this:
Code:
case MOD_TARGET_LASER:
message = "saw the light";
causeShader = cgs.media.skullShader;
break;
which is in the "normal suicides" deaths section, but not in the "weapons & assisted suicides" deaths section.... should it also be there? And with which text? I don't know which kind of death is it referring to. Maybe it's referring to the "target_laser" entity listed in Q3 Radiant manual? Reading there it looks like it's a leftover probably not working, and in NetRadiant I don't see it listed as an available entity. So maybe a such cause of death never actually happens in the game.

------------
UPDATE: I updated the post with a strange bug I noticed while doing the tests...
« Last Edit: November 22, 2016, 04:02:36 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: 4195


WWW
« Reply #32 on: December 13, 2016, 04:34:33 am »

Back to the aggressive award pushing (g_awardpushing 2)... I suppose that now would also reward in case of drowning, right? I was wondering... does that need a specific message in console?

Thinking again about this, what do you think about adding something like this?
Code:
case MOD_WATER:
message = "was kept underwater by";
causeShader = cgs.media.skullShader;
break;
Of course the message can be different. I also already included the line for setting Idrone/1pixel's iconographic obituary icon.

Note 1: doing a test with an OAX nighly build from past week (in oa_dm5, a character out from the water, shooting at a character inside the water then waiting for him to drown), it looks like at the moment it writes "Player B was too eager against Player A", while I would have expected just "Player B was killed by Player A". Strange. Aren't "MOD_SUICIDE" and "MOD_WATER" two different things?

Note 2: doing the tests mentioned above, I found a very strange bug. When Player B died, blood was shown like he was gibbed, but his corpse did not disappear (an did not even fall to the ground with a death animation): it stayed there like a ghost. It was standing still (standing), on the floor of the pool, and I was able to shoot through it from the other player. It happened more than one time, and using different models. Maybe it's related with awardpushing 2, but I'm not sure about it (I don't see why it should... but when I did a try without awardpushing 2 the bug did not happen... it may be just a coincidence). See attached screenshots: that "ghost" character is already dead.

I did another test, this time I used a "dedicated 1" (not from oa_ded.exe) to see which MOD_ was considered (side note: this time I actually had to connect the second player from another PC, because I got "duplicated guid" error if I tried to connect two clients from the same machine). I may have just looked at games.log, but I wanted to see it "live"...
Same setting as before: one character out from the water, shooting at a character which is drowning, so the final "damage" comes from drowning.
In case "g_awardpushing" is 1, it records "<world> killed X by MOD_WATER" (okay, as expected)
In case "g_awardpushing" is 2, it records "Y killed X by MOD_SUICIDE" (which is coherent with what was printed on players' consoles -see previous message-, but is wrong: it should have been MOD_WATER).

Also, it may be a coincindence, but again the "broken death animation" bug (for which you also opened an "issue" here) happened when I did the test with g_awardpushing 2 and not when I did the test with g_awardpushing 1.
Is it possible that the missing custom message in case a player kills another one with drowning causes a bug which is not limited to the fallback to the generic "X was killed by Y" message not working, but also prevents the death animation from correctly playing?
Uhm... maybe the problem starts before that: not when the text message is put together, but when the MOD_ (cause of death) is determined (or when it is evaluated if it has to be considered a "pushing" or not)...
And maybe that may also be related with the unexpected text shown with Kamikaze (see post above)...?

PS: I also tried a different thing, still about g_awardpushing 2: shooting someone to push him against a killing pendulum: it was recorded as a "generic (assisted) suicide" (MOD_SUICIDE, "x was too eager against y") instead of a "squished" kill (MOD_CRUSH, "x was crushed in y's trap"). May it be the same bug? It looks like g_awardpushing 2 still needs some tuning...  Undecided
« Last Edit: December 13, 2016, 08:03:15 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: 1639


Open Arena Developer


WWW
« Reply #33 on: December 13, 2016, 01:56:17 pm »

Except for Kamikaze it is deliberately that I say that it is a MOD_SUICIDE.
MOD_WATER did not have a message and I wonder if the information is really informative (it is a very indirect kill)
Generally the lack of messages was the primary reason. The limited use of those messages was the next one.
I find it quite nice to know if the player was pushed into void or lave but not into water.
Logged

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

Cakes 48
Posts: 4195


WWW
« Reply #34 on: December 14, 2016, 02:49:09 am »

Except for Kamikaze it is deliberately that I say that it is a MOD_SUICIDE.
Oh. I have to admit this actually caught me off-guard. I mean, I really did not expect that to be on purpose; I thought they were all bugs.

Having the same exact hazard resulting two different MOD_ (cause of death) sounds strange to me.
While it can be understandable that some infos may not be considered "vital" (e.g. someone drowning or activating kamikaze after being shot), the "main" reason I can think about is that managing all cases may require many more lines/more complicated code than what I thought.[1] I thought that the MOD_ (cause of death) set by a certain hazard should have been the same independently from g_awardpushing value (e.g. a crusher is always a crusher like lava is always lava), but it looks like that's not the case.

However, if a "common" cause had to be used to keep the code lighter, wouldn't it have been better to be "X was killed by Y" instead of implying that X committed suicide in response to being attacked? (Note: of course I'm referring to award pushing feature).

I don't want to bore/annoy you too much, however let's consider:
- That MOD_ (cause of death) is stored in games.log, which is used by statistics tools
- That MOD_SUICIDE is often related with usage of "/kill" command (which is not considered a "nice" action by some players), and so we may be misleading, causing people think that X is a "/kill" abuser while instead he only gets pushed into hazards by other players.
- That since there is a "x was crushed in y's trap" message in the code, when you created g_awardpushing 1 you thought that it was a good thing to know that that Y pushed X into a crusher.
- That the same exact hazard giving different causes of death feels "strange".

To sum up, IMHO the best thing would be being coherent with the same MOD_ (cause of death) independently from g_awardpushing value; in second place, even better if with appropriate messages for every possible case. In case a "common" cause of death has to be used, maybe a generic "x was killed by y" may be better than MOD_SUICIDE.
I cannot force you or anybody to do anything, I just ask you to consider (reflect on) what I wrote here.


[1] I don't know how the kill attribution code works exactly. Considering that it looks like that composing a specific obituary text+icon message requires just four very simple code lines, I can guess the hard part is where the kill actually happens, or where the "award pushing" is evaluated.
I thought it was roughly something like
Code:
IF: is player X blocking func_pendulum?
      THEN
            player X gets killed
            set cause = MOD_CRUSH
            IF: is awardpushing active and was X under attack?
                THEN
                      set attacker = player Y
                ELSE
                      set attacker = <world>
            END IF
      ELSE
END IF
Repeated for every single thing that causes killing a player. Then "cause" and "attacker" would have been considered when later putting together the obituary message. Seeing that different award pushing settings showed different messages may have hinted that the "set cause" line may have been two times inside inner "IF" instead of a single line before it.

But if you had to use a common (shared?) value for various kinds of death, it looks like the "set cause" is located elsewhere, at least for awardpushing... something like:
Code:
IF: is player X blocking func_pendulum?
      THEN
            player X gets killed
            set cause = MOD_CRUSH
            set attacker = <world>
      ELSE
END IF
IF: has been player X killed and was under attack and is awardpushing active?
       THEN
             CASE: has been player X pushed into lava?
                       set cause = MOD_LAVA
                       set attacker = Player Y
             CASE: has been player X pushed into slime?
                       set cause = MOD_SLIME
                       set attacker = Player Y
             CASE: everything else (which also includes being killed by a pendulum)
                       set cause = MOD_SUICIDE
                       set attacker = Player Y
             END CASE
       ELSE
END IF
Something similar would explain the reason why using a "common" MOD_ for various kinds of deaths in awardpushing would have sense, to save some lines of code.

PS: Also, I thought the fact that the death animation not playing (at least apparently) happening only with g_awardpushing 2 may have been caused by some bug which caused an unexpected exit from a cycle/if/case which caused both that and a wrong "MOD_" being picked up... but if that's not the case, then the origin of the death animation bug may be harder to find...

PPS: Sorry, maybe the post turned out somehow longer than it should have been, again... Please forgive me.
    
« Last Edit: December 14, 2016, 04:29:41 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: 4195


WWW
« Reply #35 on: December 14, 2016, 05:50:38 am »

About the kamikaze thing, a quick look to games.log after player "Test" used kamikaze:
In 0.8.8:
  0:46 Kill: 0 0 26: Test killed Test by MOD_KAMIKAZE
  0:47 Kill: 0 1 26: Test killed UnnamedPlayer by MOD_KAMIKAZE

In OAX with g_awardpushing 2, being shot before activating it:
  1:21 Kill: 1 0 20: UnnamedPlayer killed Test by MOD_SUICIDE
  1:22 Kill: 0 1 20: Test killed UnnamedPlayer by MOD_SUICIDE

In OAX with g_awardpushing 2, without being shot before activating it:
  0:43 Kill: 0 0 26: Test killed Test by MOD_KAMIKAZE
  0:45 Kill: 0 1 20: Test killed UnnamedPlayer by MOD_SUICIDE

While this does not really add too much than what was previosly seen with the hud console output (we alredy knew those "suicides" are strange)... it shows to me that in classic behavior the same MOD_KAMIKAZE is applied for both the player activating kamikaze and for those killed by him, suggesting to me that the different text "X goes out with a bang" or "X falls to Y's Kamikaze blast" just depends from X being the same client as Y or not (or, well, from the presence/absence of an "attacker").
Thus, my idea of a message like "Player X was forced to activate his/her/its explosive by Player Y" or similar now sounds harder to apply, because it may require a distinct MOD_ (or some other "trick") to differentiate it from the other case, and I did not want to ask to create a new "MOD_" just for that. So, we may have to stick to have it show "X goes out with a bang", or "X was too eager against Y", or "X was killed by Y" in case X activates kamikaze after being shot (or maybe only the last two)... which one is better?

Of course, I may be wrong!
« Last Edit: December 14, 2016, 08:22:45 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: 1639


Open Arena Developer


WWW
« Reply #36 on: December 14, 2016, 04:05:02 pm »

I am going to go for a completly different approach.

In case of g_awardpushing 2, the cases where g_awardpushing 1 does not count: I am going to let the log show as the player kills itself and then just award the point to the last attacking player. This is roughly equivalent to how it already works in 1 vs. 1.

The current approach has too many unwanted site effects. For instance MOD_SUICIDE assumes that the corpse is gibbed and that might cause the animation problem. Using other MOD_'s doesn't really work too well because if the player blows himself up and the type is MOD_ROCKET, the message will be player A failed to dodge player B's rocket and that is wrong.

If that is not practical (and it might be impractical due to certain limitations) then I'll remove the feature.
Logged

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

Cakes 48
Posts: 4195


WWW
« Reply #37 on: December 15, 2016, 04:53:06 am »

I am going to let the log show as the player kills itself and then just award the point to the last attacking player. This is roughly equivalent to how it already works in 1 vs. 1.
Brainstorming: if you want to still show a trace of the "pushing", maybe when awardpushing 2 kicks in, it may set a flag later read when showing the message, to add something like "(pushed)" or "(pushed by)"?
The different output style in case of awardpushing 1 or 2 may not be the nicest thing in the world, but sometimes one has to accept some compromises.
Examples: "Player X did a backflip into lava (pushed)" or "Player X did a backflip into lava (pushed by Player Y)", or "Player X blew himself up (pushed by Player Y)"; about iconographic version I'm not sure, maybe it may just add the same text to keep code simple (e.g. "<rocket icon> Player X (pushed by Player Y)").
From a "show message" code point of view, it may just require adding a further check shared for all death kinds, however other parts of its implementation may be harder.
I have no idea about how to report that to games.log.

Quote
For instance MOD_SUICIDE assumes that the corpse is gibbed and that might cause the animation problem.
You might probably be right.
I did another test with current OAX: Player Y machinegunning Player X, then player X killing himself with a rocket.
It wrote "Player X was too eager against Player Y", games.log stored "Player Y killed Player X by MOD_SUICIDE"... and the death animation bug happened.

Quote
If that is not practical (and it might be impractical due to certain limitations) then I'll remove the feature.
That may be an option. It's not a vital feature (e.g. in modes other than FFA, individual scores do not really matter so much, and in 1vs1 the opponent is already awarded), and if it is not possible to manage it properly without making things extremely complicated, maybe removing it may be the solution. A bit sad, but sometimes giving up is the only (or best) thing to do. You will evaluate.

- How does g_awardpushing (2, and to a lesser likelihood, 1) deal with Kamikaze?
2 will likely award a point to the last attacker rather than subtracting one from the suicidal player.

1 will likely not award the attacker because the types of attacks that are counted is limited to: MOD_FALLING, MOD_LAVA, MOD_SLIME, MOD_TRIGGER_HURT and MOD_SUICIDE
Does this mean that this part of code which currently is in code/cgame/cg_event.c
Code:
case MOD_CRUSH:
   message = "was crushed in";
   message2 = "'s trap";
   causeShader = cgs.media.skullShader;
   break;
is never actually used?

Quote
I usually do consider using kill in a team game a valid tactic. I actually think it is a bit weird that it cannot be bound in the menu.
UI3 github branch is there for you! Smiley
« Last Edit: December 15, 2016, 07:50:16 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.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3653


Trickster God.


« Reply #38 on: December 15, 2016, 06:55:11 am »

Well, /kill originally was a developer command, it makes sense that it isn't in the menu, even in more modern arena shooters.

(I agree, however, that players shouldn't be forced to use the console in order to change something in the game, as it's anti-intuitive)
« Last Edit: December 15, 2016, 07:02:29 am by Neon_Knight » Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 48
Posts: 4195


WWW
« Reply #39 on: December 15, 2016, 08:28:46 am »

Well, /kill originally was a developer command, it makes sense that it isn't in the menu, even in more modern arena shooters.

(I agree, however, that players shouldn't be forced to use the console in order to change something in the game, as it's anti-intuitive)
I can imagine that id software thought about it as a "last resort" thing and did not bind it to any key by default like "Do you really got "trapped" in a hole in a badly designed map? Pull down the console and type /kill there". But since it is possible to bind it to a key and to "exploit" this to return in game faster when you are on low health, I guess it would be more fair allowing everyone to do it, and not only those who know how to bind a key through the console.

As said in previous posts of this thread, disabling it may be impractical (badly designed maps may still exist), and while some players consider it a "dirty" manouvre, other ones (including Sago) consider it a perfectly legit one... so maybe allowing server admins to optionally (e.g. a DMFLAGS?) enable a delay of a few seconds before clients' "kill" commands are executed may be a nice solution, in case Sago does not find it too complicated to implement code-wise.

PS: Hello Neon Knight, it's a pleasure to read you again.  Smiley
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.
Suicizer
Member
Member
*

Cakes 2
Posts: 398


WWW
« Reply #40 on: December 16, 2016, 04:47:53 am »

Well, /kill originally was a developer command, it makes sense that it isn't in the menu, even in more modern arena shooters.

(I agree, however, that players shouldn't be forced to use the console in order to change something in the game, as it's anti-intuitive)
I can imagine that id software thought about it as a "last resort" thing and did not bind it to any key by default like "Do you really got "trapped" in a hole in a badly designed map? Pull down the console and type /kill there". But since it is possible to bind it to a key and to "exploit" this to return in game faster when you are on low health, I guess it would be more fair allowing everyone to do it, and not only those who know how to bind a key through the console.

As said in previous posts of this thread, disabling it may be impractical (badly designed maps may still exist), and while some players consider it a "dirty" manouvre, other ones (including Sago) consider it a perfectly legit one... so maybe allowing server admins to optionally (e.g. a DMFLAGS?) enable a delay of a few seconds before clients' "kill" commands are executed may be a nice solution, in case Sago does not find it too complicated to implement code-wise.

PS: Hello Neon Knight, it's a pleasure to read you again.  Smiley

You also forgot defrag highly depends on  the command (altough it's a mod)....
Logged

I'm good at everything but can't do anything...
Gig
In the year 3000
***

Cakes 48
Posts: 4195


WWW
« Reply #41 on: December 16, 2016, 05:43:08 am »

You also forgot defrag highly depends on  the command (altough it's a mod)....
Do you fear we may compromise Defrag behavior? Don't worry about that!  Smiley
1) Very probably, adding a "delay" before suicide would be a gamecode thing (opposite to an engine thing), hence it technically cannot apply to any previously existing mod or to any older OpenArena version.
2) Due to 1), the only way it may apply to Defrag would be Defrag developers making a new Defrag mod version based upon OA3 gamecode. Is Defrag still under development?
3) Even if that was the case, I imagine it as an "optional" feature, disabled by default. So it would be the server admin to purposely enable it on his server... and in case of Defrag (or similar) mod, why would he do it?
Wink

PS: Maybe you were mostly replying to Neon Knight instead of to me? Meaning that you said that binding it through the GUI would be useful also in Defrag?
In that case I'm sorry, AFAIK we technically cannot add options to the GUI of mods.  Rest In PEACE!
« Last Edit: December 16, 2016, 05:50:45 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.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3653


Trickster God.


« Reply #42 on: December 16, 2016, 09:59:36 am »

It is a mod, but it won't be affected by this as the Defrag mod, last time I've checked, is based on the Q3 code, not on OA code, as far as I'm concerned.
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Gig
In the year 3000
***

Cakes 48
Posts: 4195


WWW
« Reply #43 on: December 19, 2016, 02:04:37 am »

Excuse me Sago, I noticed this commit, but I don't get it...
What's this "now it does not check for solid ground" thing?  Undecided
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: 1639


Open Arena Developer


WWW
« Reply #44 on: December 19, 2016, 12:08:05 pm »

What's this "now it does not check for solid ground" thing?  Undecided
The current g_awardpushing cancels if the player ever gets solid ground under his feet. With g_awardpushing > 1 it does not. So if the player uses kill within 5 seconds of being hit, it is a kill to the attacker, even if the player is standing on the ground.
Logged

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

Cakes 48
Posts: 4195


WWW
« Reply #45 on: December 19, 2016, 12:12:27 pm »

But do you mean that now "2" only applies to the same kinds of death of awardpushing 1 (trigger hurt, suicide, falling, lava, slime), instead of all kinds of death?

Sounds ok to me. Diminishes what awardpushing 2 initially was, but should fix various headaches... It doesn't award in case of one suiciding by rocket... but that turned out too complicated...

And what about that "mod_crush" bit? http://openarena.ws/board/index.php?topic=5289.msg54511#msg54511


Ps: so "the only difference" sentence meant "against awardpushing 1"... at first, I thought it was against the previous "2" implementation. (The "not checking for solid ground" sounded strange to me because awardpushing 2 already did not check for it). Poor me...
« Last Edit: December 19, 2016, 03:06:50 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: 1639


Open Arena Developer


WWW
« Reply #46 on: December 20, 2016, 01:10:23 pm »

Ok, that could be enabled too for award_pushing 2. For award_pushing 1 it did not make much sense.
Logged

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

Cakes 48
Posts: 4195


WWW
« Reply #47 on: December 20, 2016, 03:54:55 pm »

Ok, that could be enabled too for award_pushing 2. For award_pushing 1 it did not make much sense.
While it is unprobable, I can guess in theory a crusher may crush you horizontally even while you are jumping/falling.
And having to enable it for awardpushing 2, enabling it also for 1 should allow to keep code simpler, right?
« Last Edit: December 20, 2016, 03:57:47 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: 4195


WWW
« Reply #48 on: December 23, 2016, 07:02:31 am »

I just did a few quick tests with awardpushing 2 with OAX nightly build 2016-12-18.

1) With the same environment of that famous screenshot. The player in the water just "sank like a rock" and the death animation was played properly. Ok, right? Smiley

2) With player A shooting player B... then B using "/kill". In this case, MOD_FALLING was used ("B was given a small push by A"), although B wasn't actually falling. Why isn't MOD_SUICIDE used instead? Is the "B was too eager against A" text unused at the moment?  Undecided

Ok, that could be enabled [...]
Waiting for that to do a few more tests.  Smiley
« Last Edit: December 23, 2016, 07:07:33 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: 4195


WWW
« Reply #49 on: December 26, 2016, 04:09:50 am »

Is the "B was too eager against A" text unused at the moment?
Just a small detail not really important: if that text has to be only related to the usage of /kill, then maybe it may say something like "B had too fear of A", "B had chicken against A", "B was too scared by A"... maybe I did not use the perfect English but I hope you got what I mean.

It's just a random thought, probably "eager" would be ok, too...
« Last Edit: December 28, 2016, 04:00:27 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 [2]
  Print  
 
Jump to: