Download AntiRape
Special thanks to dehav and the international community for the ideas and help in seeing this mutator through. =)
################################################################################
AntiRape
readme.txt (Version 1)
(Last Modified - 03.24.07)
################################################################################
Thank you for downloading AntiRape. This README file contains information
regarding the installation and usage of AntiRape.
################################################################################
Table of Contents
################################################################################
1. About
1.1 Functionality
2. Installation
2.1 Server Installation
3. Configuration
3.1 BaseDeviceInclusionList
3.2 TeamPlayerMin
3.3 TimerInterval
4. Version Notes
4.1 Version 1
5. Contact Information
5.1 Comments, Questions, and Concerns
5.2 Donate
6. Warranty
7. Copyright
################################################################################
1. About
################################################################################
1.1 Functionality
AntiRape is a small mutator that checks the number players on each team during
timed intervals. If the number of players per team is less than a specified
minimum, all desired base assets will become invincible. That is, rape will be
disabled under these circumstances. Conversely, if the number of players per
team meets the specified minimum, rape will be enabled, and the base devices
will become susceptible to damage. AntiRape will broadcast a message anytime
rape has been enabled or disabled. This mutator disables itself in tournament
mode.
################################################################################
2. Installation
################################################################################
2.1 Server Installation
To install, first extract the AntiRape_v1.u and AntiRape.ini files to the
\Program\Bin\ folder of your server installation.
Open the appropriate server ini. This is typically
\Program\Bin\Beta_Dedicated_Server.ini.
Under the [Engine.GameEngine] section, add "ServerPackages=AntiRape_v1" to the
bottom of the ServerPackages list.
Save and close the appropriate server ini.
Open AntiRape.ini.
Configure AntiRape.ini to your liking. For a full explanation of the
configuration ini, please refer to the following section of this README.
Save and close the AntiRape.ini.
################################################################################
3. Configuration
################################################################################
3.1 BaseDeviceInclusionList
The list of base device classes affected by AntiRape. For example:
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseCatapult'
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseDeployableSpawn'
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseInventoryStation'
BaseDeviceInclusionList=Class'BaseObjectClasses.BasePowerGenerator'
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseResupply'
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseSensor'
BaseDeviceInclusionList=Class'BaseObjectClasses.BaseTurret'
3.2 TeamPlayerMin
The minimum number of players on a team before rape is enabled. For example:
TeamPlayerMin=6
3.3 TimerInterval
The number of seconds between each check verifying all teams' player count.
For example:
TimerInterval=30
################################################################################
4. Version Notes
################################################################################
4.1 Version 1
AntiRape released.
################################################################################
5. Contact Information
################################################################################
5.1 Comments, Questions, and Concerns
If you have any questions, comments, or concerns, feel free to drop me a message
at rapher@rapher.net. Granted, I may not always respond promptly, but I will do
my best to address any mail that is sent my way. Alternatively, you can visit my
website at http://www.rapher.net/ for the most up to date information.
5.2 Donate
If you appreciate my work or would like to show your support, donations are
graciously accepted. Donations may be sent via PayPal to rapher@rapher.net.
################################################################################
6. Warranty
################################################################################
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
IN NO EVENT WILL THE AUTHOR BE HELD LIABLE FOR ANY DAMAGES ARISING FROM THE USE
OF THIS SOFTWARE.
################################################################################
7. Copyright
################################################################################
Copyright (c) 2006 Chase "rapher" Sensky
Download PingControl
################################################################################
PingControl
readme.txt (Version 1)
(Last Modified - 03.24.07)
################################################################################
Thank you for downloading PingControl. This README file contains information
regarding the installation and usage of PingControl.
################################################################################
Table of Contents
################################################################################
1. About
1.1 Functionality
2. Installation
2.1 Server Installation
3. Configuration
3.1 MinPing
3.2 MaxPing
3.3 TimerInterval
4. Version Notes
4.1 Version 1
5. Contact Information
5.1 Comments, Questions, and Concerns
5.2 Donate
6. Warranty
7. Copyright
################################################################################
1. About
################################################################################
1.1 Functionality
PingControl is a small mutator that checks each player's ping during timed
intervals. If a player's ping falls above or below a set range, the player will
be warned that their connection does not coincide with server specifications.
If the player's ping does not adjust to the acceptable range during the
subsequent check, this player will be removed from the server. This mutator
disables itself in tournament mode.
################################################################################
2. Installation
################################################################################
2.1 Server Installation
To install, first extract the PingControl_v1.u and PingControl.ini files to the
\Program\Bin\ folder of your server installation.
Open the appropriate server ini. This is typically
\Program\Bin\Beta_Dedicated_Server.ini.
Under the [Engine.GameEngine] section, add "ServerPackages=PingControl_v1" to the
bottom of the ServerPackages list.
Save and close the appropriate server ini.
Open PingControl.ini.
Configure PingControl.ini to your liking. For a full explanation of the
configuration ini, please refer to the following section of this README.
Save and close the PingControl.ini.
################################################################################
3. Configuration
################################################################################
3.1 MinPing
The minimum acceptable player ping. For example:
MinPing=0
3.2 MaxPing
The maximum acceptable player ping. For example:
MaxPing=300
3.3 TimerInterval
The number of seconds between each check verifying each player's ping.
For example:
TimerInterval=30
################################################################################
4. Version Notes
################################################################################
4.1 Version 1
PingControl released.
################################################################################
5. Contact Information
################################################################################
5.1 Comments, Questions, and Concerns
If you have any questions, comments, or concerns, feel free to drop me a message
at rapher@rapher.net. Granted, I may not always respond promptly, but I will do
my best to address any mail that is sent my way. Alternatively, you can visit my
website at http://www.rapher.net/ for the most up to date information.
5.2 Donate
If you appreciate my work or would like to show your support, donations are
graciously accepted. Donations may be sent via PayPal to rapher@rapher.net.
################################################################################
6. Warranty
################################################################################
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
IN NO EVENT WILL THE AUTHOR BE HELD LIABLE FOR ANY DAMAGES ARISING FROM THE USE
OF THIS SOFTWARE.
################################################################################
7. Copyright
################################################################################
Copyright (c) 2006 Chase "rapher" Sensky
If you read my previous blog, you'll know that I have no intentions of working on vanilla further. As such, I've decided to release the (albeit simple) source code. You may download the code from the link below:
http://www.rapher.net/tv/vanilla_b1_src.zip
I hope someone can put it to good use. =)
-Chase "rapher" Sensky
It would seem to me that there has been a rather impressive resurgence in the Tribes: Vengeance community. Whether this means that more players are actively playing or players are just getting more involved, I simply do no know. Either way, I’m glad to see some interesting discussion resulting from it. With that said, a lot of this discussion has focused on compmod and the various changes it implements. As to be expected, vanilla has been thrown into the mix, with various discussions on weapons, physics, vehicles, and other fine details. A number of individuals have asked for my input on these matters, so I’d like to address these issues now.
As it stands, I actually think that Tribes: Vengeance is a relatively well put together game. There are some balance issues, granted, but nothing that requires a large quantity of changes. The whole intent with vanilla was to address a couple key issues, in a relatively simple or plain way. This is how vanilla obtained its name.
In my opinion, there existed a triad of issues, namely the shield pack, grappler, and vehicles. Did vanilla address these in the best manner possible? Of course not, but the changes were somewhat minimal, and easy to implement. It was a quick fix that did the job. Could it have used some refinement? I’m sure, but in all honesty, it wasn’t an issue I was concerned with. Sometimes balance involves making a decision and sticking with it.
Knowing this, there have been a number of mods with the intent to balance gameplay. I can’t help but feel the number one reason why none of these caught on was directly related to the fact that they bit off more than they could chew. How can you balance a game when you introduce a significant number of changes to nearly all aspects of the game? Balancing has to start extremely small and build in a systematic manner.
Furthermore, how can you balance a game (and why would you want to try), when very few people can actually agree on what balance is? Usually, balance is not obtained by listening to a community because the sample is too small, too large, or the balance shifts towards those that scream the loudest (which is not always indicative of majority). Most individuals are not concerned with honest balance, but rather, what suits their roles. Rarely will you find a heavy that doesn’t favor more resilience, a capper more grapples, and a chaser a weaker shield pack. With so much input and so many changes, how could such a mod ever be balanced?
I have no desire to work on such a thing. In regards to vanilla, it is what it is. I have no intentions of changing it, combining it, or pursuing a similar project further. I’m generally a busy person, and the last thing I want to do is spend my free time tweaking values and listening to people *** and moan. It’s not for me; I’d much rather work on some creative content.
Additionally, I feel inclined to say that I don’t think any significant changes this late in the game will contribute to the growth of a community. In particular, I have always felt changing physics would be a mistake. Moving from server to server having to adjust how you shoot, fly, or ski should never be an issue. It creates inconsistency, is confusing to players, and diminishes their ability to improve. For those that were asking me, I will not be changing any physics for any custom gametype. All new gametypes will function as stock Tribes: Vengeance. It will merely be the governing rules of play that change. By following this principle, stock players will be happy, and those desiring changes can run the gametype with a custom mutator.
So, in short, I have no intentions of making any changes to my gametype weapons, physics, vehicles, etc. I have no desire to pursue vanilla or any competition/balancing further. But, this is not to say I am totally against it. If someone wants to take a stab at it, more power to them. In fact, this may help. ;)
So, I guess the question remains; what am I still working on? Well, of course, I’ll continue to work on antics. In addition, I’ll be releasing a number of new gametypes, bug fixes, and a couple new surprises here and there. I’m excited, and you should be to!
-Chase "rapher" Sensky
Well, no, not quite.
If you read my previous blog regarding adding network particle effects to maps, you may have been inspired to create some custom effects of your own. However, if you try this, you’ll notice that these custom effects likely won’t work in a networked environment.
To correct this problem, be sure that the effect has the following properties:
bAlwaysRelevant=True
bGameRelevant=True
bNetInitialRotation=True
bNetTemporary=False
bNoDelete=True
This should enable the custom particle effect in a networked environment, empowering you to create your own effects far beyond the stock emitters provided with Tribes: Vengeance.
Thanks to Aereogramme for prompting me to look at this.
-Chase "rapher" Sensky
Recently, Aereogramme (mapper extraordinaire) approached me with a fairly interesting problem. It seems as though a number of Tribes mappers desired to add some fairly interesting particle effects to their maps, but could not seem to get these effects to work in a networked environment. I recall hearing of this issue once before, but never really thought much of it. Now curious of the issue at hand, I set out to solve this mystery.
After a bit of research, it became quite apparent that the problem was rather simple. In Tribes: Vengeance, all particle effects ultimately extend from the Emitter class. If one were to take a look at the default properties of this class, it would be easy to see that the RemoteRole of this class is ROLE_None. Essentially, this prevents any emitter actors from being replicated to the client.
So, now that we know the problem at hand, here is a solution that will enable mappers to add client side particle effects:
1.) Open TVEd and the appropriate map in which you would like to add the visual effects. For this example, I will be using MP-Arid.
2.) Open the actor browser. It is likely you will be adding effects from the FX.pkg, so go to File->Open Package… and select Content\Art\FX.pkg.
3.) For this example, I’m only concerned with effects in the FX.pkg, so I am only viewing actors of this package:
4.) Next, highlight the effect you would like to add. For this example, I will be using FX_Fire:
5.) Right click your visual effect and select New…
6.) Name your new class. Since this will be our replicated FX_Fire class, I’ve decided to name this FX_NetworkFire.
7.) Enter “MyLevel” for the package. This will embed your new class within the current level. Your new class should look something as follows:
8.) Click OK. If prompted, overwrite the existing MyLevel package.
9.) Select the myLevel package from the actor browser. You should see the newly created class:
10.) In the command line at the bottom left of TVEd, type in “editdefault class=FX_NetworkFire” where FX_NetworkFire is the name of the newly created class:
11.) Hit enter and the default properties for the class should appear. Locate the RemoteRole property and set it to ROLE_SimulatedProxy:
12.) Close the window. Your network particle effect may now be added to the map. Simply select the actor from the browser. Right click a viewport and select Add->Add FX_NetworkFire Here, where FX_NetworkFire is the name of your newly created class:
Here, you will see the result. Essentially, I added my FX_NetworkFire to the eye sockets of the dead creature on Arid:
UPDATE:
If you try adding custom effects to a map, you’ll notice that these emitters likely won’t work in a networked environment. To correct this problem, be sure that the effect has the following properties:
bAlwaysRelevant=True
bGameRelevant=True
bNetInitialRotation=True
bNetTemporary=False
bNoDelete=True
This should enable the custom particle effect in a networked environment, empowering you to create your own effects far beyond the stock emitters provided with Tribes: Vengeance.
Thanks to Aereogramme for prompting me to look at this.
I hope this was of some help!
-
Chase "rapher" Sensky