Unreal Tournament 99 http://unrealtournament.99.free.fr/forum/ |
|
Antibackshot 0.1 http://unrealtournament.99.free.fr/forum/viewtopic.php?f=51&t=3555 |
Page 1 sur 1 |
Auteur: | shai [ 11 Sep 2019, 02:38 ] |
Sujet du 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. |
Auteur: | shai [ 11 Sep 2019, 02:41 ] |
Sujet du 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 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. |
Auteur: | medor [ 11 Sep 2019, 06:57 ] |
Sujet du 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 |
Page 1 sur 1 | Heures au format UTC + 1 heure |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |