This page has been translated automatically.
Video Tutorials
Interface
Essentials
Advanced
How To
UnigineEditor
Interface Overview
Assets Workflow
Settings and Preferences
Working With Projects
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Lighting
Landscape Tool
Sandworm
Using Editor Tools for Specific Tasks
Extending Editor Functionality
Built-in Node Types
Nodes
Objects
Effects
Decals
Light Sources
Geodetics
World Nodes
Sound Objects
Pathfinding Objects
Players
Programming
Fundamentals
Setting Up Development Environment
Usage Examples
C#
UnigineScript
UUSL (Unified UNIGINE Shader Language)
Plugins
File Formats
Rebuilding the Engine Tools
GUI
Double Precision Coordinates
API
Containers
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Objects-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
IG Plugin
CIGIConnector Plugin
Rendering-Related Classes
Content Creation
Content Optimization
Materials
Material Nodes Library
Miscellaneous
Input
Math
Matrix
Textures
Art Samples
Tutorials
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.

Library's Namespace

Warning
The scope of applications for UnigineScript is limited to implementing materials-related logic (material expressions, scriptable materials, brush materials). Do not use UnigineScript as a language for application logic, please consider C#/C++ instead, as these APIs are the preferred ones. Availability of new Engine features in UnigineScript (beyond its scope of applications) is not guaranteed, as the current level of support assumes only fixing critical issues.

By default, all variables and functions are exported from C++ in the global namespace. Libraries provide a convenient way to organize exposed functionality by adding a library's namespace. This namespace is used instead of Foo::Bar syntax that is not allowed for export.

Namespace Export Example#

  1. In order to use a library namespace, a library should be registered first via Unigine::Interpreter::addExternLibrary().
  2. After that, you can use a library namespace to register your variables and functions.
Source code (C++)
#include <UnigineEngine.h>
#include <UnigineInterpreter.h>
#include <UnigineInterface.h>

#include "AppSystemLogic.h"
#include "AppWorldLogic.h"
#include "AppEditorLogic.h"


using namespace Unigine;

// A variable within a namespace for export.
namespace Foo {
	int i = 25;
}

#ifdef _WIN32
	int wmain(int argc,wchar_t *argv[]) {
#else
	int main(int argc,char *argv[]) {
#endif

	// Register a library in order to use a library namespace.
	Interpreter::addExternLibrary("Foo");

	// Export a variable with a library prefix.
	Interpreter::addExternVariable("Foo.integer",MakeExternVariable(&Foo::i));

	AppSystemLogic system_logic;
	AppWorldLogic world_logic;
	AppEditorLogic editor_logic;
	
	Unigine::EnginePtr engine(argc,argv);

	// Enter main loop.
	engine->main(&system_logic,&world_logic,&editor_logic);

	return 0;
}

Access from Scripts#

You can simply call the registered variables, functions, classes from Unigine scripts using the registered name. (If Foo library is not registered, the first dot in an object or function name is treated as an operator of class member access, which is wrong in our case).

In the init() function of the world script .usc file add the following:

Source code (UnigineScript)
// my_world.usc

int init() {
	/* ... code ... */

	log.message("Foo.i is %d\n",Foo.integer);
	engine.console.setActivity(1);

	/* ... code ... */

}

Output#

The following console message will be printed:

Output
Foo.i is 25
Last update: 2021-12-13
Build: ()