Mmo PhotonUnity3D client library source

dreamora
dreamora
edited May 2010 in DotNet
I wanted to ask if there are plans to add the code to the Unity3D Client Library (Photon.Modules.Mmo.PhotonUnity3D) to the distribution too?
At the time only the DotNet one is present, which due to dependence on .NET 3.0+ features can not be used


I think generally a larger amount of exposure of code is required on the Mmo side to make it a usable solution for flexible development.
Also some of functionality thats required to use it requires documentation. Especially the OperationResponse returnValues filling isn't explained anywhere (I personally expect this to use MethodReturnValue<T>.Ok(T), right? as the .Fail isn't an option with the lack of an exposed ReturnCode enum)

Comments

  • Boris
    Boris ✭✭
    Hi dreamora,
    dreamora wrote:
    I wanted to ask if there are plans to add the code to the Unity3D Client Library (Photon.Modules.Mmo.PhotonUnity3D) to the distribution too?
    At the time only the DotNet one is present, which due to dependence on .NET 3.0+ features can not be used
    It's the same code that you find in "Photon.Modules.Mmo.Client.PhotonDotNet", the only difference is that it's compiled with the unity3D client library.
    dreamora wrote:
    I think generally a larger amount of exposure of code is required on the Mmo side to make it a usable solution for flexible development.
    Also some of functionality thats required to use it requires documentation. Especially the OperationResponse returnValues filling isn't explained anywhere (I personally expect this to use MethodReturnValue<T>.Ok(T), right? as the .Fail isn't an option with the lack of an exposed ReturnCode enum)
    MethodReturnValue and OperationResponse are not really related... in fact OperationResponse is not used anywhere in the mmo sample.
    MethodReturnValue is used in combination with the ActionQueue for the purpose of error handling.

    If an exception is thrown abstract ActionQueue members "OnException", "GetMethodReturnValue" and "OnOperationActionFailed" are called, the last one containing the MethodReturnValue from "GetMethodReturnValue". The developer decides how to handle the error: Send an event, send an operation response or ignore it? If sending something: Use which error code and debug message?

    if the executed method returns an error code != 0 "OnOperationActionFailed" is executed, too.
    If you don't want to use this error handling you can send your own response before returning MethodReturnValue.Ok.

    OnOperationActionFailed in the mmo sample sends event OperationError. It does not contain a ReturnCode, it's just an integer error code... MethodReturnValue.Fail accepts any integer.

    MethodReturnValue<T> is used to return an object or an error.. for example: try to find an item and either return the item or return an error code and debug message that say "item not found".

    I can't promise that we are going to open the source for photon.socketserver.modulecore.. there are some pros and cons we need to take into consideration and we need some time to discuss them internally..
    I think the most important part is a good documentation in order to understand the concepts...

    Please keep posting your questions, your feedback helps us a lot to improve the documentation.

    Thanks, Boris
  • Unity3D Client:

    Thank you for that information. Will check that :)

    Exposure:

    Might be that they aren't used on the server.
    But that does not hold for the client as the Operations class and especially the Game class show (EventAction, OpeationResult, PeerStatusCallback which all get their stuff straight from MethodReturnValue)

    To explain why these things are troublesome I would like to bring up the example of something as simple as login:
    Without the possibility to define own ReturnCode its required to basically send the generic OKs to send information on why the login failed because there is no ReturnCode that could be used to signal it.

    I guess as there are plans for something even more sophisticated (at least I guess so by the licensing page), you thought about how this and other standard functionality would be implemented optimally in the current environment?


    Exposing Core:
    I don't expect that the core is being exposed.
    Fully understand that there might be potentially more con than pro points.

    But I think that important functionality thats related to the data sent etc should be fully accessable.
    On the other hand I naturally just can implement own handlings in cases where its easy to work around because its not passed in their "native form" as with the ReturnCode values.
  • Boris
    Boris ✭✭
    dreamora wrote:
    But that does not hold for the client as the Operations class and especially the Game class show (EventAction, OpeationResult, PeerStatusCallback which all get their stuff straight from MethodReturnValue)
    PeerStatusCallback will never get values from MethodReturnValue.
    OperationResult has values from MethodReturnValue only if you send an operation response in OnOperationActionFailed - that is 100% your own choice. The same applies to EventAction which is used in the MMO sample (event OperationError) and included in the sources.
    dreamora wrote:
    To explain why these things are troublesome I would like to bring up the example of something as simple as login:
    Without the possibility to define own ReturnCode its required to basically send the generic OKs to send information on why the login failed because there is no ReturnCode that could be used to signal it.
    you can use any integer as error code.. the mmo sample uses the Photon.Modules.Mmo.Common.ErrorCode for all error codes
    Again, the client's ReturnCode enumeration has absolutely nothing to do with class MethodReturnValue.

    What might contribute to the confusion is the new separation between PeerStatusCallback and OperationResult in the client library.
    PeerStatusCallback returns one of the defined ReturnCodes and is never invoked by a server operation response.
    OperationResult is invoked by using SendOperationResponse as seen in Lite, but the MMO sample does not use this mechanism to send messages to the client. The returnCode parameter of OperationResult is completely unrelated to the ReturnCode enumeration. It's just the value of the ErrorCode property returned by the operation. Compare this to Lite - you won't find it in the MMO sample as it uses events (EventAction) only.
  • What contributes significantly to the confusion is the DotNet Client - Game class and the operationresult, peerstatuscallback and eventaction functions there and their documentation part.

    Perhaps its just missleading though and I just missinterpreted the variable naming, the docs and the return value of the operation handling functions completely wrong and can't get out the picture out of my head anymore (operation handler -> methodreturnvalue -> internal event / packet queuing system -> client -> Game -> corresponding handler)
  • Boris
    Boris ✭✭
    dreamora wrote:
    Perhaps its just missleading though and I just missinterpreted the variable naming, the docs and the return value of the operation handling functions completely wrong
    yes.. it appears you got the internal client lib ReturnCode, the server operation return code (aka error code), and the server internal methodreturnvalue mixed up..
    dreamora wrote:
    operation handler -> methodreturnvalue -> internal event / packet queuing system -> client -> Game -> corresponding handler
    correct would be:

    case MethodReturnValue.Fail:
    operation handler -> methodreturnvalue.Fail -> event OperationError (MMO sample) -> client -> Game -> EventAction

    case MethodReturnValue.Ok:
    operation handler -> methodreturnvalue.Ok --> no!.. nothing happens here. we are done.
    the operation handler can send events or operation response unrelated to the methodreturnvalue, for example:
    operation handler -> send event OperationSuccess & return methodreturnvalue.ok -> client -> Game -> EventAction

    If we used the same approach for lite an error would look like this:
    operation handler -> methodreturnvalue.Fail -> send OperationResponse with ErrorCode -> client -> Game -> OperationResponse
  • Thank you for that explanation boris
    That makes sense and explains some of the things I kept seeing

    And what kind of reaction from the server would end in the OperationResult function on class Game of the PhotonDotNet DemoClient? As its there and even routed through to the different strategies I assume it is definitely fed through some path.
    And how would that path that leads there offer the returnValues (unless thats naturally directly clear from the path that one has to use anyway)
  • Boris
    Boris ✭✭
    Sorry for the late response...

    The OperationResult is routed through the different strategies just for completion... in case a developer decides to use operation return values. You can remove it if you like.

    If you want to use return values the client lib requires the following 2 keys in the response Hashtable:

    1) Key"0" with the error code as value (0 = OK).
    The following enums contain code "0":
    - Lite (server): ParameterKeys.ERR
    - MmoSample (Common lib): ParameterCode.ErrorCode
    - Photon Client Lib: ParameterKey.ReturnCode

    2) Key "60" with the operation code as value.
    The following enums contain code "60":
    - Lite (server): ParameterKeys.Code
    - MmoSample (Common lib): ParameterCode.EventCode (same used for events, mmo sample never uses operation returns)
    - Photon Client Lib: ParameterKey.Code

    Lite makes heavy use of the OperationResult and class LiteOperationBase shows how it's implemented.
    The MMO sample does not use this pattern, but you can use it if you want..
    example with operation AddInterestArea:
    public partial class AddInterestArea
    {
            &#91;OperationReturnValue((short)ParameterCode.EventCode)&#93;
            public byte OperationCode { get { return (byte)OperationCode.AddInterestArea; } }
           
            &#91;OperationReturnValue((short)ParameterCode.DebugMessage)&#93;
            public string DebugMessage { get; set; }
    
            &#91;OperationReturnValue((short)ParameterCode.ErrorCode)&#93;
            public int ErrorCode { get; set; }
    }
    
    In the MmoItem.OperationAddInterestArea method return the operation response instead of event OperationSuccess:
    operation.ErrorCode  = 0;
    operation.DebugMessage = "OK";
    OperationResponse response = operation.GetOperationResponse();
    operation.OperationRequest.Context.SendOperationResponse(response);
    
    now the client needs to handle OperationResult for operation AddInterestArea; event OperationSuccess is unexpected for this operation.
  • Thank you for the indepth information Borus.

    I knew that especially since the 2.0 Photon SDK there was more behind the MMO project than a "few additions" but I wouldn't have assumed that core patterns are changed which is likely why my thinking always turned around the same points although they were not related in the end.

    Already your previous answer explained it at least for me but I'm sure that especially new developers will find this insight and comparision very helpful