Welcome to the Turbulenz Local Server User Guide!
Document Sections
Here is a summary of the topics covered in each section:
What is the Turbulenz Local Server?
What does the Turbulenz Local Server do? An integral part of the Turbulenz development process; the local development server provides the foundation work flow for developing Turbulenz apps/games. This section describes the features the technology provide and how to start using it from day one.
How do I try it out? The best way to see what it does is to start using it! This section guides you through the server, step-by-step, showing you how the basics works.
What features are available? There are tools you can use with your projects that are designed to assist you during development. This section provides further step-by-step guides explain how to use the features and how they might be of assistance.
What common patterns am I likely to encounter when developing? This section covers how you may interact with the local server on a daily basis. It offers suggestions for how best to use it and describes how to perform some more advanced tasks.
What else should I know about? An additional reference for the local server that covers some aspects in more detail. This section contains information to help you get the most out of the local server and its tools.
I can’t get it to work: If you are encountering problems when using the local server, check out this section to see if you can find a solution to your problem. It covers the possible pitfalls you might encounter and offers you suggestions to help you get going again.
Assumptions
Note
Some parts of this guide may require you to have an understanding how your application/game is built including build processes and tools. The prerequisite information can be found in the Getting Started Guide.
The Turbulenz Local Server is a web server you can run on your computer to simulate the online infrastructure provided by Turbulenz. It provides cloud-based service APIs locally for you to test your game/app against. Not limited to just web server functionality, it also provides the tools to help you develop your game/app on your local machine. You can visually debug your game assets, test file mappings, view server response metrics and inspect your Turbulenz Services data, all without internet access. If you are working on a local network with other developers, you can allow them to access your projects and test your work as you are developing it, great for tracking down bugs. Once your code is running on your local server, even in a basic form, you can use the local server to deploy a build of your project to your account on the Turbulenz Hub. In this way you can allow 3rd parties to try your project even during development to help with testing, demoing and getting feedback.
It all starts with the local server and here are the features it provides:
Projects
File Serving
Turbulenz Services APIs
Metrics
Built in Tools
A disassembler tool for inspecting converted asset files in JSON format.
Deployment
To get started using the local server quickly, the following step-by-step instructions will help you navigate the server:
Once you have installed the SDK on your computer:
Windows:
- Click the link: (Start Menu -> Programs -> Turbulenz -> SDK X.X.X -> Run Local Server X.X.X)
- Wait for the server to start. This should take no more than a minute (If it seems to be taking longer try troubleshooting).
- Once loaded, your default browser should navigate to http://127.0.0.1:8070, this is the web address for your local server.
- You should see a page entitled ‘local.turbulenz’.
Mac / Linux:
- In the terminal, navigate to location of your SDK. The default location is: ~/Turbulenz/SDK/X.X.X
- Type: ./start_local.sh
- Wait until you get a message such as “Serving on 0.0.0.0:8070 view at http://127.0.0.1:8070”.
- Navigate to http://127.0.0.1:8070 using your browser.
- You should see a page entitled ‘local.turbulenz’.
If you are using the Turbulenz open source repository the local server can be started by following the setup instructions.
The local server comes with preloaded content of samples and apps for you to explore.
To select to project to play, click on its art image. Try clicking on ‘Sample App’.
You will see a selection of purple buttons that represent what you can do on your project. Click on the ‘Play’ button.
You will see a list of configurations that have been built for your project. This usually includes plugin debug/release and canvas debug/release builds.
- To play a build, click on the link. The requirements for each configuration are:
- sampleapp.release.html - Turbulenz Engine installed. Any supported browser.
- sampleapp.debug.html - Turbulenz Engine installed. A development browser.
- sampleapp.canvas.release.html - Any browser with canvas2D support (for 2D apps) or WebGL support (for 3D apps).
- sampleapp.canvas.debug.html - A development browser supporting canvas2D/WebGL.
- sampleapp.tzjs - Turbulenz Engine installed, certain supported browers.
The app will start running in the page. For the Sample App you should see a spinning duck.
To select another option, use the back button in the browser.
Note
To get a shortcut to app on your computer you can bookmark the url in the address bar when you are playing. e.g. http://127.0.0.1:8070/#/play/sample-app/sampleapp.canvas.html Remember that this will change if you modify your project configurations or project name.
Once you have taken into account project considerations, you can add a new project to the local server. This involves letting the server know where your project is located and creating a configuration ‘manifest.yaml’ file for your project.
If starting from scratch:
From the local server page click on the ‘+’ button on the left hand side (under the ‘home’ icon).
This will create an empty project page.
At the bottom you will be asked to specify a ‘Game Directory’. You can either:
- Type a directory name - i.e. ‘MyAwesomeProject’ this will allow you to create a project for this SDK at *SDKINSTALLDIR*/devserver/games/MyAwesomeProject
- Type a relative/absolute path to a directory you want to put the project - i.e. Windows: “C:\Users\*USERNAME*\Dev\MyAwesomeProject” or Mac / Linux: “/Users/USERNAME/Dev/MyAwesomeProject”
Note
Use of ~/ to denote home is not possible. Please use the full path e.g. ~/Dev/MyAwesomeProject becomes /Users/USERNAME/Dev/MyAwesomeProject.
If no directory exists: The server will ask you to ‘create’ this directory (and show you the full path) If the directory exists: The server will ask you to ‘confirm’ this directory.
The server will automatically create a ‘manifest.yaml’ file in that directory to store your settings.
You will be asked to fill in the following details for your project:
Title - This is the name of your project and how you can easily identify it. If you are adding ‘Working project’ layout, then something like ‘MyAwesomeProject (Dev)’ would be suitable. If you are adding a ‘Deployed project’ layout, then depending on the configuration you are deploying, something like ‘MyAwesomeProject (v0.1) [*BUILDCONFIGURATION*]’
Slug - This is how the server will access your project by url. This is usually automatically generated by the title, but you can edit this if required. (See choosing a slug)
Main - This is the file that represents the entry point to your game. For a development build this will be ‘myawesomeproject.debug.html’. For release builds this will be either: ‘myawesomeproject.tzjs’ or ‘myawesomeproject.canvas.js’ for plugin and canvas builds respectively. If you specify a HTML file (for the purpose of debugging), then you must remember to add the required files to the ‘Deploy Files’. Note how this file is automatically added to the ‘Deploy Files’.
Mapping Table - This is the file that provides mappings for assets from the ‘Asset Name’ to ‘Request Name’ (What’s this?). This file is how the server knows how to serve your asset files correctly. The mapping is usually ‘mapping_table.json’ and is located in the root project directory. Note how this file is automatically added to the ‘Deploy Files’.
Deploy Files - This is where you can view and add files that will be part of the deployment to the Turbulenz Hub. See the section on deploying to the Hub. You can specify individual files or patterns. Here are a few examples:
- mapping_table.json - The mapping table. Required for deployment.
- myawesomeproject.tzjs - The main plugin file for MyAwesomeProject.
- images/* - All files located in the ‘images’ and its sub-directories.
- css/*.css - All .css files located in the ‘css’ sub-directory. Note: This is not recursive.
- scripts/app/* - All files in the ‘app’ sub-directory of ‘scripts’. Note: Will not include files in ‘scripts’. Note: This command will also search sub-directories in ‘app’.
Note
To recursively include files with a certain type in sub-directories you need to specify each sub-directory you intend to include.
Example:
To include JavaScript files in ‘jslib’ for a canvas debug build, you would need to add the following entries:
- jslib/*.js
- jslib/services/*.js
- jslib/webgl/*.js
Note
Eventually you may want to include content for the Turbulenz Services such as leaderboards and badges. The deploy files is where you need to add this information to ensure they are uploaded to the Hub. See badges and leaderboards for an example of what to include.
Note
For more detail on the manifest.yaml format. See the manifest format section in the documentation.
If you have an existing project with an existing manifest.yaml file that needs to be configured for this local server. The process is similar to adding a new project.
To demonstrate this we will use the Sample App as a basis.
Duplicate the ‘sampleapp’ directory and call it ‘MyAwesomeProject’
From the local server page click on the ‘+’ button on the left hand side (under the ‘home’ icon).
This will create an empty project page.
At the bottom you when you are asked to specify a ‘Game Directory’, type in the path of the ‘MyAwesomeProject’ directory. In this case the relative path should be fine:
../../apps/MyAwesomeProject
Once the server finds the existing manifest file it will ask you to either:
- To ‘use’ the data.
- To ‘overwrite’ the data with a new, empty project. This will be like starting from scratch.
If you select ‘use’, it will fill in the form with the details of the Sample App project. Note that the slug has been changed so that this project doesn’t clash with your existing sampleapp project.
Since the project is already configured, we will only change the title and slug to make it unique.
Add the title ‘My Awesome Project’ (the slug will change automatically).
The ‘Save Game’ button at the bottom right of the form will be available in green. Press this to save the configuration changes.
Note
In this example we have only changed the title and directory for configuration in the local server. There are many other aspects of the app that would need to be changed to convert it over to the MyAwesomeProject naming.
If you created a project as a test or simply want to remove a project from your list you will need to delete it.
- From the local server main page, select the project you want to delete by clicking on the artwork image.
- Select the ‘Manage’ button.
- At the bottom there is a ‘Delete Game’ button, press this button.
- A message will pop up asking you to confirm.
- As described in the message this will only delete the configuration file. To truly delete the project you will need to delete the directory that the project referred to.
To get a quick overview of the functionality provided by the local server, follow these steps to explore:
Once you have run an app you can investigate the metrics generated during that session.
- Select the project you want to get the metrics for. Try the ‘Sample App’ project you just ran.
- Select the ‘Metrics’ button.
- You will see a list of session data starting with the most recent at the top.
- Open a closed session by pressing the arrow next to the session date.
- If you press the ‘Files’ button at the bottom of an open session, it will expand a list of files that were requested during that session.
- You can compare the size and response time of the message for each file. This is useful if you want to find out which assets are taking the longest to transfer.
- Sort the list by clicking on ‘time’ to see the order in which requests were received.
Note
After repeat plays, you may notice that some sessions have a size of 0 bytes. The server response for some of these files is “304 Not Modified”. This means the server was queried, but the file hadn’t changed and the file has been served directly from the browser’s cache. In this case the time between requests represents the time taken to query the server.
Warning
When a session has a size of 0 bytes, some files are not listed. This is the case for assets located in ‘staticmax’. Theses files are cached indefinitely and hence they were served from the browser’s cache. In this case there is no server response. An example asset in Sample App would be ‘models/duck.dae’. If you want to get a true representation of the response time for a user with no cached files, clear your browser cache and play the game again.
Try clearing your cache and run the Sample App again.
- Select the ‘Sample App’ project.
- Select ‘Metrics’.
- Look at the top session (Size > 0).
- If the session is closed, open it by pressing the arrow by the date.
- Press the ‘Assets’ button at the bottom of the open session.
- You should see a colored bar, breaking the total size down by file type. This is useful if you want to see how much of a project is asset data such as sounds, textures compared to application code.
If a project has assets containing geometries, animations or physics data, this can be visualized in the ‘Asset Viewer’ tool.
- Select the project with the model asset. In this case select the Sample App, which contains a duck model.
- Select the ‘Assets’ button.
- Below the button is a list of the assets which are part of the project. If a mapping table is present, then this represents the root of the mapping table structure.
- Select the ‘models’ link.
- There is a ‘duck.dae’ asset, which in the game will be referenced by ‘models/duck.dae’. This maps to a request name, which is the request that will be sent to the server.
- Under the column ‘View’ click on the link. This will load the file in the viewer.
- You should see a 3D blue grid on a white background with a yellow duck in the middle.
- Click on the window and try using the mouse and keyboard to move around the duck. (WASD + Mouse look).
- Press Esc to release the mouse
For geometries, such as the duck you can try:
- Draw normals - Toggle the ‘Draw normals’ checkbox. You should see green lines representing the normals.
- Turn on the debug normals shader - Select it from the ‘Debug Normals’ options. This will color the geometry based on the direction the normals are facing.
- Turn on wireframe mode - Choose ‘Blueprint’ from Select Wireframe. This allows you to inspect your mesh geometry.
- Draw extents of the object - Toggle the “Draw opaque nodes extents” option.
Since your game/app is run in JavaScript in the browser, its logical that the data is transferred JSON format. The Turbulenz JSON formats for assets are also specified in this documentation. Turbulenz provides a tool called the Disassembler for visualizing these assets from the local server.
Select the project with the assets you want disassemble. Try the Sample App.
Select the ‘Assets’ button
This time we will browse the files as they are laid out on the file system. Click on ‘View as Files’
Click on the folder ‘staticmax’. This is the folder where you put assets you would like to cache.
The green background for each row indicates that files has successfully been found in the mapping table (red rows indicate missing mappings). More details about staticmax and mapping tables see the introduction in the getting started guide and Creating a Mapping Table.
To look at the disassembled JSON for an asset, click the ‘disassemble’ button. Try this for the standard.cgfx shader.
You should see the disassembler view of the shader. The controls on the top allow you to expand the following:
- depth - How many levels deep the expanded JSON object tree is. This applies to all branches.
- list - If the JSON contains a ‘list’ or ‘array’, how many of the items are shown.
- dict - For JSON objects in the tree, what is the maximum number shown when expanded.
Each of these options can be performed per object by clicking on the blue more or less text.
Press the ‘reset’ button to return the tree to its initial state.
The User Data API provides the ability to save settings, game saves and other user specific data. On the local server you can inspect this data to ensure your game/app is correctly using the API.
- Select the project that uses the User Data API. In this case we will look at the example in ‘Samples’
- Select ‘Play’
- Choose a configuration that uses user data. Find the userdata.release.html configuration in the list and click on it.
- Perform some action that ends up setting data. In the case of userdata.release.html, save a different state of rotation to each of the save slots using the ‘set’ button. Try using ‘get’ button to retrieve the state of the duck to ensure it has worked.
- Go back to the project page on the local server
- Select ‘User Data’ button
- If there is data set, you will see a list of users.
Note
By default on the local server you will see a single user. The user will take on the user name of the account owner that is running the local server. To inspect this information and other profile information on local, see the documentation for the User Profile API.
- Select the user, in this case the username of the account hosting the server.
- You will see a list of keys and the respective sizes. Since the data is JSON, you will also see the option to disassemble the values.
- To download a copy of the file, click on the name of the key you want to inspect.
- Alternatively you can view the data in the ‘Disassembler’.
The local server includes the ability to deploy a build of your project directly to the Turbulenz Hub. For a configured project this is as simple as:
- Selecting a project to deploy.
- Pressing the ‘Deploy to Hub’ button.
- Filling in your Hub account information.
- Selecting which of your Hub projects to deploy to (including versioning).
- Pressing deploy and watching it transfer, ready for you to try remotely.
- Navigating to http://hub.turbulenz.com and playing it immediately.
There are a few checkboxes you need to check to get it ready to do this. The deploying to the Hub guide should help.
The login button on the top right of the local server page allows you to quickly switch between users. The current user is stored as a cookie. This cookie will be shared across the tabs on your browser. To login as multiple users simultaneously either:
This is most useful when debugging and testing the multiplayer, notifications and data share API’s.
Once you’ve discovered the basic features, here are a few more examples of how to use the local server on a day-to-day basis:
To add a new project to the local server requires:
- A root project directory - This is the directory structure for your project. All the references for your project must be files in this directory or sub-directories (This is so that they can be hosted by the server).
- Url safe naming of files - This applies only to the files you are going to serve. Generally you should replace whitespace with ‘_’ or ‘-‘. Url safe is uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde (Section 2.3 of RFC 3986)
- Play files need to be at root level - Files such as yourproject.canvas.release.html, yourproject.debug.html and yourproject.tzjs should be output at the root level. This allows the local server to locate and correctly serve them.
- The directory needs to have write permission - The directory should be located in a place where the local server has write permission. If it is run under account *USERNAME* then the directory must be writeable by that user.
Picking a suitable slug is an important step for your project. The slug is the unique part of the URL that represents your project on the live sites (Hub & game site). This cannot be the same as any other project on the site.
Usually this is the name of the game as your users would see it. You should use only url-safe characters. e.g. ‘awesome-adventure’ or ‘super-duck-3’
- Keep it concise.
- Don’t use any trademarks that don’t belong to you.
- Avoid the usual inappropriate words.
- lowercase with hyphens for spaces is recommended.
Note
Although worth considering now, your slug only needs to be globally unique on the live servers, not for the local server. This means that on local you can have extended slugs or slugs with additional configuration information. E.g.
super-duck-3: Suitable for the Hub, the game site and the local server. super-duck-3_v1.0_canvas-release: Only suitable on local server.
One choice you have is how to structure your project. You might want to create a working project or a deployed project. Here is a description of the terminology and advantages and disadvantages of each.
| Working Project: | |
|---|---|
A working project is a project that is structured ready to be hosted by a webserver. This usual means:
Advantages:
Disadvantages:
|
|
| Deployed Project: | |
A deployed project is a project that undergoes a ‘deployment’ step from your working directory to create a ‘build’ that is ready to deploy. Advantages:
Disadvantages:
|
|
These are the fields recognized by the local server and deploygame tool when loading/deploying manifest.yaml configurations.
Warning
Be careful when editing these files. Any errors can result in the failure of the server to load your project configuration. It is preferable to use the local server ‘Manage’ interface to edit the details.
| SDK 0.5.0 - 0.12.0: | |
|---|---|
| Version: 0.X | |
| SDK 0.13.0: | Version: 1.0 |
| SDK 0.19.0: | Version: 1.1 |
| SDK 0.20.0: | Version: 1.2 |
| SDK 0.21.0: | Version: 1.3 |
| SDK 0.23.0: | Version: 1.4 |
| SDK 0.24.0: | Version: 1.5 |
These versions of manifest.yaml are unofficially supported. They may require manual conversion to 1.0 or greater.
aspect_ratio
Added: 0.21.0
Summary: This defines the target ratio that the game expects the site to provide.
Note
The dimensions of the graphics device can be any width or height, but the browser will attempt to maintain this aspect ratio. Games still need to handle any dimensions provided by the graphics device.
Format: Ratio in the format X:Y (Single Quotes)
Description: The target aspect ratio of the project.
Requirements: Must be either defined as X:Y where X is the ratio for width and Y is the ratio for height X and Y must both be integers
Used by: Hub
Required by: Hub
Notes: The resulting aspect ratio is subject to pixel rounding per browser. The game must assume that it is rounded up or down to the nearest pixel in each dimension. The aspect ratio is only honored on turbulenz.com If no value is specified, it will default to 16:9.
Examples:
canvas_main
Added: 0.20.0
Summary: This is the file that will be the entry point to the canvas build configuration when deployed on the Hub. Format: String (No Quotes) Description: The name of the file that represents the canvas main of the project. Requirements: Must be either a .js (generated by maketzjs), .html file. The file must exist at the root level. No directories are allowed. The file must exist in the deploy_files section of the manifest file. Used by: Local, Hub Required by: Hub Notes: Can be ‘’ if not main is not yet defined. If not defined, the project will not deploy a canvas build to the Hub. Examples:
cover_art
Summary: This is the image shown on main page of the local server. It is used to help you visually select your project. Format: String (No quotes) Description: File path of the image to display. Requirements: The file pointed to should be a JPG/PNG. The file should have dimensions 160 x 234. The path must be exist in the root project directory or a sub directory. The path must be relative. Used by: Local Required by: None Notes: The image should be at the root level. Examples:
deploy_files
Summary: This is list of all the files that are required by your app/game to run. They will be uploaded to the Hub when deployed. You can use patterns to match groups of files. Format: List of Strings. Description: Filename OR file pattern to match. Requirements: The list must include a field identical to the ‘main’ and ‘mapping_table’ if those fields are defined. All patterns defined must be for files in the root directory or sub directories. Used by: Local, Hub Required by: Hub Notes: Added: 0.19.0: To include all files and sub-directories in a directory, use the ‘name/*’ notation. To include certain types of file e.g. *.js in sub-directories, an entry must be added for each sub-directory. See the examples. Examples:
deployed
DO NOT EDIT
Summary: This is the time and date the local server last deployed this configuration file. The local server will read and update this file. Format: String (No Quotes) Description: Time, date string in format (HH:MM | DD/MM/YYYY) OR Never Requirements: N/A Used by: Local Required by: Local Notes: This field should only be set by the local server. Examples:
engine_version
Added: 0.19.0, Modified: 0.23.0, Modified: 0.24.0
Summary: This defines the latest engine version that the project is compatible with. This information is used to inform the Hub, what the developer expects the configuration to be compatible with. This will usually represent the version the project has been tested locally against.
Format: String (Quotes)
Description: The engine version in the form X.X, where X.X is the engine interface version that the game requires.
Requirements: Modified: 0.24.0 As of SDK 0.24.0 the engine_version field must abide by these requirements:
Must be a valid 2-digit engine version. Must be formatted ‘X.X’ or ‘’
Used by: Hub
Required by: Hub
Notes: The tools in the SDK append an minimum compatible version. This field is in addition to that. Not specifying will default to the latest engine version.
Warning
By not specifying an engine version, your game will request the version of the SDK with which it was uploaded to the Hub, which may be incompatible with interfaces used by the game. Please make sure to consider the compatible engine carefully.
Examples:
is_multiplayer
Added: 0.21.0
Summary: This defines if this configuration is compatible with the Turbulenz multiplayer system. If this value is true, additional functionality is enabled on the Hub to view, join and manage active sessions for the project. Format: Boolean Description: true OR false Requirements: N/A Used by: Hub Required by: Hub Notes: Examples:
is_temp
DO NOT EDIT
Summary: This defines if this configuration is temporary. This is usually true when a new project configuration is in the process of being created. Format: Boolean Description: true OR false Requirements: N/A Used by: Local Required by: Local Notes: This field should only be set by the local server. Examples:
main
Depricated: 0.20.0 (Unused)
Summary: This field is unused, but has been left in for backwards compatibility. It has been replace by ‘canvas_main’ and ‘plugin_main’ Treat this field as DO NOT EDIT.
mapping_table
Summary: This is the file that will be the entry point to the configuration when deployed on the Hub. Format: String (No Quotes) Description: The name of the file that represents the main of the project. Requirements: Must be either a .js, .tzjs or .html file. The file must exist at the root level. No directories are allowed. The file must exist in the deploy_files section of the manifest file. Used by: Local, Hub Required by: Hub Notes: If not defined, the project cannot be deployed. Examples:
modified
Summary: This is the time and date the local server last modified this configuration file. The local server will read and update this file. Format: String (No Quotes) Description: Time, date string in format (HH:MM | DD/MM/YYYY) OR Never Requirements: N/A Used by: Local Required by: Local Notes: This field should only be set by the local server. Examples:
path
DO NOT EDIT
Summary: This is path that the local server has used to locate the project directory. This is written when the project is added to the local server. Format: String (No Quotes) Description: Directory of the project root. Can be absolute OR relative to *SDKINSTALLDIR*/devserver/games/ Requirements: Must be the same path as the path to the root directory that the manifest file corresponds to. Used by: Local Required by: Local Notes: This field should only be set by the local server. Examples:
plugin_main
Added: 0.20.0
Summary: This is the file that will be the entry point to the plugin build configuration when deployed on the Hub. Format: String (No Quotes) Description: The name of the file that represents the plugin main of the project. Requirements: Must be either a .tzjs (generated by maketzjs), .html file. The file must exist at the root level. No directories are allowed. The file must exist in the deploy_files section of the manifest file. Used by: Local, Hub Required by: Hub Notes: Can be ‘’ if not main is not yet defined. If not defined, the project will not deploy a plugin build to the Hub. Examples:
slug
Summary: This is part of the url that is used to locate project on the local server. It is used by the local server and tools to identify the project they perform actions on. Format: String (No Quotes) Description: A url-safe identifier that uniquely identifies this project. Requirements: Must be url-safe. (Section 2.3 of RFC 3986) No white space. Must be unique on this local server (no other projects with the same slug). Used by: Local Required by: Local Notes: This usually automatically defined by the project title, but is not a requirement. Examples:
title
Summary: This is the title of the project as displayed on the main local server page. This should help the user of the server quickly identify which project/configuration they are looking at. Format: String (No Quotes) Description: The human readable name for the project. Whitespace is allowed. Requirements: UTF8 string. No white space. Must be unique on this local server (no other projects with the same slug). Used by: Local Required by: Local Notes: This usually automatically defined by the project title, but is not a requirement. Examples:
title_logo
Depricated: 0.19.0 (Unused)
Summary: This field is unused, but has been left in for backwards compatibility. Treat this field as DO NOT EDIT.
Warning
Future versions of the manifest files may not be backward compatible with older local servers. Loading manifest.yaml files on those local servers may result in loss of configuration data. All versions of 1.X should be forward compatible unless marked as such.
This section contains a list of frequently asked questions (FAQ) relating the use of the local server. If you are trying to troubleshoot a problem, try checking this section before requesting support from Turbulenz.
| How do I stop the local server?: | |
|---|---|
Windows:
Mac / Linux:
If you can still see the server, make sure you don’t have another instance open in another terminal. |
|
| How do I manually start the local server?: | |
|---|---|
If you encounter an error at this stage, make an note of the error and send it to Turbulenz. |
|
| How do I change the port number of the local server?: | |
|---|---|
You may find that on some occasions you want to run multiple versions of the local server (from different SDKs for example). It might even be the case that you have another service on your computer that requires port 8070. To change the port:
|
|
| How do I change the local server configuration?: | |
|---|---|
If in the unlikely event you are required to change the server configuration in any way, you will need to edit the release.ini file in the devserver directory of the SDK. Warning Modifying this file, unless specified by Turbulenz, is not recommended. Changes could affect the setup of your local server. If in doubt restore the default release.ini file from the Turbulenz SDK. To change the configuration:
|
|
These hints are steps to try if you become stuck when using the local server:
My local server doesn’t appear to be running
If you navigate to the default server location http://127.0.0.1:8070, you should see a web page with a list of games on it. If you get a browser message such as ‘Unable to connect’, the browser can’t find the server or something has gone wrong starting local.
Try the following:
- Wait a few seconds
- Refresh the page
- Check that the browser is not in an ‘offline mode’ (Firefox)
If you still see the same page you will need to look at the local server console:
- Windows:
- Is there an open command window on your taskbar that with a title “Run Local Server X.X.X” that says:
Serving on 0.0.0.0:8070 view at http://127.0.0.1:8070
- Mac / Linux:
- In the Terminal you ran the ./start_local.sh command, does it say:
Serving on 0.0.0.0:8070 view at http://127.0.0.1:8070
- If NO:
- You may need to try starting the server again manually.
- See manual starting of local server
- If you see addition text in the window other than the default message (without navigating to it in the browser) it is likely an error.
If YES:
Have you tried playing a game previously?
If so, is there any activity in that window such as: [13/Mar/2007 13:37:00] “GET /play/myawesomegame/myawesomegame.debug.html” 200 5167 (OK)
- If NO:
There appears to be a communication error between the browser and the server.
- Check you are not trying to access the wrong port i.e. something other than 8070.
- Check that you don’t have something else running on that port.
- If YES:
Your server has been working at some point.
- Try restarting the browser in case it dropped the connection.
- Try navigating to the same page with a different browser.
In the local server terminal window, if you see something that looks like a python stack trace. Copy the text in the window and send it Turbulenz via the support system.
| When trying to run the devserver manually I get the error: | |
|---|---|
socket.error: [Errno 48] Address already in use: This means that you are probably running another elsewhere (in another terminal window) or another application is using the port you specified. Try looking for the server and shutting it down. The default port for the local server is 8070. This guide describes how to change the port that the local server is running on. |
|
| When running the Asset Viewer, I only see a gray background: | |
Have you installed the Turbulenz Engine component?
Is the Engine compatible with the version of the SDK that you are using it with?
Do other apps work?
Do other assets work?
Are there any options in the Select Wireframe and Debug Shader boxes?
If the answer to all these questions is ‘no’ then submit a support request to Turbulenz outlining:
Please include the output of the ‘device_initialization’ sample, if you are able to run it. |
|
| The Asset Viewer loads but the object is missing/partial, only the blue grid appears: | |
Is the type of the asset in Turbulenz JSON format and either a geometry, animation, physics data etc?
Can you see the asset in the file system?
Has the object been exported with the normals in the wrong direction?
Do you specify a bound volume?
Some assets may not be renderable or have properties not supported by the viewer. Sending Turbulenz Support more information about the asset may help:
|
|