TildaW4

Dear NQ, 
 
Please for the love Quanta, please increase the copy/paste size limits. 
 
It is the single most annoying aspect of build large ships. 
 
Love, 
Wadiss. xoxo

Hello Noveans,

Following our recent patch, we have decided to clear all restorations from all elements that are both placed on constructs and currently present in inventories and containers. Permanently destroyed elements that have not been "scavenged" will be restored as well.

Active health of elements will however not be affected, so elements that are partially damaged will remain that way and will have their restore count reset to the base number. 

This is a one time event following the patch, any damage sustained through PvP going forth will still reduce the restore counts on elements.

Thanks, all! ?

Again,
 
 
After two hours, automatically dump the ship's cargo, if any, in to the market container nearby. Turn the ship into a special token and also put that into the market container.
 
The special token can only be used in the same hex as the market container it was pulled from and only one such token can be used every 24 hours.
 
This not only gets rid of the mess, but also prevents players from exploiting tokenized ships with cargo. It's all still gotta be hauled away and players cannot simply log on every 2.1 hours to replace their crap, in the way of people actually playing the game.
 
It is not so restrictive that players who have a RL situation and have to log out unexpectedly are penalized as it has no cost to them at all.
 
If they know they are going to have to leave, they can leave the market and go back to their base.
 
 

So, I don't think anyone would deny that the markets (at least on Sanctuary and Alioth) are a mess because players just dump their ships everywhere and park without any sense of order or decency (not to mention the unregulated advertisements, etc). I think this could be tackled by:
 
- Set up a rule whereby a construct left for longer than a month in a safe zone (or maybe any zone not owned by a player or an org they are affiliated to) reverts to No Owner and can be salvaged by anyone.
 
- Provide a dedicated space around the market for parking and player stalls (ie: two separate areas).
 
- In the "parking zone", if players park their ships appropriately (within a designated space and not at some janky angle), then the above rule is extended to, say, three months.
 
- In the player stalls area, constructs pay a small fee that needs to be upkept monthly and, if it does not, the constructs revert as above.
 
I'm sick of dodging junk every time I go to the markets (mostly the same junk). Especially stuff that is, for example, parked right between the shuttle button and the shuttle, or across the walkways.

I really like your proposed solutions - these seem viable! I'll share it with the team and let you know what they think.  

Yes, maybe disable build mode.  However, throwing away your cargo could be considered a legitimate tactic to discourage pirates.  Which appears be working on you?  With that said the cargo should  probably be hurtling through space with a possibility of being picked up.

Hi everyone.
 
Until now, we couldn’t manually manage (remove/promote) Legates in an organization easily on the administration side.
Since Yesterday, we are able to use a feature simplifying considerably the process. 
 
As we already mentioned many times in the past, we (Novaquark) don’t want to involve ourselves in the management of organizations created by players. However, we are also aware that the current (and temporary) state of the management system contains obvious flaws. You know it. We know it. As this is still “work in progress”, we hoped that organizations creators will be reasonable enough to avoid abusing the well-known flaws of the system and would wait that all the rules are implemented before trying to sabotage other organizations. 
 
So we are going to state the obvious here:
It’s ok to “play a bad guy” and use dirty tricks once all the rules are implemented. However, it’s absolutely not ok to start exploiting the flaws of a work in progress system: this is not “playing a bad guy”, this is just toxic behavior and trying to gain an advantage while not playing by the rules.
 
That’s why - despite our will of non-involvement - we will make exceptions until the full implementation of the RDMS (Rights & Duties Management System) for the Organizations.
 
Why did we decide to intervene? 
Two reasons:
1) In the current state, a Legate has much more power than in the final system, due to the minimalistic mechanisms temporarily in place. If in the current system, any Legate has the right to promote a member to Legate status by himself alone, in the final system the default rights will be completely different: promoting a legate will be done only with a vote by majority rule, or the right to promote someone will be given to specific persons and not every Legate.
2) In the current state, a Legate cannot be demoted by any mean (even by the creator of an organization). In the final system, default configurations will allow to demote a Legate with a vote by majority rule. A Legate could also be demoted by specific persons who have been given the right (most probably by the Organization founder) to do so.
 
How is this going to work?
Each organization is going to have one "wild card": if there is a problem with the Legates in an Organization, you can contact the support team at support@novaquark. However, keep in mind we (Novaquark) reserve the right to intervene (or not) on a case by case basis. 
 
Example of a case where we will intervene:
Some Legate using the flaw of the current temporary system to vandalize (or generate troubles in) an organization.
 
Example of a case where we won’t intervene:
Two organizations have merged in one, and now both creators of previous organizations want to mutually exclude each other from the organization. In this kind of case, we won’t remove anyone. We won’t favorize one creator above another. However, we will do our best to help finding a satisfying solution for both parties.
 
As a global reminder:
If someone finds a loophole in the rules in place (that may happen), and this loophole is used to generate trouble and spread a toxic behavior, we won’t stay idle watching the situation deteriorating. 
 
Best Regards,
Nyzaltar.

Most crashes are player fault. You come in too steep, do not have enough braking capacity  or engines are not able to warm up fast enough to catch and provide propulsion. You leave from one planet with half the gravity of your destination at max mass for the destination.. you are bound to go boom on arrival.
 
I guess proper ship design will become a thing now  
And the changes in TP policy make even more sense now
 

Good day, Noveans!
 
Much of the allure of Dual Universe is the ability to be the captain of your own destiny as you pilot the ship of your dreams. Piloting your ship requires skill and a strategic use of the tools available.
 
The Maneuver Tool is an important part of that toolbox. In its current state, however, it wasn’t working quite the way we planned. As we approach the launch of the 0.23 update, we wanted to talk about changes we’ll be making to the Maneuver Tool as well as changes to issues around what happens when you’re disconnected from the game (intentionally or not) when actively flying your ship.
 
The Maneuver Tool is for maneuvers

The Maneuver Tool was originally introduced to offer a simple way to get your ship out of a small hole or to flip it over when it landed upside down. It also provided a handy way to lift your ship off the ground a bit so you could work on it from below.
 
But as is often the case when designing video games, the cunning imaginations of players found unexpected ways to use the tools that were not intended by the designers, some of which are detrimental to gameplay and could cause issues in the not-so-distant future. Let’s take a closer look at some of the issues caused by the “creative” use of the Maneuver Tool and the upcoming changes we’ll be implementing in the imminent 0.23 update to correct them.
 
Cooperative play is all about collaboration and players helping other players. That’s great, and we don’t want to discourage players from doing that, but how it’s done is important. The Maneuver Tool was not intended as a way to move a ship “by hand” over kilometers or to create a ladder of two ships used as intermediary steps to reach space. These uses went clearly beyond the original intent of the tool.
 
To address this, we’re introducing some limitations in line with the purpose of the tool: 
 
A ship will not be able to move more than 50m in total between accumulated uses of the tool. The distance between the start and end points is added at each run of the tool. The moved distance is reset after three minutes to ensure that players aren’t stuck forever. It is, of course, a per-construct limitation.  Unless the player was in contact with a planet ground or a static/space construct, a ship will no longer freeze in the air during the use of the Maneuver Tool. This will make it possible to lift it up to work under it, but no higher than that.
No more instant stopping of ships upon disconnection

Everyone has “the need for speed”, the desire to get from Point A to Point B in the shortest time possible. So you pull that throttle back, amp up the power and blast off. The danger is that if you don’t carefully monitor your speed, you’ll smash full-force into a planet, your ship will blow up, and you’ll find yourself either returned to your bind point or resurrection node. Ouch!
 
A common workaround for this has been to disconnect from the game just before impact. Upon reconnection, your speed would be reset to zero, and thus you could approach with a safe speed. Although it’s convenient, that’s not how it’s supposed to work.

With the upcoming change, upon reconnecting, as soon as you get in range of the construct, the speed and rotation will be restored to whatever they were when travel was interrupted. The benefits to this change are twofold. First, it will close the aforementioned loophole. Second, it will prevent you from expending twice the amount of fuel to reaccelerate a ship at maximum speed if you had been disconnected for whatever reason.
 
Further, if you disconnect while another player is in range, the server already assigns the task of handling the physical properties of your ship to that nearby player. This means that your ship will continue to move in this situation. On a large ship with many people on board, disconnecting will no longer have the effect of freezing your ship because there will always be other players nearby to continue the simulation of your ship’s movement.
 
We will also add the option to have the Emergency Control Unit (ECU) activated in that case, so that an emergency “braking” can take place if the ship capacity allows it.
 
Keep Doing What You’re Doing
 
We tip our hats to the ingenuity of our Beta testing community. The way you use the tools and mechanics we toss into the sandbox gives us lots of food for thought, showing us the changes we need to make to make the game we all want to play. We encourage you to maneuver your way to the discussion thread to tell us what you think about the adjustments we’re bringing to DU! ❤️ 

Due to numerous reports of this happening, including pictures, lets talk about end of warp obstacles and ramming in general.
 
Here is an example of a net placed exactly in front of a warp exit. You have about 10-15 seconds to change direction right after end of warp, but most people won't pay attention and ram into whatever is in front of them.
 

 

 

 
This has been a thing for a while now, but we now have some reports of ship destruction due to warp destination constructs being purposefully placed in the way.
One way to get around it is of course to pay attention and maneuver the ship immediately after warp destination is reached. However, there is a lot of discussion to be had about warp obstruction and ramming in general.
 
For example:
 
1) disabling collisions between cores: this has already been done with trees so I imagine it can be disabled for static / dynamic cores, probably will increase server performance too, but also an effective way of getting rid of warp traps.
2) disable damage on collision with constructs: an alternative of the above, except collision will cause velocity changes as expected between collisions. We don't have bumper car physics, could be a bit strange, but this also gets rid of warp traps.
 
My personal favorite and very biased option:
3) reverse ramming logic (THE RIGHT LOGIC): it's really strange to consider that an L core going at 30,000km/h can be obliterated by a stationary xs core. It just doesn't make any sense from a logic perspective, although the reason for this implementation probably has roots in server performance considerations. I think collision damage should be shared between constructs and distributed according to mass and voxel logic. Added benefits are: COMPLETELY LAG FREE MARKETS... because naturally people will start ramming, hence a necessity for garages / safe parking facilities, opportunities for business, etc. I would go so far as to say that static cores should be rammable as well. This has huge ramifications for space stations... there will be a need for space mine fields or wreckage around stations to prevent people from completely destroying stations with ramming dynamic cores. Space stations will need engagement rules such as: if dynamic construct is going faster than X amount inside a certain radius around space station, fire all weapons at dynamic core. There are all sorts of interesting ramifications for this gameplay.
 
There is something important here I think: it is not ok to simply add a rule to the EULA saying warp traps are illegal. This is a sandbox, emergent gameplay will always happen, and a bunch of players can give a hell of beans about what the rules are. It's in poor taste when a game cannot / will not implement systems to prevent certain actions from happening but simply adds a "RULE" of conduct. In some cases it is certainly appropriate (abuse, discrimination, etc) but in this case, this is emergent gameplay and adding a RULE will not solve this issue. In this situation NQ actually has an opportunity to capitalize on the situation and create game mechanics to either solve this issue or enable ramming AND add mechanics in order to counter ramming.
 
On the other hand, warp traps such as these can be cancerous. This is a tactic used extensively in Eve, see here: 
 
 
Do you think warp traps are an acceptable emergent gameplay mechanic? What are your issues with it? What can be done to solve it? Again, to reiterate, simply adding a rule of conduct doesn't work here in my opinion. NQ should really capitalize on this opportunity... I think they failed in the district 15 drama, they could have done some epic stuff there... problems can be turned into opportunities, lets contribute to the discussion and find opportunities
 
Edit: After writing this post, I have received confirmation that players are "netted" both when:
1) player finishes warp, comes to a complete stop, then accelerates/or planet gravity pulls the player, and they end up in a strategically placed net
2) player finishes warp and gets damaged in net BEFORE coming to a complete stop from the warp

Luca...do you even PVP?  Why gunners?  Get out of here, the team work element of combat is great. Stop trying to make an MMO a solo player game.  Using sweeping generalizations such as "Everyone wants to pilot big ships." to fit your narrative isn't appropriate. 

I would wager people want to be able to have PvP be accessible.  Anyone who says flying a ship in combat is something that is easy and that everyone should be able to solo is outta their minds.  Play the dang game.  Having a crew to work a ship isn't about who "fly's it" its about the goal.  Of enabling each other to beat the snot out of the other team.  It is exact reasons like that that NQ should ignore these types of suggestions and move forward with their design vision.

Make PvP more accessible.

Naunet running by with a quick edit for clarity: Element Destruction will be applied to all damages sustained, both in and outside of PvP battles.
____________________________________________________________________________________________________________________________________________

Draw your weapons and get ready to shoot first! In today’s Dual Universe Dev Blog we will discuss an upcoming PvP feature: Element Destruction.
 
In its current iteration, the feature works rather simply. Once destroyed, an Element can be restored indefinitely. There is currently no way for a crafted Element to disappear from the game unless it’s done intentionally. This poses a problem in the dynamics of the economy. In the real world, most purchased goods will inevitably need to be replaced. This helps to fuel the economy by creating a steady demand of goods. And, as in the real world, Dual Universe relies on a strong supply and demand chain for its economy to thrive. 
 
To facilitate this, we’re making some changes to Elements that will not only give them value as a commodity on the Market but also add some exciting layers of strategy in how they are manufactured and used by discerning pilots who won’t settle for anything less than the best on their prized ships. 
 
Let’s take a closer look at the incoming changes.  
 
ELEMENTS DESTRUCTION
 
When an Element on your ship is damaged in combat, can go next to it and repair it using scrap. If destroyed, you can also restore it completely. The change we’re making will limit the number of times an Elements can be restored, i.e. three times for an Engine and five times for a Container. Once an Element has hit its maximum amount of restores, it is Destroyed and can’t be repaired anymore.
 
This will be less brutal than an immediate destruction, allowing you to manage a critical situation during combat, yet give you the opportunity to plan for a long-term replacement strategy as your restore counter is approaching the limit. Getting low on the restore counter for an engine? Swap it for a brand-new one at the next station. 
 
An Element which has been restored once or more will be allowed to be brought back into a player’s inventory, but  please keep the following points in mind:
This Element will be marked as a Modified Element. As such, it cannot be sold on Markets or used in Blueprints This Element can be bartered. Unlike certain other modified elements, the restoration count cannot be reset. The number of times an Element can be repaired depends solely on the nature of the Element.  
Note that this is a first step. We may introduce other forms of degradation in the future, possibly impacting Element performance. Another important thing to note is that when an Element of type “Container” is fully destroyed, everything it contains is destroyed as well. This includes all types of fuel and ammo. 
 
Tier 2+ Elements and Industry Units
To push this logic even further, we introduced the idea of a new class of elements with better stats, by extending some existing elements with variants into higher tiers. This will impact Engines, Weapons and Radars to start with, and we will also make a push for Containers and Control Units a bit later. 
 
In any real world industry, you have room for producers specializing in high-end products with better returns, or low-end products with higher volumes. This is what the addition of Tier 2+ Elements will bring to the table. We envision a future where Tier 2-5 engines will become the norm for performance-savvy players because of their better stats while Tier 1 will remain a commodity that is basically good enough for most players who don’t care about the stat boost. This adds variation to the gameplay and will certainly be a factor in PvP and efficiency-oriented logistic operations. 
 
Note that only Tier 2 Industry Units will be able to produce Tier 2 Elements, the same for Tier 3 and so forth. Industry Units of higher tiers will be considerably more expensive to produce and/or buy.
 
Element perma-destruction
A deployed Element that has been destroyed cannot be brought into the inventory. This Element is totally non-functional and can only be deleted or Replaced. 
 
When Replacing an element, all custom properties and settings are maintained. This action will consume an Element of the same type in the player’s active inventory, as it would do with an Element that was deployed standard. Of course, we will introduce a proper tool to replace your Elements to prevent the need for reconfiguration when you’re swapping in a fresh new one. This should help to create a healthy level of demand as PVP increasingly heats up across the Universe.  

Weapon limitation by core size, and better hit formula
Speaking of PVP, we want to address some imbalances in general around PvP. 
 
Several things are on the way to address this, some of which might affect your ship designs:
Limitation of weapon sizes based on the core size, no more L weapons strapped onto an XS core unit. Previously, the probability to hit another ship was based on the size of its core. From now on, that probability will use the surface of the ship that's visible from the view of the shooter as defined by the cross-section of the ship from that same point of view. In other words, the surface of the ship exposed to your weapons will matter and generate more damage. That way, building a borg cube will simply not be efficient and will expose you to greater damage risk.  Radar lock range unification: Instead of having each radar lock different core unit sizes at different ranges, every radar will now have a global lock range at which it locks all targets. Smaller radars will now lock at lower ranges, but retain their faster lock times while larger radars will lock slower but at greater distances. Unlike weapons, there will not be any further core-based restrictions on radar placement.  
SHARE YOUR THOUGHTS
As always, we encourage you to share your thoughts about these changes. We appreciate your support and look to your constructive feedback to help us make Dual Universe the absolute best it can be. 
 


**Edit note: Clarified RESTORE vs REPAIR verbiage

yes.. i think its unfair i could get away with my simple hauler made from 1 or 2 month in the game so far, against someone who plays this for over an year, have all the talents, all the radar, all the weapons, and all the know how this game works.. man the injustice.. 

And that is totally fine. But have you noticed that while 'carebears' are generally fine with there being PvP in the game, PVP'ers are the ones loudly complaining about safe zones.

The problem with 'carebear' is that it is a derogatory term, and forcing people to PvP is just as disrespectful if not more so.

Topic pretty much says it all. Currently every seat in the game (at least functional ones) can only have ONE Radar linked to it. While the reasons for that are fairly obvious between atmospheric & space combat uses, it also limits the pilot severely for craft that transition between the two. So I'd suggest that Non-Weapon Chairs (ie. Command Chairs, but not Cockpits or Hoverseats) be allowed to link to both Atmospheric & Space Radar. They cannot use weapons in any size, shape or form, so the Radar would be used for navigation purposes only. As a pilot (and non-gunner), it only makes sense that they would (or SHOULD) be able to detect what is ahead of the ship whether it is in atmosphere or in space. Flying towards a space station? Better adjust course! Flying towards a building or single voxel 'tower' ahead? Ditto!
 

Right now, command chair pilots are forced to use one or the other radar. Go with space to help spot potential PVP pirates or better align a ship for your gunners? Or use the atmospheric radar so you can see and avoid space stations, buildings, etc, as you fly through an atmosphere and near the ground? Give pilots both! Those chairs are already limited from using any size weapon, so give them SOME advantage for use.

Wut.
 
The safe zone may be where most of the players are, but it's a pretty small portion of the game "world".  And it will become even smaller if they start adding more star systems.
 
As for the whole "we should get rid of the safe zone" argument that folks are making, they're looking at this extremely short-sightedly.  NQ should absolutely keep the existing safe zone.  This not only ensures that new players can get a good foundation for the game, it ensures that there's actually an economy in place, because I'm pretty sure that all of the, "OMG, I just wanna blow people up!!!" crowd is not going to be contributing to anything other than the ammunition trade.  On top of that, as time goes on and NQ adds more systems, the fact that three planets and a few moons are a safe zone will become less and less relevant in regard to PvP.  As long as NQ puts something worth going to other systems for, the "I'm only happy if what I do makes someone else sad" crew can get all the PvP shenanigans they want and we get a functional economy.
 
If NQ gets rid of the safe zone, DU *WILL* lose far more players than would ever join specifically for that feature.  Despite what the PvP-obsessives tell themselves, there is almost no demand for MMOs with unrestricted PvP.  Or did y'all think it was a strange coincidence that MMOs with unrestricted PvP* rarely last more than a year?
 
If you still want to be playing DU a year or more from now, you'll want them to keep the safe zone in place indefinitely.
 
*No, EVE does not count as an unrestricted PvP MMO.  If a game has an NPC faction dedicated to blowing your ass up if you start stuff in the wrong system(s), it's not unrestricted.

Just found out recently when using 'V' I do see whoever is around me.
Not blind anymore - now I'm comfortable hitting space any time

Give this man a shit ton of credit. He got shot in the pvp zone, but came to the forums asking what HE could do better to prevent it. Yes we know pvp needs lots of work, but in the mean time you use what you have. I for one sir applaud you and if you want you can personally message me and I will give you a bunch of tips for avoiding pirates with and without warp. This type of attitude is what people should strive for when choosing to play this game. 

The fact that they Wrote Pls NO Ban, just shows that they knew that they would be banned. This is a Beta game still in development and part of being in the beta is your testing and reporting bugs. Which you should have reported it and left the building alone. This was just a blatant bad response that you knew would affect many things in the Beta, but you choose to do it anyway. 

You knew you would be banned and you still did it. So you deserver what you knew was going to happen in the first place.

Hello Noveans, 
 
By now, some of you may be aware that unlucky number Market 15 has been stripped bare and left to create ugly memes for generations to come. We’re trying to look at this in good humour as, from the front, it appears to be an issue that was created when we moved the markets, making it editable by players. It doesn’t take a rocket scientist (though we know there are a few of you out there) to understand that the markets are not a community construction, and as such not intended to be handled by players on this level. The destruction of the build isn’t a quick fix, and was clearly done knowing it shouldn't be. 
 
An important aspect we are considering in all cases and investigations is intention. The intention behind this destruction is very clear to us. The players involved did not report this bug to us, but instead simply filled their pockets. Had this stopped with a single voxel removed it would be a different story.  This is, at its core, a violation of the EULA and against the intentions of beta. We have been as understanding as we can until this point, but there must be a line.
 
Let us be clear, we will not tolerate this kind of behaviour during any phase of the development of Dual Universe.
 
The players responsible for the destruction of the market have been permanently banned from Dual Universe, and all salvaged materials and assets gained will be removed without compensation.
 
Sincerely,
The Novaquark Team
 
Follow up statement: