Agent

You can't just give it an arbitrary class and expect it to know what to do with it. That's why you must have a class that extends Rx_Mutator that replaces classes out for you. I'm sure nBab could post some examples from his mutator for Fort, but you're going to want to make use of Mutator's CheckReplacement() function.

How is that bloat? It would drastically simplify gameplay, remove the single most convoluted mechanic from the game, and remove much more from the code base than it would add. Dedicated defenders would no longer be nearly as critical. And that's half team participation if you want every door mined instantly. The base would actually probably get mined sooner than it currently does even with mines costing 250/300. And even then, not every door needs to be instantly mined and secured. It's perfectly fine for it to take a couple minutes.

Thanks!

Mines in the HoN floor are kind of cheesy and should be fixed, but they're really not worth moderating. Yes, I would say a glitched nuke is indeed "intentionally ruining other people's fun", and as freak pointed out they're against CT's rule set -- which I agree with. Server moderators should disarm glitched/undisarmable/invisible beacons and warn the player. That's a very proportionate response. However, a permanent ban for example would be a disproportionate response for any glitch. Glitches get fixed, they're temporary, and they're not an egregious form of cheating. Glitches can also occur unintentionally or unknowingly that it's considered a glitch. It'd be a bit unfair to kick someone or disarm all of their mines just because their mines fused into the HoN's mesh for example, if that wasn't their intention. It's also very difficult to prove many accusations of glitching unless somebody happens to be recording. It's extremely difficult to moderate glitching. That's part of why I prefer a lenient policy over a strict one any day.

It's a pretty minor exploit, and the beacon itself was still perfectly disarmable. He put it in a legal location, and how you get there is up to you. The beacon succeeded more-so because he successfully defended it, than it did because he used this minor exploit. I wouldn't get too salty over a minor exploit like that, though I did forward the post to @Havoc89 to see if he can fix it real quick. There is some merit in that he grabbed attention, even if it's not in the most elegant fashion. That's a much more severe exploit, as you're placing the beacon in a location that is in no way accessible.

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.