Endstar

All I know is Aphelia is one mean AI <insert foul word here>.  She has taken everything from me a few times now and played really bad tricks about how my whole DU existence was a simulation. You can fight her and see her wrath. I'm still hoping she is not again messing with us and come next year we awake poor, talentless, and on an empty planet to start over. 
 
#StopTheWipeHype

We have asked NQ to consider this: 
 
Release with a new system. All new accounts will only spawn in that system. 
 
All existing accounts are stuck in Heilous until a stargate is crafted. Make the craft time long like in the 90-180 day area. 
 
This gives new players a clean start without veteran interference. It gives existing players an option without a wipe where they cannot snowball over new players. By the time the stargate is crafted enough time has taken place to allow new players to grow without interference. 
 
Lastly it will add subs for NQ as some of you will not wait you will just sub a new toon to see and start in that system until the gate is open. 
 
Sort of a middle ground between wiping and not wiping. 
 
 

We have asked NQ to consider this: 
 
Release with a new system. All new accounts will only spawn in that system. 
 
All existing accounts are stuck in Heilous until a stargate is crafted. Make the craft time long like in the 90-180 day area. 
 
This gives new players a clean start without veteran interference. It gives existing players an option without a wipe where they cannot snowball over new players. By the time the stargate is crafted enough time has taken place to allow new players to grow without interference. 
 
Lastly it will add subs for NQ as some of you will not wait you will just sub a new toon to see and start in that system until the gate is open. 
 
Sort of a middle ground between wiping and not wiping. 
 
 

We have asked NQ to consider this: 
 
Release with a new system. All new accounts will only spawn in that system. 
 
All existing accounts are stuck in Heilous until a stargate is crafted. Make the craft time long like in the 90-180 day area. 
 
This gives new players a clean start without veteran interference. It gives existing players an option without a wipe where they cannot snowball over new players. By the time the stargate is crafted enough time has taken place to allow new players to grow without interference. 
 
Lastly it will add subs for NQ as some of you will not wait you will just sub a new toon to see and start in that system until the gate is open. 
 
Sort of a middle ground between wiping and not wiping. 
 
 

We have asked NQ to consider this: 
 
Release with a new system. All new accounts will only spawn in that system. 
 
All existing accounts are stuck in Heilous until a stargate is crafted. Make the craft time long like in the 90-180 day area. 
 
This gives new players a clean start without veteran interference. It gives existing players an option without a wipe where they cannot snowball over new players. By the time the stargate is crafted enough time has taken place to allow new players to grow without interference. 
 
Lastly it will add subs for NQ as some of you will not wait you will just sub a new toon to see and start in that system until the gate is open. 
 
Sort of a middle ground between wiping and not wiping. 
 
 

Seems like a lot of big org hating here... 
 
Why?

This is a civilization building game or at least it has been promoted as such. It is not a single player game where you can solo fly a battleship and take down anything you encounter without loss. That is called a single player game with a difficulty setting of  "ridiculously beyond easy". 
 
Why do people care about what someone else has? 

How would anything be different in 2 years if the game wiped everything right now? 

Having no player snowball effect in persistent game state is a really hard problem very few games ever crack with giving up something major.  Maybe put the salt away and tell us what do you want to give up for these two incompatible aspects?
 

We were always told our stuff would only be safe on the sanctuary moon if we left the game long term. 
 
Taxes are a means to remove inactive players and give us salvaging opportunities. 
 
The scans we have were obtained by fair game play. Keeping them seems acceptable as the time was invested in the game to explore that hex. 
 
 

Whatever this whole thread is about that is one smexy looking ship  

If you bought a stacked ship tough love. You knew and if you did not the fact only handful of ship builders have the ability to make haulers that can haul 2-5 times everyone else should have been a sign something is not right. Pled ignorance, complain all you want. In the end your just self justifying your cheating.  
 
I'm happy players that really know how to properly engineer and build ships now can again without everyone passing their ships by because they cannot haul insane amounts of cargo. 
 
Small unintentional or even slightly overlooked stacking is not the problem. Making a ship to haul insane amounts of cargo or having a PvP ship the size of a pea shooter with the elements you would normally find on a capital ship is what this is all about. This whole matter is around the intent to abuse over the OMG I have one single overlapping element I accidently somehow did. This is why NQ wants to do this via reporting. 

How do you make a game without grinding? 

I understand this. That is why when I stopped playing I donated all my money, materials, real estate and constructs to someone who intended to keep playing.

When you quit, do your bit for for the future of the game and don't horde binary wealth in a black hole that you will never open again.

I just like the ship in the corner! Go 1K ! 

Let's be clear here, it is no secret that I have been a HUGE advocate of this game. I love playing it.

But I am now, at least partially, on Hiatus until we have the ability to turn off the hand tool graphic effects while in build mode (and frankly the hand and tool themselves would be nice too.)

The constantly bobbing hand and gun that takes up a third of the space is bad enough while building, but adding strobing, rippling, distortion causing effects that bleed even further into the build space is absurd. 
 
Dear devs, Imagine you're at your desk, you're trying to program, concentrating hard, and someone comes along, sticks his hand over your shoulder and starts waving around a LED strobing nerf gun covering up a substantial portion of your work space. Would you be happy?

Please, pretty please, add a checkbox to settings YESTERDAY to turn this obnoxious bit of useless silliness off. I really want to be able to continue building and designing, doing the Voxelmancy that I love so much. Right now, it is impossible for me.

Thank you.
Tordan

This video actually gets into the reason you need P2W and F2P together. Just thought it was interesting as if NQ is having problems more than likely that is due to needing more revenue. 
 
 

This video actually gets into the reason you need P2W and F2P together. Just thought it was interesting as if NQ is having problems more than likely that is due to needing more revenue. 
 
 

This video actually gets into the reason you need P2W and F2P together. Just thought it was interesting as if NQ is having problems more than likely that is due to needing more revenue. 
 
 

Give us ship power management, make us have to fit elements to a power schedule.  Do not let us just stack power elements to get a wall of engines. 

Give us ship power management, make us have to fit elements to a power schedule.  Do not let us just stack power elements to get a wall of engines. 

Sample Scripts (Advanced)
These more advanced scripts demonstrate what can ultimately be achieved with this API. Perhaps they will inspire you a bit!
 
Entropy Like the bouncy ball example, but fancier!
local ballCount = 5000 local speed = 20 local rx, ry = getResolution() --[[ init ]]-------------------------------------------------------------------- if not init then init = true function randF (a, b) return a + (b - a) * math.random() end function randExp () return -math.log(1.0 - math.random()) end balls = {} for i = 1, ballCount do local e = {} e.x = randF(0, rx) e.y = randF(0, ry) e.r = 1 + 1.0 * math.log(1.0 - math.random()) ^ 2.0 e.vx = randF(-1, 1) * randExp() e.vy = randF(-1, 1) * randExp() e.cx = 1.0 * math.random() e.cy = 0.1 * math.random() e.cz = 0.4 * math.random() e.ca = math.random() table.insert(balls, e) end end --[[ simulation ]]-------------------------------------------------------------- local dt = speed * getDeltaTime() for _, v in ipairs(balls) do v.x = v.x + dt * v.vx v.y = v.y + dt * v.vy if v.x < 0 or v.x > rx then v.x = v.x - dt * v.vx v.vx = -v.vx end if v.y < 0 or v.y > ry then v.y = v.y - dt * v.vy v.vy = -v.vy end end --[[ rendering ]]--------------------------------------------------------------- local l = createLayer() -- render balls for _, e in ipairs(balls) do setNextFillColor(l, e.cx, e.cy, e.cz, e.ca) addCircle(l, e.x, e.y, e.r) end -- render title local font = loadFont('Play-Bold', 64) addText(l, font, '{{ E N T R O P Y }}', 32, ry - 32) requestAnimationFrame(1) --------------------------------------------------------------------------------  
 
Radial Menu Practical example of how responsive UI elements could be designed, creates 3 radial menu's using the same function.
Left: Example with transparency on the circle layer to demonstrate layering and the use of math to define the circle stroke.
Top right: Example without transparency, drawn to a different scale.
Bottom right: Example of a collapsible version saving screen real-estate and reducing rending costs while collapsed. (Only a dot is drawn while collapsed)
-- Get screen resolution and center coordinates local resolutionX,resolutionY = getResolution() local centerX,centerY = resolutionX/2, resolutionY/2 -- Draw radial menu layers local triLayer = createLayer() local circleLayer = createLayer() local textLayer = createLayer() -- Define some helpers to convert degrees to radians local d2r = math.pi/180 -- Helper function to get distance of cursor from coordinates function getCursorDistance(x,y) local curX,curY = getCursor() curX = curX - x curY = curY - y return math.sqrt(curX^2+curY^2) end -- Helper function to check if cursor is inside a radial menu section function isCursorInside(radialCenterX,radialCenterY,radiusMin,radiusMax,degMin,degMax) local curX,curY = getCursor() curX = curX - radialCenterX curY = curY - radialCenterY local magnitude = getCursorDistance(radialCenterX,radialCenterY) local deg = math.atan(curY/curX)/d2r if curX < 0 then deg = deg + 180 end if curX > 0 and curY < 0 then deg = deg + 360 end if magnitude <= radiusMax and magnitude >= radiusMin and deg > degMin and deg < degMax then return true end end -- Define function that can draw a radial menu on demand function drawRadialMenu(posX,posY,radius,steps,hide,strokeAndCenterAlpha) -- Define default variables local posX = posX or centerX local posY = posY or centerY local radius = radius or 200 local steps = steps or 15 if hide ~= nil then hide = hide else hide = true end local strokeAndCenterAlpha = strokeAndCenterAlpha or 1 -- minimum of 4 segments steps = math.max(steps,4) -- work out the depth of the triangular facets along the circumferance and use it to determine the outer circle stroke width local aX,aY = radius*math.cos(0) , radius*math.sin(0) local bX,bY = radius*math.cos(((360/steps)*1)*d2r) , radius*math.sin(((360/steps)*1)*d2r) local stroke = math.min(-(radius-math.sqrt(((aX+bX)/2)^2+((aY+bY)/2)^2)),-3) if not hide or (hide and getCursorDistance(posX,posY) < (radius)) then -- Draw triangular segments local alpha = 0.5 for step=1,steps,1 do -- calculate the corners of the triangles on the radius local aX,aY = posX + (radius*math.cos(((360/steps)*(step-1))*d2r)) , posY + (radius*math.sin(((360/steps)*(step-1))*d2r)) local bX,bY = posX + (radius*math.cos(((360/steps)*step)*d2r)) , posY + (radius*math.sin(((360/steps)*step)*d2r)) -- call helper function to determine if cursor is inside the segment and change color if true if isCursorInside(posX,posY,radius/3,radius,((360/steps)*(step-1)),(360/steps)*step) then setNextFillColor(triLayer,1,1,1,1) -- create center number while the cursor is over a selection local font = loadFont('Montserrat', math.floor(radius/4)) setNextFillColor(textLayer, 1, 1, 1, 1) addText(textLayer, font,step, posX-((radius/12)*#tostring(step)), posY+math.floor(radius/12)) else setNextFillColor(triLayer,1,0,0,alpha + 0.5) end -- Draw the triangle based on pre-calculated coordinates and with the color now preset addTriangle(triLayer,posX,posY,aX,aY,bX,bY) -- flip the alpha between 1 and 0 for the next segment alpha = 0.5 - alpha end -- Create the outer stroke which should be a negative value so it overlaps the triangle facets setNextStrokeColor(circleLayer,0.5,0.5,1,strokeAndCenterAlpha) setNextFillColor(circleLayer,0,0,0,0) setNextStrokeWidth(circleLayer,stroke) addCircle(circleLayer,posX,posY,radius) -- Create the inner stroke and fill to create the "hole" in the center at 1/4th of the radius. setNextStrokeColor(circleLayer,0.5,0.5,1,strokeAndCenterAlpha) setNextFillColor(circleLayer,0,0,0,strokeAndCenterAlpha) setNextStrokeWidth(circleLayer,stroke) addCircle(circleLayer,posX,posY,radius/4) else -- Create a transparent dot to indicate its position while its hidden. setNextFillColor(circleLayer,0.5,0.5,1,0.2) addCircle(circleLayer,posX,posY,radius/4) end end -- Draw three examples -- Example 1 (large one on left) with transparency to demonstrate how the circular shape was achieved with the triangles. drawRadialMenu(resolutionX/3,centerY,200,6,false,0.5) -- Example 2 (Top right) Does not hide, shows the result without transparency drawRadialMenu((resolutionX/3)*2,resolutionY/3,100,8,false) -- Example 3 (Bottom right) Remains hidden and un-rendered until the cursor enters its area, reducing render cost by ~120000 while hidden. drawRadialMenu((resolutionX/3)*2,(resolutionY/3)*2,80,36) -- 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 -- Request a refresh requestAnimationFrame(1)  
 
Text positioning Demonstration example of the various alignment points for text using Font Metrics and Text Align.
local fontName = 'Play' local fontSize = 32 local font = loadFont(fontName, fontSize) local fontDebug = loadFont('FiraMono', 12) local back = createLayer() local layer = createLayer() local rx, ry = getResolution() local ascender, descender = getFontMetrics(font) local text = "??" frame = (frame or 0) + 1 setDefaultFillColor(layer, Shape_Text, 1, 1, 1, 1) setDefaultFillColor(layer, Shape_Circle, 1, 0, 0, 1) function drawTextBox (x, y, alignH, alignV) local w, h, ascent, descent = getTextBounds(font, text) if alignH == AlignH_Left then x = x elseif alignH == AlignH_Center then x = x - w/2 elseif alignH == AlignH_Right then x = x - w end if alignV == AlignV_Ascender then y = y h = ascender - descender elseif alignV == AlignV_Top then y = y elseif alignV == AlignV_Middle then h = ascender - descender y = y - h/2 elseif alignV == AlignV_Baseline then y = y - ascent elseif alignV == AlignV_Bottom then y = y - h elseif alignV == AlignV_Descender then h = ascender - descender y = y - h end setNextFillColor(back, 0.1, 0.5, 1.0, 1.0) setNextStrokeWidth(back, 1) addBox(back, x, y, w, h) end function main () if frame % 2 == 0 then text = "acemnor " else text = "aCjÅkö[]|!r " end -- display debug info about font if true then local infoLines = { string.format(" font : %s", fontName), string.format(" size : %d", fontSize), string.format(" ascender : %d", ascender), string.format("descender : %d", descender), } for i, line in ipairs(infoLines) do setNextTextAlign(layer, AlignH_Left, AlignV_Top) addText(layer, fontDebug, line, 16, 16 + (i - 1) * 12) end end local alignHs = { 'AlignH_Left', 'AlignH_Center', 'AlignH_Right', } local alignVs = { 'AlignV_Ascender', 'AlignV_Top', 'AlignV_Middle', 'AlignV_Baseline', 'AlignV_Bottom', 'AlignV_Descender', } -- draw text boxes with various alignments local sx = 300 local sy = 80 local x0 = rx/2 - sx * (#alignHs-1)/2 local y0 = ry/2 - sy * (#alignVs-1)/2 for y, alignVName in ipairs(alignVs) do for x, alignHName in ipairs(alignHs) do local px = x0 + sx * (x - 1) local py = y0 + sy * (y - 1) local alignV = _ENV[alignVName] local alignH = _ENV[alignHName] drawTextBox(px, py, alignH, alignV) setNextTextAlign(layer, alignH, alignV) addText(layer, font, text, px, py) addCircle(layer, px, py, 3) end end -- draw AlignH labels for x, alignH in ipairs(alignHs) do setNextTextAlign(layer, _ENV[alignH], AlignV_Descender) setNextFillColor(layer, 0.5, 0.5, 0.5, 1) addText(layer, fontDebug, alignH, x0 + (x - 1)*sx, y0 - 16) end -- draw AlignV labels for y, alignV in ipairs(alignVs) do setNextTextAlign(layer, AlignH_Right, _ENV[alignV]) setNextFillColor(layer, 0.5, 0.5, 0.5, 1) addText(layer, fontDebug, alignV, x0 - 16, y0 + (y - 1)*sy) end end if not isFontLoaded(font) then requestAnimationFrame(10) else main() requestAnimationFrame(120) end  

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

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

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

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

 

Awesome! 

Discuss the final chapter of this series below!  What are you most looking forward to? 

Awesome! 

PART THREE: FINDING THE FUN 
 
In this third and final segment of this series, we’ll take a look at Dual Universe gameplay and how we’re aiming to improve it. There’s a delicate balance to strike between staying as true as we can to the original vision, making smart design and production choices, taking players’ feedback into consideration, and creating more opportunities for community engagement. The game needs to be challenging but, most of all, fun. It can be a tall order sometimes, but not an impossible goal. 
 
This is far from being a comprehensive list of everything we’re working on, but we think it’s a good starting point for sparking conversation with the community. You’ll also notice that we have intentionally stayed away from precise timeframes. We would rather stay flexible and give ourselves the opportunity to revise our plans based on the feedback of players. 
 
Now, let’s get to the good stuff!
 

BREAKING THE MONOTONY 

Even if the main pillars of the game aren’t quite finished yet, the launch of the beta allowed us to see how the various systems work together, how fun they are, and what actually works or sometimes doesn’t.
 
Analyzing data on player behavior and reading the copious amount of feedback we receive (thanks for that!) have pointed to two main objectives we’ll be addressing in the coming months (in addition to continuing to fix bugs and balancing issues). These are: 
 
First, emend gameplay loops that are tedious for some players. We call it “fixing the player routine”, so that playing DU doesn’t feel like “going to work”. Up the stakes, adding meaningful opportunities for conflict so that the in-game economy, social components, and building aspects come together. 
  Some elements of gameplay are more fun than others in Dual Universe. Mining can often be seen as a must-do for many new players, and because it is perceived as mandatory it can rapidly feel tedious. Earning quanta is fundamental. When we launched beta, it seemed like mining was almost the only way to get money, especially for new players who didn’t have much in the way of resources or allies. 
 
To make it more interesting with a real sense of progression over time, here is the high-level plan:
 
Make it easier for newcomers to gather resources from the surface of planets without the need to dig; Then, transition players to deploying mining units once they’ve claimed a territory. Mining units will supply a steady stream of ore, depending on the specifics of the tiles the player has claimed. These mining units come in tiers and should add a sense of progression even to early mining. There will also be a production optimization gameplay if you want to use several mining units. For players who want to specialize in mining, we will introduce asteroid mining. Think of asteroids as epic mining with high reward potential. Asteroids will be spawned in the universe. Players will be able to scan clues in space to discover where they’re located. Some asteroids will contain not just regular ores, but also rare and valuable ones. Once discovered, there will be a delay before their location is broadcast to all players. This is an opportunity for explorers who find these asteroids to reap their resources first or monetize their location. The control of valuable asteroids will also create opportunities for combat, information trading, and collaboration between players. Please also note there will be asteroids in safe zones with lower-value ores.
  THE QUEST FOR QUANTA   
Another way for players to earn quanta is the previously-announced Mission System, coming in version 0.25. It will include two components: a job board to facilitate interactions between players (for example, “I need gold delivered to this location”), as well as a secure framework for player- and NQ-created hauling missions. We hope that this will kindle the game’s economy with increased specialization and proper tools for exchanges between players. The upcoming introduction of in-game challenges will also add fun ways for players to earn cash. 
 
On that note, we plan to revise the way the markets work, considering different ways to improve connections and making it less painful to trade for goods. This should make markets more accessible and fluidify trade.
 
We are looking into how we can rebalance the industry. The reaction to changes introduced in 0.23 told us that there is more work needed here. The role of schematics is definitely one of the areas we’re looking at; whatever we do with schematics, we are particularly sensitive to making a fair move for players who have invested in buying them. 
 
Builders haven’t been forgotten. We just delivered new tools for them in 0.24, and we are already working on new ones that should let builders enhance their artistic arsenal to create more amazing constructs. We’re pretty excited about them, but should forewarn you that it may be some time before they appear as higher priority changes will take precedence. 
 
The first-time player experience will get a full overhaul to facilitate the onboarding of new players. We’re doing away with the long monologues from Aphelia and the length of time it took to get into the action. The tutorials will be more contextual, and the experience of new players should get them into the core gameplay faster. As it is now, new players sometimes need to travel long distances to find a tile free of neighbors and suitable for future expansion. The redesign will allow these new pioneers to start with their friends in a location of their choosing in a more streamlined fashion. They will also be able to select an outpost design and receive startup resources. 

STOKING THE PVP FIRES 
We know a lot of players want to hear about PvP. Once we’ve fixed the main gameplay loops, this will be the next thing we’ll tackle. Our goal is for space warfare to be one of the driving forces of the emergent gameplay, fueling the economy of the game, including for players who don’t want to directly partake in combat but might want to provide ships, ammunition, and services for those who do. 
 
While there are PVPers who are in it for the thrill of the pirate’s life, there are others who aren’t pirates so much as protectors who enjoy defender-type PVP scenarios. In its current state, PVP can be seen as gratuitous, devoid of reasons to fight beyond pillaging a bested ship’s cargo. The current PvP mechanics will be modified with the addition of construct shields and a rebalancing of weapons, among other things, as well as introducing territory control in space and, later, on planets. Controlling space territories will give players benefits such as the ability to acquire highly-lucrative space resources (i.e. rare gas, singularities) and a worthwhile reason for organizations and solo players to fight. Not only that, but you’ll be waging war in style with an array of new, unique cannons and skins. 
 
GLITZIER GRAPHICS
Admittedly, graphics improvements have been on the back burner for a while in favor of building the main gameplay systems. Upgrading the visual immersion has now taken a more prominent position in our priorities, the goal being to give more “life” to Dual Universe. 
 
This ongoing process began in 0.24 when we overhauled many of the assets used in world generation (i.e. trees, rocks, ground textures, etc.) We’ve also undertaken a big push on visual effects, with a slew of new and improved visual effects planned for gradual release in the near future. Continuing our efforts with the recent addition of new voxel textures for builders, we will freshen up many older elements in the game to bring coherence between older and newer assets, as well as between voxels and assets.
 
We are also investigating longer-term visual improvements. For some time, we’ve been working on prototypes for a new planet generation technology to make sure that our planets are interesting to explore. Before we can roll this out, we will be doing an overall pass on the existing planets, like Jago, with improved terrain and more varied environment assets. There is also a project to improve lighting with the inclusion of global illumination.

CLOSING THOUGHTS
Again, please remember that all these changes will be tested first on the public test server. The final versions of these features may vary depending on your feedback and our own thought  processes. In terms of timing, most of the “player routine” fixes are planned to be gradually introduced before the end of the summer while the space warfare and PvP revamp should begin rolling out sometime after.
 
As you hopefully see, a lot of these changes are based on your feedback and a more grounded, pragmatic approach to game design. We realize that many of these topics require additional explanations and that they will probably trigger more questions. We will answer them in due time, as we’re able, in future devblogs. Until then, we look forward to hearing your thoughts in this discussion thread. See you there! 
 

I don't think it hurts anyone.  From NQ's point of view every DAC in existence has already been paid for, and it shouldn't matter who redeems it.