Photon Plugins Manual

With Photon 4 plugins are introduced as the new way to extend the Game/Room behavior replacing what in Photon 3 used to be done through inheritance.

For best practices and frequently asked questions see the Photon Plugins FAQ.

Introduction

Over the years Photon Loadbalancing has evolved as a platform for room based games in both environments "as-is" (no server side custom code) in the cloud and self-hosted extended with custom behavior.
And although the feature set over the years has been changing the core flow between client and server (operations create game, join, leave, etc. and their events) has remained remarkably stable - allowing to keep backwards compatibility.

Customizing up to Photon 3 was based on the source code (Lite & Loadbalancing) and typically inheriting from the Game class.
This was flexible but somewhat brittle / more complex in development since the flow between Client, GameServer and Master could break unexpectedly, for example a client getting "stuck" waiting for a response or an event.

The Plugin API has been designed close to the core flow (create room, join, leave, etc.)

1. keeping a high degree of flexibility: allowing to hook into the core flow before and after its processing.
2. minimizing chances to break the flow: failing fast providing errors on client and server.
3. allowing to use lock free code: plugin instances will never get more than one call at the time and the framework provides a HTTP client and timers integrated in the underlying Photon message passing architecture (fibers).
4. lowering complexity and increasing ease of use: see "Minimal Plugin".

Concept

To add custom server logic, you inject your code into predefined Photon server hooks.
Currently Photon server supports GameServer plugins only as hooks are triggered by room events.

By definition, a Photon plugin has a unique name and implements those event callbacks.
Custom plugins are compiled into a DLL file called plugins assembly.
Then, the required files are "deployed" on your Photon server or uploaded to your Enterprise Cloud.

The configured plugins assembly is dynamically loaded at runtime with each room creation.
A plugin instance is then created based on a factory pattern.

The room which triggers the plugin creation is called the "host" game.
The latter can be directly accessed from plugins and they both share the same lifecycle.

Webhooks is a good example of Photon plugins.
Source code of Webhooks 1.2 is available in the plugins SDK.
We encourage you to dig into it.

Basic Flow

The Photon hooking mechanism relies on a 6 steps flow:

1. Intercept the hook call
   When the callback is triggered, the host transfers control to the plugin.
2. [optional] Alter call info
   Access and modify request sent by client/server, before it is processed.
3. [optional] Inject custom code
   Interact with the host before processing call (e.g. issue HTTP request, query room/actor, set timer, etc.)
4. Process hook call
   Decide how and process the request (see "ICallInfo Processing Methods")
5. [optional] Inject custom code
   Once processed, the request sent by client/server is useful "as read-only".
   However, plugin can still interact with host even after processing.
6. Return
   Plugin returns control to host.

Getting Started

Minimal Plugin

The Plugin

The recommended and easy way of making plugins is to extend PluginBase class instead of implementing all IGamePlugin methods directly.
Then you can override just the ones you need.

To obtain a minimal plugin implementation, you only need to override the PluginBase.Name property. It is what identifies a plugin.

C#

namespace MyCompany.MyProject.HivePlugin
{
  public class CustomPlugin : PluginBase
  {
    public override string Name
    {
        get
        {
            return "CustomPlugin"; // anything other than "Default" or "ErrorPlugin"
        }
    }
  }
} 

The Factory

A plugin factory class is expected to be implemented as part of the plugins assembly.
It is responsible for the creation of a plugin instance per room.
For the sake of simplicity, in the following snippet the factory returns an instance of CustomPlugin by default without checking the plugin name requested by client.

The room which triggers plugin instantiation is passed as a IPluginHost parameter to the IPluginFactory.Create method.
The same parameter should be passed to the IGamePlugin.SetupInstance in order to keep a reference to the game inside the plugin itself.
IPluginHost provides access to the room data and operations.

C#

namespace MyCompany.MyProject.HivePlugin
{
  public class PluginFactory : IPluginFactory
  {
    public IGamePlugin Create(
          IPluginHost gameHost,
          string pluginName, // name of plugin requested by client
          Dictionary<string, string> config, // plugin settings
          out string errorMsg)
    {
        var plugin = new CustomPlugin();
        if (plugin.SetupInstance(gameHost, config, out errorMsg))
        {
            return plugin;
        }
        return null;
    }
  }
} 

Configuration

Enterprise Cloud

To add a new plugin:

1. Go to the dashboard of one of the supported Photon product types.
2. Go to the management page of one of the Photon applications listed there.
3. Click on the "Create a new Plugin" button on bottom of the page.
4. Configure the plugin by adding key/value entries of type string.
   Configuration is done by defining key/value pairs of strings.
   The maximum length allowed for each string is 256 characters. The required settings are:

• AssemblyName: Full name of the DLL file uploaded containing the plugins.
• Version: Version of the plugins. The same version string used or returned when uploading the plugins' files using the PowerShell script provided by Exit Games.
• Path: Path to the assembly file. It should have the following format: "{customerName}\{pluginName}".
• Type: Full name of the PluginFactory class to be used. It has the following format: "{plugins namespace}.{pluginfactory class name}".

On-Premises

Add or modify the following XML node in the "Photon.LoadBalancing.dll.config" file of your GameServer application ("deploy\LoadBalancing\GameServer\bin\Photon.LoadBalancing.dll.config").
The default attributes of <Plugin.../> element are presented in the example below.
Only "Version" is not required.
You can add other optional configuration key/value pairs that are passed to the plugin code.
You can easily activate or deactivate plugins by changing Enabled attribute value in <PluginSettings> element.

XML

<PluginSettings Enabled="true">
    <Plugins>
      <Plugin
          Name="{pluginName}"
          Version="{pluginVersion}"
          AssemblyName="{pluginDllFileName}.dll"
          Type="{pluginNameSpace}.{pluginFactoryClassName}"
      />
    </Plugins>
 </PluginSettings>

The plugins DLL, its dependencies and other files required by the build must be placed in the folder "deploy\plugins\{pluginName}\{pluginVersion}\bin\" according to the configured value of plugin name.

At least these two files should there:

• "deploy\plugins\{pluginName}\{pluginVersion}\bin\{pluginDllFileName}.dll"
• "deploy\plugins\{pluginName}\{pluginVersion}\bin\PhotonHivePlugin.dll"

If the "Version" configuration key is not used or its value is kept empty, the path will be "deploy\plugins\{pluginName}\\bin\".
And since "\\" is treated as "\" the expected path is "deploy\plugins\{pluginName}\bin\".

So at least these two files should there:

• "deploy\plugins\{pluginName}\bin\{pluginDllFileName}.dll"
• "deploy\plugins\{pluginName}\bin\PhotonHivePlugin.dll"

Plugin Factory

Our plugin model uses a factory design pattern. Plugins are instantiated by name on demand.

A single Photon plugins assembly may contain multiple plugin classes and one active "PluginFactory".
Although it is possible, there is no particular use of making more than one "PluginFactory".
On the contrary, writing multiple plugin classes can be very useful.
For instance, you can have a plugin per game type (or mode or difficulty, etc.).
The factory could also be used to server mutliple plugin versions. Read more about this use case.

Client creates rooms requesting a plugin setup using roomOptions.Plugins.
roomOptions.Plugins is of type string[] where the first string (roomOptions.Plugins[0]) should be a plugin name that will be passed to the factory.

Examples:
roomOptions.Plugins = new string[] { "NameOfYourPlugin" };
or
roomOptions.Plugins = new string[] { "NameOfOtherPlugin" };

If the client doesn't send anything, the server will either use the default (when nothing is configured) or whatever the plugin factory returns on create if it is configured.

In the factory just use the name to load the corresponding plugin as follows:

C#

public class PluginFactory : IPluginFactory 
{
    public IGamePlugin Create(IPluginHost gameHost, string pluginName, Dictionary<string, string> config, out string errorMsg) 
    {
        PluginBase plugin = new DefaultPlugin(); // default
        switch(pluginName)
        { 
            case "Default":
                // name not allowed, throw error
            break;
            case "NameOfYourPlugin":
                plugin = new NameOfYourPlugin();
            break;
            case "NameOfOtherPlugin":
                plugin = new NameOfOtherPlugin();
            break;
            default:
                //plugin = new DefaultPlugin();
            break;
        }
        if (plugin.SetupInstance(gameHost, config, out errorMsg)) 
        {
            return plugin;
        }
        return null;
    }
}

ICallInfo Processing Methods

The idea of the plugin is that you hook into the "normal" Photon flow before or after the server processes the incoming request.
The developer needs to decide what to do using one of the 4 available methods depending on the request type:

1. Continue(): Used to resume the default Photon processing.
2. Cancel(): Used to silently cancel processing, i.e. without any error or other notification to the clients.
   It is equivalent to skipping further processing:
   • Called inside OnRaiseEvent will ignore the incoming event.
   • Called inside BeforeSetProperties will cancel properties change.
3. Fail(string msg, Dictionary<byte,object> errorData): Used to cancel further processing returning an error response to client.
   From client, you can get msg parameter in OperationResponse.DebugMessage and errorData in OperationResponse.Parameters.
4. Defer(): Photon expects that one of the processing methods is called before control is returned.
   This method is used to defer processing. It can be used to allow continuing at a later point in time,
   e.g. in a callback of a timer or when making an asynchronous HTTP request. Read more about this use case in Outbound HTTP section.

Notes:

• Plugins should have strict mode enabled by default (UseStrictMode = true).
  Strict mode means that a call to one of the ICallInfo processing methods is expected in each plugin callback.
  Not calling any of the available methods will throw an exception.
  Read more here.
• All callbacks of the PluginBase implementation of IGamePlugin call {ICallInfo}.Continue().
• Continue(), Fail() and Cancel() are expected to be called only once. Calling any of them again throws an exception.
• Defer() and Cancel() can only be called inside OnRaiseEvent or BeforeSetProperties.
• All classes that implement ICallInfo expose the client's original operation request when available.
  You can get the operation code and parameters from the {ICallInfo}.OperationRequest (or Request) property.
• All classes that implement ICallInfo include helper properties to inform you of the processing CallStatus of the operation request:
  • IsNew: Indicates if the request was not processed nor deferred.
  • IsProcessed: Indicates if the request has already been processed (i.e. Continue or Cancel or Fail method was called).
  • IsSucceeded: Indicates if the request was successfully processed (i.e. Continue method was called).
  • IsCanceled: Indicates if the request was canceled (i.e. Cancel method was called).
  • IsDeferred: Indicates if the request is deferred (i.e. Defer method was called).
  • IsFailed: Indicates if the request "has failed" (i.e. Fail method was called).

Plugin Callbacks

Photon Server has 9 predefined hooks. You don't need to explicitly register for those hooks in the code.
By default, any plugin class can intercept all 9 events.
However, you should implement the ones you need. We recommend extending PluginBase and overriding the required callbacks.

All core event callbacks have a specific ICallInfo contract.
Most callbacks are directly triggered by client actions.
The operation request sent by the client is provided in ICallInfo.Request where available.

OnCreateGame(ICreateGameCallInfo info)

Precondition: client called OpCreateRoom or OpJoinOrCreateRoom or OpJoinRoom and room cannot be found in Photon Servers memory.

• Notes:
  • Before processing request, the room state is not initialized and contains default values.
    This is the only situation where the room state can be loaded from external source, parsed and assigned to the room by calling IPluginHost.SetGameState.
  • Before processing request, any call to PluginHost.SetProperties or PluginHost.BroadcastEvent will be ignored.
  • You can use ICreateGameCallInfo.IsJoin and ICreateGameCallInfo.CreateIfNotExists to know the type of the operation request.

BeforeJoin(IBeforeJoinGameCallInfo info)

Precondition:
client called OpJoinRoom or OpJoinOrCreateRoom or OpJoinRandomRoom and room is in Photon Servers memory.

• Notes:
  • Before processing the IBeforeJoinGameCallInfo, if you call PluginHost.BroadcastEvent do not expect the joining actor to receive the event unless you cache it.

OnJoin(IJoinGameCallInfo info)

Precondition: IBeforeJoinGameCallInfo.Continue() is called in BeforeJoin.

OnLeave(ILeaveGameCallInfo info)

Precondition: client called OpLeave, peer disconnects or PlayerTTL elapses. (see Actors life cycle).

• Notes:
  • PlayerTTL can be set during room creation.
  • If you call PluginHost.BroadcastEvent do not expect the leaving actor to receive the event.

OnRaiseEvent(IRaiseEventCallInfo info)

Precondition: client calls OpRaiseEvent.

• Notes:
  • If the IRaiseEventCallInfo is successfully processed, no operation response is sent back to the client.

BeforeSetProperties(IBeforeSetPropertiesCallInfo info)

Precondition: client calls OpSetProperties.

• Notes:
  • In order to know if the properties to be changed belong to the room or to an actor, you can check the value of IBeforeSetPropertiesCallInfo.Request.ActorNumber.
    If it's 0 than the room's properties are about to be updated. Otherwise it's the target actor number whose properties need to be updated.
  • Be careful not to mix the previously mentioned ActorNumber with IBeforeSetPropertiesCallInfo.ActorNr.
    The latter refers to the actor making the operation request.

Precondition: IBeforeSetPropertiesCallInfo.Continue() is called in BeforeSetProperties.

BeforeCloseGame(IBeforeCloseGameCallInfo info)

Precondition: all peers disconnected.

• Notes:
  • EmptyRoomTTL can be set by clients during room creation.
  • Any call to PluginHost.BroadcastEvent will be ignored unless it changes the room events cache.

Precondition: IBeforeCloseGameCallInfo.Continue() is called in BeforeCloseGame and the EmptyRoomTTL elapses.

• Notes:
  • Before processing the ICloseGameCallInfo, you can choose to save room state or lose it forever.
    In webhooks, this can be done when there is still at least one inactive actor in the room.

Advanced Concepts

Actors Life Cycle

Peer <-> Actor <-> Room

An actor is a player inside a room.
Once a player enters a room, either by creating or joining it, he/she will be represented by an actor.
The actor is defined first by its ActorNr then using UserId and NickName.
It can also have custom properties.
If the player enters the room for the first time, he/she will get an actor number inside that room that no other player can claim.
Also for each new player an actor will be added to the room's ActorsList.

If a player leaves the room for good, the respective actor will be removed from that list.
However, if the room options permit it, a player can leave a room and come back later.
The corresponding actor in this case will be marked inactive when the player leaves.
The timestamp of the event will be saved in DeactivationTime actor property.

You can limit the amount of time actors can stay inactive inside rooms.
This duration can be defined when creating rooms by setting the PlayerTTL option to the value needed in milliseconds.
If the value is negative or equal to maximum int value, actors can stay inactive indefinitely.
Otherwise, inactive actors will be removed from the room once PlayerTTL is elapsed after their DeactivationTime.
The player can rejoin the room until then.
And if he/she decides to temporarily leave the room again, a new DeactivationTime will be calculated and countdown will be reset.
So there is no restriction on the number of rejoins.

Photon plugins SDK offers a way to get all actors at any given moment using one of the following properties:

• IPluginHost.GameActors contains all actors inside a room (active and inactive).
• IPluginHost.GameActorsActive contains all actors currently joined to the room.
• IPluginHost.GameActorsInActive contains all actors who left the room (without abandoning).

Sending Events From Plugins

You can send custom events inside the room using the Photon plugins SDK.
Custom events' type and content should be defined by their codes.
Your event codes should stay below 200.

There are two overload methods for this.
Although the name BroadcastEvent suggests that events will be broadcasted,
you can do a multicast based on filters or even send to a single actor:

• Send to a group of actors:

C#

void IPluginHost.BroadcastEvent(byte target, int senderActor, byte targetGroup, byte evCode, Dictionary<byte, object> data, byte cacheOp, SendParameters sendParameters = null);

You can set the target argument to the following values:

• 0 (ReciverGroup.All): all active actors.
  targetGroup parameter is ignored.
• 1 (ReciverGroup.Others): all active actors except the actor with actor number equal to senderActor.
  targetGroup parameter is ignored.
  If senderActor is equal to 0, the behaviour is equivalent to the one where target is set to 0 (ReciverGroup.All).
• 2 (ReciverGroup.Group): only active actors subscribed to the interest group specified using targetGroup argument.

• Send to a specific list of actors using their actor numbers:

C#

void IPluginHost.BroadcastEvent(IList<int> recieverActors, int senderActor, byte evCode, Dictionary<byte, object> data, byte cacheOp, SendParameters sendParameters = null);

It is also possible to use either methods to update room events cache.
You can define the caching option using the cacheOp parameter.
Read more about "Photon Events Caching".

And since Photon events require an actor number as the origin of the event (sender), you have two options:

• Impersonate an actor: set the senderActor argument to an actor number of an actor joined to the room (must be an active actor).
• Send an "authoritative" or "global" room event: set the senderActor argument to 0.
  Since the actor number 0 is never assigned to a player.
  So it may be used to indicate that the event origin is not a client.

If you choose to extend your plugin class from PluginBase, which is what we recommend, you may want to use the following helper method to broadcast event to all actors joined in the room:

C#

protected void BroadcastEvent(byte code, Dictionary<byte, object> data)

public void RaiseEvent(byte eventCode, object eventData, 
    byte receiverGroup = ReciverGroup.All, 
    int senderActorNumber = 0, 
    byte cachingOption = CacheOperations.DoNotCache, 
    byte interestGroup = 0, 
    SendParameters sendParams = default(SendParameters))
{
    Dictionary<byte, object> parameters = new Dictionary<byte, object>();
    parameters.Add(245, eventData);
    parameters.Add(254, senderActorNumber);
    PluginHost.BroadcastEvent(receiverGroup, senderActorNumber, interestGroup, eventCode, parameters, cachingOption, sendParams);
}

public void RaiseEvent(byte eventCode, object eventData, IList<int> targetActorsNumbers, 
    int senderActorNumber = 0, 
    byte cachingOption = CacheOperations.DoNotCache, 
    SendParameters sendParams = default(SendParameters))
{
    Dictionary<byte, object> parameters = new Dictionary<byte, object>();
    parameters.Add(245, eventData);
    parameters.Add(254, senderActorNumber);
    PluginHost.BroadcastEvent(targetActorsNumbers, senderActorNumber, eventCode, parameters, cachingOption, sendParams);
}
```</div>

<a id="http"></a>
### Outbound HTTP Calls

`HttpRequest` is a helper class to construct HTTP requests. 
Using this class, you can set the URL and the HTTP method (default is "GET"), the required `Accept` and `ContentType` headers. 
The values of these properties should be supported by [HttpWebRequest](https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(v=vs.110).aspx).
Additionally, you can specify other custom HTTP headers as a `IDictionary<string, string>` and assign it to `HttpRequest.CustomHeaders`.
You may also add request data by converting it into a `MemoryStream` object first then assigning it to `HttpRequest.DataStream`.
See the [Post JSON](#json) example for more information on how to do this.

<div class="alert alert-info">
What's worth noting, is that there are two properties that are exclusive to Photon and important in the plugins logic:  
<ul>
<li> <code>Async</code>: a flag that indicates if the normal processing of the room logic should be interrupted until the response is received or not. 
This should be set to false if the room logic depends on the HTTP response. 
<li> <code>UserState</code>: an object that will be saved by Photon Server for each request and sent back in the response's callback. 
One example use case is to store the deferred <code>ICallInfo</code> (in <code>OnRaiseEvent</code> or <code>BeforeSetProperties</code>) to be able process it later (call <code>Continue()</code>).
</ul>
</div>

The `HttpRequest` class also should hold reference to the response callback which should have the following signature:
`public delegate void HttpRequestCallback(IHttpResponse response, object userState)`.

Once the request object is setup, you can send it by calling `IPluginHost.HttpRequest(HttpRequest request)`.

#### Use Case Examples:

**Example: making use of Defer and Async in OnRaiseEvent**

In this basic example we demonstrate how to delay `RaiseEvent` operation process until a HTTP response is received.
First we should send the HTTP request in `OnRaiseEvent` callback and then defer the `ICallInfo`.


```csharp
public override void OnRaiseEvent(IRaiseEventCallInfo info) 
{
    HttpRequest request = new HttpRequest() 
    {
        Callback = OnHttpResponse,
        Url = "https://requestb.in/<token>", // change URL
        Async = !WebFlags.ShouldSendSync(info.Request.WebFlags),
        UserState = info
    };
    // here you can modify the request to suit your needs
    PluginHost.HttpRequest(request);
    info.Defer();
}

private void OnHttpResponse(IHttpResponse response, object userState) 
{
    ICallInfo info = userState as ICallInfo;
    // here you can make an extra check to resume or cancel the RaiseEvent operation
    if (info.IsDeferred) 
    {
        info.Continue();
    }
}

void PostJson(string url, HttpRequestCallback callback, string json) 
{
    var stream = new MemoryStream();
    var data = Encoding.UTF8.GetBytes(json);
    stream.Write(data, 0, data.Length);
    HttpRequest request = new HttpRequest() 
    {
        Callback = callback,
        Url = url,
        DataStream = stream,
        Method = "POST",
        ContentType = "application/json"
    };
    // here you can modify the request to suit your needs
    PluginHost.HttpRequest(request);
}

void HttpGet(string url, HttpRequestCallback callback, Dictionary<string, object> getParams) 
{
    StringBuilder sb = new StringBuilder();
    sb.AppendFormat("{0}?", url);
    foreach(var p in getParams)
    {
        sb.AppendFormat("{0}={1}&", p.Key, p.Value);
    }
    HttpRequest request = new HttpRequest() 
    {
        Callback = callback,
        Url = sb.ToString().TrimEnd('&'),
        Method = "GET"
    };
    // here you can modify the request to suit your needs
    PluginHost.HttpRequest(request);
} 

private void OnHttpResponse(IHttpResponse response, object userState) 
{
    switch(response.Status)
    {
        case HttpRequestQueueResult.Success:
            // on success logic
            break;
        case HttpRequestQueueResult.Error:
            if (response.HttpCode <= 0) 
            {
                PluginHost.BroadcastErrorInfoEvent(
                    string.Format("Error on web service level: WebExceptionStatus={0} Reason={1}", 
                    (WebExceptionStatus)response.WebStatus, response.Reason));
            } 
            else 
            {
                PluginHost.BroadcastErrorInfoEvent(
                    string.Format("Error on endpoint level: HttpCode={0} Reason={1}", 
                    response.HttpCode, response.Reason));
            }
            break;
        default:
            PluginHost.BroadcastErrorInfoEvent(
                string.Format("Error on HttpQueue level: {0}", response.Status));
            break;
    }
}

public override void BeforeSetProperties(IBeforeSetPropertiesCallInfo info)
{
    PluginHost.CreateOneTimeTimer(
                () => info.Continue(), 
                1000);
    info.Defer();
}

private object timer;
public override void OnCreateGame(ICreateGameCallInfo info)
{
    info.Continue();
    timer = PluginHost.CreateTimer(
                ScheduledEvent,
                1000,
                2000);
}
private void ScheduledEvent()
{
    BroadcastEvent(1, new Dictionary<byte, string>() { { (byte)245, "Time is up" } });
}
public override void BeforeCloseGame(IBeforeCloseGameCallInfo info)
{
    PluginHost.StopTimer(timer);
    info.Continue();
}

bool IPluginHost.TryRegisterType(Type type, byte typeCode, Func<object, byte[]> serializeFunction, Func<byte[], object> deserializeFunction);

class CustomPluginType
{
    public int intField;
    public byte byteField;
    public string stringField;
}

private byte[] SerializeCustomPluginType(object o)
{
    CustomPluginType customObject = o as CustomPluginType;
    if (customObject == null) { return null; }
    using (var s = new MemoryStream())
    {
        using (var bw = new BinaryWriter(s))
        {
            bw.Write(customObject.intField);
            bw.Write(customObject.byteField);
            bw.Write(customObject.stringField);
            return s.ToArray();
        }
    }
}

private object DeserializeCustomPluginType(byte[] bytes)
{
    CustomPluginType customObject = new CustomPluginType();
    using (var s = new MemoryStream(bytes))
    {
        using (var br = new BinaryReader(s))
        {
            customObject.intField = br.ReadInt32();
            customObject.byteField = br.ReadByte();
            customObject.stringField = br.ReadString();
        }
    }
    return customobject;
}

public override bool SetupInstance(IPluginHost host, Dictionary<string, string> config, out string errorMsg)
{
    host.TryRegisterType(typeof(CustomPluginType), 1, 
        SerializeCustomPluginType, 
        DeserializeCustomPluginType);
    return base.SetupInstance(host, config, out errorMsg);
}

<!-- "plugin" log file appender -->
<appender name="PluginLogFileAppender" type="log4net.Appender.RollingFileAppender">
    <file type="log4net.Util.PatternString" value="%property{Photon:ApplicationLogPath}\\Plugins.log" />
    <param name="AppendToFile" value="true" />
    <param name="MaxSizeRollBackups" value="20" />
    <param name="MaximumFileSize" value="10MB" />
    <param name="RollingStyle" value="Size" />
    <param name="LockingModel" type="log4net.Appender.FileAppender+MinimalLock" />
    <layout type="log4net.Layout.PatternLayout">
        <param name="ConversionPattern" value="%d [%t] %-5p %c - %m%n" />
    </layout>
</appender>
<!-- CUSTOM PLUGINS:  --> 
<logger name="Photon.Hive.HiveGame.HiveHostGame.Plugin" additivity="false">
    <level value="DEBUG" />
    <appender-ref ref="PluginLogFileAppender" />
</logger>