Physics

Hello, everyone! I'm Mark van den Heuvel, known to many of you as NQ-Deckard, a member of the Production team here at Novaquark.
 
First, to those of you who celebrated your new year recently, I wish you a wonderful new year, and I look forward to seeing all of your creations in-game. As we step into 2023, I want to bring you all up to speed on where we're at with Dual Universe and where we are going.
 
After our launch last September, we have all worked hard to squash remaining bugs and improve balancing. We also delivered the promised digital Kickstarter rewards to our backers.
 
As is always the case with Dual Universe, work does create itself in front of us, and we have a great deal to work on and improve. One of our current central goals is to enhance the gameplay experience and catch up with some features and quality-of-life improvements, particularly some of those requested by our community.
 
Let me walk you through some of what we have planned for you both soon and further down the road.
 
Planets

We’ve recently released a new version of Talemai, and we’re continuing work on the others. After reviewing our progress, we've decided to take extra time to make the new planets truly feel different with new art, new terrain, and more exciting features. This means they are coming at a slower pace and possibly in a different order than we had envisioned. Expect new teasers, concept art, and images from us soon™!

Combat Missions

We had decided early in the life of Dual Universe not to focus on a PvE combat system, given other priorities. With all of the feedback we’ve received since the beginning of the game, PvE combat has consistently remained a highly requested feature from our community. We always try to listen to your feedback, and I’m happy to announce that we have begun work on implementing the first iteration of a PvE combat system into the game!
We’re planning the first version to be a PvE mission system that takes players into combat in their ships. The missions will scale in size to allow all players (solo or part of a larger group) to participate.
 
We’re very excited about the PvE combat feature. It will add more engaging gameplay for all Noveans and allow players to try out the rigors of space combat before heading out to battle with other players in Dual Universe PvP.
 
We are still in the early development of this feature, and it will take time, but we are already looking forward to seeing you all trying it in future PTS sessions. Your feedback will be instrumental in our developing PvE combat in Dual Universe.

PvP Improvements

Following a recent and very successful round table discussion with members of our PvP community, we are reviewing all the feedback gathered and our own data to determine what changes we will make. We are considering increasing the importance and/or requirement of having voxel armor onboard successful PvP ship designs, finding ways to encourage multi-crew ship setups, and potentially restricting the ability to remove cargo while in combat. Stay tuned for more exciting developments on PvP.

Contest Winner Constructs

Before launch, we ran the Build Your Legacy Contest for players to design starting outposts and speeders, with the winning entries being added to Dual Universe. We are currently working to make the constructs that the contest winners submitted available as options to select during the first start of the game, and we are also looking to make these available for purchase in the UEF shop. The contest entries were original and impressive. I want to congratulate all of you who took part. 

Maintenance Unit

A complete rework of the repair unit was planned for the 1.2 release just before the holidays. The feature still needed more work, and we decided to delay its release with plans to include it in the upcoming 1.3 update. When finished, the repair unit will be replaced with the maintenance unit, which can repair constructs with scrap and disassemble constructs. However, construct disassembly is the feature that still requires the most work, and we are determining if the feature will make it into the 1.3 release. When added, this feature will remove the pain of finding that one last bit of voxel in a construct and make redesigning builds easier, with the Maintenance Unit taking down constructs for you.

Joystick Support

Dual Universe already has a basic system to connect joysticks to the game. However, these were never cohesively connected with the Lua system. We will change that, allowing players to map analog and button inputs from Joysticks, Throttles, Pedals, and even simple Gamepads into Dual Universe. This will significantly improve the flying experience for non-Lua developing players and open new doors for Lua developers through projects such as Lua arcade games, custom flight control systems, and other nifty things our community creates.

Default Lua Configuration Rework

Once we’ve added Joystick support, we will redesign the default Lua scripts we give to players. Our community has long requested this update, and we want to ensure we deliver it. We will add a full suite of features and improvements. This means new Lua flight control systems, the ability to toggle widgets on and off without requiring Lua code, and integrating several systems not fully encapsulated in current control scripts, such as Anti-Gravity Generators.

Fuel Intake Changes

This has been a popular demand by our players, and we are looking into options to allow players to refuel tanks from another element. Currently, we plan to make a  'Fuel Intake' able to act as a proxy for a single fuel tank. This feature is still on the drawing board and may change as we dive deeper into it.
 
-------------------------------------------

As always, thank you for reading this short overview of some of what’s coming up. I hope you have a clearer picture of the direction we're taking Dual Universe in, and I look forward to hearing your thoughts on the forums. Have a wonderful day.
- Mark (NQ-Deckard)
 

When I look at that and remember the ships before the changes ?
 

Make it so the more packages you have, the further away you can be seen 🍿

Make it so the more packages you have, the further away you can be seen 🍿

Apologies for my tone but this post has really annoyed me. The Karen's here are entitled to cry and moan all they want but threats and harassment is an absolute f***ing no.
 
Please report any of these activities because these players needs to be gone.

Apologies for my tone but this post has really annoyed me. The Karen's here are entitled to cry and moan all they want but threats and harassment is an absolute f***ing no.
 
Please report any of these activities because these players needs to be gone.

First just to be absolutely clear, on September 27th Dual Universe will launch and all player accounts will have their talent points reset to a nominal (near zero) starting value.
The talent point accelerator event applies to all active subscribers. Backer status has no effect. The 6 months of talent queue was merely a recommendation to ensure that players get the most value out of said event. Feel free pick a different time period if you wish but keep in mind longer queues will help NQ plan for the future since they can pull statistics on them and thus get a feel for what players are specializing in. Being a gold Kickstarter or higher, a Patron Supporter, or having subscribed for 13+ months during the beta phase makes your account eligible for the Exotic Pioneer Pack. If you meet this requirement, have an active subscription, and login to the game at least once during the first month, then you will be awarded the items listed in Pioneer Pack Rewards. The quanta and talent point rewards listed in the packs are distributed at the end of each month for 6 months. Meaning an Exotic Pack owner will get 400,000 quanta and 3 million talent points at the end of each month for 6 months, resulting in a total of 2.4 million quanta and 18 million talent points by the end of the 6 month event. Note that the larger 52.9 million talent point value listed in the graphic also includes passive talent point accumulation (with accelerator) during the first 6 months and is hence a rough estimate for the total number of talent points said pack holder can expect to have at the end of the 6 month launch period.

Every  item you put on a ship adds adds weight, adds cross section, must be repaired when damaged. Unless it serves a purpose there is no reason to have one on your ship other than looks. 
 
You could go as far as removing  the repair cost,  removing all the weight not having it add cross section.  Which would not seem right for DU. 
 
But these are all negative things. So why dont we give them bonuses.  They dont need to be huge bonuses. Not to the point where people feel they have to have them on their ships.  For instance placing down a metal beam might increase element HP of nearby items maybe by a set amount or maybe by a percentage. Maybe that bonsai plant reduces weight of nearby items.  or what ever part reuces cross section. Or having the decorative radar increases the usuable radars range. Or having a bed increasing weapons damage. Maybe having a toilet increases explosive damage of your ship. 
 
There are hundreds of different stats to effect. Give players fun instead of taking it away. 
 
Ohh and rework repairing ships so the repair are actually economically feasible. 

I will attempt to give a better picture regarding blueprints, what I can confirm is that in the event of a reset you will keep:
Any Core Blueprints in your Nanopack. Any Core Blueprints inside Packages in your Nanopack. Any Core Blueprints inside Containers on constructs in your personal ownership. Any Core Blueprints inside Packages inside Containers on constructs in your personal ownership. If you're the Super Legate of an organization you will also receive:
Any Core Blueprints inside Containers on constructs in the organizations ownership. Any Core Blueprints inside Packages inside Containers on constructs in the organizations ownership. I hope this clarifies it a little bit.  

I actually agree with many points here. NQ needs to drop a pair and just announce the obvious. Blueprints are a given exemption from any wipe (Blueprint snapping is a must have before any wipe also). Talent point retention is the sweetner. Pretty much anything else needs the delete key and have done with it all. 
 
Anyone trying to vocally keep their horded crap (I have billions worth of schems and other stuff also) without caring about the wider picture of the game just needs to shut up and NQ needs to hurry up and get this announcement over and done with. 
 
As for this Schematic removal idea NQ mentioned I'm a bit concerned on that. That would mean harsh gating on resources to balance it all out. Kinda like the current plasma gating but this would go all the way down the tiers and maybe even harsher. 

I'm going to bite tounge on my thoughts on this subject for now and just say thank you for the response Entropy. I'll always applaud the dev team jumping in direct communication like this. Keep it coming mate!

i always repair myself even when its not my fault i never have asked a GM to repair my ship.

Keep the events coming Nyota 👍

I'm going to bite tounge on my thoughts on this subject for now and just say thank you for the response Entropy. I'll always applaud the dev team jumping in direct communication like this. Keep it coming mate!

really appreciate the detailed reply.  It sounds like pvp ships are destined to remain tiny little blobs with no design flexibility.  My M core only has 45t of voxel and is already considered too heavy in athena.  I feel like we have all this design freedom in DU but in pvp its squeezed into a thimble.  
 
I like that you appear to want 'some' honeycomb to be used.  but as primarily a ship builder, building pvp ships at the moment is dead in the water. 
Venting should be a tool that gives arnoured ships an advantage because they can tank more damage but are easier to hit...but at the moment having armour is such a disadvantage (especially on m cores that become too easy to hit by exotic L weapons if they are armoured/bigger) that the benefit venting brings is insignificant.  
 
DU has miles to go to make pvp work imo and NQ are moving 1mm at a time. 

Hello there,
 
First off, thanks for the feedback. 
 
So there's a couple of different things to touch on here:
 
The internal balance of shields sizes CCS/honeycomb health vs Shield Health per mass Venting
I’ll try to address in that order but they will mesh a little since they have some obvious links.
 
First of all smaller shield sizes are at an advantage in regards to HP/mass. So something to keep in mind is that as you go up in size, as it pertains only to shields, you are losing out on the HP/mass ratio (in simpler terms, each HP weighs more on larger shields). This is an inbuilt advantage smaller sizes simply have.
However, the main and primary reason we have different shield sizes at all, is to support constructs of varying sizes and mass. This is the key center-point around which everything else mostly revolves.
 
If you are intending to make a larger, heavier construct, that is going to trend towards or go past the max mass, then the large shield becomes the obvious choice. However, should you want to make something smaller, more agile, and quicker, you may start to use shields of smaller sizes. We already see people experimenting with constructs of smaller sizes using S and M shields to take advantage of the speed, this is a great direction, as long as the pendulum does not swing too far in the favor of smaller constructs.
Now, if the weight penalties do not sufficiently affect the design of the ship, and large shields are still too mass effective even on smaller designs. That's a subject we will continue to address. We do not want to see S designs using exclusively L shields because the additional mass from larger shields doesn't matter in regards to acceleration, max speed, and rotation speed.
 
To answer your question clearly, there is no direct goal for an M shield and an equivalent 95t of voxel to be worse, equal, or better than an L shield and I’ll try to explain why as we go. You should take the shield of the size that makes sense for the design of your ship. If you have the mass available, or are willing to “spend” the mass to have a larger shield, then go for it.
 
Don't want to get into the venting subject too quickly, but using an M with a bunch of honeycomb could allow you to vent once or twice during a battle, especially on a lighter design that can also evade some damage. Maybe the balancing on that isn't perfect, but it should be an option.
At the end of the day the inbuilt advantage of an M shield over an L shield is that it's significantly lighter. You say it's always worth going to an L shield because M+HC is worse in HP, maybe this is the case (more on that later) but the point is that for that 95t you could probably build out a good part of a fully equipped construct, allowing you to have a quicker, more agile construct with a superior max speed, that's the upside.
 
Talking concretely in regards to the mass, if I made a competitive light-ish design with an M shield around 250t ( I don't have one on hand, this is probably on the lighter side after the changes). I'm going about 38-39k km/h max speed, just switching from an M shield to an L shield, I drop down to about 35k km/h. Now adding an extra 95t to a 250t design is probably going to seriously hurt my acceleration as well, so now I'm probably at least looking at redoing my engine setup, which likely adds some more mass as well.
So now the question is more along the lines of, do I prefer an extra 5mill HP from the L shield, or about 5000-6000km/h extra max speed and some extra rotation speed. Well that's a question I’d love feedback on, maybe the max speed and rotation speed isn't enough, I could see that.
 
Secondly there could be an advantage to being able to “modulate” your weight while still gaining some tankiness from honeycomb. An M shield with some honeycomb unlocks some venting on that design, while retaining some/most of the mobility.
 
In regards to your reasoning about M vs L shields. Roughly you're going from “it only makes sense to use the largest shield mass wise, so I can never vent on xs-m because I'm not going to be using voxels on anything smaller than the L”.
 
Well honestly, I don't particularly agree with that, at least not in theory. The interest of voxels is that it's scalable, and you can choose how much voxel you think you need. If you're going to use an M shield because that makes sense for your design mass wise, you don't “have” to use 95t of honeycomb. You can use 30t of a good hc over your ship. That's already going to give you a chunk of armor to help you get some venting going, and probably not endanger your cross-section too much. If that honeycomb buys you enough time for 2 vents (probably optimistic), then you’ve essentially caught up on an L shield in raw shield HP and you’re operating at more than half the mass. 
Now maybe that's not viable, maybe the honeycomb itself is too weak and even reasonable quantities of honeycomb get blown apart too quickly, that's possible and that's something we can look at. Perhaps at that point the subject is more that voxels are generally weak.
 
It's also important to note that in regards to your “real HP”, some amount of the incoming hits are also going to be hitting elements, elements that can be repaired which can give you more tankiness down the road. That means that when comparing raw HP to CCS, you have to take into account that CCS is counting every hit no matter where it's going, as opposed to your raw voxel HP which will, in effect, have additional health from elements.
 

For point 2, there's a couple things to say here. Shields are not inherently in competition with honeycomb, as mentioned we don't want them to be magnitudes apart in terms of HP because it wouldn't make sense, but fundamentally they are supposed to be complimentary.
 
Now in regards to your chart and conclusions. You didn't quite explain what “mean raw HP” is but I can guess it's the actual HP value of the deployed m3 HC multiplied by the average resistance, or at least I get close enough to your numbers using that.

Internally, in our tests using real ships CCS almost always goes first as opposed to the direct destruction of the core, I’d say in general this is situational depending on the design of the ship. In my experience, when constructs actually have a good amount of voxels, it's very difficult to dig your way to the core, and between the HC and the elements and the (occasional, hopefully fewer and fewer) lost shot, I believe that most of the time, you can count on your CCS HP being your “real” HP bar.  If that's not the case, especially on ships that have a good amount of HC, I’d love to see/hear more about it, since that would be contrary to what we’ve tested. Perhaps certain voxels are outliers.
 
My gut feeling is that in the “nano-age” during which CCS was introduced and voxels were rebalanced, people haven't been using voxels a ton in pvp. The goal is for that to change and honestly, if people start using voxels in some quantity, that's already good progress. If it does come out that cheaper voxels, or certain cheap voxels are always way better than more expensive voxels, I'll be more than happy to take a look at that (and to be honest, I’ve started already since I had to look at a bunch of stuff for this).
Lastly on this, you’ve defined that plastic is the best material on the basis of it having the most “mean HP” for the mass. That may be the case, but seeing how much effort players have put into reducing cross-section at almost any cost, I don't think 6700 m3 of plastic is always going to be the best solution.
 

For the last point in regards to venting, I feel like I’ve partly answered the question already but I’ll answer more broadly. Venting isn't something that will or needs to be used. It's a tool at your disposal and it's up to you to figure out how and when you're going to use it depending on the situation and the design of your ship. In contrast it's our job to make sure that those avenues can exist in the game.
 
In view of that, lighter ships now can try to disengage using their speed and try to get away and disengage to vent and come back, some ships may have honeycomb to tank on the CCS, some ships may not be able to reliably vent. If you design your ship in such a way that it cannot vent, then that's on you. However, if it is the case that there are NO competitive designs that allow you to vent at all, I agree that's a problem we need to change.
 
It will come down to the design of your ship, and it's possible that venting will be more usable in certain situations, and certain circumstances than others. For example, I don't expect smaller and lighter ships to have enough CCS/voxels to tank more than a couple hits (let alone all the elements that will die on a compact design) so if they can't escape the firepower using their speed/agility, they are likely dead. But who knows, it might be worth it now to dedicate some amount of HC on ships, specifically to be able to tank a handful of shots to get some shield HP back, even if you don't manage a full cycle off.
 
Essentially from my perspective, if you go no honeycomb, you are accepting that venting is going to be a tougher proposal than if you had dedicated some mass to HC protection, there's a tradeoff there. Now maybe that tradeoff isn't balanced, and there's one obvious better choice than the other, in that case we will take a look (that was sort of what was happening up to 0.29, there wasn't much point to using HC, but I think between the shield mass and health changes,  and the speed changes, HC could have merit again in at least some designs, but maybe it's not enough).
 
For an example on a relatively light design, even just 100m3 of that grade 5 titanium is going to give you around 1.2milll CCS health for 4-5~ extra tonnes. Is that enough to tank serious damage for a while? No, probably not. Is it enough to absorb a couple hits as you try to pull out of range, get your transversal speed up and start venting some HP back, probably yes. The downside is your cross-section may suffer and you'll lose some speed (honestly the speed loss won't be much, even at the most severe parts of the speed curve). Is it worth it? I’d say so yeah, in some designs and some situations, especially now that heavy L ships can’t easily rotate to keep up with smaller constructs, having a slightly larger cross-section probably isn't such a big deal in certain scenarios now.
 
To be fair in regards to that point, I agree that on lighter and more compact constructs, the damage dealt to elements will sometimes be what ends up killing you rather than CCS, or even the core being killed. If you take a nasty hit that blows up half your elements, you are essentially dead. My question is are you able to use some HC, to reduce the chances of a good hit taking you out of the fight entirely.
 
I did a quick test, put up 50m3 of grade 5 titanium and blasted it with a fully talented laser L. It took 3 shots to get through and kill the core I had placed  just behind the material. To be honest though, based on my hit chance on a totally immobile target with zero cone or range issue, I would actually expect an actual S design to take almost 0 damage from L weapons. The shield and the CCS at that point is more of an insurance policy for the occasional hit, or to fight off other smaller constructs.
 
There's also something to be said about balancing cross-section vs compactness. Not having all your elements in the same spot, even on smaller designs, means a single shot has less chance to obliterate half your elements.
 

Anyway, I'm just spitballing on a lot of things, I certainly don't have all the answers, and likely there's some things I’ve missed, or some things I've overestimated the importance of or underestimated the importance of.
 
 
Now to address your “problems to be solved” directly as a conclusion of sorts.
 
   Point 1: In regards to this point, if people start using any honeycomb at all it’ll be a good direction. Once we get to the point where we’re saying “we’re using HC and these honeycombs are all clearly better than these honeycomb”, we will be in a good place to start addressing HC internal balancing. The second thing is I do currently believe that especially on larger ships, CCS is a better representation of health than raw HP, and this is likely the opposite on smaller ships.
 
   Point 2: I‘m not totally set on this. Unplayable seems like a strong word here. I think lighter, smaller constructs have more opportunities now to disengage from fights in order to vent, or potentially exploit larger ships' slow rotation to stay out of the cone of the guns. Additionally, in my mind, some honeycomb can be a valuable addition to smaller designs, to give yourself some room to vent. However, If this isn't enough, we could explore more powerful and quicker vents for smaller shields, that's certainly a possibility.
 
   Point 3: Maybe, I’ve gotten some info by looking into it again today, and it's possible some changes can come down the line on this. In the past we’ve had the opposite issues, so it's possible we went too far.
 

I know this is a big blob, I hope my numbers were right, my brain is a little hazy, and hopefully I’ve answered most of your questions and made this a little clearer for you guys.
 
 
Thanks.
 

(initially posted on the PTS forums, oops)   Thank you everyone who played the PTS version of the new FTUE and gave your feedback.    It really helps to have fresh eyes on this.
The new FTUE has been over a year in the making, so some of us Level Designers have tunnel vision when playing through it for the thousandth time  
 
A few of you ran into two big bugs:
Those of you that spawned in the middle of nowhere with no lander obviously did not experience the intended onboarding.   That you continued to play and took detailed notes was appreciated, however clearly this is not the path a new player should take.   This happened due to problems with the server, and always requires CS intervention to rectify.  Since server hiccups do happen, I may add a backup step that if players get stuck on the "interact with the pilot's seat" step, after a certain time Aphelia will recommend the Help chat.   That, or another backup. Many of you ran into an issue trying to deploy the Speeder, getting an error message "speeder too far".   This was a bug that has been fixed in the latest update (released today). Aside from that, the rest of you successfully played the golden path of the new FTUE and provided great feedback.
 
Here are fixes we have already implemented. They are live on Athena. (this list is not exhaustive):
Lander section: now no build mode possible, no suicide/force respawn possible Flatten/Blueprint deploy section: added "you can walk around using maneuver keys" F4 map section: added a step to unlock HUD at the end Objective Screen section: added a step to remove currently active tool (skipped if no tool active) Objective Screen section: Added a recommendation to take the Talent mini-tutorial Objective Screen: fixed crash when triggering mini-Construction Lander: infobutton removed Tutorial skip buttons (Shift-PgUp and Shift-PgDn) now have a confirmation popup, to avoid accidental skips Here are our next steps (this list is not exhaustive):
Golden Path: encourage players to join an organisation Golden Path: teach "H" button in screen lock mode and inventory Investigate if "playing with friends" is convenient enough, now that the bugs are fixed Outposts: balance outpost constructs and provide more information on the Outpost Picker page Objective Screen: create the missing mini-tutorials Objective Screen: make the objective screen persistent (hopefully) make the objective screen reactive to the player completing mini-tutorials Tutorials: sort tutorials in the VR Surrogate Station tutorials tab Tutorials: do a polish pass of tutorials in the VR Surrogate Station as many are out of date (btw Golden Path = all the steps from "player spawns in the lander" to the end where Aphelia hands the player off to the Objective screen)
 
The principle goal of the new FTUE is to avoid bloat of the "forced tutorial" by getting a new player to a point where they can have few hours of fun tinkering and exploring before they would need to learn more.  Some people will choose more tutorials right away, but that is their choice, others might visit a bunch of places using VR Surrogate instead, or harvest ore.   This is roughly the blanket answer to the feedback "you really need to teach the player XYZ".    The golden path ignores some DU features by design, hoping that the Objective screen and player discovery fills the gap.
I do agree, however, that getting a player to have a look at organisations as soon as possible is a great suggestion, which is why I'm planning on adding that to the golden path.
 
If your comment or feedback is not listed above, I haven't missed it.  All feedback has been collected and is being considered.
Thanks everyone again for your help.
Cheers,
NQ-AntiGravitas
 
PS. For those who pointed it out, the lander -always- lands safely.  Its geometry and light weight slows it down in atmosphere and it has an autobrake at the very end.  it's impossible to crash (I tried many times).  Well, I'll say "nearly" impossible to crash because I'm sure someone will find a way one day (and no, that is not a challenge to you, dear players).  

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.
 
 

Apologies for the caps but the tone is intended. LEAVE TALENT POINTS OFF ANY WIPE DECISION JUST LIKE BLUEPRINTS.
 
As for my opinion. If you must weigh pro and con list make it so Voxel only constructs survive the wipe. Make a warning pre-wipe if the construct will fail the check just like you did with element stacking.
 
Pro - Builders can keep their hard voxel work and only have to replace the elements on the other side of the wipe.
Pro - Far less Back Lash.
Pro - Closes nearly all Loopholes apart from Voxel but Voxel will be the most easy to reproduce post wipe anyway so economic effect is very limited.
Pro - Newbies can be instantly inspired by the veterans creations of the Beta period.
 
Con - Some veterans will have to dig out ther buildings again.
Con - Nq will have to add a small bit of effort to save the 1,000's of hours of work created by the community.