This page has been translated automatically.
Setting Up Development Environment
Usage Examples
UUSL (Unified UNIGINE Shader Language)
File Formats
Rebuilding the Engine and Tools
Double Precision Coordinates
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
Rendering-Related Classes
Warning! This version of documentation is OUTDATED, as it describes an older SDK version! Please switch to the documentation for the latest SDK version.
Warning! This version of documentation describes an old SDK version which is no longer supported! Please upgrade to the latest SDK version.

Running Syncker for a Custom Project

Syncker system is deprecated and no longer supported. We can't guarantee the stable work of the system.

To use Syncker most efficiently from the point of view of performance, selective synchronization of nodes and materials is needed. This is possible if Syncker is run from a script (and it does not matter if it will be a world, editor or a custom system one) for full control over synchronization.

If you use projectors to render your application, see the article on Running Syncker with AppProjection.

Script Implementation

To run the Syncker master from the world script of a custom project, to synchronize nodes, render parameters and the player over the network, implement your script according to instructions below. Notice that similar logic is used to synchronize materials.

  1. First of all, initialize Syncker in the script that is run on the master computer. Also you should initialize a console to enable the ability of running master command-line options. To synchronize creation of a node on all connected slaves, use the Unigine::Syncker::Master::createNode() function.
    Source code (UnigineScript)
    // unigine_project.cpp on a master computer
    #include <core/unigine.h>
    #include <core/systems/syncker/syncker_master.h>
    #include <core/systems/syncker/syncker_master_console.h>
    // It is more efficient to serialize nodes stored in an array and pass them as
    // one packet instead of sending them one by one
    ObjectMeshStatic meshes[0];
    int init() {
    	// Set a fixed FPS value to make simulations consistent across all computers / 60.0f);
    	// Initialize master console
    	// Initialize Syncker using a given broadcast address
    	PlayerSpectator camera = new PlayerSpectator();
    	// Fill the world with meshes that will be synchronized
    	for(int j = 0; j < 2; j++) {
    			for(int i = 0; i < 2 - j; i++) {
    				// you can specify the path to any other mesh
    				ObjectMeshStatic mesh = node_remove(new ObjectMeshStatic("unigine_project/meshes/box.mesh"));
    				// Synchronize creation of the mesh on all slaves
    	return 1;
    For this code to be compiled, copy the box.mesh file from the <Unigine SDK>/data/samples/common/meshes folder to the unigine_project/data/unigine_project/meshes folder.
  2. Implement logic, which allows loading the world for all of the slaves on the master side, and call it in the init() function after the Syncker initialization.
    You can skip this step and load the world on each slave individually.
    Source code (UnigineScript)
    void sync_world() {
    	// load slave world
    	Unigine::Syncker::Master::systemCall(~0,"",("world_load " +;
    	// waiting for the slave world
    	int ret[0];
    	float begin = clock();
    	while(clock() - begin < 2.0f) {
    		int is_loaded = 1;
    		foreach(int i = 0; ret) is_loaded &= i;
    		if(is_loaded) break;
  3. Then, specify the shutdown logic for the console and Syncker:
    Source code (UnigineScript)
    // unigine_project.cpp on a master computer
    int shutdown() {
    	// Run a console command on all slave applications, if necessary.
    	// The command being called is run from a system script of slaves.
    	// Shut down the console
    	// Shut down Syncker.
    	return 1;
  4. And synchronization logic in the script render() function. Such logic allows you to specify all nodes (and materials, if required), which have to be synchronized. Detailed function descriptions can be found here.
    Source code (UnigineScript)
    // unigine_project.cpp on a master computer
    int render() {
    	// Synchronize frame information
    	// Synchronize player position
    	// Synchronize render parameters
    	// Synchronize nodes
    	// End of the frame
    	return 1;

If you run the same world script on the master and slave sides, you need to wrap your code around with #ifndef DEFINE_NAME ... #else ... #endif as follows:

The DEFINE_NAME should be specified on the application start-up.
Source code (UnigineScript)
#include <core/unigine.h>

// logic to run on the master

	#include <core/systems/syncker/syncker_master.h>
	#include <core/systems/syncker/syncker_master_console.h>
		ObjectMeshStatic meshes[0];
		// init() function defined above
		// shutdown() functions defined above
		// render() function defined above

		// logic to run on a slave
		int init() {

			PlayerSpectator camera = new PlayerSpectator();
			return 1;

Running Syncker

As the Syncker master initialization and shutdown logic and also synchronization of nodes and materials is implemented in the world script, there is no need to use the Syncker script for the master. However, you still need to use the Syncker script for slaves as you didn't implement a custom logic for it.

After the master script is implemented, you need to run it as follows:

  1. Run all slave applications that will be synchronized with the master.

    For that, specify the following options on the slave application start-up to override the default editor script with the Syncker script for slaves. In case you use the same world script on the master and slave sides, specify also the required definition:

    Shell commands
    main_x64 -data_path "../" -editor_script "core/systems/syncker/syncker_slave.cpp" -extern_define "DEFINE_NAME" -console_command "editor_reload"
    The editor_reload console command is required to load the Syncker script for slaves.
    Do not forget to add other required start-up arguments.
  2. Load the world for each slave if you didn't implement the loading logic in the script:
    Source code
    world_load unigine_project/unigine_project
    You can also perform this command on the application start-up (see the previous step):
    Shell commands
    -console_command "world_load unigine_project/unigine_project"
    If you open the console, you will see that a slave application listens on two ports for packets from a master (this default values can be left unchanged):
    ---- Syncker::Slave ----
    Name: unknown
    UDP: 8890
    TCP: 8891
  3. Run the unigine_project script on the main computer to be used as the master.
    Shell commands
    main_x64 -data_path "../" -console_command "world_load unigine_project/unigine_project"
    After that, in the console of the connected slaves you will see the following:
    ---- Syncker::Master ----
    UDP: 8890
    TCP: 8891
  4. Change the broadcasting network address of the master:
    Source code
    And reload the world by using the world_reload. After that, in the master console you will see messages that slaves have connected:
    Connection to "" accepted in 0.00 seconds
If the world on the slaves is not loaded programmatically, console commands world_reload or world_load with the same world as currently loaded are not run on slaves after the master. Only loading of a new world works.

Configuring Displays

After launching your application on the master and slave computers, you need to configure a viewport of each slave depending on the screen configuration:

  • If your screen configuration is represented by a grid of monitors, you can simply follow the instructions specified in the Changing Screen Configuration chapter of the main article on Syncker.
  • In case your screen configuration is represented as a mesh or CAVE, set it for all of the connected slaves via the master_mesh console command.
    Make sure that the name of each mesh surface matches the name of the corresponding slave.
    Source code
    master_mesh <mesh_name>
    To set the slave name, run the slave_name console command:
    Source code
    slave_name <name>
Last update: 2017-07-03
Build: ()