You may want to read some of the UnrealScript documentation before this. At least peruse the UnrealScript Language Reference. You can get more details on networking in the Networking & Replication documentation; I'm just going to go over a high-level overview of a few replication features that might hopefully help bring all of that Epic documentation together for you. Maybe.

Because of replication, it's crucial that you test most any gameplay-related change with a dedicated server. Just opening a map in Standalone mode is not the same thing. You should test with the dedicated server files, though you can test the game with client files like UDK.exe server AOCFFA-Arena3_p?adminpassword=testpassword

Roles

Every actor has a Role and a RemoteRole property, which have different values on the server and the client. The two values are auto-swapped on clients when the server replicates an actor to them. The roles:

ROLE_Authority – this instance of the game has authoritative control over this actor. This is generally the Role of every actor on a server, or on a client running in Standalone.
ROLE_SimulatedProxy – this actor is being simulated. This is true of most every actor on clients. This actor still runs physics in-between position updates from the server so it doesn't move jerkily, but otherwise it's fairly dumb. SimulatedProxy actors can only run events and functions with the simulated keyword in them.
ROLE_AutonomousProxy – special case for a player's Pawn and PlayerController on the player's client. There's some special logic handling movement for pawns that checks for this case, and these can enter non-simulated functions.
ROLE_None – you only see this on Remote Roles; it tells the game not to replicate this actor

An important thing to take away from this is the simulated keyword. You need that to run any functions on almost all actors on clients. If there's a function that clients need to run, stick simulated in front of it. Inside simulated functions, when you need to be sure you're on the server before doing something, check for Role == ROLE_Authority. There are plenty of examples of Chivalry doing this.

Function Replication

Function replication is easy. Stick a pair of keywords before a function, and when you execute it, it runs on another machine iff the actor exists on the other machine. If you're running in Standalone mode, it all runs on the same machine and just passes through.

<reliable/unreliable> <client/server> function DoSomething() { };

reliable – this keyword marks the function as reliable. Reliable functions must get through to the machine on the other end, and must do so in the order they were sent. If they don't make it through, they get resent.
unreliable – Unreliable functions don't have to get through; if there's packet loss, they may be lost. They also don't have to get through in the right order. Whenever possible, make replicated function unreliable
client – client functions get replicated to the owning client of the actor. Hence you only see us using it in Weapon, Pawn, and PlayerController-derived classes. These functions are not replicated to other clients. If you need something replicated to every client, you use variable replication (below)
server – server functions get replicated to the server. Simple enough. Be careful with these: each one is a hacking risk, as it's fairly trivial to download UE3 cheat tools (or create them using documentation that's out there) that can call any of these. You therefore can't trust that what you're getting is reasonable. You can, however, trust that you're getting it from the owning player. One player can't call another's AdminKick function, hence we just have a check inside AdminKick for whether the player is an admin before allowing the command to proceed.

We've found that server functions may be executed on the client, and client functions on the server, during map changes. This might only happen in functions called from Kismet, it's not clear. Hence, the Client-side Kismet support functions like ClientActivateServerToClientKismetBridge have a check for whether we're actually on the machine we expected, as these functions crash otherwise.

Variable replication

WIP

Things in the replication{} block (see AOCPawn) gets replicated using the conditions noted in the block. I don't know, look at AOCPawn, look at the documentation, it's fairly straight-forward. Make note of the repnotify keywork, which fires an event when a thing is replicated.

Variable replication is the typical way of running something or copying a variable to every client (the other way being calling a Client function on every PlayerController on the Server).

Kismet Replication

Kismet runs on the server unless you mark an event as "client-side only", in which case it runs on the client. If the Kismet needs to communicate between server and client somehow, and the nodes we want to use don't do that (or don't do it in the way we want; e.g. Matinees will run on the server and replicate the actor changes to every client, but replicating every changed property every frame or so can end up being pretty expensive for non-gameplay-relevant actors), there are some tools to fix that. See Client-side Kismet.