NQ-Deckard

Sample Scripts (Basic)
The following scripts are intended to minimally demonstrate basic usage of render script.
 
Checkerboard Creates a simple checkerboard pattern by covering the screen with rectangles of alternating color. 
local resX, resY = getResolution() local tilesX, tilesY = 32, 16 local tileW, tileH = resX / tilesX, resY / tilesY local layer = createLayer() for y = 0, tilesY - 1 do local color = y % 2 for x = 0, tilesX - 1 do if color == 0 then setNextFillColor(layer, 1, 1, 1, 1) else setNextFillColor(layer, 0, 0, 0, 1) end addBox(layer, x * tileW, y * tileH, tileW, tileH) color = (color + 1) % 2 end end  

 
Simple Text Draws some lines of text. 
local lines = { "Lua screen units are great!", "They can render lots of contents...", "even really smooth, complex animations!", "They're very fast.", "They're not as easy to use as HTML,", "...but once you get the hang of them...", "you'll be unstoppable.", } local fontSize = 32 local font = loadFont('Play', fontSize) local layer = createLayer() local y = fontSize + 16 for i, line in ipairs(lines) do addText(layer, font, line, 16, y) y = y + fontSize + 2 end  

 
Bouncy Ball Demonstrates usage of both one-time initialization for local persistent data, as well as requestAnimationFrame(), to draw a moving ball that bounces off the edges of the screen.
local resX, resY = getResolution() local dt = 100 * getDeltaTime() -- initialize ball position once if not init then init = true ball = {} ball.x = resX * math.random() ball.y = resY * math.random() ball.vx = 2 * math.random() - 1 ball.vy = 2 * math.random() - 1 ball.radius = math.min(resX, resY) / 8 end -- animate ball position ball.x = ball.x + ball.vx * dt ball.y = ball.y + ball.vy * dt if ball.x < ball.radius or ball.x > (resX-ball.radius) then ball.x = ball.x - ball.vx * dt ball.vx = -ball.vx end if ball.y < ball.radius or ball.y > (resY-ball.radius) then ball.y = ball.y - ball.vy * dt ball.vy = -ball.vy end -- render local layer = createLayer() addCircle(layer, ball.x, ball.y, ball.radius) requestAnimationFrame(1)  
 
 

Technical Details
How to use Properties Different shapes support different properties that can be set to alter various aspects of the rendering of the shape. The current properties are: 
fillColor - the interior color of the shape 
rotation - the angular orientation of the shape about its center 
shadow - the shadow of the shape 
strokeColor - the color the border around the shape 
strokeWidth - the size, in pixels of the border around the shape; negative values produce an interior border, while positive values produce an exterior border 
The current API design requires that these properties are set before adding the shape, so that, for example, rendering a red rectangle looks as follows: 
local layer = createLayer() setNextFillColor(layer, 1, 0, 0, 1) -- red with 100% alpha addBox(layer, 0, 0, 16, 16)  
When you set a property, it does not persist. Thus, to render many red rectangles, you must call setNextFillColor each time. 

Note that every shape rendering command consumes all properties for that layer even if the shape does not support them. 
This is for safety and to ensure that the global state does not impact your script in confusing ways. 
For example, although images do not currently support a stroke color or width, if you call setNextStrokeWidth before addImage, the stroke width will be reset to the default after the call to addImage. 
Consult the above API specifications to learn which properties are supported for which shapes. 
 
Shape Render Order When you need explicit control over the top-to-bottom ordering of rendered elements, you should use layers.
As stated in the createLayer() API documentation, each layer that is created within a script will be rendered on top of each previous layer, such that the first layer created appears at the bottom, while the last layer created appears at the top.
 
Shapes that live on the same layer do not offer as much control. Among the same type of shape, instances rendered later will appear on top of those rendered before. So if you add two boxes to a layer, the last box added will appear on top.
 
However, the situation is more complex when mixing different shapes. For efficiency, rendering happens in batches, so that all instances of a given shape on the same layer are drawn at the same time.
 
This means, in general, that all instances of one shape will appear below or above all instances of other shapes, regardless of the relative order in which they were added to the layer.
 
Currently, the ordering is as follows, from top to bottom:
addText() -- Top addQuad() addTriangle() addLine() addCircle() addBoxRounded() addBox() addImage() -- Bottom  
Thus, all boxes will always render below all circles on the same layer, and text on the same layer will appear on top of both.
It is not possible to control this behavior, nor is it a good idea to rely on it, as it is subject to change in the future.
If you need to rely on something appearing in front of something else, you should probably use multiple layers. (There is currently a maximum of 8 layers)
 
Render Cost Limitations Since render script is intended to solve screen unit performance problems, we impose relatively harsh restrictions on content compared to HTML.  
This does not mean you won’t be able to create amazing, detailed, high-framerate screen contents – it simply means that you’ll need to be aware of the budgeting mechanism. 

Any render script call that draws a shape (box, circle, line, text..) adds to a hidden ‘cost’ metric, that consumes some of the screen’s total rendering budget.
The details of how this cost is computed are beyond the scope of this document, and it is likely that they will undergo changes in the future as we learn how to best optimize this technology. Roughly-speaking, however, the render cost incurred by any shape is proportional to the screen-space area of the shape, plus a constant factor.
 
This means that a box of dimension 16 x 16 consumes roughly four times as much render cost as a box of 8 x 8 . This is fairly intuitive when you realize that the number of pixels filled by the larger box is,  indeed, four times that of the smaller box. Note that four times is not exact, as we neglected to consider the constant factor, but it is close enough. 

For most render scripts, it is unlikely that the maximum cost will ever be exceeded, so most users probably don’t need to worry too much about this mechanism. However, drawing lots of large text or lots of large, overlapping images, may cause you to exceed the budget. 

If you wish to dig deeply into this mechanism, you can do so using the built-in API calls getRenderCost() and getRenderCostMax().
getRenderCost() can be called at any point during a render script to see how much all the contents added so far costs.
You can use this function to profile the specific cost of specific shapes, if you wish. 
 
It is easy enough to draw a render cost profiler on top of your screen to help you understand this mechanism. You can add this snippet at the end of your script to do so (you may need to adjust the text’s fill color if your background is a light colour):
-- render cost profiler if true then local layer = createLayer() local font = loadFont('Play-Bold', 14) setNextFillColor(layer, 1, 1, 1, 1) addText(layer, font, string.format('render cost : %d / %d', getRenderCost(), getRenderCostMax()), 8, 16) end  
Coordinate Space All render script coordinates are in screen pixels, ranging from (0, 0) at the top-left of the screen, to (width, height) at the bottom-right.
The width and height of the screen in pixels can be retrieved by calling getResolution().
For maximal robustness, and the ability to fit different aspect ratios, scripts should be written so as to adapt to the resolution using getResolution().
 
Control Units and Synchronization It is important to know that screen unit Lua runs locally to the player viewing it, this means that dynamic content seen for one player will likely not match what is seen by another player as the two will often be in differing states. For example the bouncy ball example below will not display the ball in the same location for both players viewing the same screen. To achieve similar results for multiple players you can route communication to a screens getInput() which can be interacted with from the control unit side using screen.setScriptInput(). By setting the screen.setScreenInput() from a programming board, we set a string variable (getInput()) for all viewers of the screen unit that will synchronize about once per second. (This is already a considerable amount faster than HTML does currently.)
 
Similarly a screen unit can set an output string variable using setOutput() which can then be read by the programming board using screen.getScriptOutput() to receive data back from the screen. It is important to note that a screens output field is local only, this is a technical limitation for synchronization reasons. 
 
The limits of these fields are currently 1024 characters at any given time.
 
Using JSON strings it is possible to send back and forth packets of data to and from the screens for the player running both the control unit and the screen.
All other players are limited to the input field only, this allows for one player to "control" the interaction and data exchange between the programming board and screen unit. And all others to use and operate the screen using the screen Lua.

An example of how we see this working, would be that the pilot of a ship controls it from the control seat with a screen in front of them which allows them to see various readouts from their ship. Using a mouse they are able to click various interface parts to use the screen to control aspects of their ship. These are relayed back to their control unit using setOutput(). In the meantime fellow crew members are still able to see those readouts animated and moving in real time from their perspective, even if the data they are receiving is only synchronized once per second.
 

Render Script Lua API (PTS v1.1)
Shapes Squares
addBox(layer, x, y, width, height) Add a rectangle to the given layer with top-left corner (x, y) and dimensions width x height. 
Supported properties: fillColor, rotation, shadow, strokeColor, strokeWidth
 
 Rounded Squares (New!)
addBoxRounded(layer, x, y, width, height, radius) Add a rectangle to the given layer with top-left corner (x, y) and dimensions width x height with each corner rounded to radius. 
Supported properties: fillColor, rotation, shadow, strokeColor, strokeWidth
 
 Circles
addCircle(layer, x, y, radius) Add a circle to the given layer with center (x, y) and radius radius. 
Supported properties: fillColor, shadow, strokeColor, strokeWidth
 
 Images
addImage(layer, image, x, y, width, height) Add image reference to layer as a rectangle with top-left corner (x, y) and dimensions width x height. 
Supported properties: fillColor, rotation 
 
 Lines
addLine(layer, x1, y1, x2, y2) Add a line to layer from (x1, y1) to (x2, y2). 
Supported properties: rotation, shadow, strokeColor, strokeWidth
 
 Quadrilaterals
addQuad(layer, x1, y1, x2, y2, x3, y3, x4, y4) Add a quadrilateral to the given layer with vertices (x1, y1), (x2, y2), (x3, y3), (x4, y4). 
Supported properties: fillColor, rotation, shadow, strokeColor, strokeWidth 
 
 Text
addText(layer, font, text, x, y) Add text to layer using font reference, with top-left baseline starting at (x, y).
Note that each glyph in text counts as one shape toward the total rendered shape limit. 
Supported properties: fillColor 
 
 Triangles
addTriangle(layer, x1, y1, x2, y2, x3, y3) Add a triangle to the given layer with vertices (x1, y1), (x2, y2), (x3, y3). 
Supported properties: fillColor, rotation, shadow, strokeColor, strokeWidth 
 
Layers Creating a new layer
createLayer() -> int Create a new layer and return a handle to it that can be used by subsequent calls to the above add shapes. 
Layers are rendered in the order in which they are created by the script, such that all shapes on layer N+1 will appear on top of layer N. 
This results in the first created layer being the in the background and the last created layer will be in the foreground.
Layers now have a fixed render cost and are no longer limited to 8.
 
 Set Screen Background (New!)
setBackgroundColor(r, g, b) Set the background color of the screen as red (r), green (g), blue (b) in the range [0, 1]
 
Screen State Functions Get Cursor Coordinates
getCursor() -> int, int Return the screen location that is currently raycasted by the player in screen pixel coordinates as a (x, y) tuple. 
Returns (-1, -1) if the current raycasted location is not inside the screen. 
 
Get Cursor Down State (New!)
getCursorDown() -> boolean Return true if the mouse cursor is currently pressed down on the screen, false otherwise. 
Retains its state if dragged out of the screen.
 
Get Cursor Pressed (New!)
getCursorPressed() -> boolean Return true if the mouse button changed from being released to being pressed at any point since the last update.
Note that it is possible for both getCursorPressed() and getCursorReleased() to return true in the same script execution, if the mouse button was both pressed and released since the last execution. 
 
Get Cursor Released (New!)
getCursorReleased() -> boolean Return true if the mouse button changed from being pressed to being released at any point since the last update.
Note that it is possible for both getCursorPressed() and getCursorReleased() to return true in the same script execution, if the mouse button was both pressed and released since the last execution. 
 
Get Delta Time
getDeltaTime() -> float Return the time, in seconds, since the screen was last updated. Useful for timing-based animations, since screens are not guaranteed to be updated at any specific time interval, it is more reliable to update animations based on this timer than based on a frame counter.
 
 Get Render Cost
getRenderCost() -> int Return the current render cost of the script thus far, used to profile the performance of a screen.
This can be used to abort further render instructions when close to the render maximum preventing the screen from shutting down.
 
 Get Maximum Render Cost
getRenderCostMax() -> int Return the maximum render cost limit. When a script exceeds this render cost in one execution, an error will be thrown and the contents will fail  to render. 
 
 Get Resolution
getResolution() -> int, int Return the current viewport resolution as a (width, height) tuple.
 
 Log Message to Lua Chat (New!)
logMessage(message) Write message to the Lua chat if the output checkbox is checked.
 
Loading References Loading Images
loadImage(path) -> int? Return an image handle that can be used with addImage. If the image is not yet loaded, a sentinel value will be returned that will cause addImage to fail silently, so that the rendered image will not appear until it is loaded. Only images that have gone through image validation are available.
 
Loading Fonts
loadFont(name, size) -> int? Return a font handle that can be used with addText. The font size is size vertical pixels. If the font is not yet loaded, a sentinel value will be returned that will cause addText to fail silently, so that the rendered text will not appear until the font is loaded.  A maximum of 8 fonts can be loaded for each render.
Name must be one of the following currently-available fonts:
FiraMono FiraMono-Bold Montserrat Montserrat-Light Montserrat-Bold Play Play-Bold RefrigeratorDeluxe RefrigeratorDeluxe-Light RobotoCondensed RobotoMono RobotoMono-Bold New: We added monospaced fonts
 
 Is Image Loaded (New!)
isImageLoaded(imageHandle) -> bool Returns true if the given imageHandle is loaded.
 
 Get Text Bounds (New!)
getTextBounds(font,text) -> float, float Compute and return the bounding box width and height of the given text in the given font as a (width, height) tuple.
 
 Get Font Metrics (New!)
getFontMetrics(font) -> float, float Compute and return the ascender and descender height of given font.
 
Animation  Request refresh in amount of frames
requestAnimationFrame(frames) Notify the screen manager that this screen should be redrawn in frames frames.
A screen that requires highly-fluid animations should thus call requestAnimationFrame(1) before it returns. 
Usage of this function has an obvious and significant performance impact on the screen unit system.
Scripts should try to request updates as infrequently as possible for their application. 
A screen with unchanging (static) contents should not call this function at all. 
 
Properties Defaults (New!) Shape Types (New!)
For shapeType defaults the following constants are valid:
Shape_Box Shape_BoxRounded Shape_Circle Shape_Image Shape_Line Shape_Polygon Shape_Text  
 Set Default Fill Color (New!)
setDefaultFillColor(layer, shapeType, r, g, b, a) Set the default fill color for all shapeType on layer. 
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the fillColor property.
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Default Rotation in Radians (New!)
setDefaultRotation(layer, shapeType, radians) Set the default rotation for all shapeType on layer. 
Rotation is specified in CCW radians radians. 
Has no effect on shapes that don't support the rotation property. 
 
 Set Default Shadow (New!)
setDefaultShadow(layer, shapeType, radius, r, g, b, a) Set the default shadow for all shapeType on layer with size radius.
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the shadow property. 
 
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Default Stroke Color (New!)
setDefaultStrokeColor(layer, shapeType, r, g, b, a) Set the default stroke color for all shapeType on layer. 
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the strokeColor property. 
 
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Default Stroke Width (New!)
setDefaultStrokeWidth(layer, shapeType, width) Set the default stroke width for all shapeType on layer. Width is specified in pixels. 
Positive values produce an outer stroke, while negative values produce an inner stroke. 
Has no effect on shapes that don't support the strokeWidth property. 
 
Properties Set Fill Color for the next shape
setNextFillColor(layer, r, g, b, a) Set the fill color of the next rendered shape on layer. 
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the fillColor property.
 
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Rotation for the next shape in Radians
setNextRotation(layer, radians) Set the rotation of the next rendered shape on layer. 
Rotation is specified in CCW radians radians. 
Has no effect on shapes that don't support the rotation property. 
 
 Set Rotation for the next shape in Degrees
setNextRotationDegrees(layer, degrees) Set the rotation of the next rendered shape on layer. 
Rotation is specified in CCW degrees degrees. 
Has no effect on shapes that don't support the rotation property. 
 
 Set Shadow for the next shape (New!)
setNextShadow(layer, radius, r, g, b, a) Set the shadow of the next rendered shape on layer with size radius.
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the shadow property. 
 
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Stroke Color for the next shape
setNextStrokeColor(layer, r, g, b, a) Set the stroke color of the next rendered shape on layer. 
Red (r), green (g), blue (b), and alpha (a) components are specified, respectively, in the range [0, 1].  
Has no effect on shapes that don't support the strokeColor property. 
 
For users who are used to using colors in the range [0, 255] they can simply divide their color by 255 to achieve a [0,1] range.
For example: setDefaultFillColor(layer,shapeType, 50/255, 150/255 , 200/255, 255/255)
 
 Set Stroke Width for the next shape
setNextStrokeWidth(layer, width) Set the stroke width of the next rendered shape on layer. Width is specified in pixels. 
Positive values produce an outer stroke, while negative values produce an inner stroke. 
Has no effect on shapes that don't support the strokeWidth property. 
 
 Set Text Alignment for the next shape (New!)
setNextTextAlign(layer, alignH, alignV) Set the next text alignment for the next rendered shape on layer.
alignH controls the horizontal alignment of a text shape relative to the draw coordinates.
alignV controls the vertical alignment of a text shape relative to the draw coordinates.
 
alignH must be one of the following built-in constants:
AlignH_Left AlignH_Center AlignH_Right  
alignV must be one of the following built-in constants:
AlignV_Ascender AlignV_Baseline AlignV_Top AlignV_Middle AlignV_Bottom AlignV_Descender  
Note that there is a subtle difference between AlignV_Ascender/AlignV_Descender and AlignV_Top/AlignV_Bottom: the ascender and descender alignment modes anchor a text string to a global top/bottom position of the font, while the top and bottom alignment modes anchor a text string relative to its own bounding box. Thus, while top/bottom are useful for aligning individual text strings with high precision, they depend on the contents of the text string that is rendered. On the other hand, ascender/descender align text in such a way that the alignment will not change depending on the text string. The correct choice will depend on your specific use case and needs.
 
Control Unit Interaction Get Input (New!)
getInput() -> string Return a string of input data (or an empty string, if no input has been set) that can be set via a control unit with the screen unit API function screen.setScriptInput(inputString).
 
 
Set Output (New!)
setOutput(outputString) Set the script’s output string to outputString, which can be retrieved via a control unit with the screen unit API function screen.getScriptOutput().
 

Introduction
Updated: 19/07/2021
 
Lua screen units are a new technology aimed at solving the performance issues associated with our current implementation of HTML on screens, while bringing a new feature allowing complex animations with thousands of graphical elements.
 
Alongside of setting HTML on screen units, it is now possible to set a render script on screen units instead.
Render scripts are Lua scripts residing inside the screen units themselves that provide rendering instructions for screen units. 

Each screen also has a maximum render cost to limit the impact a single screen can have on users that are able to see it, this is important as the impact of a screen is not limited to only the creator of the screen's render script or content but also other nearby players.
 
Inside the render script the content is built up using layers which are rendered on top of each other in order of creation at the end of the render script.
 
After creating a layer, it is then possible to optionally specify a few parameters for the next shape you intend to add to that layer. Such as stroke color, fill color, stroke width and rotation depending on what's available for that shape. Once those parameters are defined we then use "add" functions that draw shapes on those layers using those parameters.
 
If the screen is intended to be a static display there is no further requirement, if you wish for the screen to be animated we can then add:
requestAnimationFrame(<frames>) Using this at the end of the script which will aim to refresh the screen after <frames> amount of frames.
This should only be used when required for animated content. For performance reasons we recommend not calling this function if no animations are intended to be run.
 
In future we will further expand on this feature to provide more functionality and synergy with control units allowing for far more efficient and responsive screens in the game.
 
Getting Started
To start creating renderscripts we start by right clicking the screen and using the context menu option Edit Content (Ctrl+L) to start editing the screen.

 
This will bring up a new Lua & HTML editor window which will allow you to switch between Lua (Render Script) and HTML display modes.

 
In Lua mode it will provide error reporting for the render script in the lower portion of the screen, and to aid in debugging processes there is a check box which will allow you to write to the Lua Channel using logMessage("message") inside the renderscript. This is logging method is local only to you if you have the check box enabled and will be automatically be disabled when the screen is unloaded.
 
Drawing screen contents with render scripts consists of creating one or more layers, on which shapes will be drawn, and then adding shapes to these layers to populate the screen contents. The API currently supports relatively basic shapes: rectangles, circles, lines, triangles, quadrilaterals along with images and text. In the future, we will consider adding more complex shapes as we receive your feedback. 
 
Take a look at this basic ‘hello world’ render script: 
local layer = createLayer() -- Creates a new layer local rx, ry = getResolution() -- Gets the resolution of the screen local font = loadFont("Play", 20) -- Loads the "Play" font at size 20 setNextFillColor(layer, 1, 0, 0, 1) -- Prepares the fill color (Red,Green,Blue,Alpha) for the next shape to be drawn on the layer addBox(layer, rx/4, ry/4, rx/2, ry/2) -- Adds a box shape to layer, starting a 1/4th into the screen, with half the screens width and height addText(layer, font, "Hello world!", rx/3, ry/2) -- Adds a text shape without any properties to layer, using the font, one third from the left, and half way down.  
This script renders a red rectangle that is half the size of the screen, in the center of the screen, and "Hello World!" on top. Simple! 

 

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

Actually, a multitude of causes and edge cases leading to this have been fixed. But clearly there may be a few more, will look into it again.

If I look at my factory, it seems that every production that is running and finishes during the patch period gets in an error state. Pending elements, or products that need a long runtime seem to be fine.

We have identified a bug that permits the initiation of combat while constructs are in warp.
This is an unintended behaviour and will be removed and prevented in a future update.

From 17:30 UTC on January 4th, 2022 going forward, the action of initiating PvP between two constructs while in warp will not permitted and will be subject to intervention by Novaquark.

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

In short, I suppose this is possible. The chances of that happening however are very very small. 
How often have you accidentally collided with asteroids so far?

 
 
Zarcata hit this nail on the head.
 
We still have no intention to reset everything at this time, and will avoid doing so if we can.
 
 
Quite a few of those are still out there undiscovered!
 
 
All these questions will be answered in a later devblog when we have more information to share with you. Many of the listed features and systems are still undergoing a lot of change. As such it's to early for us to go into specifics at this time.
 
 
The Camera Lua API will provide a way for control units to retrieve the view direction of the player. Allowing for improved tracking and overlaying in player made Lua scripts such as some of the already very impressive "Alternate Reality" overlays some of our players have been making. It will not however introduce new camera views.
 
 
Sure, it needs to happen during a maintenance. The materials for the maintenance are not ready, and rather than introducing new bugs and issues to the game it was postponed by one day.
 
- NQ-Deckard

We have identified a bug that permits the initiation of combat while constructs are in warp.
This is an unintended behaviour and will be removed and prevented in a future update.

From 17:30 UTC on January 4th, 2022 going forward, the action of initiating PvP between two constructs while in warp will not permitted and will be subject to intervention by Novaquark.

We have identified a bug that permits the initiation of combat while constructs are in warp.
This is an unintended behaviour and will be removed and prevented in a future update.

From 17:30 UTC on January 4th, 2022 going forward, the action of initiating PvP between two constructs while in warp will not permitted and will be subject to intervention by Novaquark.

Hello fellow Noveans! This is your friendly neighborhood coder, Nikolaus (Ephranor#8746), here with yet another big update to the DU Factory Generator:
 
https://tvwenger.github.io/du-factory-generator/latest/
 
Given a set of items to build, this tool will determine a factory plan from raw ores to the final products. The factory is designed to support the production rates of all intermediate industries. Therefore, this is a factory plan that will maximize production efficiency even after production interruptions.
 
Some new features in version 4.0:
Support for talents! Calculate ore values of produced items Add some missing items Minor bug fixes and performance improvements   Give it a go and let me know what you think! If you have any questions or problems, please let me know. Links to the Github repository and Discord server are on the bottom of the website.
Happy building!

We have identified a bug that permits the initiation of combat while constructs are in warp.
This is an unintended behaviour and will be removed and prevented in a future update.

From 17:30 UTC on January 4th, 2022 going forward, the action of initiating PvP between two constructs while in warp will not permitted and will be subject to intervention by Novaquark.

Ring in the new year with a parade of Dual Universe community streamers in the second-annual Stream-a-Thon! The two-day event starts at 14:00 UTC | 9:00 am EST on Friday, December 31st. 
 
Throughout the remainder of the day and into the next, you’ll be entertained by a variety of streamers including Gottchar, Shamsie, and many others who will share their expertise about the game. You’ll also have a chance to win gametime codes and in-game goodies*!   
 
SCHEDULE 
Friday, Dec. 31
14:00 - Gottchar 17:00 - Rexsilex 20:00 - fridaywitch 23:00 - Shamsie Saturday, Jan 1
2:00 - AngryDadGaming 6:30 - NeoCrypter  
Head over to the official Dual Universe Twitch channel now to follow and turn on notifications so you don’t miss the fun. 
 
* Please note that these are community-donated gifts. Novaquark is not responsible for any lost, misdirected, or undelivered items. 
 

Introduction
Updated: 19/07/2021
 
Lua screen units are a new technology aimed at solving the performance issues associated with our current implementation of HTML on screens, while bringing a new feature allowing complex animations with thousands of graphical elements.
 
Alongside of setting HTML on screen units, it is now possible to set a render script on screen units instead.
Render scripts are Lua scripts residing inside the screen units themselves that provide rendering instructions for screen units. 

Each screen also has a maximum render cost to limit the impact a single screen can have on users that are able to see it, this is important as the impact of a screen is not limited to only the creator of the screen's render script or content but also other nearby players.
 
Inside the render script the content is built up using layers which are rendered on top of each other in order of creation at the end of the render script.
 
After creating a layer, it is then possible to optionally specify a few parameters for the next shape you intend to add to that layer. Such as stroke color, fill color, stroke width and rotation depending on what's available for that shape. Once those parameters are defined we then use "add" functions that draw shapes on those layers using those parameters.
 
If the screen is intended to be a static display there is no further requirement, if you wish for the screen to be animated we can then add:
requestAnimationFrame(<frames>) Using this at the end of the script which will aim to refresh the screen after <frames> amount of frames.
This should only be used when required for animated content. For performance reasons we recommend not calling this function if no animations are intended to be run.
 
In future we will further expand on this feature to provide more functionality and synergy with control units allowing for far more efficient and responsive screens in the game.
 
Getting Started
To start creating renderscripts we start by right clicking the screen and using the context menu option Edit Content (Ctrl+L) to start editing the screen.

 
This will bring up a new Lua & HTML editor window which will allow you to switch between Lua (Render Script) and HTML display modes.

 
In Lua mode it will provide error reporting for the render script in the lower portion of the screen, and to aid in debugging processes there is a check box which will allow you to write to the Lua Channel using logMessage("message") inside the renderscript. This is logging method is local only to you if you have the check box enabled and will be automatically be disabled when the screen is unloaded.
 
Drawing screen contents with render scripts consists of creating one or more layers, on which shapes will be drawn, and then adding shapes to these layers to populate the screen contents. The API currently supports relatively basic shapes: rectangles, circles, lines, triangles, quadrilaterals along with images and text. In the future, we will consider adding more complex shapes as we receive your feedback. 
 
Take a look at this basic ‘hello world’ render script: 
local layer = createLayer() -- Creates a new layer local rx, ry = getResolution() -- Gets the resolution of the screen local font = loadFont("Play", 20) -- Loads the "Play" font at size 20 setNextFillColor(layer, 1, 0, 0, 1) -- Prepares the fill color (Red,Green,Blue,Alpha) for the next shape to be drawn on the layer addBox(layer, rx/4, ry/4, rx/2, ry/2) -- Adds a box shape to layer, starting a 1/4th into the screen, with half the screens width and height addText(layer, font, "Hello world!", rx/3, ry/2) -- Adds a text shape without any properties to layer, using the font, one third from the left, and half way down.  
This script renders a red rectangle that is half the size of the screen, in the center of the screen, and "Hello World!" on top. Simple! 

 

Dear Noveans,
 
We read all your feedback about the changes coming about Element stacking. We agree the previous announcement on the topic was made on a very short notice. As a result, we will limit the Construct deletion to Constructs with stacked Elements which meet both of the following requirements:
The involved Construct has been involved in PvP after Ares release. The involved Construct has also been reported to the Customer Support which will address the situation accordingly.
Clarifications:
There will be no automatic deletion after Ares update hits the live server. Construct deletion will only happen in the case that the said Construct with stacked Elements has been reported for participating in PvP (and proof has been found on our side). If you’re not sure your Construct(s) have stacked Elements, if you have any doubt, don’t use the involved Constructs in PvP until you are sure there are no stacked Elements. Ultimately, in the update after Ares (Demeter), constructs will be negatively impacted if they contain stacked elements, we don’t currently have specifics yet but see this as an advanced notice. Elements Stacking is a bug, there’s no way around it. As a bug, especially one generating a lot of gameplay imbalance, it has to disappear at some point. So here’s a heads up for all builders who made Constructs with stacked Elements.  
The Ares update approaches, it's time for a maintenance! It will start tomorrow on Tuesday the 21st at 11:00 UTC and the Live server should reopen at 15:00 UTC if everything unfolds as planned. 
 
There will be another maintenance on Wednesday from 08:00 UTC to 09:30 UTC, but more information on that will follow soon.

It is very clear, we had an issue, and we have implemented a solution.
 
The specifics are simply not up for sharing. The announcement is there to let you know that territories have been credited with additional time as part of the solution and why.
I will not being going into technical detail for every change or alteration we make, we will let you know what effect it has on our players however.
 
That's the purpose of the communication. ?
 
- Deckard.

Hello everyone,
 
To be very clear, this is not the right place to report constructs.
We have a new in-game reporting feature which you can use to simply right-click on a construct and report it, that goes directly to the GM's.
 
I hope this clear this up.
- Deckard

You would indeed be correct in that it is an edge case,
 
However, even from the ground you have the ability to file a generic report if you feel you need to.
For example:
 
 
- Deckard

Unfortunately that's a little beyond my own scope, however I can tell you it's related to how its converted for storage.
 
Perhaps, if there is a lot of demand for it. I can look into a more extensive devblog on the topic. However that will greatly depend on time available for the team members who's scope that does fall into. ?
 
 
Static and Dynamic constructs are pretty much the same from that perspective, although they do have some behavioural differences obviously as one supports movement and the other supports industry.