Nous sommes le 28 Mar 2024, 20:42


Online     TeamSpeak UT99     UnrealTournament-V3     Download     Utfiles medor     Vote Weborama     Vote Unrealtop200     Vote xtremetop100     free TeamSpeak     Unreal Soundtracks     Google    Mini-Chat Mini-Chat

Poster un nouveau sujet Répondre au sujet  [ 3 messages ] 
 Antibackshot 0.1 
Auteur Message

Inscription: 22 Oct 2017, 03:57
Messages: 4
Nouveau message Antibackshot 0.1
Hello Medor,

First, my apologies. I know I've been promising to send this to you for at least 18 months. When I had it running on my own server, it was integrated into SmartCTF. But I wanted to make it function as a stand-alone mutator.

I've done that now, and I'm including a download link for the mutator below. I've tested it offline with bots, and it seems to work. However, I'm certain there will be bugs that I'm not aware of, since I haven't been able to test it with human players - I've really no idea how well it will function on a live server. Caveat emptor.

I don't know whether it will fulfil its basic purpose for being, satisfactorily, either. But it is what it is. If nothing else, maybe someone can use it for inspiration to build something better.

download from Mediafire

I'll repost the readme.txt file below this message. Best regards.


Dernière édition par shai le 11 Sep 2019, 02:48, édité 2 fois.

11 Sep 2019, 02:38
Profil Envoyer un e-mail

Inscription: 22 Oct 2017, 03:57
Messages: 4
Nouveau message Re: Antibackshot 0.1
EDIT: Since the forum doesn't use a fixed-width font, some of the formatting below is a bit messed up. But it's mostly legible.


===============================================================================
= "Antibackshot" mutator, version 0.1 =
===============================================================================

[What?]
=======
A server-side mutator designed to punish persistent "backshooters" by preventing
them from killing other players for short periods of time (whenever
"backshooting" is detected)


[Installation]
==============
Files
-----
Copy the "anti_backshot_01.u" file to:

"\UnrealTournament\System"

Copy the "antibackshot.ini" file to:

"\UnrealTournament\System"

This file is NOT re-created by the mutator if it gets deleted.


Configuration
-------------
You can run "antibackshot" as a mutator (via the command line / batch file) or
as a server actor, depending on your preference.

1) If you want to add it as a mutator to your command line server start-up
instruction, do something like:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
ucc server CTF-Coret?game=Botpack.CTFGame?mutator=anti_backshot_01.antibackshot,Botpack.InstaGibDM?MaxPlayers=10

2) If you want to add it as a server actor, open your server's
UnrealTournament.ini file, find the "[Engine.GameEngine]" section, scroll down
to the ServerActors part and add this line below the last currently listed
ServerActor:

ServerActors=anti_backshot_01.antibackshot


INI file settings
-----------------
Some of these settings have a very subtle effect, and so it's difficult to
observe any noticeable change in-game after tweaking them.
I haven't done very much range checking, so if you put insane values for
any of these settings, strange things might happen. Some of my descriptions
are probably a bit unclear, but writing this stuff is tedious and difficult
to articulate accurately (for me, anyway).
Something to bear in mind for a few of the settings listed below:
1 meter = 52.5 Unreal Units

The section header for the INI file should be:
"[anti_backshot_01.antibackshot_proxy]"


"gbActive":
Determines whether antibackshot is active (enabled) or not.
Set it to true or false.
[Default is: true]

"gbDebug":
Outputs debug information to the server log. You'll probably want to set this
to false unless you're trying to diagnose a problem.
[Default is: false]

"gbDetailedDebug":
Provides more extensive debug information. Again, you'll probably want to set
this to false.
[Default is: false]

"gbTesting":
Leave this set to false. It was included so that the mutator could be tested
offline with bots... in the absence of human test subjects
*mad scientist cackle*
[Default is: false]

"gbConsiderConsecutiveshots":
The general philosophy is that a player will only be judged a "backshooter"
if a certain percentage of their shots are "backshots." However, there might be
games where a player never triggers the "backshot percentage" (the player might
be careful to remain below this limit by racking up "legitimate" kills too).
Set this value to 'true' to ALSO consider consecutive "backshots" as a reason
to punish players who never trigger the "backshot percentage" - see the
description for "giConsecutiveShotTrigger" below.
[Default is: true]

"gbDisableForOneVSOne":
If this is set to 'true', backshot tracking will be disabled in games where
only 2 human players are present.
[Default is: true]

"gbShakeOnBackshotWarn":
A visual effect, the player screen 'shakes' when they are warned about
backshooting.
[Default is: true]

"gbSoundOnBackshotWarn":
An auditory effect, the player hears a sound when they are warned about
backshooting (you can choose between 4 sounds using the
'giBackshotWarningSound' setting).
[Default is: true]

"giBackshotPercent":
A value which will trigger an automatic warning and punishment. When a player
gains a number of 'backshot' kills equal to this percentage, they'll be
punished. So if you set this value to 40, then players will be punished if 40%
of their kills are backshots. Lower = backshooting detected more often;
higher = backshooting detected less often
[Default is: 40]

"giBackshotWarningSound":
Allows you to choose between 4 different sounds that a player will hear when
punished. The value can be any number from 0-3. 0 = buzzing fly sound,
1 = breaking glass sound, 2 = woman screaming, 3 = man screaming
[Default is: 1]

"giConsecutiveShotTrigger":
This setting allows you to set a number of backshots /in a row/ which would
also trigger a "backshot" warning - a bit like a killing spree - a backshot
spree. So if you set this to 5, and a player kills 5 enemies in a row with
backshots, they'll be punished (i.e., even if their backshot percentage is
less than giBackshotPercent). Lower = backshooting detected more often;
higher = backshooting detected less often
[Default is: 5]

"giMinShotsBeforeTrigger":
This setting works in partnership with the "giBackshotPercent" value. It
determines a minimum number of kills that the player must first achieve before
the "giBackshotPercent" value comes into play. For example, if you set this
value to '5' then the player must get 5 kills before they start to be assessed
as a "backshooter" or not. It's designed to allow a bit of flexibility at the
start of a new game, a player might accidentally get a "backshot" or two at the
beginning of the match, but and then settle into a more well-behaved pattern of
behaviour - this setting allows for that. Lower = backshooting detected more
quickly; higher = backshooting detected less quickly
[Default is: 5]

"giWarnTime":
The number of seconds for which a player will be punished when they are judged
to be a 'backshooter' - either triggered automatically by the server, or in
response to an administrator action.
[Default is: 20]

"gfDefendingDroppedEnemyFlagClose":
If a player kills an enemy while close to the dropped enemy flag, then the
player is /probably/ trying to grab the dropped flag before it can be returned.
If the player was facing towards their own base when the enemy was killed, this
might ordinarily be a "backshot" - but here it won't be counted as a "backshot"
if the distance between the player and the dropped flag is within the distance
specified here. This value is specified in Unreal Units.
Lower = backshooting detected more often; higher = backshooting detected less
often.
[The default value is: 525 unreal units, or 10 meters]

"gfDefendingDroppedEnemyFlagFar":
This is similar to gfDefendingDroppedEnemyFlagClose, but it allows an increased
distance between the killer and the dropped flag IF the killer has
line-of-sight to the flag.
Lower = backshooting detected more often; higher = backshooting detected less
often.
[The default distance is: 1536 Unreal Units (about 30 meters)]

"gfDefendingDroppedOwnFlagClose":
If a player kills an enemy while close to their own dropped flag, then the
player is /probably/ trying to defend and return the dropped flag before the
enemy player can reach it (or to support a team mate who is trying to return
the flag). This value determines the maximum distance that a player may be
from their own dropped flag when they kill another player without it being
considered a "backshot" (i.e., even if they are facing towards their own
base when they make the kill).
Lower = backshooting detected more often; higher = backshooting detected less
often.
[The default distance is: 525 Unreal Units (10 meters)]

"gfDefendingDroppedOwnFlagFar":
This is similar to gfDefendingDroppedOwnFlagClose, but it allows an increased
distance between the killer and the dropped flag IF the flag has been dropped
for less than 10 seconds. Otherwise - if the killer is a long way from the
dropped flag - the killer probably isn't trying to get the flag back, and it's
more likely to have been a 'backshot'
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default is: 1536 Unreal Units (about 30 meters)]

"gfDefendingOwnBaseFlagPresent":
If a player kills an enemy while near to their own flag, it's /probably/ a
defensive kill, and legitimate. But there are other factors to consider.
1) Is the player's flag 'home' (returned)? If so, and the player is within the
distance specified by this value, then it's a legitimate defensive kill.
2) If the player's flag is not 'home', and the victim is close to the flagbase,
then the kill is questionable - the killer should be busy trying to recover
their missing flag, not spending time shooting backwards at enemies who are not
involved in trying to support a flag run. It's possible that the killer might
have given up on chasing down the enemy flag carrier (if the carrier is close
to scoring, for example), and therefore the killer is trying to prevent a quick
follow-up flag run. These possibilities are considered by the mutator in
partnership with the value specified here, which is the distance between the
killer and the killer's flagbase at the time when the shot was made.
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default value is: 525 Unreal Units (10 meters).]

"gfDefendingOwnBaseEnemyFCFar":
This corresponds to point (2) of "gfDefendingOwnBaseFlagPresent" If a player
kills an enemy near to the player's flagbase, and the player's flag has been
taken, is the enemy team close to scoring? In other words, is the player
attempting to prevent a quick follow-up flag grab? This value specifies the
maximum distance between the enemy flag carrier, and the enemy flag carrier's
base at the time when the player kills the enemy near his /own/ base.
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default is: 787.5 Unreal Units (15 meters)]

"gfDuelDistance":
If a player kills an enemy in the middle of a map, and the players are close
together when the kill occurs, then the mutator considers this to be a
legitimate frag, even if the killer was facing towards their own base at the
time when the kill took place. This value specifies the maximum distance
between two players at the time when a frag occurs. If the players are within
this distance, it's judged a legitimate frag. If the distance is greater it
might be a "backshot"
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default value is: 262.5 Unreal Units (5 meters)]

"gfAttackingEnemyBase":
If a player kills an enemy while close to the enemy base, it's /probably/ a
legitimate kill (even if the killer is facing towards their own base at the
time of the kill - i.e., the killer might be sweeping the base clear of freshly
spawned enemies before making a flag grab). This value specifies the maximum
distance between the killer and the enemy flag base within which a kill will
not be considered a "backshot"
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default value is: 787.5 Unreal Units (15 meters)]

"gfConeOfObservationTowardsOwnBase":
This is a geometric angle. Visualize standing in the center of a map, and
looking back towards your own base, so that your line of vision is
perpendicular to your flag. Now imagine a triangle which has one of its
points where you are standing, and then expands to your left and right, and
extends to the back wall of your base. This width of this cone, or arc - the
size of the angle - of the triangle is determined by this value. Sane values
are between 0 and 90, but a reasonable value is around 35-40 degrees

Image

This value determines how the mutator makes decisions about a "backshot" If a
player shoots an enemy within the 'cone' defined by this angle then it's a
backshot. If the enemy is outside of this cone, then it isn't a backshot.
Full disclosure: I'm writing this description about 2 years after I made this
mutator in its original incarnation, I'm awful at maths, and I don't remember
the formula by which these values are calculated. So this description is sort
of my layman's understanding of what's going on, and might not be technically
accurate. But I think it's *vaguely* sound.
Lower = backshooting detected more often; higher = backshooting detected less
often (I think. Within reason. Not sure what happens above 90, you might never
detect a backshot. I'd stick to somewhere in the 30-40 range)
[Default value is: 35]

"gfSupportingFCTeamMate":
If a player kills an enemy, and the player is close to a team mate who is
carrying the enemy flag, then the player was /probably/ supporting his team
mate's flag run when he made the kill, even if aiming back towards his own base
at the time. This value determines the maximum distance between killer and
killer's team mate within which a kill will not be evaluated as a potential
backshot.
Lower = backshooting detected more often; higher = backshooting detected less
often.
[Default is: 1050 Unreal Units (52.5 meters)]

"gsBackshotWarnTxt":
The text that's displayed to a player when they are warned against backshooting
(rendered in large white letters in the center of the screen). The '%s' will
be replaced by a number representing the number of seconds for which the
punishment will last.
[Default text is: "Don't backshoot! Hits won't kill for %s seconds."]

"gsBackshotAlreadyWarnedTxt":
A message shown to a server administrator when attempting to warn a player
against backshooting using a mutate command when the player has already been
warned (and the warning has not yet expired). The '%s1' will be replaced by
the name of the warned player, and '%s2' will be replaced by a number
representing the number of seconds remaining for the player's warning.
[Default text is: "Player %s1 is already serving a warning. Current warning
expires in %s2 second(s)."]

"gsBackshotWarnerTxt":
A message shown to a server administrator after issuing a manual warning to a
player (using a mutate command), and when a player has not already been warned.
The '%s1' will be replaced by the name of the warned player, and '%s2' will be
replaced by a number representing the number of seconds for which the
punishment will last.
[Default text is: "You warned %s1 to stop backshooting. They won't be able to
kill for %s2 second(s)."]


[Purpose]
=========
The concept itself is controversial, but in broad terms a "backshot" is
considered to be any shot directed at an enemy player where the attacker and
the intended target have passed one another, and have moved on beyond their
meeting point with sufficient distance that - from a strategic Capture the Flag
perspective - they should be focusing on other objectives. In other words
they've moved beyond a notional 'dueling' distance of each other, and ought to
be grabbing flags, or retrieving flags, or attacking other enemy players still
ahead of them, NOT fixating on some other player who is now behind them and has
turned their attention elsewhere.

There are caveats to this of course. If you're carrying an enemy flag, all bets
are off. If the person you're attacking has your flag, all bets are off.
And then things get more complicated. Is it still a 'backshot' if the person
who killed you was laterally positioned relative to you, but some distance
away, or is this 'deathmatching' instead? Is it a 'backshot' if you aim towards
your own base from mid-map and kill an enemy player who is approaching (but has
not yet reached) your flag, because you know that they were about to grab it,
or is this reasonable base defense? There are other ambiguities too, and it
makes coming up with a set of rules which define backshooting rather tricky.

I've tried to design a mutator that will track 'backshooting' while attempting
to be somewhat sympathetic to the vagaries of circumstance that can be involved
in CTF dog-fighting. The set of rules that I've chosen might be poor ones. Or
poorly ordered. It's the kind of scenario where you could sit 10 people down
and get 10 different perspectives on how each shot, in any given circumstance,
should be judged.


[Mutate commands]
=================
Very limited. All must use the prefix 'antib'. Only an administrator can issue
these commands.

1) mutate antib list -> lists players in the status array (in the console)
2) mutate antib config -> shows INI configuration settings (on the screen)
3) mutate antib warn <playername> -> manually warn a player
4) mutate antib help -> lists the mutate commands (on the screen)


[Technical considerations]
==========================
Player status (frag count, whether warned or not) is stored in a sorted list
(an array). However, the choice about which item of data to use to uniquely
identify a player within this list is a complicated one. This issue would
become much simpler if we could assume that Nexgen or ACE were available. But I
don't want to make this assumption. So we're limited to more ephemeral
information: player name, player ID, player IP.

If we use player name, it's possible to add name-change tracking (I've only
managed to achieve this reliably with a extended StatLog class assigned to the
Level.Game.LocalLog variable). But the user could disconnect from the server,
change their name, then reconnect and we'd be none-the-wiser. If we used player
IP, then it's possible that several players could connect from behind a single
network address - if they're all on a LAN for example - and all share the same
IP. If we use player ID, this is reset every time a player reconnects to the
server.

So, we could use IP in the first instance, and then a name to separate out
players with a shared IP. But then searching becomes much more tricky. If a
player reconnects with a new name, and our list search finds a matching IP but
a different stored name, we're left to ponder: is this the entry belonging to
the reconnected player, or does it belong to another in-game or departed player
who also had the same IP? We don't know. We could search the UT maintained
collection of active players to see whether anyone in the server has the same
name - and therefore eliminate this entry as our target if an active players is
found. We could then try searching near this entry to see if the status list
contains other entries with matching IP addresses and an identical name. But if
no "name matches" are found, but IP address matches are identified, we have the
same problem for each of these too. So the joint IP-name strategy doesn't really
help very much.

On balance, I think that the likelihood of more than one player with the same
IP address being in the server at the same time is relatively low. So, although
it could quite easily lead to a situation where the wrong player is blamed for
backshooting, and the real villain escapes, that's what I've gone with for now.
Since the penalty for backshooting is relatively brief (depending on the time
penalty setting selected), I don't think that the consequences of this are too
dire even if this were to happen.


When a player kills another player, the mutator begins evaluation in the
PreventDeath function. The sequence is as follows:

1) If either the server-reported killer or victim is unassigned ('none') then
the function exits (this seems to happen, for example, when a player leaves
the server - this is registered as a 'kill' on the leaving player, but with
no attacker).

2) If the flags or flagbases for either team cannot be located, the function
exists (these objects are used as points of reference throughout the function).

3) If the killer is carrying the enemy flag -> no backshot; exit function

4) If the killer and victim were having a fair 'duel' (gfDuelDistance) -> no
backshot; exit function

5) If a team mate of the killer has the enemy flag, and the killer was
providing cover (gfSupportingFCTeamMate) -> no backshot; exit function

6) If the victim was carrying the killer's flag -> no backshot; exit function

7) If the victim's flag is loose (dropped) and the killer was attempting to
grab it (gfDefendingDroppedEnemyFlagClose & gfDefendingDroppedEnemyFlagFar) ->
no backshot; exit function

8) If the killer's flag is loose (dropped) and the killer is attempting to
recover it, or provide support for a team mate who is trying to recover it
(gfDefendingDroppedOwnFlagClose & gfDefendingDroppedOwnFlagFar) -> no backshot;
exit function

9) If the killer is near their own flagbase (gfDefendingOwnBaseFlagPresent)...
a) If the killer's flag is 'home', the kill was defensive -> no backshot;
exit function
b) Or if the killer's flag is absent (taken)...
i) If the killer is closer to their own flagbase than the victim, then
- by definition -> not a backshot; exit function
ii) If the victim is closer to the killer's flagbase than the killer
(gfDefendingOwnBaseEnemyFCFar), is the enemy flag carrier close to
scoring? If so, the killer is probably killing the enemy player to
prevent a quick follow-up grab once the cap is complete -> not a
backshot; exit function
iii) ...else the killer's flag is loose somewhere in the mid-point of
the map, and the killer should be trying to recover it ->
processing continues

10) If the killer is close to the enemy flag...
a) If the enemy flag is 'home' (untaken) then this is an attacking maneuver
(gfAttackingEnemyBase) -> not a backshot; exit function
b) ...else might be spawnkilling -> processing continues

11) On a map like CTF-UTR-Attempt, the player spawn area is adjacent to the
flag base, so players might be in that area and shooting towards their own base
to pick off incoming attackers. But with the preceding rules, this will be
detected as a "backshot". We need to account for this -> if the enemy flag is
more distant then the player flag, and in the same general direction... ->
not a backshot; exit function

12) If processing reaches this point, after all of the above rules have failed
to exclude the kill as a backshot, and if the killer was aiming towards their
own base when they made the kill (according to
gfConeOfObservationTowardsOwnBase), then this WAS a backshot


[Updates / future / re-use]
===========================
Chunks of the unrealscript for this mutator are either directly pulled from, or
heavily inspired by other existing work, primarily Nexgen, SmartCTF and
BTPlusPlus. As far as I'm concerned, you can do whatever you like with it.

For the future, I think it'd be nice to have ACE integration for more accurate
player tracking.

The best place to discuss anything like this is ut99.org - sign up and join
the community.


11 Sep 2019, 02:41
Profil Envoyer un e-mail
Administrateur
Avatar de l’utilisateur

Inscription: 01 Oct 2008, 01:14
Messages: 5598
Nouveau message Re: Antibackshot 0.1
Just excellent.
Save http://medor.no-ip.org/Mods/antibackshot01.zip

I confess that I did not believe at all at the exit ^^ .
It is likely to be included in a project Twenty Years of Unreal Tournament - we should celebrate that.

Test will start on the Deepu test server with the last build NewNet :obgay:

Image

_________________
UT99 files
Image
Image
Image
Image
Image
Image
Image


11 Sep 2019, 06:57
Profil Envoyer un e-mail
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 3 messages ] 


Qui est en ligne

Utilisateurs enregistrés : Aucun utilisateur enregistré


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Powered by phpBB © phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.
Traduction par: phpBB-fr.com