Kismet is usually run only on the server. This prevents issues where the server and client become out-of-sync and bad things happen. However, for non-gameplay-relevant Kismet, running the Kismet on the server sometimes causes noticeable performance issues. We noticed this with the ships in Hillside, as they use a number of matinees and effects that ended up tanking any server they were run on. Since those ships are purely cosmetic, there's no reason for the server to be involved with them in any way other than initially triggering them. Client-side Kismet allows LDs to run whatever Kismet they want solely on the client, directly giving them the ability to improve server performance while still doing all the Kismet magic they so love.

Client-side and server-side events

Normal client-side Kismet starts with a client-side event, in contrast to the server-side events that start server-side Kismet. You turn an event into a client-side event by clicking Client Side Only in the event's properties. However, only some events will even fire client-side. A client-side event fires from the client's side; if a thing happens on the server but not the clients, it won't trigger events on the clients (so Objective Completed events won't fire on clients for instance, since that's a purely server thing).

Here's an example:

Note that the Beginning of Level and Level Reset outputs are never fired on the client, since these things only happen on the server. 

Everything connected to this event is now running on the client, not on the server. It's specific to one player. There's no communication between server Kismet and client Kismet, so you can't expect any variables you set in server Kismet to be valid in client kismet.

Bridges

This is all well and good, but we have quite a bit of game state in our levels' Kismet, so we we'd like to be able to trigger client-side Kismet from server-side Kismet. For this, we now have a few new tools.

The above example uses a Client->Server Bridge node (found in the AOC Client/Server Comm. category) to start a matinee on every currently-connected player as soon as Level Reset fires on the server. Since everything to the right of the Bridge is running on clients and not on the server, clients who join after the bridge fires won't see the matinee as being underway. They won't see it playing at all. 

The Bridge passes through its output into the client-side Kismet of every currently-connected player, unless a player is explicitly passed to it in its variable link, like so:

This also demonstrates a new event: Player Login. This event fires on the server whenever a player joins the server. It only fires once for every player. This lets you do whatever you need to on the player's client before they've even spawned.

 You can also trigger Remote Events on clients. This node also optionally takes a player, or triggers on every currently-connected player. Remember to check Client Side Only on the Remote Event you want to trigger!

Finally, to pull this all together into something a little less contrived:

In this example, we start with a Signal Fire Extinguished event being shot off on the server. Once this happens, the Kismet shoots over a bridge to start playing a matinee on all the clients on the server. It also enables a player login event that shoots off a second bridge connected to the same matinee. This design pattern fixes the problem where players who join after a bridge fires won't see the result of the bridge (since they missed it), by firing the bridge individually for every new user.

Important notes

There are a few things to watch out for with client-side Kismet:

• Testing with PIE or in a client without a server is not the same as testing with a dedicated server. You need to test with a dedicated server. 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
• Try to keep the number of bridges fired to a minimum. Use one for every "happening" if you can; branch out once you've hit the Client, not while you're still on the Server (see second image below)
• Mixing client-side and server-side Kismet will make a mess which will lead to mistakes. Try to keep them at least somewhat separate
• Matinees will be playing at different points on every client, which is why only non-gameplay-relevant matinees should be handled client-side.
• Matinees should have their Client Side Only property checked if they're intended to be client-side only, even if they're not connected to any server-side events at all. This makes sure that connected Actors don't auto-replicate
• Variables set at runtime (during gameplay, not references you set ahead-of-time in the editor) in server-side Kismet will not be set in client-side Kismet. Remember that the two are running on completely different machines; there's no communication between the twoexcept when we do so explicitly, such as over bridge nodes
• Only some events will work as client-side-only events. Volume triggers ought to, since volumes exist on the client (*I should probably test this). Objective Complete events won't, since the gamemode runs on the server. That's why we have the Bridge.
• Once more, keep gameplay-relevant things on the server, don't use any client-side Kismet for them!

(There are also client-to-server bridges and events. Client-to-server bridges/events are not secure, you can assume hackers will trigger them if they want to so be extremely careful about using them for anything gameplay-relevant. Just assume that they can be triggered by anyone at any time, and treat them appropriately. Use the "Target" variable link to determine who fired the bridge; this variable itself should be trustable)