Jump to content

NQ-Deckard

Staff
  • Posts

    100
  • Joined

  • Last visited

Everything posted by NQ-Deckard

  1. Hello everyone, We would love to hear your feedback about the new ability to detect if your construct has stacked elements! NQ-Deckard
  2. With production on the Demeter update well underway, we wanted to make you aware of one of the big changes that will be included in the release, the Stacked Element Detection function. Previously, it was possible (though not permissible) to stack elements while creating ships. We’ve since eliminated the means to do this; however, there could still be players who are unknowingly piloting purchased ships that contain stacked elements. Used in tandem with the in-game build helper, we will now provide a way to identify stacked elements on constructs so that the owner can remove them. You may now find that some elements listed have a red triangle in front of them, indicating a stacked element and/or an element that is overlapping another element. The following elements* are currently subject to disabling: Repair units Shield generators Weapons Elevators Anti-gravity generators Anti-gravity pulsors Containers Industries Mining units Airfoils (wings, stabilizers, and ailerons) Space and air brakes Adjustors Engines (atmospheric, space, rocket, hover, and vertical boosters) Control units (including PvP seats) Deep space asteroid trackers Resurrection nodes Surrogate pods and VR stations Territory scanners *List subject to change Please note that this is a temporary method to address the issues caused by stacked elements. An automated process will be introduced in a future update in which any stacked or overlapping element will have its function disabled. We highly recommend that all players use this to retrofit, redesign, or unstack any stacked elements to ensure retention of functionality once the final phase of the stacking fixes is implemented. A forum thread is available here for questions and comments.
  3. Hello @EasternGamer! That was quite the read. Although we do already have very similar plans on the drawing board, it is unlikely that this will happen soon as it will likely have to go hand in hand with a larger Lua change for which we simply do not have an ETA at this time. And it's also not something that can be implemented at any point as it involves some major changes that would mean refactoring and "fixing" just about every single Lua script that currently exists in the game. As such, although we agree with the idea and would eventually like to do something along these lines. It is very unlikely it will be before release.
  4. The Event Library Example Below you will find example Lua code for a Lua Screen Units renderscript which demonstrates some of the use cases of the events library. (Yes, I realise this is a stunning example screenshot. 😎) The Event Library example code: (This example will not work in game until the related update is deployed.) --Local libs used in this example local event = require('utils/event') local rslib = require('rslib') --Layers instanciation and font loading local font = loadFont('RefrigeratorDeluxe',20) local back = createLayer() local front = createLayer() local fore = createLayer() local rx,ry = getResolution() local mx,my = getCursor() --Default styles definition setDefaultFillColor(back,Shape_BoxRounded,0.2,0.2,0.3,1) setDefaultFillColor(front,Shape_Text,1,1,1,1) setDefaultFillColor(fore,Shape_Text,1,193/255,32/255,1) --Background color definition setBackgroundColor(15/255,25/255,40/255) --[EXAMPLE] Button class definition local function addButton(x,y,w,h,text,ft) --Pubic properties local self = {} self.text = text or "" self.font = ft or nil self.onPressed = event:new() self.onDown = event:new() self.onReleased = event:new() self.onHover = event:new() self.onLeave = event:new() --Local properties local _x,_y,_w,_h = x,y,w,h local _lines = {} local _hover = false local _asc, _desc = 0,0 if self.font then _asc,_desc = getFontMetrics(font) _lines = rslib.getTextWrapped(font, text, _w) end --Set the caption of the button function self:setText(text) if self.font then _lines = rslib.getTextWrapped(self.font, text, _w) end end --Handle button events function self:compute(x,y) if x>_x and x<_x+_w and y>_y and y<_y+_h then if getCursorPressed() then self.onPressed:emit(self,x,y) elseif getCursorReleased() then self.onReleased:emit(self,x,y) elseif getCursorDown() then self.onDown:emit(self,x,y) end _hover = true self.onHover:emit(self,x,y) elseif _hover then self.onLeave:emit(self,x,y) _hover = false end end --Draw the button function self.draw(self) local x,y,w,h,txt,ft = _x, _y, _w, _h, self.text, self.font local layer = _hover and fore or front addBoxRounded(back,_x,_y,_w,_h,6) if ft then for k,l in pairs(_lines) do local ty = y + h*0.5 - (#_lines-1)*(_asc+_desc)*0.5 + _asc*(k-1) setNextTextAlign( layer, AlignH_Center, AlignV_Middle) addText( layer, ft, l, x+w/2, ty) end end end return self end ---# Initialization - Executed only at the first frame if not _init then display = {"Don't click me!","No! What did I say?!","STOP!! I SAID STOP !","STOP!! I'M BLOCKING MYSELF NOW"} k = 1 --Create the button btn_print = addButton(rx/2 -93, ry/2 -28, 186, 56, display[1], font) --Add the action on the onPressed event. --event:addAction( call, enabled, limit) btn_print.onPressed:addAction(function(self,x,y) k = k+1 self:setText(display[k]) end, true, 3) --In this case, we limit the action to 3 invoke and is disabled after. _init = true end ---# Computation btn_print:compute(mx,my) ---# Rendering btn_print:draw() requestAnimationFrame(10)
  5. The Atlas Library Example Below you will find example Lua code for a Lua Screen Units renderscript which demonstrates some of the use cases of the atlas library. The Atlas Library example code: (This example will not work in game until the related update is deployed.) ----------------------------------------------------------------------------------- -- Atlas Lua Screen -- -- This screen provides an example of a stellar atlas based on screen rendering -- and the local atlas.lua library. ----------------------------------------------------------------------------------- ---# Local constants class and objects definition local atlas = require("atlas") local json = require("dkjson") local rslib = require("rslib") local vec3 = require("cpml/vec3") local system = atlas[0] local rx,ry = getResolution() local rear = createLayer() local back = createLayer() local front = createLayer() local fore = createLayer() local small = loadFont('Play',10) local smallBold = loadFont('Play-Bold',10) local normal = loadFont('Play',16) local normalBold = loadFont('Play-Bold',16) local medium = loadFont('Play',22) local mediumBold = loadFont('Play-Bold',22) ---# Local functions definition --Returns the id of the images requested to load (prevent to load multiple time the same image) local images = {} local function loadImages(src) for k,img in pairs(images) do if k == src then return img end end images[src] = loadImage(src) return images[src] end --Returns a concatenated string of the given table with the comma separator according to the language local function concatList(list,lng) local out = {} for i,v in pairs(list) do out[i] = v[lng] end return table.concat(out,', ') end --Check if the given table t has the given entry u local function contains(t, u) for i,v in pairs(t) do if v == u then return true, i end end return false end --Used to set the view to a given stellar body id local function setView(id) local i = 0 for k,b in pairs(system) do if b.id == id and b.systemId == 0 then i = k else for k,b in pairs(system) do if b.id == b.systemId then i = k end end end end if _mode == 1 then _viewX = 470-(i*350) else _initShift = _viewX _shift = 470-(i*350) _time = 0 end end ---# Settings -- showCursor : Set at true to display a cursor -- _lang : Set here the default language (1: English, 2: French, 3: German) -- _mode : Set the view mode (1: system view, 2: local view) -- _select : Set the default selected stellar body (i.e. 2 for Alioth) local showCursor = false _lang = _lang or 1 _mode = _mode or 1 _select = _select or 1 local loc = { description = {"Description", "Description", "Beschreibung"}, ores = {"Ores", "Minerais", "Erze"}, biosphere = {"Biosphere", "Biosphere", "Biosphare"}, habitability = {"Habitability", "Habitabilite", "Bewohnbarkeit"}, classification = {"Classification", "Classification", "Klassifizierung"}, satellites = {"Satellites", "Satellites", "Satelliten"}, distance = {"Distance", "Distance", "Entfernung"}, radius = {"Radius", "Rayon", "Radius"}, gravity = {"Gravity", "Gravité", "Schwerkraft"}, atmoThickness = {"Atmo. Thickness", "Epaiss. atmosphère", "Atmospharendicke"}, noSatellite = {"This stellar body does not have satellites.","Ce corps stellaire ne dispose pas de satellites.","Dieser Sternkörper hat keine Satelliten."} } ---# Initialization _viewX = _viewX or 220 _planets = _planets or {} _time = _time and _time+getDeltaTime() or 0 _initShift, _shift = _initShift or 0, _shift or 0 local input, dist = getInput(), 0 if not _init then if not system[_select] then _select = 1 end setView(_select) local data = json.decode(input) or {} if data.pos then dist = vec3(data.pos) - vec3(planet.center) end _init = true for _,b in pairs(system) do if b.systemId == 0 then if b.satellites then table.sort (b.satellites, function (b1, b2) return system[b1].positionInSystem < system[b1].positionInSystem end ) end _planets[#_planets+1] = b end end table.sort (_planets, function (b1, b2) return b1.positionInSystem < b2.positionInSystem end ) end local planet = system[_select] local vignette = loadImages(planet.iconPath) ---# Computation local mx, my = getCursor() local down, pressed = getCursorDown(), getCursorPressed() --Compute actions on mouse clicks if pressed then for k=1,3 do local lx = rx-84 + k*24 if (mx-lx)^2 + (my-13) < 20^2 then _lang = k end end if _mode==2 and (mx-256)^2 + (my-32)^2 < 24^2 then _mode = 1 end end if my>ry-60 and mx>224 and down then if _mode==1 then _viewX = 220-((mx-224)/700)*4200 + (rx-224)/2 else _mode = 1 end end --Slide animation when clicked on a planet if _mode == 2 then local t = _time/1 local sqt = t * t; _viewX = t>=1 and _shift or _initShift + (sqt / (2.0 * (sqt - t) + 1.0))*(_shift-_initShift); end --Clamp the view shift _viewX = _viewX>220 and 220 or _viewX _viewX = _viewX<-3800 and -3800 or _viewX ---# Rendering --Draw backgrounds and cursor circle setBackgroundColor(5/255, 6/255, 10/255) setNextFillColor( front, 15/255, 16/255, 20/255, 1) addBox( front, 0, 0, 224, ry) setNextFillColor( back, 5/255, 6/255, 10/255, 1) addBox( back, 224, ry-60, rx-224, 60) if showCursor then setNextStrokeWidth( fore, 0.1) setNextStrokeColor( fore, 1, 193/255, 32/255, 1) setNextFillColor( fore, 0,0,0,0) addCircle( fore, mx, my, 5) setNextFillColor( fore, 1, 193/255, 32/255, 1) addCircle( fore, mx, my, 1) end ---Main view --Draw the main view sun glow, only if visible on the view if _viewX > 0 then setNextStrokeWidth( rear, 0) setNextStrokeColor( rear, 0, 0, 0, 0) setNextShadow( rear, 200, 255/255, 120/255, 5/255, 0.85) addBox( rear, _viewX-10, 0, 0, ry) end local bx,by = _viewX+300, ry/2 --Draw the thumbnail sun glow setNextStrokeWidth( back, 0) setNextStrokeColor( back, 0, 0, 0, 0) setNextShadow( back, 45, 255/255, 120/255, 5/255, 0.75) addBox( back, 200, ry-35, 0, 10) --Draw all planets for i,body in pairs(_planets) do local img = loadImages(body.iconPath) local hover = false local r = body.radius/900 local mbx = 224+(i*350)/6 if _mode==1 or (_mode == 2 and _select == body.id or (body.satellites and contains(body.satellites, _select))) then --Check the hover and click events in the rendering (exception made to avoid having to do the same loop in the computation part). if (mx-bx)*(mx-bx) + (my-by)*(my-by) < (r+18)^2 then hover = true if pressed then _select = body.id if _mode == 1 then _mode = 2 setView(body.id) end end end --Draw the planet only if it is visible on the screen in order to optimize the rendering cost. if bx > -r*1.5 and bx < rx+r*1.5 then if hover then setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 193/255, 32/255, 1) end setNextFillColor( rear, 0, 0, 0, 0) addCircle( rear, bx, by, r+18) --Draw atmosphere if the stellar body has if body.hasAtmosphere then local atm = body.atmosphereRadius/900 setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 1, 1, 0.03) setNextFillColor( rear, 1, 1, 1, 0.025) addCircle( rear, bx, by, atm) end --Draw back line setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 1, 1, 0.25) addLine( rear, bx, 0, bx, ry) --Draw planet image if body.id == 3 then addImage( back, img, bx-(2*r)+8, by-(2*r)+14, 2*(2*r), 2*(2*r)) else r = 1.025 * r addImage( back, img, bx-r, by-r, 2*r, 2*r) end --Draw satellites if in local view if _mode == 2 then if body.satellites then local dsx = 0.5 * (rx-bx+r)/(#body.satellites+1) local sx, sy = bx + r + dsx, by for j,sid in pairs(body.satellites) do hover = false local sat = system[sid] local satImg = loadImages(sat.iconPath) sr = sat.radius/1240 if (mx-sx)*(mx-sx) + (my-sy)*(my-sy) < (sr+18)^2 then hover = true if pressed then _select = sat.id end end if hover then setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 193/255, 32/255, 1) end setNextFillColor( rear, 0, 0, 0, 0) addCircle( rear, sx, sy, sr+18) if sat.hasAtmosphere then atm = sat.atmosphereRadius/1240 setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 1, 1, 0.03) setNextFillColor( rear, 1, 1, 1, 0.025) addCircle( rear, sx, sy, atm) end addImage( back, satImg, sx-sr, sy-sr, 2*sr, 2*sr) setNextStrokeWidth( rear, 0.1) setNextStrokeColor( rear, 1, 1, 1, 0.25) addLine( rear, sx, sy + (sr+10)*(-1)^j, sx, sy + (sr+38)*(-1)^j) setNextTextAlign( back, AlignH_Center, AlignV_Middle) addText( back, normal, sat.name[_lang], sx, sy + (sr+48)*(-1)^j) sx = sx + sr + dsx end else --Otherwise, if the star body has no satellites, we display a message. setNextTextAlign( back, AlignH_Center, AlignV_Middle) addText( back, normal, loc.noSatellite[_lang], (rx+bx)/2, by) end end --Draw the planet name setNextTextAlign( back, AlignH_Center, AlignV_Baseline) addText( back, medium, body.name[_lang], bx, by+r+38) end end --Draw the thumbnail view setNextStrokeWidth( back, 0.1) setNextStrokeColor( back, 1, 1, 1, 0.25) addLine( back, mbx, ry-60, mbx, ry) addImage( front, img, mbx -r/8, ry-30 -r/8, 2*r/8, 2*r/8) --If the local view, show the back button arrow if _mode == 2 then setNextStrokeColor( fore, 1, 193/255, 32/255, 1) setNextStrokeWidth( fore, 1) addLine( fore, 250, 32, 262, 44) setNextStrokeColor( fore, 1, 193/255, 32/255, 1) setNextStrokeWidth( fore, 1) addLine( fore, 250, 32, 262, 20) end bx = bx +350 end --Draw the minature view box setNextFillColor( front, 1, 1, 1, 0.1) addBox( front, 224+(220-_viewX)/6, ry-60, (rx-224)/6, 60) --Draw the language selector local langs = {'EN', 'FR', 'GE'} for k,l in pairs(langs) do if _lang == k then setNextFillColor( fore, 1, 193/255, 32/255, 1) end addText( fore, small, l .. (k<3 and ' |' or ''), rx-96 + k*24, 18) end ---Lateral View --Draw all informations on the lateral panel addText( front, medium, string.upper('| '..planet.name[_lang]), 18, 38) local y = 50 setNextFillColor( front, 10/255, 11/255, 15/255, 1) addBox( front, 0, y, 224, 120) addImage( fore, vignette, 112 - 50, y+10, 100, 100) y = y + 140 addText( front, smallBold, string.upper('| '.. loc.description[_lang]), 18, y) local _lines = rslib.getTextWrapped( small, planet.description and planet.description[_lang] or '-', 200) for k,l in pairs(_lines) do setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, l, 18, y+2+k*10) end y = y + #_lines*10 + 16 addText( front, smallBold, string.upper('| '.. loc.ores[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) local _lines = rslib.getTextWrapped( small, concatList(planet.ores, _lang), 200) for k,l in pairs(_lines) do setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, l, 18, y+2+k*10) end y = y + #_lines*10 + 28 if planet.biosphere then addText( front, smallBold, string.upper('| '.. loc.biosphere[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, planet.biosphere[_lang], 18, y+11) y = y +26 end if planet.habitability then addText( front, smallBold, string.upper('| '.. loc.habitability[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, planet.habitability[_lang], 18, y+11) y = y +26 end if planet.classification then addText( front, smallBold, string.upper('| '.. loc.classification[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, planet.classification[_lang], 18, y+11) y = y +26 end addText( front, smallBold, string.upper('| '.. loc.satellites[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, planet.satellites and #planet.satellites or 0, 18, y+11) y = y +38 addText( front, smallBold, string.upper('| '.. loc.distance[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, string.format('%.2f km', dist/1000), 18, y+11) y = y +26 addText( front, smallBold, string.upper('| '.. loc.radius[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, string.format('%.2f km', planet.radius/1000), 18, y+11) y = y +26 addText( front, smallBold, string.upper('| '.. loc.gravity[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, string.format('%.2f m/s²', planet.gravity), 18, y+11) y = y +26 if planet.hasAtmosphere then addText( front, smallBold, string.upper('| '.. loc.atmoThickness[_lang]), 18, y) setNextFillColor( front, 1, 1, 1, 0.75) addText( front, small, string.format('%.2f m', planet.atmosphereThickness), 18, y+11) end ---# Request animation frame requestAnimationFrame(1)
  6. Lua is a real programming language that can be used in Dual Universe to bring dynamics and interactivity. Whether it is to fly a ship made in voxels or to add movement and functionality to a construct (such as controlling doors), Lua is everywhere. If you haven’t read the first two devblogs in this series, here’s what you missed: Part 1: Recent changes and additions, docking-related changes, and the deprecation of quaternions Part 2: Radar API changes and transponder API additions In Part 3, we’re wrapping up this round of Lua devblogs by taking a look at highly-requested features, an update to the database library, the in-game atlas, and the event handling system. OTHER ADDITIONS We took the time to add a few minor features to the Lua following some popular requests that we felt would gel well with the other changes. <string> core.getConstructName() : Returns the name of the construct. <int> core.getCurrentPlanetId() : Returns the ID of the current close stellar body. <string> system.getPlayerName(<int> pid) : Returns the name of the given player if in range of visibility or broadcasted by a transponder. <list> unit.getMasterPlayerOrgIds() : Returns the list of organization IDs of which the player running the script is a member. <string> system.getOrganizationName(<int> oid) : Returns the name of the given organization, if known, e.g. broadcasted by a transponder. <string> system.getOrganizationTag(<int> oid) : Returns the tag of the given organization, if known, e.g. broadcasted by a transponder. DATABASE LUA LIBRARY UPDATE With all of these other changes and improvements being deployed, it seemed a perfect time to update the local database library accordingly and to add some others based on players’ feedback. You will now find the following functions: <table> database.getPlayer(<int> pid) : Returns all information about a given player, identified by its ID. <table> database.getMasterPlayer(<table> unit) : Returns all information about the player running the script. <table> database.getOrganization(<int> oid) : Returns all information about the given organization, identified by its ID. <table> database.getConstruct(<int> cid) : Returns all information about a given construct, identified by its ID; requires a radar to detect the construct. <table> database.getElement(<table> core,<int> uid) : Returns all information about a given element, identified by its ID, and requires a linked core unit. LUA ATLAS ADDITION Lua designers have indicated the need for an in-game atlas. With the addition of the getCurrentPlanetId function, we can make that available now. We’re pleased that we were able to stick close to a similar structure that players were already familiar with, but with certified values and refactoring, especially for localization aspects. The text fields for the name, description, minerals, etc. are not strings but tables. This was done with the objective of providing simple information in the three languages we currently support: English, French, and German. With this atlas library, you will have the following information: <int> id : The id of the stellar body. <list> name : The name of the stellar body. <list> type: The type of the stellar body (planet or moon). <list> biosphere : The stellar body biosphere. <list> habitability : The level of habitability of the stellar body. <list> classification : The thermal classification of planetary habitability. <list> description: The description of the stellar body. <string> iconPath: The stellar body icon image path (i.e. to be used on screens). <bool> hasAtmosphere: True if the stellar body has an atmosphere. <bool> isSanctuary: True if the stellar body is a sanctuary moon. <bool> isInSafeZone: True if the stellar body is in the safe zone. <int> systemId: The stellar system id in which is the stellar body. <int> positionInSystem: The indicative position of the stellar body in the stellar system. <list> satellites: The list of IDs of the satellites of this stellar body. <vec3> center: The position of the center of the stellar body in world coordinates. <float> gravity: The gravitational acceleration at the nominal radius of the stellar body in m/s². <float> radius: The nominal radius of the stellar body. <float> atmosphereThickness: The atmosphere thickness in meters. <float> atmosphereRadius: The radius of the sphere of the atmosphere measured from the center of the stellar body. <float> surfaceArea: The nominal surface area for the stellar body. <float> surfaceAverageAltitude: The average altitude at the surface of the stellar body. <float> surfaceMaxAltitude: The maximum altitude at the surface of the stellar body. <float> surfaceMinAltitude: The minimum altitude at the surface of the stellar body. <float> GM: The standard gravitational parameter of the stellar body. <list> ores: The list of ores available on the stellar body. <int> territories: The number of territories on the surface of the stellar body. Example of use: local atlas = require(‘atlas’) --You can access to any stellar body from its id : atlas[system_id][stellar_body_id] local alioth = atlas[0][1] EVENT HANDLING LUA LIBRARY ADDITION To make it easier for players to organize and implement an event handling system, either for use on Lua screens or for various board systems, we added a new local Lua event library. This makes it possible to create events, associate actions to it, and manage these events and their emissions. Here is a short documentation of this light library. Event Description: An event contains actions to be triggered on its emission. Properties: <table> actions: The tables of actions attached to the event. Functions : event:emit(...): Emit the event and invoke attached actions with the given arguments. <bool, int> event:findAction(<string> id): Find a specific action associated with this event with the given ID. The function can take an action in argument to know if the action is attached to this event. Arguments: <string> id: The ID of an action. Returns: <bool> success: True if an action is found attached to this event. <bool> index: The index of the action found in the actions table of the event. <string> event:addAction(<any> call,<bool> enabled,<int> limit): Add an action to the event with the given arguments. Arguments: <object> call: The function or the thread invoked when the event is triggered. <bool> enabled: The boolean that indicates whether or not the action is enabled. <int> limit: The number of times the event can invoke this action. Returns: <string> id: The ID of an action. <nil> event:removeAction(<string> id): Remove the action associated with the event with the given arguments. The function can take an action object in argument. Action Description: An action is defined by a callable object, a function, or a thread. Properties: <string> id: This is an ID that can be used later to refer to this action. <any> call: Invoked when the event is triggered. <bool> enabled: This boolean indicates whether or not the action is enabled. <int> limit: This property represents the number of times events can invoke this action. <int> nbCall: This property keeps track of how many times events have invoked this action. <float> interval: This property allows to limit the time interval between two calls. <float> lastCall: This property helps track the time of when we last called this action. Example of use of the Atlas Library. Example of use of the Event Library. <BOOL> ARTICLE.ENDDEVBLOG() We hope you’ve enjoyed the Lua devblog series. Our work here is done, but yours isn’t. Our primary motivation for the blogs was to gather your feedback before perhaps considering further Lua changes and new features, whether for the API, as for the addition of additional libraries. Head over to the forum and join the conversation, share your thoughts and insights, and let us know what Lua-related improvements you’d like to see in the future.
  7. Hello everyone, I just want to quickly chime in on the conversation and take the time to respond to this post. There are a few factors at play here, including security, sandboxing and learning. Particularly the last one, as Lua is a very verbal language, with terms such as if something == true then doAction() end It is a particularly easy language for someone to learn who has never seen code before, and as Dual Universe is a game for everyone it is a much better fit. Besides that, it also meshes well with C++, can be nicely sandboxed and is commonly used in many games and thus a familiar platform for many players. Chances are high, that if you have good knowledge of JS, Lua will be a piece of cake to learn. On top of all that, there is also simply: Lua, Lua, oh baby, said we gotta go. Yeah, yeah, yeah, yeah...
  8. Sure, you can go it alone in Dual Universe, but you don’t have to, thanks to our new Recruit a Friend program. Who better than your tried and true mates to join you as wingmen on your epic adventures? The Recruit a Friend program is a reward system that allows you to earn free game time and great in-game rewards (including exclusive item skins and elements such as thrones and firework types) when you invite friends to purchase game time. In turn, your recruits will also receive items that will help them in their journey, such as handy starter elements, a speeder blueprint, and a week’s worth of talent points. The program is built in a way that rewards the total game time purchased by your recruits and not just the total number of players who were recruited. Watch this video to see the incredible benefits that await you and your recruits: HOW DOES IT WORK ? GET YOUR CODE Go to My Account, copy your Recruiter link and send it to your friends. RECRUIT A NOVEAN When your friends: create a Dual Universe account with your unique link (clicking on it will redirect your friend directly to the signup page), or enter your link in My Account before subscribing for the first time with an existing account, or enter your link in My Account before applying game time for the first time on an existing account, THEN, their accounts become linked to yours. GET THE REWARDS Every time a linked friend buys game time, it is added to your total and contributes toward unlocking new rewards. CHECK YOUR PROGRESS Go to My Account to check which rewards you have unlocked. Visit the Recruit a Friend page on our website for more information. You need to have an active subscription to qualify for the Recruitment Program.
  9. In Part 1, we went over some of the fresh new Lua options available, such as changes to repositories, the removal of quaternions, and docking-related changes. In Part 2, we’re back to spread the good word about exciting things like radars and transponders. Previously, we announced that Part 2 would also include databases, the atlas, and event libraries. Instead, these will be covered in Part 3. RADAR LUA API CHANGES AND ADDITIONS There are some future backend radar changes in the planning stages now. In preparation, we have made some improvements to the Lua implementation of the radar. These should not only have a usability benefit, but also improve performance as we reduce the usage of JSON strings to deliver payloads in Lua in favour of tables and values. See below: <list> radar.getEntries() : DEPRECATED (renamed to getConstructIds for consistency). <int> radar.isOperational() : Returns 1 if the radar is not broken, works in the current environment and is not used by another control unit. <float> radar.getRange() : Returns the scan range of the radar unit. <list> radar.getIdentifyRanges() : Returns ranges to identify a target based on its core size. <list> radar.getConstructIds() : Returns the list of construct IDs in the scan range. <list> radar.getIdentifiedConstructIds() : Returns the list of identified construct IDs. <int> radar.getTargetId() : Returns the ID of the target construct. <float> radar.getConstructDistance(<int> cid) : Returns the distance to the given construct. <int> radar.isConstructIdentified(<int> cid) : Returns 1 if the given construct is identified. <int> radar.isConstructAbandoned(<int> cid) : Returns 1 if the given construct was abandoned. <int> radar.getConstructCoreSize(<int> cid) : Returns the core size of the given construct. <string> radar.getThreatTo(<int> cid) : Returns the threat rate your construct is for the given construct. <string> radar.getThreatFrom(<int> cid) : Returns the threat rate the given construct is for your construct. With a matching transponder: <table> radar.getConstructOwner(<int> cid) : Returns a table with ID of the owner entities (player or organization) of the given construct if in range and if active transponder tags match. <vec3> radar.getConstructPos(<int> cid) : Returns the position of the given construct in construct local coordinates if the active transponder tags match. <vec3> radar.getConstructWorldPos(<int> cid) : Returns the position of the given construct in world coordinates if in range and if the active transponder tags match. If identified: <float> radar.getConstructSpeed(<int> cid) : Returns the speed of the given construct if identified. <float> radar.getConstructAngularSpeed(<int> cid) : Returns the angular speed of the given construct if identified. <float> radar.getConstructRadialSpeed(<int> cid) : Returns the radial speed of the given construct if identified. <float> radar.getConstructMass(<int> cid) : Returns the mass of the given construct if identified. <list> radar.getConstructInfos(<int> cid) : Returns a list of working elements on the given construct if identified. If identified AND a matching transponder: : <vec3> radar.getConstructVelocity(<int> cid) : Returns the velocity vector of the given construct in construct local coordinates if identified and if the active transponder tags match. <vec3> radar.getConstructWorldVelocity(<int> cid) : Returns the velocity vector of the given construct in world coordinates if identified and if the active transponder tags match. TRANSPONDER LUA API ADDITIONS We also heard your feedback that many of you found the transponder lacking in usability. To counter this, we’ve added and modified the following functions: transponder.activate() : Activate the transponder. transponder.deactivate() : Deactivate the transponder. transponder.toggle() : Toggle the state of the transponder. <int> transponder.getState() : Returns the activation state of the transponder. <int> transponder.setTags(<list> tags) : Set the tags list with up to eight entries. Returns 1 if the application is successful, 0 if the list is too long or if the tag format is invalid. <list> transponder.getTags() : Returns the tag list. transponder.toggled(<int> active) event : Emitted when the transponder is started or stopped. JOIN THE CONVERSATION What do you think of these Lua changes and additions? Are there more you’d like to see? We’d love to hear your thoughts in this thread.
  10. Hello Noveans! We would love to hear your feedback on the latest Lua DevBlog. I'd also personally like to read you all the following quote: ( You can't stop me @NQ-Pann! 😆 ) “... quaternions appear to exude an air of nineteenth century decay, as a rather unsuccessful species in the struggle-for-life of mathematical ideas. Mathematicians, admittedly, still keep a warm place in their hearts for the remarkable algebraic properties of quaternions but, alas, such enthusiasm means little to the harder-headed physical scientist Novean.” — Simon L. Altmann (1986)
  11. We have been adding a lot of features to the Lua API following the additions of shields and core combat stress in addition to the docking and boarding changes. We have taken a lot of your feedback and suggestions into consideration and have made a few changes to improve some of the consistency and implementation of Lua. These changes are minor; we can't rework the whole Lua API without breaking most of your scripts. With this in mind and to finalize the implementation of the Lua API associated with docking and future changes to other mechanics, we have decided to adjust a few parts that may be major for Lua creators, both for the addition of new features and the improvement and consistency of the API as a whole. In this first part of a three-part devblog, we’ll cover the recent Lua changes and additions, including some related to docking and the deprecation of quaternions. You can read up on the other parts here: Part 2 & Part 3 CHANGES AND ADDITIONS First, we have decided to rework the way the repositories associated with constructs and elements are managed. Previously, some functions returning position or orientation information referred to the center or even a corner of the construct, others to the position of the core unit in the construct. Going forward we have standardized everything. Once these changes go live, all functions will be based on the reference frame of the construct whose origin is the center of the build zone. Further, in order to guarantee the functionality of the flight systems and to safeguard the gyro unit, we have integrated in a clearer way of representing orientation. An orientation unit is an element that is used to define the orientation of your construct. There are two orientation units in the game, the core unit and the gyro unit. As a construct cannot exist without a unique core unit, the core unit is always the default orientation unit. By pressing F on a gyro unit, you can switch to using the gyro unit as the current orientation unit. You can see that the marker and arrow displayed when you enter the build mode will indicate the orientation given by the active orientation unit. You can activate a gyro unit by pressing F on it and so use its orientation. See examples below: For these changes, we have added: <int> core.getOrientationUnitId() : Returns the UID of the currently active orientation unit (the core unit or the gyro unit). We have also modified the following functions: <vec3> core.getConstructOrientationForward() : Returns the forward direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructOrientationUp() : Returns the up direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructOrientationRight() : Returns the right direction vector of the active orientation unit in construct local coordinates. <vec3> core.getConstructWorldOrientationForward() : Returns the forward direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldOrientationUp() : Returns the up direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldOrientationForward() : Returns the right direction vector of the active orientation unit in world coordinates. <vec3> core.getConstructWorldPos() : Returns the position of the center of the construct in world coordinates (instead of orientation units position). REMOVAL OF QUATERNIONS Quaternions are the quotient of two directed lines in a three-dimensional space or the quotient of two vectors. In looking at how players were using Lua and reading their feedback, , we realized that very few players were familiar with this mathematical notion of representing rotation. Therefore, we decided to deprecate quaternions from the Lua API and instead expose the direction vectors of objects. While this leads to the addition and change of some functions, deprecated functions will remain backwards compatible and will display a deprecated message in the Lua console. <quat> core.getElementRotationById(<int> uid) : DEPRECATED <vec3> core.getElementPositionById(<int> uid) : Returns the position of the element, identified by its UID in construct local coordinates (instead of the construct corner). <vec3> unit.getMasterPlayerRelativePosition() : DEPRECATED <quat> unit.getMasterPlayerRelativeOrientation() : DEPRECATED And we have added the following functions: <vec3> core.getElementForwardById(<int> uid) : Returns the forward direction vector of the element identified by its UID in construct local coordinates. <vec3> core.getElementUpById(<int> uid) : Returns the up direction vector of the element identified by its UID in construct local coordinates. <vec3> core.getElementRightById(<int> uid) : Returns the right direction vector of the element identified by its UID in construct local coordinates. <vec3> unit.getMasterPlayerPosition() : Returns the position of the player currently running the control unit in construct local coordinates (relative to the construct center instead of the control unit). <vec3> unit.getMasterPlayerWorldPosition() : Returns the position of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerForward() : Returns the forward direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerUp() : Returns the up direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerRight() : Returns the right direction vector of the player currently running the control unit in construct local coordinates. <vec3> unit.getMasterPlayerWorldForward() : Returns the forward direction vector of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerWorldUp() : Returns the up direction vector of the player currently running the control unit in world coordinates. <vec3> unit.getMasterPlayerWorldRight() : Returns the right direction vector of the player currently running the control unit in world coordinates. DOCKING-RELATED LUA API ADDITIONS With the new docking mechanic, we wanted to empower players to manage the parent-child relationship between constructs. Some of the additions were added in the Ares (0.26.12) update; however, we still had more changes and additions planned and these will be included with the Lua changes release We have added and modified the following functions: <vec3> core.getVelocity(): Returns the construct's linear velocity, relative to its parent, in construct local coordinates. <vec3> core.getWorldVelocity(): Returns the construct's linear velocity, relative to its parent, in world coordinates. <vec3> core.getAbsoluteVelocity(): Returns the construct's absolute linear velocity in construct local coordinates. <vec3> core.getWorldAbsoluteVelocity(): Returns the construct's absolute linear velocity in world coordinates. <vec3> core.getParentPosition(): Returns the position of the construct's parent when docked in construct local coordinates. <vec3> core.getParentWorldPosition(): Returns the position of the construct's parent when docked in world coordinates. <vec3> core.getParentForward(): Returns the construct's parent forward direction vector in construct local coordinates. <vec3> core.getParentUp(): Returns the construct's parent up direction vector in construct local coordinates. <vec3> core.getParentRight(): Returns the construct's parent right direction vector in construct local coordinates. <vec3> core.getParentWorldForward(): Returns the construct's parent forward direction vector in world coordinates. <vec3> core.getParentWorldUp(): Returns the construct's parent up direction vector in world coordinates. <vec3> core.getParentWorldRight(): Returns the construct's parent right direction vector in world coordinates. Questions? Comments? We’re sure some of the Lua-enthusiasts in our community will have questions and comments about this blog. Post them here so our resident Lua expert, Ligo, can discuss them with you. Watch for Part 2 next week. It’s got great information about radar changes, the library database, an in-game atlas, and an event handling system.
  12. Hello everyone! We would love to hear your feedback on the Apollo & Ares Q&A.
  13. We invited the Dual Universe community to submit questions about the new features and changes in the recent Apollo and Ares updates. In lieu of the traditional written format, we opted for an on-camera approach to spice things up a bit. In this video, Sesch, General Manager of the Montreal studio, Pann, Senior Community Manager, and Deckard, Community and Live Ops Specialist, tackle topics from antlers and Mickey Mouse ears to asteroids and docking. We would love to hear your feedback here!
  14. During service maintenance today, we were hoping to finally launch the long-awaited Recruit a Friend program that we're so excited about. Unfortunately, once deployed in the live environment, we found a bug that couldn't have been discovered during testing on our internal server. It seems that this "silent non-launch" (yes, it's a thing) of the program triggered something in our back-office that wasn't supposed to happen, so the RAF program was shut down (or “silently un-non-launched”). The anomaly caused some players to receive a small quanta and talent point boost. We were able to identify the issue quickly and disable the event that was causing it. The team is actively working now to identify the affected accounts and to squish the bug that caused this. We expect to be able to launch the RAF program within a week or so, based on our preliminary findings. Thank you for your patience! You can discuss about the coming recruit a friend program on the forums.
  15. Hello Noveans! With the recruit a friend system coming soon, we would love to hear your initial thoughts about some of the rewards and the system.
  16. Hello Noveans! We invite you to pose questions about the Apollo (0.26.2) and Ares (0.26.12) updates in this thread. We’ll answer what we can in an upcoming, postmortem-ish Q&A. Thank you all for your support!
  17. Dual Universe: Ares (0.26.12) has launched! Earlier this month, we announced that the Ares update had been added to the Dual Universe public roadmap. Less than a month later, we’re pleased to announce that players can now enjoy all that Ares has to offer, from brand-new features to a long list of improvements. In many ways, Ares is a complementary companion to the Apollo (0.26) update. Released in August, Apollo introduced the first wave of PVP-centric assets, balancing, and features, such as Shields v1. Watch this video for a short (yet visually stunning!) overview of key features from both Apollo and Ares. Turning our attention back to Ares, here’s a topline view of the key facets of Ares, our fifth major update so far this year. New PvP-focused features Core combat stress - In conjunction with core unit destruction, core combat stress gives weapons another way for all that delicious firepower to bring down the opposing construct. Depending on which side of the battle you’re on, this can be viewed as an additional victory or loss condition. (Hopefully victory. We believe in you!) Shields v2 - Shields were introduced in the Apollo update to amp up PvP gameplay. In Ares, shields acquired adjustable resistance and venting, giving them more depth, taking them from a purely passive accessory to a prized load-out that can have a big impact on the outcome of dust-ups. For a closer look at core combat stress and Shields v2, along with important information about ways we’ve closed the gate on some problem-causing PvP-related exploits, read Inside Ares, Part 1. Improvements to existing features Warp drive improvements - Taking player feedback into account, we’ve made some adjustments to warp drives that will encourage pilots to employ a higher level of strategy. We’ve reduced warp speed, increased the cool-down time, added spooling, and several other tweaks and recalibrations, all of which should factor in for more excitement. Docking and boarding revamp - It’s yours and you should have control over who has access to it. The docking and boarding revamp makes nonconsensual boarding a thing of the past. Details about these changes can be found in our latest devblog, Inside Ares, Part 2. Full patch notes can be viewed here. Production is underway for our next update, Demeter, which will focus primarily on mining with the introduction of automated mining units and a revamp for territory management. As always, we’ll pave the way with devblogs and other Demeter-related content. In the meantime, we invite you to pose questions about the Apollo and Ares updates in this thread on our forum. We’ll answer what we can in an upcoming, postmortem-ish Q&A.
  18. 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.
  19. UPDATE: More up to date information on this announcement can be found here. In the recent PTS 0.26.12 update, we fixed an exploit related to placing elements in the same location. Exploits Fixes Fixed an industry duplicate production. Fixed an exploit that allowed placement of several elements at the same position. This was done to prevent the ability to overlap elements in the same location, which was never part of the intended game design. Several months ago, we stated in our clarification on bugs and exploits that we would continue to allow element stacking for the time being until a solution was in place. With this fix now coming in the Ares update as part of our continuing effort to close the loop on a number of issues, we will be changing our stance on the stacking of elements. When the Ares update is released on the Live server (date TBA), constructs containing stacked elements will no longer be permitted. Violations of the “no element stacking” mandate will be subject to deletion without warning or compensation. We strongly urge players who have currently overlapping elements to remove those immediately to prevent the loss of those constructs once Ares arrives. Players may report violations via Support ticket or by messaging @gm in the in-game Help channel.
  20. The Dual Universe team is nearing the finish line, doing a last round of checks before transitioning the Ares (0.26.X) update from the public test server to Live. You can help! Listed below are some features and fixes that we have planned for the update. Before we take them to Live, we want to verify that everything is working as intended for our players. For that, we need you - as many of you as possible - to log onto PTS now and check them out. Core combat stress Shields v2 Boarding and docking Crashes related to AMD graphics cards Inventory-related crashes Previously, we had a background asset on the inventory that caused the game to crash. We removed it as a temporary workaround, but now we have a proper fix and reintroduced the asset and would like to know if it's working. [UEF Store] All the ships at the UEF store have had a quality improvement (Mark 2) pass. Some ships look very similar to their predecessors with power, lift, and balance tweaks, while some others (such as the Dragonfly, the Mule, and the Specters) have been overhauled so that their performance improvements are also matched by visual improvements. The ship prices have also been adjusted to match current market conditions. Please give the ships a try and let us know what you think. (Note: Eclipses are currently unavailable.) Feedback regarding these specific items (or any additional anomalies you may encounter this weekend on PTS) should be reported in this designated thread. We are sincerely grateful to everyone who answers the call. You are helping DU be the best it can be and we appreciate your support.
  21. Hello Noveans! This time we would love to hear your thoughts about Devblog: Inside Ares, Part Two!
  22. This is the follow-up to Tuesday’s devblog, Inside Ares, Part One. Here we’ll go over the improvements and changes to warp sequences as well as docking and boarding. Even if you read the previous devblog about docking and boarding, you should give this a look; we’ve been finessing the original plans to make them even better. WARP IMPROVEMENTS Based on player feedback, we’re turning the knobs down a bit on warp drive. The ability to cancel a warp at any time made it more powerful and flexible than originally intended. To curb that, warp speed has been divided by 4. Although it may seem like we’re overcorrecting, in effect it’s not as drastic as it sounds. Travel will take a little longer at the new rate; expect trips to be closer to the minute mark rather than 15 seconds. This will take it from “blindingly fast” to “still pretty damn fast”. The cooldown has been adjusted to 150 seconds (2.5 minutes). This will require more judicious use of warping as you weigh the convenience of using it against having it available in case of needing to bug out quickly if you unexpectedly encounter threats. Probably the most impactful change is that auto-align strength during the warp sequence has been reduced to 20%. This change will correct a situation where the warp alignment was way too powerful for larger ships. Keep in mind you can still align manually before warping and skip this step. We hope this will keep pilots more engaged and thinking about the warping process either by passive aligning to an extract point or actively aligning before warping. We’re also adding spool-up time. Spooling is a post-align state in which your warp drive is spooling after aligning. This is intended to curb the purely reactionary defensive use of warp drives. Going into a PvP zone is a risk, and the risk vs. reward needs to reflect the weight of those situations. If you’re paying attention, hitting warp could get you out of most dangerous situations in a flash and we felt that this was a little too strong. Initially, the spool-up time will be set to 15 seconds. Last but not least, weapon fire taken during the initialization sequence - be it starting the warp, alignment, or spooling sequences - will cancel the action. (Note: Hits taken once the ship enters warp after the spooling process will not cancel the warp and the ship will continue to warp.) This is a behavior players have requested and we've also intended to implement for a while. Although we don’t want to shift the risk-vs-reward ratio too far the other way, we believe this is a good change. DOCKING AND BOARDING REVAMP Since we published the Docking and Boarding Revamp devblog, we have continued to iterate on the design to make it even better. Before explaining the incoming changes, here’s a quick recap of what we previously announced. The owner of a construct or ship is considered the “parent”. As a parent, you will now have more control of, and more information about, your current docking and boarding situation. On the information side, you will always see your current avatar/ship boarding/docking status. You are free to (un)dock/(un)board while in the immediate proximity of any construct to which you have RDMS rights. To get ''in'’ the construct, you will need to be docked/boarded to that construct or you will be repulsed. A new widget will display your construct parenting information. This will also be available in the control unit data in Lua. We’re also adding a build helper window that lists parented masses (player or construct) to the inspected construct. This will allow you to evict any unwelcome guests. Thanks to your feedback, we’ve revisited our plans and made some additional adjustments based on your input. The introduction of two alternative docking modes to complement the existing default “manual” mode. To change your docking mode preference, you will need to reset it in the context menu action on the targeted new parent construct or by using the new shortcut to switch active docking to the closest docking candidate. The "Automatic'’ mode will automatically dock you to the closest ship for which you have docking rights. ''Automatic (owner)'' will do the same if the ship is owned by the same entity as the pilot. The docking widget is changing to display these changes. New Lua functions will give you more flexibility to create docking rules for your constructs. Players also told us that having to use a context menu while maneuvering the construct felt awkward. To address this, we’re making changes to the reticle that will give more fluidity by allowing you to see the best docking candidate of the maneuvered constructs, using the same shortcut (Alt-T) so that you can switch docking of the maneuvered construct without using a context menu. COMING SOON Production to transition Ares from PTS to Live is well underway. It bears repeating that players, especially those who enjoy PvP, should spend a little time on the test server to see the impact these changes will have on their personal gameplay. We’d love to hear your feedback about Ares. Join the conversation in this thread.
  23. Hello Noveans! We would love to hear your thoughts about Devblog: Inside Ares, Part One!
  24. We recently announced that an additional update, Ares, was added to our public roadmap. Many of the features and changes for Ares will be available on our public test server (PTS), when it is updated and back online tomorrow, September 15th, at 10.00 UTC. (See the roadmap here.) In that announcement, we promised a devblog that would talk about the big-ticket items we plan to deliver with Ares: the new Core Combat Stress victory condition, more functionality for shields, and PVP-related fixes. (Inside Ares, Part Two will cover warp improvements as well as boarding and docking changes. Watch for it on Thursday.) Without further ado, let’s dive in! CORE COMBAT STRESS In a nutshell, core combat stress represents a core's ability to keep functioning under prolonged weapons fire. A core unit that takes too much stress will be destroyed and will be considered a PvP destruction. Core combat stress will be used as a second loss condition on constructs during PvP, working in tandem with generic core unit destruction. It does not matter which one happens first, only that one happens eventually. This will allow us to support larger fights and ensure that everyone's weapons are doing damage, even if it is only against core stress. Stress will be accumulated as the construct takes non-shield weapons hits, taking the form of a gauge that starts at 0% and goes up to 100%. Non-shield hits on a construct will make the gauge go up. The core stress gauge is affected by a weapon's raw damage and is unaffected by the resistances of the element or material the attack hit. Example: A weapon hit does 1,000 thermic damage. It hits an element with 50% thermic resistance doing 500 damage to the element; however, the core stress gauge will count 1,000 damage for that hit. When the core stress gauge hits 100%, the core unit will be destroyed and will be considered a PvP destruction (as if it was destroyed by a weapons hit) and everything that implies. The value of the stress gauge will be defined by the following: The base of the core stress gauge value will be the health sum of honeycomb materials on your construct. The quality of the material used will provide multipliers to the value. Higher honeycomb tiers will provide better multipliers. The type of material used will provide a different multiplier, with products having a better multiplier than pure materials. Finally, the stress gauge will gain health linearly with honeycomb until a cap, at which point additional honeycomb will have diminishing returns. SHIELDS v2 The fundamentals for shields were unveiled in this devblog and made their initial debut with the Apollo update in August. The time has come to increase their potency and value with some new features. Shields v2 brings adjustable resistances and venting. Adjustable resistances Shields have a base resistance value of 10/10/10/10 with an additional resistance pool of 60% that players can assign in 5% increments to any of the four resistances. (Examples: 10/10/10/70 or 25/25/25/25) Once players have locked in their resistance selections, those choices will be active and cannot be changed until the cooldown time of 60 seconds has expired, at which time the resistances will remain as set unless they are recalibrated. Shields UI will display which resistances are taking the most damage on the shield, allowing pilots to make an informed decision regarding the settings. Venting Pilots may vent their shields at any point, the exception being when the venting cooldown is active. Cooldown duration varies per size, with smaller shield variants having lower cooldowns. Venting shields will do two things: Turn off the shields, bearing in mind that they can’t be active during venting. Begin shield regeneration of a certain percentage per second. Venting may be deactivated at any time. Deactivation will occur automatically when shields have reached maximum capacity. We highly encourage pilots to explore the use of shields and venting while it’s available on PTS. Since there’s a bit of a learning curve involved, the test environment is the perfect place to experiment freely without any real cost to your ship on the Live server. PVP FIXES We’re closing the loop on some “unintended” uses of these game mechanics. Speed Resume deactivated on construct death: When a core is destroyed, that construct will be incapable of benefitting from speed resume in any way. This will avoid and fix various exploits in regards to “ghost-riding” destroyed ships into safe zones. Offline player deaths on construct death: Offline players on constructs will now be killed on core destruction. This will avoid logging off characters that can then log back in, repair the core unit, and attempt to flee. Originally, the plans also included a change that would cause ownership loss on core unit crash destruction. Thanks to our intrepid PTS players who tried it out and promptly let us know the problems such a change could cause, we pulled it from the Ares update. (Read the related post from the Game Design team’s NQ-Entropy.) This is exactly why we have a test server and why we value those who do reconnaissance there before the updates are released on the Live server. We offer sincere thanks to the players who took the time to give us candid, constructive feedback. SEE YA THURSDAY Inside Ares, Part Two will be published on Thursday. While you’re waiting, why not head over to the forum and share your thoughts about Part One?
  25. The Dual Universe roadmap that we presented in July has been revised with an additional update, Ares (0.26.10), sliding in before Demeter (0.27), which has, in turn, been slightly delayed. Ares will bring more changes to PvP with the addition of Shields v2 thanks to the introduction of adjustable resistances and venting to complement the feature introduced in Apollo (0.26). Together with a new victory condition called “Core Combat Stress”, we hope to offer an improved PvP experience as players continue to fight for the riches of the newly introduced asteroids. Watch for an upcoming devblog that will cast more light on these PvP-related topics. Other additions in the Ares release include warp drive improvements and the previously announced boarding and docking revamp. Ares is full to the brim with new features, necessary tweaks, and lots of bug fixes. With this update, you should be able to fight more, hit harder, deflect weakness, and be the thundering galactic sky god you are meant to be. PTS UPDATED WITH ARES FEATURES TODAY For a limited time, the Dual Universe public test server (PTS) will be available with a preview of some of the content that will be featured in the Ares (0.26.10) update. (Additional Ares features, as well as several exploit fixes will be added to PTS soon.) We urge all Noveans to take advantage of this opportunity to explore all of the changes and new content as soon as possible. We would like to ask players to look into honeycomb and terrain voxels for any issues they can find with their constructs due to recent technical improvements we have made. We would also like to remind you that the PTS was recently updated with a mirror of the live server database, which means that most of your recent possessions and creations should be right there, waiting for you to help test the future Ares release. If you’re new to the PTS, please read more about what to expect here. The universe is waiting for you! Head to the PTS and start pew-pewing to your heart’s content. Constructive feedback is greatly appreciated and encouraged. You can share those with us here. Join the conversation about the Ares update and the revised roadmap in this thread.
×
×
  • Create New...