Skeletmaster

why are you organizing your own PvP event, when the community is already doing one?

Please, pretty please.. provide an offline codex or at least the scripting section. It's HTML anyway so should not be that hard ..
 
having to go in and out of the in game one is not very nice.

"Hello Noveans, this is NQ-Ligo.

Whether you’re piloting with Lua, hauling cargo on a scripted VTOL platform, controlling a factory with screens and programming boards, or simply enjoying an in-game arcade machine, Lua can impact almost every aspect of your experience in Dual Universe.

After many years of accumulating Lua updates and additions, it’s time to revamp the Lua API of Dual Universe entirely. Our objective is to enhance and future-proof the tools available to those who create the fantastic scripts enjoyed by everyone in-game.

WHY REVAMP LUA API?

We must rework the Lua API to prepare it for future extensions by organizing it better, making it easier to use, and enhancing the tools available to our Lua creators. From a global point of view, the vision we have for Lua has evolved, and though we’re preparing a detailed changelog on our forum, here are some highlights:
Restructuring of the entire Lua API. Preparing for an object-oriented approach to be ready for future evolutions. Reduce JSON use in the API to favor the use of real Lua tables. Rely much more on event-driven code to reduce player loops and server requests. Reduce the complexity of the scripts, thereby reducing their size. Add some nice-to-have features. Garner more interest in certain elements like the telemeter.  
WHAT’S CHANGING WITH THIS LUA API REVAMP?

With the many changes coming to the API, we wanted to give you some of the highlights, while as we said above we’ll be giving you the specifics in another communication. For now, I want to discuss some of the most significant changes with you all in this devblog:

       NEW NAMING CONVENTION

We needed to apply a clean naming convention with this revamp to make Lua easier to use. This will become even more necessary as we expand the Lua API in the future.
As a result, multiple functions have been renamed, but most importantly, events will receive a name change. Any event will have a prefix ‘on’ from now on, for example:
unit.onStart() unit.onStop() system.onUpdate() system.onFlush() unit.onTimer([string] tag)  
 
       TWO NEW PERMANENT SLOTS ADDED

As part of the API restructuring, we have decided to add two new permanent slots:
`player` - This will represent the player using the script. Usually referred to as the "Master Player" in the current Control Unit or System API. `construct` - This will represent the construct on which the controller running the script is placed. Most of the construct-related functions were in the Core Unit API.  
Each of these slots will have the associated functions and events and will receive some additions. Let's take the example of `construct`. You will find functions and events coming from the Core Unit API and some additions. To give you an idea, here is just a snippet of the `construct` API:
[string] getName() : Returns the name of the construct. [int] getId() : Returns the construct unique ID. NEW [table] getOwner() : Returns the owner entity of the construct. NEW [table] getCreator() : Returns the creator entity of the construct. NEW [0 or 1] isWarping() : Checks if the construct is currently warping. NEW [int] getWarpState() : Returns the current warp state (Idle = 1, Engage = 2, Align = 3 …). NEW [0 or 1] isInPvPZone() : Checks if the construct is in the PvP zone. NEW [float] getDistanceToSafeZone() : Returns the distance between the construct and the nearest safe zone. [string] getPvPTimer() : Returns the current construct PvP timer state. [float] getMass() : Returns the mass of the construct. [float] getInertialMass() : Returns the inertial mass of the construct, calculated as 1/3 of the trace of the inertial tensor. NEW [matrix] getInertialTensor() : Returns the inertial tensor of the construct. NEW [vec3] getCenterOfMass() : Returns the position of the center of mass of the construct, in local construct coordinates. NEW [vec3] getWorldCenterOfMass() : Returns the position of the center of mass of the construct, in world coordinates. [float] getCrossSection() : Returns the construct's cross sectional surface in the current direction of movement. [vec3] getSize() : Returns the size of the building zone of the construct. NEW [vec3] getBoundingBoxSize() : Returns the size of the bounding box of the construct. NEW [vec3] getBoundingBoxCenter() : Returns the position of the center of the bounding box of the construct in local construct coordinates. [float] getMaxSpeed() : Returns the max speed along the current moving direction. [float] getMaxAngularSpeed() : Returns the max angular speed. [table] getMaxSpeedPerAxis() : Returns the max speed per axis. [table] getMaxThrustAlongAxis( [string] taglist, [vec3] CRefAxis) : Returns the construct max kinematics parameters in both atmo and space range, in newtons. NEW [float] getCurrentBrake() : Returns the current braking force generated by construct brakes. NEW [float] getMaxBrake() : Returns the maximum braking force that can currently be generated by the construct brakes.  
The above are just a few examples. You can find more functions in the CODEX.
 
       MORE ITEM API FOR CONTAINERS AND INDUSTRY

With the addition of the mining unit API, we also added item API to the game.
We have since had a great interest in this type of function from our community, allowing players to get more detailed information from item IDs.
As a result, we have decided to integrate it into multiple APIs for items or containers. For example:
NEW [int] element.getItemId() : Returns the element item ID. NEW [int] weapon.getAmmo() : Returns the item ID of the currently equipped ammo. NEW [int] engine.getFuelId() : Returns the item ID of the fuel currently used by the engine. NEW [event] industry.onStarted( [int] id, [float] quantity) : Emitted when the Industry Unit has started a new production process. NEW [event] industry.onCompleted( [int] id, [float] quantity) : Emitted when the Industry Unit has completed a run. NEW [int] core.getElementItemIdById(uid): Returns the item ID of the Element, identified by its local UID. NEW [table] container.getContent() (old getItemsList): Returns a table describing the contents of the container, as a pair itemId and quantity per slot.  
       CHANGING CONTAINER API

Reading the contents of a container is one of our most widely used features, but there has always been a problem. Its current implementation allows players to make ten requests as quickly as they would like, followed by a wait time of five minutes. This has caused spikes in server requests on our end and has been impractical for players.
 
We will change this behavior to allow you to make a content request with a fixed minimum delay of 30 seconds between two requests made with the `updateContent()` method.
 
As before, receiving content from the server triggers the `onContentUpdate()` event allowing you to get the contents with the `getContent()` function. We have also made the updateContent function return the time left before the next request to give our players better tracking of the process.

       CLICK WITH LUA

We’re adding a simple but often requested function; a mouse click for Lua!

Left-click, named ‘leftMouse’, has been added as a Lua action, triggering the onActionStart, onActionStop and onActionLoop events.
For design and security reasons, Lua will only detect left mouse clicks when not in use by the game. So if you click on a widget or in your inventory UI, Lua won't detect it.

We’re excited to see what our talented coders in-game will make of this tool!
 
       MAKE THE LIGHTS FLASH
 

 
In the past, we added the possibility of making light-elements glow with color components set to higher than 255. However, this caused graphical issues, and we had to remove the feature.

We are reintroducing this feature with Mercury but limiting it to a maximum factor of 5. And at the same time, we are changing the color format from 0-255 to 0-1 and 0-5 for HDR colors for consistency.

We will convert the color property of all existing light elements deployed in the game.
 
----------------------------------------------------------------------------------------------------------------------------------------------------------------

Many other changes and additions will be included with this revamp. There are so many that it would not be practical to cover them all in a general devblog, but we hope this small selection will inspire your creative spirit!
 
WILL ALL MY SCRIPTS BE BROKEN?

Although we consider this revamp necessary, we still want to give you time to transition and adapt your systems and allow your scripts’ users to continue using them during this transition.
To simplify the transition, we will deprecate all of the current API from Mercury, which means that the current functions and events will remain functional for a time but will not be referenced in the CODEX anymore, nor visible on the UI for events.
You will then receive a warning when using a deprecated function or event for the first time.
Please note: This depreciation will be time-limited. The goal is to remove all of the old API by the game’s launch. Along with other factors, we will need to release a new-API version of the default flight configuration before removing the depreciation. We will continue to assess whether removing the old API before launch is possible, and we’ll keep you apprised.

HOW CAN I CHECK THE UPCOMING API CHANGES?

Given the extent of the changes, we have chosen not to list them all in this devblog. The list of changes is very long, so our goal is to try and post a detailed forum thread with all changes and we have published a mock API on the official Github to allow you to prepare yourself as well as possible.

CONCLUSION

We hope you are excited, as players and creators, by the few changes mentioned here, especially about the new opportunities for all to enjoy that our passionate Lua community will create in Dual Universe. Our goal with the revamp is to push the door to future possibilities, evolutions, and additions for Lua. 

We'll be looking to go even further in the future and provide you with more tools to create content for other players.

As always, we appreciate your feedback and opinions, so please feel free to come and share your thoughts and ideas on this forum thread! We look forward to seeing you there.

Yours truly,
NQ Ligo"
 

Dear Noveans, we hope you're as excited as we are about the Lua changes coming in the next update, Mercury.
 
Let us know your thoughts below!

NQ why are you managing things that we as players could also do, dont waste your time on things like this. Put more efford in balancing and economy problems then in smt that WE as a community could do the same. If you want to give us a place for advertisment give us a pinboard or so as a menu point, where we can post ads, events, org recrutment... (maybe with a price for some quanta a week. 

NQ why are you managing things that we as players could also do, dont waste your time on things like this. Put more efford in balancing and economy problems then in smt that WE as a community could do the same. If you want to give us a place for advertisment give us a pinboard or so as a menu point, where we can post ads, events, org recrutment... (maybe with a price for some quanta a week. 

NQ why are you managing things that we as players could also do, dont waste your time on things like this. Put more efford in balancing and economy problems then in smt that WE as a community could do the same. If you want to give us a place for advertisment give us a pinboard or so as a menu point, where we can post ads, events, org recrutment... (maybe with a price for some quanta a week. 

To be honest ... the whole idea is a total mess and goes in the wrong direction. NQ is right that the players need more conncetion and communication to other ideas, projects and player groups, but the solution couldn't be a static construct on a static place. You deliver an idea which doesn't scale with the active number of players, could be build by players and needs regulary work from NQ to change the exposition. The rules are vage and the time frame for the exposition change is not even called. Will you do it, if someone by NQ find time for it ?
 
If you want a place for ideas and goods/ services who doesn't fit in the market, look like the players do it so far.
1. Discord - not the best solution. Not every player is in Discord or active on a special server. For some players it's a barrier.
2. extern websites - like https://du-creators.org/ . A barrier to, because it's extern, but widely known and used. Why ? We need something like this.
 
What we realy need is not a static, NQ managed, construct. We need more ways to communicate ingame.

1. A virtual ingame blackbord as part of the interface and menus. A place where every player can announce for a fixed time frame and and maybe some Quanta a message, commercial, call to the arms and so on. Nothing complicated a small menu to upload an image and some lines. A catalog which can see every player with pressing one button, without any barrier in DU.
2. An ingame calendar. In the past we had player driven events but no way to apply for it. Yes there is the discord-channel for events, but see Discord barriers. Same as point one, a way to announce my event for a limited time and for a price.

The goal of this is that a new player without knowing all websites or discord servers or a large org can log in, press one button and can see all the crazy staff other players do in DU and want to share. A static construct can not do this.

IMHO this is bs. (cool for new Players yes..)
 
Whenever NQ takes two steps forward, they take three steps back.
 
WTF is this and why do you waste human resources for this stupid thing. Instead of the promised player markets (some of which already exist in small form), they are now being punished and marginalized by another glorious NQ development. 64 sellers for the entire community, who decides who gets these places? What do you do when an org sends 100 signups before another player makes it?
 
So I'm getting an XS Core to sell ships or scripts there, but I can't show or demo them. I can only show nice pictures on 10 screen. What exactly does a store like this do for me? "Buy from me, won't be shit" Thanks, but no thanks. Then I will rather buy up all the slots and make signposts everywhere to the ship shops of the players. Nobody wants your stuff NQ! Player-Driven! Not Developer-Driven! Go away! Oh and "Periodic refreshes of The Exchange" -> And once you've established yourself in the market, you're then just kicked out of there and lose your revenue.... When will the refresh be? Pff ask the Devs! Player-Driven ist just a thing they promised during KS, u will never see it here!
 
What kind of screw up is that in an MMO?
 
With this announcement and the announcement of what will be stay after a wipe, it is already certain that there will be a wipe. Can't you just announce it officially?

Summer approaches and with it comes Mercury, our next update to Dual Universe.

As Cyrille Fontaine, our Creative Director, mentioned in his letter, our focus is currently on polish, and Mercury is no exception. This update also brings new features such as The Alioth Exchange, better lighting to improve visuals, Summer DACs, and more.

Read on for an overview.
 
THE ALIOTH EXCHANGE

We’re about to deploy a new installation in the heart of Alioth where players can apply to build a display to advertise and sell their creations. Applications will be open to all players who want to advertise their ship shops, markets, Lua Scripts, organizations, voxel libraries, or anything else that they create.
More details about, ‘The Alioth Exchange,’ will be available in an upcoming dedicated post.
 

 Note: constructs featured are samples only.

CONTINUED GRAPHICAL UPGRADES
 
We’re tackling illumination, vegetation, and explosion visual effects with the Mercury Update. You’ll find that the game world will be more radiant and realistic with our new global illumination, vegetation asset fixes will improve the look of foliage in the game, and whether you’re fighting or simply crashing a ship, you can enjoy more vibrant explosions.
 

 
SUMMER DACs
 
We’re implementing a separate, test version of DACs, allowing every active player to invite a friend to try Dual Universe free for one month. 
These Summer DACs are separate from real DACs, and will not impact your accrued pool of DACs from crowdfunding packages when gifted. 
One Summer DAC will be given to every active player and can only be redeemed by new accounts not yet subscribed to the game. They will expire by the end of the summer if not used. Summer DACs should allow us to test our web-based DAC system before the game’s release while offering your friends a chance to try the game for free!

NOVEAN OVERVIEW

We're adding an in-game interface which provides an overview of your general account information and unlocked possessions. We’ll expand this feature moving forward, but in Mercury, you’ll be able to see your unlocked cosmetic skins in a dedicated tab.
 

 
LUA API
 
Our vision for Lua has evolved over the years and with the new directions we’ve taken, it’s become necessary to entirely revamp our Lua API. These changes will future-proof the API and make it better serve the game by improving and tidying the system. We’re starting this process in Mercury. 
 
Naturally, such a major change will come with an enormous changelog, but to give you a brief overview of what’s coming ahead, we’re going to:
 
Restructure the entire Lua API Prepare an object-oriented approach to be ready for future evolutions. Reduce the use of JSON in the API to favor the use of real Lua tables. Rely more on event-driven code to reduce player loops and server requests. Reduce the complexity and size of scripts Add some of the, ‘nice to have,’ features Add further points of interest to some elements such as the telemeter.  
To summarize, our goal with this update is to reset the API and prepare it for future evolutions. Rest assured that your codes will still work in Mercury and that we’ll give you ample time to adapt your creations.
 
TALENT POINT RESET

Every character will have their talent points refunded back to their pool with the Mercury Update. While we must perform this reset for technical reasons related to upgrading our systems, this is also an opportunity for players to refocus talents into different areas and try new ‘builds’, or to simply correct training away from unwanted talents.
 
------------------------------------------------------------------------------------------------------------------------------------------------------
As always, we’ll publish a series of articles delving deeper into Mercury’s features, but for now, thank you for reading, Noveans! We’re excited to move forward with Mercury and are eager to hear your thoughts in this forum thread.
 
 

@NQ-Admin Hi, it's important.

Can you put all the alien core in pause (production/lockdown) until PVP was fix? (Radar + Transponder + Anynewbug)

We can't fight in good conditions, we can't have fun or enjoy this content (and it's the only PVP available atm) and with the wipe no decision + all those PVP bugs, we just lost all our motivation.

Do something, don't be passiv, thx.

Hi, Entropy

First of all, thank you again for answering in such a complete way on these precise subjects.
Even if we did not necessarily have the same desires, knowing the motivation and orientation of the modifications and additions you make to the game will allow us to be more relevant in our remarks.
I will therefore try to dig into the subject now that I have taken a few days back, and that we have seen the fleets forming and more in-game testing as well.

The objective of this post is not to contradict your vision of the game, but to help you make the necessary changes to make it happen.
Here is the feedback I can give you on the subjects for which you have requested comments.

I would have liked to detail 3 subjects but I did not have time so I will focus on 2 points only.

-----
 

Here is a chart for the speed we need to achieve when spinning around an in-game target to avoid targeting.



It is the calculation of the rope resulting from the angle (tracking of the weapon) and the distance where the target is. I arbitrarily retained 4 values:
- 50km
- 100km
- 200 km (1su)
- 400 km (2su)
The tracking being in deg/s I transformed the distance obtained in m into km/h to make it more meaningful.
 
- The first line is an example for a tracking of 1deg/s
- The second is the value I have on a siege guner with my character (talent at 4)
- The third line is the value of the biggest weapon in the game that should hypothetically have the most difficulty aiming at a target and it is the talentless value to symbolize the worst case.
- The last line is a spin test with an M railgun battleship. In 10 seconds I have time to do a 360 + stabilize my aim on a target.

Remember that the rate of fire of an M railgun is 13 seconds without talent, which leaves a comfortable margin of maneuver to align its target between 2 shots.

Here is also the visual of the rail gun firing cone.
30° cone radius in optimal + 30° cone in fallof.
The further away your target is, the more area you cover to be able to hit it.



Here is a table to symbolize the distances covered by a railgun without the ship needing to move :



With the talents on a weapon we reach a fairly huge coverage, almost 90° without fall off and almost 180° with him and that on a basic weapon without cone bonus and talents not max at lvl5.

(The choice of railgun as an example is arbitrary, this is valid for all weapons, not take this for a nerf/up request.)

Here are the issues raised (in my sole opinion) :
- The penalty linked to the tracking of weapons is valid at very short range.
- Tracking is possible if your opponent is not moving or at low speed
- If you are attacked by an opponent further away than the one you are moving arround, you will not benefit from your speed bonus to avoid shots
- Desynchronization has a strong impact on your positioning and that of your opponent, it opens or closes shooting windows independently of the players' game.
- We still have M or L size combat ships that can do 360° in less than 10 seconds, which still allows near-hand tracking using the adjusters.
 
If your opponent is far from you, the more easily he can kill you.
That's why we think going for the shield is always better. It protects you against several hazards over which your speed has no control.

-----
 

From the first returns, we can see a very large majority of small ships (but based on M or L cores rather than S or XS).
Especially a lot of small ships with an L size shield.
 
Here is a comparison of what we find in game compared to the possibility offered :



 
On the previous meta we were with ships which for the biggest approached 5% of the total construction surface that a builder had the leisure to use.
We went to Athena and now we have M ships that hardly exceed 3% of the cumulative surface of the usable box.
 
There is certainly a lever to exploit on this subject at the level of the nature of the game. The voxel and the voxel construction seems to remain a main pillar of dual universe. We necessarily need small vessels and large vessels. But shouldn't the small ships be on an XS and S core category, and the larger ones on the much more massive M and L cores? (category of vessel damaged from the voxel massive nerve).

-----
 

Just quickly on this subject.
 
I started looking to make a ship with spacing between different elements so as not to lose everything on the first try.
 
The areas of effect and the damage are so important compared to the current resistance of the voxels that even using a full block (so no interior in your ship).
The surface needed to just spread the weapons apart does not compensate (or very little) for the increased chance of hitting given by the cross section.
Since the voxel gives you a weight penalty, we always come back in the case where we seek to maximize the cross section.

 
 
I think you can try without too much risk to improve the defensive aspect of the voxels a little.
You still implanted a triple nerve:
- Significant reduction in voxel HP
- Added CSS
- Weapon DPS buff
 
In my opinion the CSS has a good balance, it will be necessary to look more on the side of the damage of weapons and voxels.
For the voxels maybe not the HP pool, but why not look into the resistor values.

-----
 
I will end with a question.
 
Would you like to have the help of the community for all things HP of the elements?
 
There are a number of elements in play currently with quite unbalanced health points.
 
I know that for the Dev team it must be tedious to review everything and that you certainly have better things to do.
 
Can we help on this subject?
 
I already have a few examples in mind. Like decoration plants having more points than weapons.
Or very heavy armored doors but with less hit points than hatches.

We would like to thank each and every one of you who has taken the time to visit our Public Test Server (PTS) and that tried our new Athena update. A special thanks to those who were able to attend our Fools Defense PvP event on April 1st, we hope you enjoyed it!
 
We recognize a good number of players were unable to attend the PTS event due to other engagements. As with any test, we had to make sure that our development teams were able to actively monitor and be present as the event took place. Thanks to your participation though, we have been able to identify some areas in need of improvements or adjustments - and thanks to your feedback, we will be working on improving them.
 
In addition, we are excited to announce that we will be bringing the PTS up for a couple of additional days, before heading into the next portion of our PTS test for Athena.
 
ATHENA ON PTS - SCHEDULE
 
- Wednesday 6th April 13:00 UTC to Friday 8th 09:00 UTC
We have finished adding more of the late stage game items, such as the schematics for the new Relic Plasma Harvester and Space Mining Unit, along with the variants of elements that have been introduced. We have also applied some fixes for added performance and stability for players to test out.
 
- Friday 8th April 11:00 UTC to Monday 11st April 09:00 UTC
Moving into the second part of our planned PTS testing for Athena, we’ll be focusing on the First Time User Experience (FTUE) beginner introduction guide. More information on this will be released very soon, so keep your eyes open for the upcoming devblog with all the details!
In order to fully test the new FTUE, the PTS will be completely reset on Friday, April 8th (hence the two hours maintenance between the two sessions). Please note that said maintenance might be a bit longer. But once it is done, everyone that connects to the PTS will be able to experience the new FTUE in detail. Of course, there will still be dispenser towers providing many in-game items for free, so players are able to continue to test other features that they are interested in as well.
 
Regarding the FTUE itself, brace yourselves for an upcoming devblog on this topic! The FTUE devblog will be available by the end of this week, so keep on the lookout for it. There will be many details to help you get ready for the FTUE PTS session!

As always, we would like to remind players that this is a Public Test Server and as such, many unforeseen issues can arise; this can include performance and stability issues. In the event that issues do arise, we will do our best to remedy them as soon as possible.
 
Get out to the PTS and test when the time comes! We look forward to reading your feedback for our Athena update in our Forum thread here.
 

I dont understand what your endgoal is. Why do we only hear changes that will cement the current meta into stone? You need to give us your vision of pvp. If we dont have it we cant tell you what would be better.
In my opinion you should limit every PvP factor ad this point to the core size or atleast partially. And give with this every core size a reason to exist and keep in mind the limiting factor are not the resources or anything like this. The limit are the player that can use a gunner seat. And yes you can even give us systems that would only work on one core size. Like Warp Inhibitor only on L. 

Hi everyone!
 
You probably heard that NQ-Pann has left Novaquark a few weeks ago.
Today, we are happy to announce that a new Community Manager is joining the team: NQ-Nyota ! ?
Please give her a warm welcome! 
 
P.S: on a side note, NQ-Naerais is still unavailable but should be back in a couple of months.
 
Best Regards,
Nyzaltar.

The main problem isn't the power of the engines at all. It is that there is no XL atmospheric engine, so that will fix itself with XL parts. 

I am even of the opinion that the high efficiency of atmospheric engines should be severly nerved and the rocket fuel consumation rate of rocket engines quartered and capacity halfed.
 
That would make for much more balanced and diverse gameplay. The pure atmospheric ships, the pure space ships and the ones able to launch into space.

Constant communication to answer players burning questions is a monumental task that is required at any time during the release cycle, even if that answer is reiterating “We [NQ] don’t know yet”.  So keep up the great comms @NQ-Naerais !
 
On another note, if the dreaded schematics arn’t banished back to the pits of hell that spawned them, players should be able to create them... though science!

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.
 

OK NQ this is something that everyone in my Org Dark Star Imperium has been wanting since Beta release, we are in DIRE NEED of MORE engine models to use the stock Atmo engines, especially the Large variant, are very ugly and hard to work with Please for the LOVE of all that is HOLY GIVE US MORE ENGINE MODELS

Valuable feedback, michaelk! I've been hearing from a lot of community members that they'd prefer another Reddit AMA instead of more Twitch interviews - is that something that would interest you?
 

Registration is avaible now! Check our Tutorial Video How To register your constructs!
 
 
Google Form Registration is now avaible! https://forms.gle/iTKdjjrPVbzghBky8

The Alioth Aerospace Expo is a Community event where all the manufacturing organizations come together to show off their latest designs. We have events and contests at these Expos as well. For now attendance is free and we rotate which Organization hosts the Expo.
 
This time Hyperion has the pleasure of hosting the Expo. We are looking forward to present you the biggest event in the beta.
 
 
► When:
Spring 2021
 
 
► Why should I attend?
The Expo aims to become a central hub of the shipbuilding scene. It is an opportunity for both industry giants and innovative startups to attract new civilian and military customers, by showcasing their talent to the wider player base. More than 600 constructs were already participating at the last Expo! 
 
 
► Want to show off your ships?
Players and Organizations can register for exhibition spaces, one construct per area. There will be 9 areas in total.
 
There will be three phases/ways to register your ships for exhibition.Choose the way you prefer. We recommend our Website.
 
Phase 1: Pre-Registration on the Hyperion website starting 23rd November
Phase 2: Registration via a Google Form starting 14th Dezember
Phase 1 and 2 are live now! Feel free to use our website to register your ships. For boring people we have this google form.
Phase 3: During the event, free space can be arranged via Discord. For each area there is one responsible person who takes care of it.
 

► What are the areas? What kind of ships can be exhibited there?
1. Military Ships - all ships that are designed for PvP
2. Freighter - any vessel designed for the transport of goods
3. Shuttle - all ships designed for the transport of persons
4. Replica - replicas of constructs from the real or a fictional world
5. Scripting - all dynamic constructs related to Lua
6. Starter & Scouts - all ships that can operate as scouts or are especially suitable for beginners
7. Racing - all ships designed for racing
8. Luxury Ships - The most glamorous ships with the only purpose to sparkle and shine
9. Organizations - Extra exhibition space for organizations with a greater amount of ships
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Further details about the Expo and the events taking place will be posted here

We welcome any support you like to contribute to the project
Contributions for the Expo can be made here: ::pos{0,2,16.7544,112.0115,42.2058} Please claim your items
 
 

Es ist mir eine große Freude, das neueste Mitglied des Community-Teams, NQ-Nudbrokk, vorstellen zu dürfen!
 
NQ-Nudbrokk ist noch dabei sich einzugewöhnen, deshalb bitte ich euch, vorerst sanft mit ihm umzugehen! Teilt unten eure Begrüßungen!
 
Willkommen an Bord, NQ-Nudbrook!
 

Hallo allerseits!
Danke für das Intro!
Als großer Sci-Fi-Fan freue ich mich sehr, euch alle auf diesem Abenteuer zu begleiten.
Ich bin noch dabei mich einzugewöhnen, aber wenn ihr etwas braucht, könnt ihr mich gerne kontaktieren und ich gebe mein Bestes, um euch zu helfen.
Vielen Dank für eure Geduld mit mir.
NQ-Nudbrokk