What needs to be defined Entity:
Stored in the database.
Ability to facilitate remote access.
Need to manage and monitor its engines, such as: View, Trap, etc...
When a disaster recovery server can automatically recover.
What needs to be defined Entity-attribute:
Stored in the database.
Entities are after migration data is still valid (only cellapp Migrating Entities, such as teleport-scene).
When a disaster recovery server can automatically recover.
What needs to be defined Entity-method:
Ability to facilitate remote access.
Registration of Entity (reference:entities.xml)
Path definition file : assets/scripts/entities.xml
Example:
<root>
<Account hasClient="true"></Account> <!-- <Account hasCell="true", hasBase="true", hasClient="true"></Account> -->
<Avatar/>
<Spaces/>
<Space/>
<Monster/>
<NPC/>
<Gate/>
</root>
Def file to create a directory in assets/scripts/entity_defs
For example: Account.def
You may also need to define some properties and methods
In the assets/scripts/ directory has three subdirectories (base, cell, client), you can add Account.py needed.
Not every entity needs to create three parts(client, base, cell), press need to select.
<root>
// The entity of the parent class-def
// This tag is only valid in the Entity.def，If itself is a def interface, the tag are ignored
<Parent> Avatar </Parent>
// Volatile attribute synchronization control
<Volatile>
// This setting is always synchronized to the client
<position/>
// No explicit settings are always synchronized to the client
<!-- <yaw/> -->
// Set to 0 is not synchronized to the client
<pitch> 0 </pitch>
// Distance of 10 meters or less and the synchronization to the client
<roll> 10 </roll>
// If true, when the entity is determined on the ground, the server does not synchronize the entity's Y axis coordinates.
// Large amounts of bandwidth can be saved when synchronizing large numbers of entities
// The default is true.
<optimized> true </optimized>
</Volatile>
// Registration interface, similar to the C# interface
// This tag is only valid in the Entity.def，If itself is a def interface, the tag are ignored
<Interfaces>
// All interface-defs must be written in entity_defs/interfaces
<Interface> GameObject </Interface>
</Interfaces>
<Properties>
// Property Name
<accountName>
// Property type
<Type> UNICODE </Type>
// (optional)
// Property of a custom protocol ID，If the client does not use the KBE supporting SDK development，
// The client needs to develop with KBE docking protocol, You can define the property ID to facilitate identification,
// The c++ protocol uses a uint16 to describe，If you do not define a ID，
// engine will use its own rules generated by the protocol ID, The ID must be unique in all the def file.
<Utype> 1000 </Utype>
// Property Scopes (reference: Propertie Scopes section)
<Flags> BASE </Flags>
// (optional)
// Is stored in the database
<Persistent> true </Persistent>
// (optional)
// The maximum length is stored in the database
<DatabaseLength> 100 </DatabaseLength>
// (optional)
// Default value
<Default> kbengine </Default>
// (optional)
// DB index, Support for UNIQUE and INDEX
<Index> UNIQUE </Index>
</accountName>
...
...
</Properties>
<ClientMethods>
// Remote Method name of the Client exposure
<onReqAvatarList>
// remote method args type
<Arg> AVATAR_INFOS_LIST </Arg>
// (optional)
// Method of a custom protocol ID，If the client does not use the KBE supporting SDK development，
// The client needs to develop with KBE docking protocol, You can define the property ID to facilitate identification,
// The c++ protocol uses a uint16 to describe，If you do not define a ID，
// engine will use its own rules generated by the protocol ID, The ID must be unique in all the def file.
<Utype> 1001 </Utype>
</onReqAvatarList>
...
...
</ClientMethods>
<BaseMethods>
// Remote Method name of the Baseapp exposure
<reqAvatarList>
// (optional)
// The definition of this tag allows clients to invoke, otherwise only allows the internal servers remote call
<Exposed/>
// (optional)
// Method of a custom protocol ID，If the client does not use the KBE supporting SDK development，
// The client needs to develop with KBE docking protocol, You can define the property ID to facilitate identification,
// The c++ protocol uses a uint16 to describe，If you do not define a ID，
// engine will use its own rules generated by the protocol ID, The ID must be unique in all the def file.
<Utype> 1002 </Utype>
</reqAvatarList>
...
...
</BaseMethods>
<CellMethods>
// Remote Method name of the Cellapp exposure
<hello>
// (optional)
// The definition of this tag allows clients to invoke, otherwise only allows the internal servers remote call
<Exposed/>
// (optional)
// Method of a custom protocol ID，If the client does not use the KBE supporting SDK development，
// The client needs to develop with KBE docking protocol, You can define the property ID to facilitate identification,
// The c++ protocol uses a uint16 to describe，If you do not define a ID，
// engine will use its own rules generated by the protocol ID, The ID must be unique in all the def file.
<Utype> 1003 </Utype>
</hello>
</CellMethods>
</root>
For example: Call the base method in the client to get a list of roles (Account.py):
self.base.reqAvatarList()
If the scope of a property have multiple parts, then in the entity of the associated part are the property.
If the scope of a property have multiple parts, this property can only have one source can be modified, other parts will be synchronized.
Please refer to the following table: (S and SC or C, represents a property contains the part, The difference is S means property source, C means by the source data synchronization, SC means real entity is the source, ghosts part, also be synchronized)
[Type] [ClientEntity] [BaseEntity] [CellEntity]
BASE - S -
BASE_AND_CLIENT C S -
CELL_PRIVATE - - S
CELL_PUBLIC - - SC
CELL_PUBLIC_AND_OWN C - SC
ALL_CLIENTS C(All Clients) - SC
OWN_CLIENT C - S
OTHER_CLIENTS C(Other Clients) - SC
download(example): rpgdemo_project.tar
https://github.com/kbengine/kbengine_demos_assets