12 | The Baseapp process is mainly responsible for communication with the client,
13 | location independent game logic (guild manager, chat system, leaderboard, etc.),
14 | archiving, backup, and so on.
15 |
16 |
17 |
18 |
19 |
20 |
PyClientApp is a part of the KBEngine
15 | Module. It is is client object created when a client is simulated from
16 | the bottom of C++. It cannot be created in the script layer directly.
49 | Instances of class Entity represent
50 | game objects on the client.
51 |
52 |
53 |
54 | An Entity can access its equivalent
55 | entities in the base and cell applications via ENTITYCALL.
56 | This requires a set of remotely-invoked functions (specified in the entity's .def file).
57 |
58 |
59 |
Member functions documentation
60 |
61 |
62 | def getSpaceData( key ):
63 |
64 |
65 |
66 | Function description:
67 | Get the space data of the specified key.
68 |
69 | The space data is set by the user on the server through setSpaceData.
70 |
71 |
72 |
73 | parameters:
74 |
75 |
76 |
key
77 | string, a string keyword.
78 |
79 |
80 |
81 |
82 |
83 | returns:
84 |
85 |
86 | string, string data for the key
87 |
88 |
89 |
90 |
91 |
92 |
93 |
94 | def player( ):
95 |
96 |
97 |
98 | Function description
99 | Gets the entity that the current client controls.
100 |
101 |
102 |
103 |
104 |
105 |
106 |
107 |
Callback functions documentation
108 |
109 |
110 |
111 |
112 |
113 |
114 |
Attributes documentation
115 |
116 |
117 | entities
118 |
119 |
120 |
121 | Description:
122 | entities is a dictionary object that contains all the entities in the
123 | current process.
124 |
12 | Bots is a kind of lightweight client program that simulates and tests the
13 | server side. Bots has no rendering parts. It can test for hidden bugs and
14 | apply load to the server through a large number of simulated client and
15 | server interactions, so that the developer can optimize the service side
16 | effectively.
17 |
18 |
19 | Note: The Bots process needs to implement the relevant client code under scripts/bots, which is extended by a Python script.
20 |
21 |
12 | The Cellapp process is primarily responsible for space-related game
13 | logic, providing players on different baseapps a real-time interaction
14 | in one space. The Cellapp can usually implement scene-related logic such
15 | as NPCs/monsters, battles, and checkpoint rooms.
16 |
17 |
18 |
96 | Login account to KBEngine server.
97 | Note: If the plug-in and the UI layer use event interaction mode, do
98 | not call directly from the UI layer. Please trigger a "login" event to the
99 | plug-in. The event is accompanied by the data username and password.
100 |
101 |
125 | Request to create a login account on the KBEngine server.
126 |
127 | Note: If the plug-in and the UI layer use the event interaction mode,
128 | do not call directly from the UI layer. Please trigger a "createAccount"
129 | event to the plug-in. The event is accompanied by the data username and
130 | password.
131 |
132 |
133 |
134 |
135 | parameters:
136 |
137 |
138 |
username
139 | string, username.
140 |
141 |
142 |
password
143 | string, password.
144 |
145 |
146 |
147 |
148 |
149 |
150 |
151 | def reloginBaseapp( ):
152 |
153 |
154 |
155 | Function description
156 | Requests to re-login to the KBEngine server (usually used after a dropped
157 | connection in order to connect to the server more quickly and continue to
158 | control the server role).
159 | Note: If the plug-in and the UI layer use event interaction mode, do
160 | not call directly from the UI layer, please trigger a "reloginBaseapp"
161 | event to the plug-in, and the incidental data is empty.
162 |
163 |
164 |
165 |
166 |
167 |
168 | def player( ):
169 |
170 |
171 |
172 | Function description
173 | Gets the entity that the current client controls.
174 |
175 |
176 |
177 |
178 | return:
179 |
180 |
181 | Entity, return controlled entity,
182 | if it does not exist (e.g.: failed to connect to the server) returns null.
183 |
184 |
185 |
186 |
187 |
188 |
189 |
190 |
191 | def resetPassword( username ):
192 |
193 |
194 |
195 | Function description
196 | Asks loginapp to reset the password of the account. The server will send
197 | a password reset email (usually the forgotten password function) to the
198 | email address to which the account is bound.
199 |
200 |
201 |
202 |
203 | parameters:
204 |
205 |
206 |
username
207 | string, username.
208 |
209 |
210 |
211 |
212 |
213 |
214 |
215 | def bindAccountEmail( emailaddress ):
216 |
217 |
218 |
219 | Function description
220 | Requests Baseapp to bind the email address of the account.
221 |
222 |
341 | This is the component that is running in the current scripting environment.
342 | (So far) Possible values are 'cellapp', 'baseapp', 'client', 'dbmgr', 'bots'
343 | and 'editor'.
344 |
345 |
346 |
347 | entities
348 |
349 |
350 |
351 | Description:
352 | entities is a dictionary object that contains all the entities in the current process.
353 |
369 | The uuid of the entity. Change the ID and entity to bind to this login.
370 | When using the heavy login function, the server compares this ID and
371 | determines the validity.
372 |
373 |
374 |
375 |
376 | entity_id
377 |
378 |
379 |
380 | Description:
381 | The ID of the entity controlled by the current client.
382 |
383 |
384 |
385 |
386 | spaceID
387 |
388 |
389 |
390 | Description:
391 | The ID of the Space where the
392 | entity controlled by the current client is located (also can be understood
393 | as the corresponding scene, room, and copy).
394 |
12 | KBEngine is an open source game server engine that does not include the
13 | complete client part, but we provide multiple client plug-ins that can quickly
14 | interface with the server. Client plug-ins handle communication with
15 | the server, registering accounts, login interface, provide an Entity base class, and
16 | so on. The plug-in layer and the client UI layer interface with each other to
17 | form a complete game client.
18 | The plug-in provides the UI layer updated data for display received from
19 | the server (eg, HP changes, the entities entering the clients View),
20 | and the UI layer provides the plug-in layer with updated data to send back to the
21 | server based on the clients input (e.g., the position and orientation of the character).
22 |
23 |
24 |
25 | KBEngine implements different client plug-ins under different front-end
26 | technologies, but each plug-in follows the methods and attributes listed
27 | in this section of the API documentation. All plug-ins follow the same implementation standard
28 | outlined here in the "Client Plugins" section of the documentation.
29 |
30 |
31 |
68 | Registers a timer. The timer triggers the callback function specified
69 | by callbackObj. The callback will be executed the first time after
70 | "initialOffset" seconds, and then executed once every "repeatOffset"
71 | seconds.
72 |
73 | Example:
74 |
75 |
# Here is an example of using addTimer
76 | import KBEngine
77 |
78 | # Add a timer, perform the first time after 5 seconds, and execute once every 1 second. The user parameter is 9
79 | KBEngine.addTimer( 5, 1, onTimer_Callbackfun )
80 |
81 | # Add a timer and execute it after 1 second. The default user parameter is 0.
82 | KBEngine.addTimer( 1, onTimer_Callbackfun )
83 |
84 | def onTimer_Callbackfun( id ):
85 | print "onTimer_Callbackfun called: id %i" % ( id )
86 | # If this is a repeated timer, it is no longer needed, call the following function to remove:
87 | # KBEngine.delTimer( id )
88 |
89 |
90 |
91 |
92 | parameters:
93 |
94 |
95 |
initialOffset
96 | float, specifies the time interval in seconds for the timer to register
97 | the first callback.
98 |
99 |
100 |
repeatOffset
101 | float, specifies the time interval (in seconds) after each execution of
102 | the first callback execution. You must remove the timer with the function
103 | delTimer, otherwise it will continue to repeat.
104 | Values less than or equal to 0 will be ignored.
105 |
106 |
107 |
callbackObj
108 | function, the specified callback function object.
109 |
110 |
111 |
112 |
113 |
114 |
115 | returns:
116 |
117 |
integer, this function returns the internal id of the timer.
118 | This id can be used to remove the timer using delTimer.
119 |
120 |
121 |
122 |
123 |
124 |
125 |
126 | def delTimer( id ):
127 |
128 |
129 |
130 | Function description:
131 | The delTimer function is used to remove a registered timer. The removed
132 | timer is no longer executed. Single-shot timers are automatically removed
133 | after the callback is executed, and it is not necessary to use delTimer
134 | to remove it. If the delTimer function receives an invalid id (for
135 | example, it was removed), it will generate an error.
136 |
137 |
138 | A use case is in the KBEngine.addTimer example.
139 |
140 |
141 |
142 | parameters:
143 |
144 |
145 |
id
146 | integer, specifies the timer id to remove.
147 |
160 | This script function executes a database command on the database, which
161 | is directly parsed by the relevant database.
162 |
163 | Please note that using this function to modify entity data may not be
164 | effective because if the entity has been checked out, the modified data
165 | will still be archived by the entity and cause overwriting.
166 | This function is strongly not recommended for reading or modifying entity data.
167 |
168 |
169 |
170 | parameters:
171 |
172 |
173 |
command
174 | This database command will be different for different database configuration
175 | scenarios. For a MySQL database it is an SQL query.
176 |
177 |
178 |
callback
179 |
180 | Optional parameter, callback object (for example, a function) called
181 | back with the command execution result.
182 | This callback has 4 parameters: result set, number of rows affected,
183 | auto value, error message.
184 | Example:
185 | def sqlcallback(result, rows, insertid, error):
186 | print(result, rows, insertid, error)
187 |
188 |
189 | As the above example shows, the result parameter corresponds to the
190 | "result set", and the result set parameter is a row List. Each line is a
191 | list of strings containing field values. If the command execution does not
192 | return a result set (for example, a DELETE command), or the command
193 | execution encounters an error, the result set is None.
194 |
195 |
196 | The rows parameter is the "number of rows affected", which is an integer
197 | indicating the number of rows affected by the command execution. This
198 | parameter is only relevant for commands that do not return results
199 | (such as DELETE).
200 | This parameter is None if there is a result set return or if there is an
201 | error in the command execution.
202 |
203 |
204 | The insertid is a long value, similar to an entity's databaseID. When
205 | successfully inserting data int a table with an auto long type field, it
206 | returns the data at the time of insertion.
207 | More information can be found in mysql's mysql_insert_id() method. In
208 | addition, this parameter is only meaningful when the database type is
209 | mysql.
210 |
211 |
212 | Error corresponds to the "error message", when the command execution
213 | encounters an error, this parameter is a string describing the error.
214 | This parameter is None when the command execution has not occurred.
215 |
216 |
217 |
threadID
218 | int32, optional parameter, specifies a thread to process this command.
219 | Users can use this parameter to control the execution order of certain
220 | commands (dbmgr is multi-threaded). The default is not specified. If threadId
221 | is the ID of an entity, it will be added to the entity's archive queue
222 | and written by the thread one by one.
223 |
224 |
225 |
dbInterfaceName
226 | string, optional parameter, specifies a database interface. By default it
227 | uses the "default" interface. Database interfaces are defined by kbengine_defaults.xml->dbmgr->databaseInterfaces.
228 |
241 | This script function is providing an external HTTP/HTTPS asynchronous request.
242 |
243 |
244 |
245 | parameters:
246 |
247 |
248 |
url
249 | A valid HTTP/HTTPS URL.
250 |
251 |
252 |
callback
253 |
254 | Optional parameter with a callback object (for example, a function) that requests execution results. This callback takes five parameters: the HTTP request return code (eg: 200),
255 | the returned content, the returned HTTP protocol header, whether it succeeded, and the requested URL.
256 |
257 | Example:
258 | def
259 | onHttpCallback(httpcode, data, headers, success, url):
260 | print(httpcode, data, headers, success, url)
261 |
262 | As the above example shows:
263 |
httpcode:The parameter corresponds to the "HTTP request return code", is an integer.
264 | data:The parameter is “ returned content & rdquo;, it is a string.
265 |
266 |
headers:The parameter is the HTTP protocol header returned by the server, such as:{"Content-Type": "application/x-www-form-urlencoded"}, is an dict.
267 |
success:Whether the execution is successful or not, when the request execution has an error, it is False, and the error information can be further judged by httpcode.
268 |
269 | url:Is the URL used by the request.
270 |
271 |
272 |
273 |
postData
274 | Optional parameter, the default is GET mode request server. If you need POST mode, please provide the content that needs POST. The engine will automatically request the server using POST, is an bytes.
275 |
276 |
277 |
headers
278 | Optional parameter, HTTP header used when requesting, such as：{"Content-Type": "application/x-www-form-urlencoded"}, is an dict.
279 |
280 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 |
Callback functions documentation
289 |
290 |
291 | def onDBMgrReady( ):
292 |
293 |
294 |
295 | Function description:
296 | This function is called back when the current process is ready.
297 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
298 |
299 |
300 |
301 |
302 |
303 | def onDBMgrShutDown( ):
304 |
305 |
306 |
307 | Function description:
308 | This function is called when the process shuts down.
309 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
310 |
311 |
312 |
313 |
314 |
315 | def onReadyForShutDown( ):
316 |
317 |
318 |
319 | Function description:
320 | If this function is implemented in a script, the callback function is called when the process is ready to exit.
321 |
322 | You can use this callback to control when the process exits.
323 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
324 |
325 |
326 |
327 | returns:
328 |
329 |
330 | bool, if it returns True, it allows the process to exit. Returning other
331 | values will cause the process to ask again after a period of time.
332 |
344 | When implemented in a script, this callback returns the database interface
345 | corresponding to an account. After the interface is selected, the dbmgr
346 | operations related to this account are completed by the corresponding
347 | database interface.
348 |
349 | Database interfaces are defined in kbengine_defaults.xml->dbmgr->databaseInterfaces.
350 | Use this function to determine which database the account should be stored
351 | in based on accountName.
352 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
353 |
354 |
355 |
356 | parameters:
357 |
358 |
359 |
accountName
360 | string, the name of the account.
361 |
362 |
363 |
364 |
365 |
366 |
367 | returns:
368 |
369 |
370 | string, the database interface name (database interfaces are defined in kbengine_defaults.xml->dbmgr->databaseInterfaces).
371 |
12 | The Dbmgr process is mainly responsible for handling the storage of
13 | entity data and loading/querying of entity data.
14 | Note: This process script is implemented in the scripts/db directory.
15 |
16 |
17 |
18 |
19 |
20 |
15 |
16 |
17 | KBEngine is an open source game server engine. The client can communicate with the server through a simple protocol.
18 | KBEngine plugins can be quickly combined with (Unity3D, OGRE, Cocos2d-x, HTML5,
19 | etc.) technology to form a complete game client. The server-side low-level
20 | framework is written in C++, and the game logic layer uses Python (supports hot-fixing).
21 | Developers do not need to repeatedly implement the underlying
22 | technologies common to some game servers, and instead can focus their efforts
23 | on the game development level, to quickly build various multiplayer games.
24 |
25 | (Because it is often asked what the upper limit of the load is that KBEngine can handle, the underlying
26 | architecture has been designed as a multi-process distributed dynamic load balancing solution. Theoretically,
27 | by continuously expanding the hardware, the upper limit of the load can also be continuously increased.
28 | The upper limit of the capacity of a single machine depends on the complexity of the game logic itself.)
29 |
61 |
62 | You can look at the installation guide first.
63 | After learning about the common tools, you can go to
64 | GitHub to join our open source team.
65 |
66 |
67 | I believe that after you have enough knowledge of KBEngine, you will like it.
68 |
69 |
70 |
Want to modify and improve the documentation?
71 |
72 | If you think there is something in the documentation that needs to be changed, you can
73 | fork kbengine_docs
74 | and submit a pull request.
75 |
76 | Again, if you find anything in the documentation that you don't understand,
77 | please submit an issue,
78 | and I will adjust the document to help everyone have a better understanding.
79 |
80 |
81 |
82 |
83 |
84 |
85 |
86 |
12 | The Interfaces process handles access to third-party platforms for the KBEngine server.
13 |
14 | Note: This processes scripts are is implemented in the scripts/interface directory.
15 |
16 |
17 |
18 |
19 |
20 |
23 | This is the conventional means of remote interaction between entities in
24 | the script layer. (other references: allClients,
25 | otherClients,
26 | clientEntity).
27 |
28 |
29 |
30 | The EntityCall object is very simple to implement in the underlying C++, it contains only the ID of the entity,
31 | the address of the destination, the entity type, and type of EntityCall.
32 |
33 | When a remote call is requested by the user,
34 | the engine first finds a description of the entity definition through the entity type,
35 | and checks the data input by the user against the description of the entity definition.
36 | If the check is legal, then the data is packaged and sent to the destination
37 | according to the protocol.
38 |
39 | Note: An EntityCall can only be used to call methods declared in its corresponding
40 | def file. It cannot call any of KBEngine's basic Entity class functions or
41 | access entity attributes.
42 |
43 |
44 | An Entity can contain up to three parts:
45 | Client: When an entity includes a client part (usually a
46 | player), the entity's client (EntityCall) property can be accessed on the
47 | server side.
48 | Base: When an entity includes a baseapp part, the base (EntityCall)
49 | attribute of the entity can be accessed in a non-current baseapp.
50 | Cell: When an entity includes a cellapp part, the cell (EntityCall)
51 | attribute of the entity can be accessed in a non-current cellapp.
52 |
53 |
54 |
55 | Example:
56 | Client remote method defined in Avatar.def:
57 |
72 |
73 | Enter in the Debug page input box of the GUIConsole tool (check the
74 | process to be debugged first in the list on the left):
75 | First find the ID of the player entity (Avatar) in the log of the server's
76 | Baseapp, and then get the player entity (Avatar) or EntityCall through
77 | the entity ID:
78 |
79 | >>> KBEngine.entities[Player ID].client.hello()
80 |
81 | At this point, the client log file will output "hello" and a remote call
82 | process will be completed.
83 |
84 |
85 |
86 |
87 |
88 | KBE_ROOT:
89 |
90 |
91 |
92 |
93 | This is a KBEngine environment variable that describes the root directory
94 | where KBEngine is located.
95 |
96 |
97 |
98 |
99 |
100 | KBE_RES_PATH:
101 |
102 |
103 |
104 |
105 | This is a KBEngine environment variable that describes the resource
106 | directory that KBEngine engine can read.
107 |
108 |
109 |
110 |
111 |
112 | KBE_HYBRID_PATH:
113 |
114 |
115 |
116 |
117 | This is a KBEngine environment variable that describes the directory
118 | where the KBEngine engine executable file is located.
119 |
120 |
121 |
122 |
123 |
124 | entities.xml:
125 |
126 |
127 |
128 |
129 | All valid entity types on the server must be registered here. When the
130 | engine is initialized, the description of the entity is loaded according
131 | to the order.
132 |
133 |
134 |
135 |
136 |
137 | kbengine_defaults.xml:
138 |
139 |
140 |
141 |
142 | Server-side default configuration, where users can modify all component
143 | configurations such as cellapp,
144 | baseapp, and loginapp.
145 |
146 |
147 | Note: You may often need to upgrade the engine. Modifying directly may
148 | cause conflicts during the upgrade, and it is not suitable for multiple
149 | projects in the same KBEngine environment.
150 |
151 |
152 | It is recommended that you modify the overload in
153 | kbengine.xml. You only need to rewrite the
154 | parts you want to modify according to the format in xml.
155 |
156 |
157 |
158 |
159 |
160 |
161 | kbengine.xml:
162 |
163 |
164 |
165 |
166 | Server configuration file, where users can modify all component configurations
167 | such as cellapp,
168 | baseapp, and loginapp.
169 | For details, please refer to kbengine_defaults.xml
170 |
191 | Each client entity connected to the server will have a View. It allows
192 | the client entity to communicate events in its View to its own client.
193 | View is related to space, and each View can be set to an independent size
194 | range.
195 |
196 | Note: The space described here is an abstract concept and does not
197 | necessarily need to be bound to the concept of physical space (except
198 | for MMORPGs). For the core gameplay of a card game, players in a room can
199 | also be considered to be in a logical space.
200 |
201 | Events include: entity movement, property change of client broadcast type,
202 | destruction on death, and so on.
203 |
204 |
205 |
206 |
207 |
208 |
209 | Witness
210 |
211 |
212 |
213 |
214 | Eyewitness.
215 | Only Witnesses bound to cell entity Views take effect.
216 | In other words, Witness is a cell proxy of the client.
217 | The cellapp continuously synchronizes the information in the View to the
218 | client through the Witness.
219 | When an NPC on the server is seen by a witness, it call the onWitness
220 | callback of the entity. The server can rely on this feature to reduce CPU
221 | consumption. When an entity is not witnessed, the server can stop any of
222 | its behavior.
223 |
224 |
225 |
226 |
227 | Space
228 |
229 |
230 |
231 |
232 | A space KBEngine allocates on the cellapp, which is isolated
233 | from other spaces. Views, traps, entity collisions, etc. only interact with each
234 | other in the current space. The space is defined by the user. It can be
235 | a scene, copy, room...
236 |
237 |
238 |
239 |
240 | cell
241 |
242 |
243 |
244 |
245 | There are two different meanings of cell in this documentation.
246 | Usually, when referring to the Entity.cell
247 | attribute, you are actually describing the entity's CellEntityCall.
248 |
249 | If a cell is described as part of a space, it refers to cellapp's load
250 | balancing technique. A space in the cellapp may be divided into n parts,
251 | each called a cell, and each cell is maintained by a different process.
252 |
253 |
254 |
255 |
256 |
257 | base
258 |
259 |
260 |
261 |
262 | Usually refers to the Base entity on the baseapp
263 | or a BaseEntityCall that points to the Base entity.
264 | For example: Entity.base
265 |
266 |
267 |
268 |
269 |
270 | client
271 |
272 |
273 |
274 |
275 | Usually refers to the client or an EntityCall
276 | that points to the client entity.
277 | For example: Entity.client
278 |
279 |
280 |
281 |
282 |
283 | cellapp
284 |
285 |
286 |
287 |
288 | The Cellapp process in mainly responsible for position-related game logic,
289 | View, AI, scene rooms, and so on.
290 | See also: cellapp
291 |
292 |
293 |
294 |
295 | baseapp
296 |
297 |
298 |
299 |
300 | The Baseapp process is mainly responsible for communication with the client,
301 | position-independent game logic (guild manager, chat system, game lobby,
302 | leaderboard, etc.), archiving, backup, and so on.
303 | See also: baseapp
304 |
305 |
306 |
307 |
308 |
309 | real
310 |
311 |
312 |
313 |
314 | Refers to an entity in a cell that is actually present in the cell at that
315 | time. (As opposed to a ghost entity broadcast there by another cell)
316 |
317 |
318 |
319 |
320 |
321 | ghost
322 |
323 |
324 |
325 |
326 | This kind of entity is a projected copy generated by cellapp's dynamic load
327 | balancing mechanism which divides a space into N shares and splits the cells
328 | between different processes.
329 | Space is divided into multiple regions. To make the client unable to
330 | perceive the existence of the boundaries between them, we synchronize a
331 | certain range of entities in each cell's boundary to an adjacent cell's
332 | boundary. The entity has a part of its data synchronized over
333 | (CELL_PUBLIC, cell broadcast types of attributes) to a ghost entity. In
334 | this way the entity can interact seamlessly with the other side of the boundary
335 | and both cells simultaneously.
336 |
337 | Non-ghost entities are called real entities.
338 |
339 |
340 |
341 |
342 |
343 | vector3
344 |
345 |
346 |
347 |
348 |
349 | Describe and manage 3D space vectors.
350 | There are three properties of x, y, and z that represent different axial directions.
351 |
352 | Example in script: import Math v = Math.Vector3()
353 |
65 | Registers a timer. The timer triggers the callback function callbackObj.
66 | The callback function will be executed the first time after "initialOffset"
67 | seconds, and then will be executed once every "repeatOffset" seconds.
68 |
69 | Example:
70 |
71 |
# Here is an example of using addTimer
72 | import KBEngine
73 |
74 | # Add a timer, perform the first time after 5 seconds, and execute once every 1 second. The user parameter is 9
75 | KBEngine.addTimer( 5, 1, onTimer_Callbackfun )
76 |
77 | # Add a timer and execute it after 1 second. The default user parameter is 0.
78 | KBEngine.addTimer( 1, onTimer_Callbackfun )
79 |
80 | def onTimer_Callbackfun( id ):
81 | print "onTimer_Callbackfun called: id %i" % ( id )
82 | # If this is a repeated timer, it is no longer needed, call the following function to remove:
83 | # KBEngine.delTimer( id )
84 |
85 |
86 |
87 |
88 | parameters:
89 |
90 |
91 |
initialOffset
92 | float, specifies the time interval in seconds for the timer to register from the first callback.
93 |
94 |
95 |
repeatOffset
96 | float, specifies the time interval (in seconds) between each execution after
97 | the first callback execution. You must remove the timer with the function
98 | delTimer, otherwise it will continue to repeat.
99 | Values less than or equal to 0 will be ignored.
100 |
101 |
102 |
callbackObj
103 | function, the specified callback function object
104 |
105 |
106 |
107 |
108 |
109 |
110 | returns:
111 |
112 |
integer, the internal id of the timer. This id can be used to
113 | remove the timer from delTimer.
114 |
115 |
116 |
117 |
118 |
119 |
120 |
121 | def delTimer( id ):
122 |
123 |
124 |
125 | Function description:
126 | The delTimer function is used to remove a registered timer. The removed timer is
127 | no longer executed. Single-shot timers are automatically removed after
128 | the callback is executed, and it is not necessary to use the delTimer
129 | function to remove it. If the delTimer function is passed an invalid id
130 | (for example, timer was removed), it will generate an error.
131 |
132 | A use case is shown in the KBEngine.addTimer example.
133 |
134 |
135 |
136 | parameters:
137 |
138 |
139 |
id
140 | integer, which specifies the timer id to remove.
141 |
154 | This script function is providing an external HTTP/HTTPS asynchronous request.
155 |
156 |
157 |
158 | parameters:
159 |
160 |
161 |
url
162 | A valid HTTP/HTTPS URL.
163 |
164 |
165 |
callback
166 |
167 | Optional parameter with a callback object (for example, a function) that requests execution results. This callback takes five parameters: the HTTP request return code (eg: 200),
168 | the returned content, the returned HTTP protocol header, whether it succeeded, and the requested URL.
169 |
170 | Example:
171 | def
172 | onHttpCallback(httpcode, data, headers, success, url):
173 | print(httpcode, data, headers, success, url)
174 |
175 | As the above example shows:
176 |
httpcode:The parameter corresponds to the "HTTP request return code", is an integer.
177 | data:The parameter is “ returned content & rdquo;, it is a string.
178 |
179 |
headers:The parameter is the HTTP protocol header returned by the server, such as:{"Content-Type": "application/x-www-form-urlencoded"}, is an dict.
180 |
success:Whether the execution is successful or not, when the request execution has an error, it is False, and the error information can be further judged by httpcode.
181 |
182 | url:Is the URL used by the request.
183 |
184 |
185 |
186 |
postData
187 | Optional parameter, the default is GET mode request server. If you need POST mode, please provide the content that needs POST. The engine will automatically request the server using POST, is an bytes.
188 |
189 |
190 |
headers
191 | Optional parameter, HTTP header used when requesting, such as：{"Content-Type": "application/x-www-form-urlencoded"}, is an dict.
192 |
193 |
194 |
195 |
196 |
197 |
198 |
199 |
200 |
Callback functions documentation
201 |
202 |
203 | def onLoggerAppReady( ):
204 |
205 |
206 |
207 | Function description:
208 | This function is called back when the current process is ready.
209 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
210 |
211 |
212 |
213 |
214 |
215 | def onLoggerAppShutDown( ):
216 |
217 |
218 |
219 | Function description:
220 | This function is called back when the process shuts down.
221 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
222 |
223 |
224 |
225 |
226 |
227 | def onLogWrote( datas ):
228 |
229 |
230 |
231 | Function description:
232 | If this function is implemented in the script, it is invoked when the
233 | logger process obtains a new log.
234 | The database interface is defined in kbengine_defaults.xml->dbmgr->databaseInterfaces.
235 |
236 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
237 |
238 |
239 |
240 | parameters:
241 |
242 |
243 |
datas
244 | bytes, log data.
245 |
246 |
247 |
248 |
249 |
250 |
251 |
252 |
253 | def onReadyForShutDown( ):
254 |
255 |
256 |
257 | Function description:
258 | If this function is implemented in the script, it is called when the
259 | process is ready to exit.
260 |
261 | You can use this callback to control when the process exits.
262 | Note: This callback interface must be implemented in the portal module ( kbengine_defaults.xml ->entryScriptFile).
263 |
264 |
265 |
266 | returns:
267 |
268 |
269 | bool, if it returns True, it allows the process to exit. Returning other
270 | values will cause the process to ask again after a period of time.
271 |
12 | The Logger process is responsible for collecting logs output by the
13 | KBEngine server.
14 |
15 | Note: This process script is implemented in the scripts/logger directory.
16 |
17 |
18 |
19 |
20 |
21 |
12 | The Loginapp process is primarily responsible for handling entity
13 | registration and login requests.
14 | Note: This process script is implemented in the scripts/login directory.
15 |
16 |
17 |
18 |
19 |
20 |