Tremulous Forum
Mods => Mod Releases => Non-Gameplay Changing => Topic started by: FooBar on February 26, 2007, 04:57:26 pm
-
*Updated* - March 6 - Added links to patches.
These patches and many more can also be found on the Tremulous Patch Tracker (http://www.mercenariesguild.net/patches/).
Right now all of these patches are testing on AVALANCHE (http://avalanche.server.googlepages.com).
AntiDecon - v0.90
AntiDecon was intended to prevent catastrophic decon events like loss of the reactor or overmind due to decon at some inopportune moment. As it turned out, this patch is slightly an anti-decon measure and mostly a modification of the voting system. The anti-decon system is simple:[list=1]
Anti-deconner option. Defaults to 0. Set g_antiDecon 1 to enable the following features:[list=a]- No one will be allowed to deconstruct the last spawn.
- Any attempt to deconstruct the Reactor/Overmind automatically calls a 10-second team vote to deconstruct it which requires a 2/3 majority to pass. (Another way of looking at it is that at least 33% of voters must OBJECT for it to fail.)[/list:o][/list:o]The rest of this patch offers several new vote functionalities to developers:[list=1]
- Custom votes: In this case "custom" can mean two things:[list=a]
- Votes that have outcomes that are not based on console commands, and
- Votes that can only be called by performing some action in the game, and CANNOT be called by players using console commands.[/list:o]Developers simply specify a new voteType_t, and add it to the Cmd_CustomVote_f routine along with the neccessary code to determine what happens when the vote is called, and what happens when the vote passes.
- Selectable voting majority: The developer may now choose a desired majority required for their vote to pass. For console-command-based votes, the majority defaults to 50% if it's not explicitly specified later. Custom votes must specify a majority.
- Team votes now operate like server-wide votes. In the past, a team vote could not pass unless a majority of the WHOLE TEAM voted yes. Now, as with general votes, the vote will pass if a majority of VOTERS vote yes.[/list:o]Credits : In AntiDecon.879.patch, section 1a (no deconning the last spawn) is copied from svn 880 code implementing g_markDeconstruct. That code is already present in svn 899. The rest of AntiDecon.879 and all of AntiDecon.899 was written by FooBar.
NewbieNaming - v0.90
NewbieNaming-0.90.zip (http://avalanche.admin.googlepages.com/NewbieNaming-0.90.zip) - for SVN 879 & 899
NewbieNaming is a patch designed to allow UnnamedPlayers to be automatically renamed with numbered names, so that they may be easily distinguished. Also I fixed a small peculiarity in the rename code.[list=1] - g_newbieNumbering ( 1 or 0 )
Defaults to 0. Set g_newbieNumber 1 to enable the following feature:[list=a]- Connecting players with the name UnnamedPlayer, or any player who is renamed to UnnamedPlayer, will automatically receive a name of the form g_newbieNamePrefix#, where # is a number from 0 to 9999 and thereafter reverts to UnnamedPlayer again. The number # resets at the beginning of each round. Only unused numbered names will be assigned.[/list:o]
- g_newbieNamePrefix ( string )
Defaults to "Newbie#". This options sets the prefix of the name that will be automatically assigned to UnnamedPlayers.- Fixed a small annoyance in the function ClientUserInfoChanged in file src/game/g_client.c. The oddity occurs when a client connects to a mod server without first selecting the mod from a list. Because mods have their own autogen.cfg files, it's possible for the player's base name to be "foo" and their mod name to be "bar". Then if a player joins a mod server while in base configuration, the server will broadcast the following messages:
"foo connected."[/li][/list]
"bar entered the game."which seems silly and is confusing. I changed the code slightly so the server will now say: "foo connected."
"foo renamed to bar."
"bar entered the game."[/list:o]Credits : by FooBar.
PureDropMessage - v0.90
PureDropMessage-0.90.zip (http://avalanche.admin.googlepages.com/PureDropMessage-0.90.zip) - for SVN 879 & 899
PureDropMessage is a slight modification to the package verification process for pure servers. Consider a client connecting to a pure server. If the client does not have the correct "pure" pk3 files and has Auto Download turned OFF, the server just drops the connection from the server side, causing the client to simply hang at the end of the level loading screen.[list=1] - I added a line to send a disconnect message to the client before the server drops the connection. When the client finishes loading the level it will disconnect properly, giving a disconnect message.
- sv_pureDropMsg ( string )
This message will be displayed in a dialog window after the client disconnects. The default value is "This is a pure server. Your client is missing files or corrupted. Try turning on AutoDownload."[/list:o]Credits : by FooBar.
RatingSystem - v0.90
RatingSystem-0.90.zip (http://avalanche.admin.googlepages.com/RatingSystem-0.90.zip) - for SVN 879 & 899
RatingSystem is intended as a device to display how much a player helps or hurts their own team. A new column called "Rating" is added to the client scoreboard. Each time a player dies, their "worth" is divided among all players based upon how much damage was done, as follows:[list=1]- The "worth" of a player is calculated based on
"worth": 1 dretch = $175 = 1.00 points[/li][/list]
1 unarmed, unarmored human = 1 evo = 1.00 pointsAll others are scaled accordingly in proportion to their value. - Players who damaged the victim receive a percentage of the victim's total worth based on how much damage they did out of the player's total health. Opponents receive positive points, teammates receive negative points.
- The victim receives negative points equal to the total points awarded to opponents.
- Points are recorded in units of 0.01 and displayed rounded to the nearest integer. So a score of 2.43 is displayed as 2. If the player then scores +0.21 points, their score becomes 2.54 and is displayed as 3.
- "Scoring a kill", that is, firing the deadly shot, doesn't convey any points beyond what the damage is worth. However, damage beyond the lethal point IS counted. So if two dretches headshot a human, they each get 50%.[/list:o]The scoring system is completely independent of gameplay and does not affect disbursement of cash/evos, team stage advancement, or anything else.
So for example, consider that Player D as a dretch dies on a turret. Before the dretch died, the following players did this much damage: Player A (alien) : 5 health (team damage)
Player H1 (human) : 10 health (opponent damage)
Player H2 (human) : 6 health (opponent damage)
Turret (world) : 4 healthThen earnings are awarded as follows: (world) (4/25) * 1.00 = 0.16 points (unawarded)
Player A : - (5/25) * 1.00 = -0.20 points
Player H1 : +(10/25) * 1.00 = +0.40 points
Player H2 : + (6/25) * 1.00 = +0.24 points
---------- ------------
Player D : = -0.64 points (total awarded to enemies)
Credits : The code for communicating to the client side was based on a patch by rasz (https://bugzilla.icculus.org/attachment.cgi?id=1168), for bug #2930 (https://bugzilla.icculus.org/show_bug.cgi?id=2930). I changed it by fixing the UI cosmetically and fixed an obvious bug with the patch. The earnings/rating calculation code was completely written by FooBar.
---------------------
Edit: March 6 - Added links to three of the four patches.
-
Ahh, Very nice FooBar.
I am looking foward to these, perhaps to be placed on SST :P
-
The latest SVN code renders your decon protection obsolete(g_markDeconstruct).
NewbieNaming is obsolete because I think the latest SVN forces UnnamedPlayers to choose a name at the server connection screen(at least on our }MG{ servers).
-
I'm pretty sure that the latest svn doesn't have this forced-naming thing you're talking about. Most likely it's a custom thing on your server. You'd be surprised how much custom stuff is floating around that never even goes into Bugzilla, let alone SVN.
Decon protect isn't obsolete, it will just have to be tweaked a little bit. Why? Correct me if I'm wrong, but even with g_markDeconstruct a player can still decon the reactor in one place and remake it somewhere useless. Decon protection makes sure that any potentially catastrophic move has the support of the team. It will be fairly straightforward to tweak it for g_markDeconstruct.
Personally, even if no one wants their patches in Bugzilla I would love to see some kind of patch repository (yes, I know about this one (http://wraths.dyndns.org/downloads/code/patches/)) where admins and hobby-coders can put up any clever coding they've done, whether they think it's good enough for bugzilla or not. Hmm... kind of like this forum....
-
NewbieNaming is obsolete because I think the latest SVN forces UnnamedPlayers to choose a name at the server connection screen(at least on our }MG{ servers).
actually i stole that code from r1ch, not svn, and it forces them to choose ea name before joining a team. in 1.2 there will be a menu similar to ET's the first time trem is run, that asks you to choose a name (and it defaults to your username on *nix systems).
-
Can you release the patch soon :) ? More ppl testing help you to debug faster XD
-
Send it to Risujin, so he can add it to his melting pot. Antidecon sounds more like a g_markdeconstruct and vote hybrid, and i dont know how much i will like the vote, but others might. As for the noob naming, i have wanted this for a long time. Finally, the worth sounds interesting, but a little over complicated. I think that retribution should just work like what TJW coded up for ETPub
-
I added a link to the Newbie-Naming patch. There's a small bug with the Newbie-Naming patch but it won't be noticable unless you run a pure server with custom client qvms.
I'm going to wait until the weekend to post the other patches so I can revise them. I have a really busy week this week, and it looks like there are some changes I'll need to make to these patches based on feedback, and I won't have time until the weekend.
I'm going to revise AntiDecon to work within g_markDeconstruct. Basically all it will do is add a 10-second vote when someone tries to move the Reactor/OM. I think I will add Martin Doucha's team vote patch (https://bugzilla.icculus.org/attachment.cgi?id=1075) from bug 2867 (https://bugzilla.icculus.org/show_bug.cgi?id=2867) to my patch, so that team votes will work with the standard F1/F2 keys when there's no global vote going on.
RatingSystem is not part of Retribution. They are entirely separate. The "rating" is simply intended to rate how "good" a player is, or how much they're helping their team. It's just a number to display on the screen that gives a better idea of a player's skill than the "kills" column. It will get more complicated, not less, because I would like to include points for structures built/deconned/destroyed, and other things.
Eventually I want it to be good enough that players can forget about where the number comes from and just assume that it's usually a fair ranking of skill or at least good team play. Obviously any rating system will have flaws -- I just wanted to make a system with fewer flaws than the "kills" system. But I kept the kills column because people like it. :)
-
lol
-
Great work! Can't wait to get my hands on your patches. 8)
-
Great work! Can't wait to get my dirty hands on your patches. 8)
-
Okay, I've added links to all patches except the Anti-Decon patch, which is undergoing revision. I expect the Rating system will also be changed fairly soon.
Any coders here who are working on patches or mods should consider contributing to the Patch Tracker (http://www.mercenariesguild.net/patches/) hosted by the Mercenaries' Guild. Thanks to khalsa for setting that up!
-
(world) (4/25) * 1.00 = 0.16 points (unawarded)
Player A : - (5/25) * 1.00 = -0.20 points
Player H1 : +(10/25) * 1.00 = +0.40 points
Player H2 : + (6/25) * 1.00 = +0.24 points
---------- ------------
Player D : = -0.64 points (total awarded to enemies)
Hm. I think it would be best to give player D -0.44 points (i.e. factor in the teamdamage) not because of any equality reasons but because without doing that you get a net loss in rating across both teams. Factoring in teamdamage will ensure that rating numbers always centre around 0 as any points lost by one player are gained by another, which, in my opinion, would result in a more logical system.
-
Nice idea. I'm working on the next version now, and I'll see what I can do. One thing to take into account: I'll be adding functionality to give scoring based on buildable-related events. So this will probably not end up being a zero-sum system anyway. :)