Marauroa 3.9: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
imported>Hendrik Brummermann No edit summary |
imported>Hendrik Brummermann No edit summary |
||
| Line 21: | Line 21: | ||
== Extended the size of the ban message == |
== Extended the size of the ban message == |
||
; Summary : Ban messages may be longer |
; Summary : Ban messages may be longer than 256 characters, if both server and client use Marauroa 3.9 or higher |
||
; Reason for change : It is desirable to include more details and contact information in the ban message. |
; Reason for change : It is desirable to include more details and contact information in the ban message. |
||
; Impact on Marauroa users : A longer ban message |
; Impact on Marauroa users : A longer ban message is possible |
||
== Logging of failed login with distinct status == |
== Logging of failed login with distinct status == |
||
| Line 35: | Line 35: | ||
; Summary : The Marauroa 3.9 client supports the omission of empty perceptions |
; Summary : The Marauroa 3.9 client supports the omission of empty perceptions |
||
; Reason for change : |
; Reason for change : This change reduces the amount of network traffic; especially for very short turn times (e. g. Marboard uses 10ms in order to be very responsive) |
||
; Impact on Marauroa users : None, yet. Starting with the future Marauroa 4.0 empty perceptions will actually be omitted. There might be an impact, if a client assumes that it receives a perception per turn time interval. |
; Impact on Marauroa users : None, yet. Starting with the future Marauroa 4.0 empty perceptions will actually be omitted. There might be an impact, if a client assumes that it receives a perception per turn time interval. |
||
; Details : The client was counting the perceptions in order to determine when to send the "keep a live" message. Starting with 3.9, the client will send the "keep a live" message based on actual passed time. Note: The server will not yet omit empty perceptions in version 3.9, but will start to do that in version 4.0 for 3.9 and above clients. |
; Details : The client was counting the perceptions in order to determine when to send the "keep a live" message. Starting with 3.9, the client will send the "keep a live" message based on actual passed time. Note: The server will not yet omit empty perceptions in version 3.9, but will start to do that in version 4.0 for 3.9 and above clients. The reason for this approach is that the server side changes are a lot simpler in the refactored code. |
||
== RPClass support for RPAction == |
== RPClass support for RPAction == |
||
; Summary : RPClass are now supported for RPActions sent from the client to the server. |
; Summary : RPClass are now supported for RPActions sent from the client to the server. |
||
; Reason for change : Reduction of network traffic and type checks before a message is sent |
; Reason for change : Reduction of network traffic and type checks on the client side before a message is sent |
||
; Impact on Marauroa users : Support for RPClass on RPActions on the server side exists since Marauroa 2.0, this change enables the client side to specify the RPClass. |
; Impact on Marauroa users : Support for RPClass on RPActions on the server side exists since Marauroa 2.0, this change enables the client side to specify the RPClass. |
||
; Details : It is an optional feature. It requires the RPClass-entries for the actions to be defined on the server side. And the client may then use those RPClasses when instantiating RPActions on the client side. |
; Details : It is an optional feature. It requires the RPClass-entries for the actions to be defined on the server side. And the client may then use those RPClasses when instantiating RPActions on the client side. |
||