Class CreateMMORoomSettings

  • All Implemented Interfaces:
    java.io.Serializable

    public class CreateMMORoomSettings
    extends CreateRoomSettings
    The MMORoom Settings extends the basic Room Settings adding new functionalities that are unique to an MMORoom.

    For a full discussion of the MMORoom features see the MMORoom class documentation.

    MMORoom Settings:

    • defaultAOI: the 2D/3D positional range used for broadcast events
    • mapLimits: (optional) min. and max. X,Y,Z coordinates representing the limits of the virtual world
    • userMaxLimboSeconds: how many seconds a User can remain without an initial position in the virtual world
    • proximityListUpdateMillis: the speed at which Proximity Lists are updated
    • sendAOIEntryPoint: toggles the additional entry position of a User inside the AOI of another Player

    Since:
    2.8.0
    See Also:
    MMORoom, Serialized Form
    • Constructor Detail

      • CreateMMORoomSettings

        public CreateMMORoomSettings()
    • Method Detail

      • getDefaultAOI

        public Vec3D getDefaultAOI()
      • setDefaultAOI

        public void setDefaultAOI​(Vec3D defaultAOI)
        The Area Of Interest (AOI) represents the area within which Users will affect each other, for example when sending public messages, updating User Variables etc... All User and Server events generated outside the AOI will not be received by the player.

        The AOI is passed via a Vec3D representing the ranges for the X, Y and Z axis. For instance a value of (100,100,40) means that each User will have an event range of +/- 100 units on the X and Y axis and +/- 40 units for the Z axis. These units can represent anything: pixels, feet, meters, miles, kilometers, etc... The Vec3D can work with both Integer or Float values, both with a 32bit precision.

        Parameters:
        defaultAOI - the range for each axis (in case of 2D worlds, the Z value can be set to zero)
        See Also:
        Vec3D
      • getUserMaxLimboSeconds

        public int getUserMaxLimboSeconds()
      • setUserMaxLimboSeconds

        public void setUserMaxLimboSeconds​(int userMaxLimboSeconds)
        When a User joins an MMORoom his position in the Room is undefined and therefore he will be in a state of limbo until the first SetUserPosition request will be received. In order to avoid Users spending too much time in this invisible state each MMORoom can be configured to allow a timeout value after which the User will be removed from the Room.

        Parameters:
        userMaxLimboSeconds - the maximum number of seconds allowed for a User in limbo state
        See Also:
        SFSMMOApi.setUserPosition(com.smartfoxserver.v2.entities.User, Vec3D, com.smartfoxserver.v2.entities.Room)
      • getProximityListUpdateMillis

        public int getProximityListUpdateMillis()
      • setProximityListUpdateMillis

        public void setProximityListUpdateMillis​(int updateMillis)
        In MMORoom(s) there are no USER_ENTER/EXIT events. The way in which each User is updated about User changes in their proximity is via the client PROXIMITY_LIST_UPDATE. All other Room events will work similarly, including the USER_COUNT_CHANGE which keeps Users in the same Room group updated about the total number of clients in each Room.

        The frequency of PROXIMITY_LIST_UPDATE events sent to clients is regulated by this parameter. The default value is 500ms which is recommended for most applications. Lower values might generate excessive traffic and/or overwhelm the client, depending on the frequency of other messages going on concurrently.

        In some real-time applications it may be needed to lower the value to 300-250ms, based on the application design.

        Parameters:
        updateMillis - the number of milliseconds between each update
      • isSendAOIEntryPoint

        public boolean isSendAOIEntryPoint()
      • setSendAOIEntryPoint

        public void setSendAOIEntryPoint​(boolean sendAOIEntryPoint)
        When a User enters the proximity list of another Player by default we also send their coordinates. This can be useful from client side to render the User's graphics in place. If this feature is not needed it can be switched off to save extra bytes.