Mmo PhotonUnity3D client library source
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)
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)
0
Comments
-
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 useddreamora 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 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, Boris0 -
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.0 -
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)
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.
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.0 -
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)0 -
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 wrongdreamora wrote:operation handler -> methodreturnvalue -> internal event / packet queuing system -> client -> Game -> corresponding handler
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 -> OperationResponse0 -
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)0 -
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 { [OperationReturnValue((short)ParameterCode.EventCode)] public byte OperationCode { get { return (byte)OperationCode.AddInterestArea; } } [OperationReturnValue((short)ParameterCode.DebugMessage)] public string DebugMessage { get; set; } [OperationReturnValue((short)ParameterCode.ErrorCode)] 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.0 -
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 helpful0