This page has been translated automatically.
Video Tutorials
Interface
Essentials
Advanced
How To
Basics
Rendering
Professional (SIM)
UnigineEditor
Interface Overview
Assets Workflow
Version Control
Settings and Preferences
Working With Projects
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Lighting
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
Materials and Shaders
Rebuilding the Engine Tools
GUI
Double Precision Coordinates
API
Animations-Related Classes
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
VR-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.

Constant Export

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.

Constants are variables, the value of which does not change no matter what happens in C++ code. To be available in Unigine scripts, they need to be exported on C++ side.

  • External constants are read-only.
  • If a value of a registered constant is changed in the C++ code, on script side it will remain the same (unlike variables).

Constant Export Example#

Constants are exported in the similar way as variables:

  1. Create a pointer to an external constant via MakeExternConstant() .
  2. Register the constant via Unigine::Interpreter::addExternVariable() .
  3. All variables are exported into a global namespace. To limit the scope of variable, use library namespace.
Source code (C++)
#include <UnigineEngine.h>
#include <UnigineInterpreter.h>

using namespace Unigine;

int main(int argc,char **argv) {

	int i = 0;
	float f = 0.0f;

	// export a variable and specify a name to access it from Unigine scripts
	Interpreter::addExternVariable("int_constant",MakeExternConstant(i));
	// you can also specify a template parameter to make sure the proper type is passed
	Interpreter::addExternVariable("float_constant",MakeExternConstant<float>(f));
	
	Engine *engine = Engine::init(argc,argv);
	// enter the main loop
	while(engine->isDone() == 0) {
		engine->update();
		engine->render();
		engine->swap();		
		// if a variable value is changed after it was registered, the value in scripts will not be changed
		i = 42;
		f = 57.55f;
	}
	// engine shutdown 
	Engine::shutdown();

}

Access from Scripts#

After the registration, you can access constants from a script by their registered names:

Source code (UnigineScript)
// my_world.usc

log.message("Integer: %d\nFloat: %f\n",int_constant,float_constant);

Output#

The following results will be printed into the console:

Output
Integer: 0
Float: 0.000000

Notice
If you reload the world, the values of the constants that have been changed on the C++ side will remain the same.
Last update: 2024-08-16
Build: ()