Namespace LlamaSoftware.Chat

Classes

AbstractPlayerDatabase<T>

Interface that defines all operations that are available on the database. Also provides singleton behavior. To swap databases you can create a new subclass of this class. Any subclasses must expose a PUBLIC constructor and subclass this class with your new class as a type parameter. This constructor will throw an exception if called. Always use the Instance property.

SQLitePlayerDatabase implements this for SQLite. Use it as a reference for your subclass.

AreaTriggeredChannelJoiner

Adds players that enter the Collider's trigger to the provided ChatChannel. This is the way to set up regional or dynamic chat channels. Any players entering this Collider will be automatically added to the channel. No players outside the collider will be able to see that chat. You can make these as large as small as you need (within the limits of Unity). Entire scenes could even be covered in this for complex multi-scene games.

BaseNetworkManager

Instead of using just NetworkManager, assign this as the NetworkManager to be used to ensure player cleanup is done properly. If you have your own custom network manager, you can extend this class as long as you call base.OnServerDisconnect(conn), or just add this code into your NetworkManager. Also make sure to assign ChatSystem in the inspector

ChatSystem

Handles all message dispatching. Local Chat Channel Physics checks, and server event messaging.

ChatSystemConstants

Container class for constants used throughout Llama Chat.

InMemoryPlayerDatabase

An In-Memory variant for the AbstractPlayerDatabase. This is useful when you have an external identity provider or external database that is hosted separately from the core game. Consider the following scenario: You have a game and an API layer that handles authentication where all user identites are stored. You do not want to host a new database for the chat system itself. In this case you would use this class and hydrate the InMemoryPlayerDatabase (which is only available on the server anyway) after API calls are made to figure out the user id and the player's channels, friends list, and block list.

To hydrate this class you simply add a player still with AddPlayer(). Instead of running queries to the database to figure out data, this keeps all player information in a Dictionary at runtime.

LlamaChatSettings

Settings ScriptableObject for Llama Chat.

LlamaChatSettingsProvider

Singleton class to provide LlamaChatSettings. Note the first call is made SYNCHRONOUSLY to provide you an instance as soon as you request it. You should preload the LlamaChatSettings by calling Instance.LlamaChatSettings to avoid hiccups.

Player_Chat

Local Player identifying script. Manages registering handlers, setting up scene references, overhead text, and the SocialUI if provided.

This should be attached to your root Player object in your game.

SQLitePlayerDatabase

Singleton. Interfaces for interacting with the database. Any SQL queries/updates should be made here. New functionality should be exposed via new functions here.

Maintains a list of currently online players and DB connection.