Agent

Over-moderation is far from desirable, and can destroy a game. In fact, I wouldn't even moderate base-to-base. CT's rules are more or less spot on though. It's a game -- as long as you're not intentionally trying to ruin other peoples' fun, you shouldn't find yourself kicked or banned from any server on any game. Many games/communities do very poorly in this area, or offer disproportionate responses to player activity (i.e: a ban when only a mute is necessary).

I don't think it's crazy for people to buy mines and place them when they walk past an unmined door. "Oh, this door needs mines. Let me just do that real quick." You don't have to "rely on 20 people" -- any remotely decent player who walks by an unmined door will likely think "oh, this door needs to be mined". Again, a team effort. You wouldn't require a dedicated defender constantly replacing mines anymore, because you wouldn't have to be a Hotwire or Technician. You wouldn't have to switch classes or wait on somebody else to take care of it.

That's exactly how mines used to be and it obviously never worked like that. Players will always demand that every mine is used as a improvised defense mechanism as long as there's a limit. Proximity C4 would become much more valuable when combined with a Hotwire/Technician, as you could then offensively mine the building you're infiltrating without worrying about over-mining. As it is, the proximity C4 on a Hotwire/Technician has no real value. There's nothing you really need to replace it with, because the class doesn't become any weaker. If anything, it's probably a buff to infiltrators. As far as costs go, I was thinking 250/300 for a pack of three. Base defense should be a team efforts, not an individual effort. If a team has 20 players and only half of them buy mines, you've already got 30 mines much earlier than you would otherwise. My biggest concern is definitely trying to make sure mines aren't too cheap, but also not too expensive.

Those are the guidelines for global moderation. Severe glitching might include things like "sniping from off the level", "getting an orca under the map", or "getting vehicles on the infantry path". The rest is left up to individual servers, though most things that aren't glitch nukes are okay. RenX doesn't really need much moderation, and I honestly think it's fine as it is. We're not really interested in heavily moderating servers globally, and it's extremely unlikely to be expanded.

"C'mon man, you got dis" "YEEEEEEEEEEEEAAAH-" "But watch out for the red guy" @Madkill40, these are absolutely great.

I'm glad my suggestion was taken seriously, and the PUG totally didn't consist purely of custom levels. I definitely didn't have to spend 2 hours downloading unnecessary gimmicks. My mood definitely didn't get soured long before I could join the game. Edit: After playing for a bit, the PUG was "eh" at best. There were far too many custom levels (as opposed to the original plan of 1), and my FPS was a whooping 15 on average on Reservoir (very pretty map btw).

I'm pretty sure this thread serves as evidence as to how broken Renegade's mine system is, and exposes the inherent flaws of having a weapon limited to an arbitrary number of team-wide uses. We're not doing a whitelist. That would be absurd. I also don't think the ability to disarm mines should be limited to the commander -- the commander isn't inherently special or more trustworthy than any other players, and this just creates more work for that player. If you're going to open up disarming team member's mines you have to give that ability to everybody on the team, not just one or two people. One way to mitigate the chances of malicious demining would be to have an EVA message similar to the current over-mining message. Again though, you're just wrapping a broken system with duct tape and band-aids and hoping it'll work. It won't. That's why I'm so insistent on making them a purchasable and disposable item -- it fixes the problems that proximity mines currently have, even if it requires a bit of balancing work.

You want a degree of randomness so that it's just the same 2 teams against eachother over and over again.

It should unload itself automatically.

It may also be possible to load a mutator through the level. To do such a thing, you would have to create a dumby Actor and then call AddMutator on your actual mutator class from PostBeginPlay, and place this dumby Actor somewhere in your level. Something along these lines: class MyMutatorLoader extends Actor; function PostBeginPlay() { WorldInfo.Game.AddMutator('MyPackage.MyMutator', false); } Then you just place MyMutatorLoader somewhere in your level.

The previous guides were written before the SDK was released, and consequently included extremely out-of-date information. So here's a new guide in hopes that someone might find it useful. Setup Before you can get started on creating any content, you will need to download the Software Development Kit from the Downloads section. Once the download is completed, extract the zip file to whatever location you prefer. With the SDK installed, the following steps will setup an extremely basic mutator that does nothing: Navigate to the SDK's /Development/Src/ directory, and create a folder named MyPackage (or whatever you want your mutator's package name to be). Create a directory named Classes in your new MyPackage directory. This is where all of your source files should go. Create an file named MyMutator.uc in MyPackage/Classes/. Write and save the following contents to MyMutator.uc: class MyMutator extends Rx_Mutator; Navigate to the SDK's /UDKGame/Config/ directory, and open DefaultEngineUDK.ini. Navigate to the UnrealEd.EditorEngine section in the file, and at the bottom of the section add: +ModEditPackages=MyPackage Now you need to compile your mutator. Simply create a compile.bat file, then write and save the following contents to it: start /Binaries/Win32/UDK.exe make Run compile.bat to compile your mutator. Some IDEs (such as the nFringe plugin for Visual Studio) allow you to compile directly inside of your editor. There is also compile scripts using /Binaries/UnrealFrontend.exe Your compiled mutator package will be named MyPackage.u, and can be found in /UDKGame/Script/. You're done! You've now created an extremely basic mutator that does absolutely nothing. To load your mutator, simply copy your MyPackage.u file to your game/server client's UDKGame/CookedPC directory, then add ?mutator=MyPackage.MyMutator when starting a server/match. For example in-game you might press F5 and type: open CNC-Field?mutator=MyPackage.MyMutator. On a server, you can add ?mutator=MyPackage.MyMutator to your server's batch script. If you have multiple mutators, simply add commas as necessary: ?mutator=MyPackage.MyMutator,MyPackage.MyOtherMutator,RenX_ExampleMutators.InfiniteAmmo You can have as many mutators in an individual package as you wish, but you have to load each one separately (as shown above) or create a mutator to load the other mutators automatically. Self Loading It is also possible to load a mutator directly inside of a level. To do such a thing, you would have to create a dumby Actor and then call AddMutator on your actual mutator class from PostBeginPlay, and place this dumby Actor somewhere in your level. For example: class MyMutatorLoader extends Actor; function PostBeginPlay() { WorldInfo.Game.AddMutator("MyPackage.MyMutator", false); } Then you just place MyMutatorLoader somewhere in your level. Notes Alright, now that initial setup is out of the way, you can actually start making your wonderful mutator. You can use the mutators located in your SDK's /Development/Src/RenX_ExampleMutators/Classes/ for references as to how to add some basic features such as giving every weapon infinite ammo or giving sniper rifles to Stealth Black Hands. There's also plenty of resources and references available for UnrealScript in general, and are extremely relevant when working on RenX, which I've included at the bottom of this post. You will also probably have to look at the classes in RenX_Game/Classes quite a bit for interacting with Renegade X specific content and systems. The 'Rx_Mutator' class differs from the 'UTMutator' class only in that it adds a function named 'InitRconCommands', which is called when RCON commands are first initialized. RCON commands are only initialized once, and that is during the initialization of the first level. RCON commands are persistent between levels. Be careful with that, because if there are any non-null Actors references in your command at the end of the level, your game/server WILL crash. Resources https://wiki.beyondunreal.com/ http://udn.epicgames.com/Three/UT3Mods.html#Mutators http://udn.epicgames.com/Three/GameplayProgrammingHome.html My favorite of the above references is the Unreal Wiki (wiki.beyondunreal.com).

It's actually not based on connection order by default anymore, though this is true for servers which seem to have manually set their TeamMode value to 4 (such as CT). The default behavior is to shuffle teams based on the results on the previous game. Sorting teams based on rank would be relatively easy, and I considered implementing it some time ago. That said, you would almost certainly want a certain value of randomness added to ranks, I think. It would also be beneficial to get around to implementing ladder points if we wanted to go that route, rather than just having cumulative score.

Fixed in upcoming patch.

It's probably best to stick to 1 custom level per week. This will help focus and generate feedback for one specific level per week, and also keep the PUGs sane.

Could always just remove mines belonging to a person when they're mind-banned. ...Or remove the mine limit and make them a purchasable item instead, so that team waste becomes personal waste instead.

You should probably remove that from the pack.

Try using an Officer. Both the Flame & Chem troopers are flak, and the officer is great against flak.

This is an engine bug which we can't/won't fix due to not having source-level access to the game engine. Blame Epic.

Did you rig the repair pad in UnrealScript already? You could look at the power plant, since I think it's the most basic of the buildings. May very well just add it to the game.

This is great.

There's issues beyond crashes with the launcher's downloader, including the fact that it's still strictly handled through an out-of-game application that not everybody uses. To switch from the Marathon server to the AOW server, a user has to exit their game client and start again. There's a reason I am still planning to replace this mechanism entirely (though I've admittedly been quite inactive lately). Also, Thommy's version of City is extremely poor and shouldn't at any point be considered a substitute for a proper finished version of City. Many assets required for City do not yet exist, and still need to be added. Adding his version of City will just leave a bad taste in people's mouths for those who have been long anticipating City, including myself.

If there aren't ramps to the roof, it's not intended for players to get to the roof.

That could open people up to team hampering more, as a malicious player could just toss remote c4 onto friendly vehicles. It would be relatively easy to just make them not stick to friendly vehicles/pawns, so that's an option.

Yet most levels don't have any base to base issues what-so-ever. But yeah, you can call in a moderator if it's against a server's rules. From what I can tell neither CT nor MPF have rules specifically against base to base posted anywhere, though one can argue that it's a level specific exploit. Again, it's mostly a level design issue and should be handled by fixing it in the level itself, rather than moderating it at the server level.