OpenArena Message Boards

It has been a lot ot time since I read such complaints (probably due to many few players actually writing on the forums), but in the past I remember there were players complaining of lamers who commited suicide for negating a score to their attacker.

At that time, I replied to one of such complaints in this way:
In short, I said the game already discourages such behavior.

However, if people who actually play the game online feel this is still an issue, maybe a new "DMFLAGS" value could be used to let server admins who really want to disable "kill" command do it (I don't think it's worth an entire dedicated CVAR).
I can guess making the server just ignore that client command should be easy enough... maybe providing a text response to the client "Kill command has been disabled on this server", avoiding the risk of flooding if one pushes it repeatedly/continuosly, may require a bit more work... (well, maybe that may be managed more efficiently making it completely client side instead... I can guess the client knows the server's dmflags value!).

What do you think about that?

Disabling suicide is a bit tricky. Not only because it can be necessary but also because it sometimes happens as a side effect.
A solution I have seen is the 10 seconds limit (used in Codename Eagle) or require a second push after 2 seconds.

In addition to the VQ3 things OpenArena already have the following extra:

• Using kill after being sent airborne will still award a kill to the attacker. ( requires g_awardpushing != 0. Default 1 in 0.8.8 ).
• Suicide in a two player game always gives a point to the other player.

This does not make any difference for 0.8.1 servers or any mods.

Excuse me... happens after a side effect of what? Do you mean that e.g. a player leaving a team actually sends a "kill" command to the server?

I do not know about Codename Eagle, do you mean you have to keep the button pushed for 10 seconds there? A technical issue would be that "/kill" is a standard command, thought for be also typed in console (it's not even binded to any key by default, IIRC)... unlike movement commands like "+forward" which are meant to be binded to keys which will be hold...

I didn't remember about the first one...  :)

True. If servers stuck with old versions, there is nothing we can do.

No but there is technically very little difference between killing yourself with a rocket and typing "/kill".

I codename Eagle after typing "kill" a message would appear: "Ok, you will die in 10 seconds".

It is a lot of code required to prevent a player from typing kill. I would rather make the g_awardpushing much more aggressive. Like killing yourself will reward the kill to the last person hitting you in the last 5 seconds even if you have touched the ground in the meantime. 

Some people think it is a bit wierd. Being killed and moments later being awarded a kill because your killer took a wrong turn shortly after.
Personally I wouldn't mind.

Maybe a more aggressive way of "awardpushing" may be enabled by g_awardpushing "2"? On one hand, that would give more control to server admis; on the other one, sometimes just keeping things simple is better.

I don't know. I hoped some more players expressed their thoughts in this thread...
Is there someone?  :-\

I have noticed this diff:
https://github.com/OpenArena/gamecode/commit/cb6f540bfbeb8ea6c86f5ac0c697b90fe54600fc

So, now if you set g_awardpushing 2, dying rewards the last one who hit you (in the last five seconds) even if you have regained "ground control" in the meanwhile, and that applies also to suiciding with a weapon, other than using "kill" or voluntarily jumping in a deadly place? Even if just due to standard falling damage?
On the other hand, the classic awardpushing 1 does work only if you are actually "pushed" in a deadly place (without having ground control) or in case you use kill (independently from ground control? Or not?) within 5 seconds after being shot, right? The "weapon suicide" does not apply to 1, right?

Re-reading my post, I see I have not used "clear" phrases, sorry. I hope you get what I wanted to know...
-If your changes modified something also in mode 1.
-If the anti-kill, in mode 1 (in 0.8.8 and after the changes) does apply only if you air airborne or not)
- Etc. To sum up, what's useful to know about the feature.

Okay, I did a few tests with nightly build... but it's not very easy to do not all alone, I'm not been able to do effectively do some tests (e.g. I wanted to try to suicide with a rocket against a wall while mid-air, but that's not so easy to do while changing pc on the fly, so I have not been able to do such test and I still don't know if that applies to 1).

It looks like that:
- g_awardpushing 1 is unchanged: it does award the attacker only if the dead one was pushed "airborne" in a deadly pit/trap, or in case he used "/kill" while still airborne. If within 5 seconds.
- g_awardpushing 2, the more aggressive one, awards the attacker in any way (more or less?) the other one dies within 5 seconds after being shot. So, this includes not only "/kill", but also other kinds of suicide. And does not care if the guy is sent airborne or not.

Is this correct?
Do you think that in the aggressive mode, also going to "spectate" after being shot should be punished/rewarded, too? Maybe it's better to do not mess with such stuff?

The spectator thing was actually something I thought about a few days ago as another way to deny a player a kill. Today it should already be that a team change trigger a suicide and act like a kill. After OA got the PlayerStore functionality fast switching teams is like a "/kill" command.

So yes, I do expect going spectator after being hit will award a point. And switching team while falling to your death will do it for g_awardpushing 1 as well (and should do so today).

Testing suicide with a rocker launcher and quad damage is not that hard. I used oa_pvomit for testing. It is one of my favorite maps but a lot of people hate it because it is too easy to kill yourself.

IIRC, time ago (before 0.8.8) some small change has been done to team switching scoring... I think it was a fix for a bug for which changing team caused your old team to score a point in tdm... maybe that bug has been fixed (probably oax b47) by making a player change team  do not affect teams scores in tdm.

This morning I did some test by switching to spectate, but I'm not so sure about the results (also due to the "no negative scores" and "shift score in case there are only two players" rules get in the way)... Maybe I tested it with "2"  and it did not trigger the thing, but I'm not sure.

I tested suicide with a weapon with "2" (works as expected)... Testing with "1" is not so easy, because shooting from a PC and taking the controls on a second pc while the character is still airborne to shoot a rocket in the wall before reaching the floor is not so easy. Maybe I'll try in oa_pvomit next week.

/kill is VERY bad cheating in Capture The Flag where no one gives a flying [*ahem*] about frags, the only thing that matters are team flag capture scores.

1. It allows for *extremely* aggressive defense when a bunch of defenders keep machinegunning anyone who grabs for their flag. They will never run out of ammo and they can keep killing themselves until they spawn in a position to blindside attackers or have a simiilar tactical advantage.

2. It could be used to quickly pass the flag to a teammate when the carrier's health is running low

3. It allows immediate return to home base if the cheater sees most of the action migrating there.

4. It allows drawing enemy players out in pursuit, then respawining back to base defense without waiting for them to finish you off.

5. It negates the tactical element of delaying enemy players by pushing them into abyss, as there is no delay between "AAAAH" and "splat" anymore. May be quite significant for maps with deep abysses. I often see the pushed-off cheaters /kill as soon as they see no chance to land anywhere.

Then maybe a server-controlled feature to (optionally) add a delay between pushing kill button and its effect (after a fixed or cvar-controlled time in seconds) may still be a solution?
I don't know how much code it would require... judging from previous responses from Sago, it's not a quick modify as one might think...

However, let's wait for his opinion...

Now that I think about it, DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Special_game_options#Respawning_in_waves]respawning in waves (http://([b) feature may have the side effect of discouraging a bit "/kill" abuses, due to adding a (variable) delay before respawning.

I know it's not a real solution (it's not the real goal of the feature, and it affects all kinds of deaths), but at least it's something already available in 0.8.8.

A "real" countermeasure would be better...

Honestly, I don't see how any of that is a problem or a hindrance to gameplay, since players from both teams are allowed to do it. It simply adds another layer of strategy and, in my opinion, is a perfectly valid element of the game. The same is true for multiple gametypes, such as FFA, where it also has its share of tactical advantages and disadvantages.

Limiting it would be limiting the game.

Also this is a point. In case Sago may decide to do something more against suicides, I suppose it should be optional, disabled by default. (By the way, it was my opinion also before your post... simply due to the general rule of "preserve Q3A gameplay").

PS: Just a couple of random thoughts for Sago:

- In case you will decide to implement a "kill delay" feature, I guess a "You will die in n seconds" text may be placed in the same place of the respawn counter: they would never appear at the same time, so there should be no overlapping problem. Maybe it may use a different color.

- How does g_awardpushing (2, and to a lesser likelihood, 1) deal with Kamikaze?

I agree about not wanting to change Q3A gameplay. Seeing as how pretty much any element of the game can be annoying if it's abused, trying to solve all these problems through the removal, limitation, or dramatic alteration of those elements would be either counterproductive or downright impossible. Aside from favoring one opinion on the matter over another, trying to address them that way would also undoubtedly lead to even more problems and abuses farther down the road, not to mention more headache for the developers.

That's why I also agree that "sometimes just keeping things simple is better." Retaining a feature's current functionality while allowing it to be enabled or disabled on a server-to-server basis would probably be the ideal approach in most cases, including this one.

From my perspective as a player and lover of Open Arena, it seems to me that (to whatever degree possible) if something doesn't clearly and unfairly benefit one player or team over another, and if it doesn't violate any server or gametype rules without consequence, it should be left alone. Generally speaking, people enjoy the game for what it is now, not for what it could potentially become in the future. 

...aaand I lost another cake. Sweet. :giggity:

While that is probably true, one should not take it too literally, otherwise working for creating new versions would lose meaning...

About cakes, do not care too much about them. I just gave you one to compensate.

Indeed. I guess I should have made it clearer that I was speaking specifically in regards to the aspects of the game that people find annoying, not to improvements in general.

The cakes thing is strange. It doesn't bother so much as puzzle me why I lose one every time I post. Zero is fine, but -1 just seems close to "troll" category. Or at least that's the impression I get, anyway. But oh well.

By the way, I don't know if it's worth mentioning or not, but Quake Live has a g_allowKill cvar that disables suiciding by default, which returns the message "Not allowed on this server" (or something to that effect) to the player who attempts to use it. EDIT: I see where this approach has already been addressed for the most part.

If that's still inadequate, perhaps awarding a health or ammo bonus to the last player to damage someone who kills themselves would satisfy. Those seem to be the biggest concerns of people who criticize the use of /kill, at least in gametypes like CTF where individual scores are mostly insignificant. That might be preferable to removing it outright anyway, because some maps (like wrackdm17) do have glitches making the use of /kill the only way out of certain locations, aside from joining the spectators or disconnecting altogether.

Mainly, I'm just concerned about unforeseen problems these workarounds, such as delays, can cause. Such a thing happened with spawn protection; I remember hearing that it helped some players at the expense of others (http://openarena.ws/board/index.php?topic=4790.msg48097#msg48097), and that's probably why I'm hesitant to recommend a similar course of action here.

I don't think it's appropriate to open a poll about who really even likes/dislikes the /kill suicide command. But I'm quite curious about how many people don't like the use of /kill. In my opinion people don't like it's use when it's not in their favor. If anyone can remember C++ (in game) or Jakash3 from the OpenArena boards.. he felt that people were using /kill as a way to prevent him from winning. In reality you need the /kill function for many parts of the game and the hidden strategy within it.

For example you may be on a map where everyone has already taken the available health/armor and you are now stuck waiting 25s/35s to heal yourself. In some cases during a FFA/DM match the goal is to gain as many kills as possible. Now having low health in FFA/DM you are subjected to being killed by anyone and perhaps giving up a lead or losing position on the score board..

In other situations you may get stuck on a position in the map that you need to suicide to get from. It's rare but it does happen.

A lot of defrag maps require you to /kill to begin the map over again.

All in all.. it's a negative to yourself at the end of the day.

Note: The bigger issue is spawn protection. But I do understand why it does exist.

About spawn protection, I'm not sure about the reason why it has been enabled by default, despite not being a baseq3 feature... probably it was not tought to be a problem.

The way the feature is currently implemented in baseoa (no visual feedback about "protected" players, and protected players capable of shooting, although that immediately ends protection) actually may give some real advantage to the respawned person, in modes such as instantgib. I thought the default duration of just 0.5 seconds would not have been a problem... but reading your posts, it looks like it is, at least in instantgib...

I just added a note in DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Spawn_protection]Spawn protection (http://([b) description on the wiki to suggest that server admins may like to disable it in modes like instantgib. (This, of course, opens the way to spawnpoint campers again).

I have no problem in discussing more about it... maybe in OA3 the feature may be disabled by default, or reworked to (optionally?) behave like some mods do (visual feedback and/or protected player not able to shoot at all). But this is not the right thread for that.
If you wish, you can open an apposite thread for it, where interested people may put their own thoughts about it, and then Sago may decide whether to make some change to it or not.

Note: also the current "no visual feedback" behavior has got sense: in "standard" modes a colored overlay over the player would be like a sign "Look here! I'm a newly respawed player with just a machinegun and no armor. You will be able to attack me soon!"...
Finding a way to make everyone happy does not seem so easy...

Also this depends from the point of view you look at things...
Also "resource control" is a tactical aspect of the game (if you are good at it, you are often more healthy than your opponents, but that's not so easy).
And if you have only one frag of difference against another player, he will reach you anyway, because using "/kill" lowers your score by one. Now that I think about it, it's even worse... because lowering your own score for you is a disadvantage against all opponents, while letting an opponent killing you for you is a disadvantage only against that specific opponent.^[1]
Yes. So I think a delay of the kill would be better that completely disable it.

I guess this would be a gamecode thing, not an engine thing... so it would not affect any existing mod.

^[1] Now that I realize this... killing yourself just for negating a score to another player is a more stupid move than what I thought before!  @_@

An idea: there is already "you have been mined, internal combustion in..."
Why not make /kill add, like, 5 mines to the player?

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.
Where frags matter, suicide is losing a frag.
Where frags do *not* matter, suicide is, in fact, insta-heal combined with base defense buff. Especially on maps where shotgun is given automatically at spawn.

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

I don't mind other modes, suicide is simply pointless in deathmatch.

I think it's not feasible:
IIRC, those mines, when exploding, would still have a blast radius which would harm players near you. That would result in a sort of "free Kamikaze" feature.
Also IIRC, mines do only deal "splash" damage and no normal damage, so they do not harm you at all if you are wearing the "battle suit".

BAD  :(

Hmmm... Then, maybe, find how it is done and copy-paste that code just replacing the damage type? :-X

From players' point of view, looking exactly the same but having a different effect than real mines may be confusing...

Also, I'm not the coder, but I feel that it may still be more complicated or may have more unforeseen drawbacks than just applying a delay (and a message) and then executing standard "kill" code...

Not to argue, but losing a frag rather than giving one to an opponent is just an option that players have to weigh when using the /kill command. The player must decide, often in a very short period of time, whether its more advantageous to risk being killed by another player (while at the same time leaving the opportunity available for finding more health/armor/ammo) or to kill himself, respawning in an unforeseen location, with replenished health but no weapons or armor and one less frag. The answer will not be the same for every situation. That simple fact alone seems enough to validate the use of /kill in OA as a legitimate strategy rather than a cheat or method of abuse.

By the same token, adding a delay would negate any such strategic use and make whatever gametype (especially DM) that much more straightforward (i.e., uninteresting).

The /kill command can be abused just like any other weapon, item, or technique out there, but its nature as a risk/reward tradeoff makes its in-game use both fair and justifiable. It's not purely beneficial for the player nor purely harmful for his opponents. Removing it or nullifying its usefulness, then, would be detrimental to both and would unnecessarily eliminate an entire dimension of the game.

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.

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?

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

Nope  >:(
If they camp, then they camp. Just be faster/trickier than them.  :D
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.

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.

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?
Of course the message can be different. I also already included the line for setting Idrone/1pixel's iconographic obituary (http://openarena.ws/board/index.php?topic=1908.msg54411#msg54411) 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:
Strange.

and if Player B activated kamikaze without being shot first:
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:
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 (https://icculus.org/gtkradiant/documentation/q3radiant_manual/appndx/appn_b_7.htm)? 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...

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 (https://github.com/OpenArena/gamecode/issues/12)) 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 (http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419))...?

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...  :-\

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.

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
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:
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.
    

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 (http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419) (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!

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.

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.

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.

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.

Does this mean that this part of code which currently is in code/cgame/cg_event.c
is never actually used?

UI3 github branch is there for you! :)

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.  :)

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!  :)
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?
;)

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.  :RIP:

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.

Excuse me Sago, I noticed this commit (https://github.com/OpenArena/gamecode/commit/ba479f857f5b30c448776f7df148a532598bf4b4), but I don't get it...
What's this "now it does not check for solid ground" thing?  :-\

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.

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...

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?

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 (http://openarena.ws/board/index.php?topic=5289.msg54419#msg54419). The player in the water just "sank like a rock" and the death animation was played properly. Ok, right? :)

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?  :-\

Waiting for that to do a few more tests.  :)

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...