NQ-Nyzaltar

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Dear Noveans, 
 
We took the time to look at all the feedback you gave us during this weekend and the past few days. We understand there are still concerns and that the second version is not the perfect solution to all potential problems. That doesn’t mean we are just going to deploy this version and be done with it. As mentioned previously, our goal has never been to punish players and we don’t want you to feel pressured to destroy/abandon/remove some of your current constructs.
 
Therefore, while monitoring how things will evolve (reminder: we are still in Beta, and things are bound to change or to be tweaked. Nothing is set in stone yet), we are going to act on two aspects when we will deploy the core units limitation with the Panacea release:
 
Extending the time period during which the automatic abandonment feature for core units in excess will remain inactive (1 month was previously announced but we now aim at 2-3 months at least). This is  to make sure everyone has enough time to reach the amount of core slots needed through queued talent training focused on specifically construct slots.  
In rare cases where it wouldn’t be enough, the Novaquark team is willing to help players who have large community projects, assuming they don’t gain any particular profit from them, and they’ve been in the limit of “one player personal cores + organization cores limit of one organization (which is 275 pre-Panacea)” and for whom the limit of 200 cores per player is not enough. We know those cases will be quite rare as there are currently less than 40 organizations going beyond the 200 Core limitation.  
If you are a player in charge of an organization with more than 200 constructs and you have a genuine issue about keeping all your Constructs, please reach out to NQ-Deckard or NQ-Nyzaltar on Discord or on the forum by private message and we will see how we can assist.
 
Again, the goal is not to frustrate you, our players, nor put you in panic mode to reduce the amount of core units you may currently have in your organization(s). We are not applying limitations with a light heart, without caring for players. We do know that these measures are frustrating for many of you, but at some point, we have to think also about the long-term sustainability of the game. All the restrictive measures already deployed, going to be deployed or activated in the coming months, have been all decided with this main goal in mind.
 
We do acknowledge the first version of the core units limitation was way too low and too much based on metrics that weren't detailed enough, not taking into account many edge cases. To show our good will, we decided to approach the problem from another angle: what could be the highest limitation of core units we could give to the players without endangering long-term sustainability? The answer is what has been suggested in the second version. Even if we wanted to go further, it would be unreasonable.  What would be the point of keeping the "no limit" policy if we find ourselves unable to sustain the model one year after its release? Dual Universe is meant to become a MMORPG and as such we have to do our best to design it for the long term.
 
You might ask:
Why didn't you set the limitations sooner?
Why is it just now you talk about long term sustainability?
 
Those are legitimate questions and here is the explanation: 
We had, of course, from the beginning, some rough estimation regarding long term sustainability. But as you can imagine, estimation on paper (or even simulations with a massive amount of bots) can vary quite significantly from actual metrics we get from running a live server with a massive amount of real players. To have accurate numbers, we needed to have two things: having all the main gameplay mechanics implemented in game, and enough metrics about player habits once all the main gameplay mechanics have been implemented. Those are things we didn't have yet before Beta launch and we could only guess before for some of them. Player habits are, for example, a parameter no one can predict perfectly in advance. Even after reaching the Beta stage, it required quite a few months to accumulate enough data to have an accurate idea of what could be the real cost per player. So yes, ideally, we should have set the limitations much earlier, to prevent players from going wild in creativity beyond what was technically reasonable and sustainable. However, this would have been a decision with just "gut feeling" (which is always very risky) and not based on relevant metrics.
 
Now to reply to the many suggestions and concerns you’ve mentioned in past few days:
 
Isn't there a risk of seeing the organization slots weaponized by opponents infiltrated in the organization through Alts?

Weaponizing organization slots - if someone ever does that - will have a very limited impact. There will be no way of catching by surprise the legates of an organization:
- Legates of the organization are all notified when a construct check has failed for the first time (opening the two-week period before random abandonment), in order to check what happened, take immediate action and handle the situation before the next check.
- Once lent, construct slots cannot be taken back for 30 days, which limits the possibilities for immediate negative actions and allows for anticipation.
- Organization legates can know from the list of active slots whether a donator is part of the organization or not (and how many slots are lent), therefore caution should be taken not to rely too much on 'external' slots to deploy new constructs, especially to the point where it becomes critical to pass the construct checks.
- Deploying a construct is restricted to legates and via RDMS, so people actually using the slots are assumed to be trustworthy.
- The log keeps track of every movement in the slot count (who gave/took back slots, how many and when, what happens to the amount lent by this player, what happens to the total amount for the organization)
  Will you give us more control ( show the values ) of : 
 - how many cores do you have free?
 - how many org slots cores do you have free?
 - what is YOUR org potential limit?

The org related numbers are visible in the new UI elements, we will look into creating better insight into your personal construct counts however this will not be available in the initial release of Panacea.  
Why chosing core units abandonment randomly?

We understand it might seem a strange decision at first glance, but we think it's a necessary measure to prevent some players to abuse the system (like inflating temporarily the number of core unit slots before a war and fill them with junk or "can afford to lose" ships). We did consider ways of selecting which type of constructs should be abandoned first, but in the end we found none exempt from loophole.   
Why not go with “constructs are not abandoned when the limit is not high enough? You just can't place new ones (otherwise many constructs will be abandoned long before the players will have leveled the skills for that)

This would in fact result in a situation where an organization could get players to temporarily increase their slots, deploy a very large amount of constructs, and then remove the slots to leave the constructs in place. This in fact does not meet our requirements.  
Suggestion: assigning automatically 10 organization core slots to each organization the player is joining? If he joins the organization, he must participate in the group effort.

While we definitely agree on the idea (each member of an organization should participate a minimum to help an organization to achieve its goal(s)), there are a lot of edge cases if we enforce a hardcoded assignment. What happens if the member doesn’t have 10 organization core slots available? Can he still join the organization? What happens to those who are already in organizations and don’t have the required slots? Moreover, if someone really doesn’t want to share some organization slots, he might just quit an organization if we try to force to assign organization slots to a player. In every case, whether it’s enforced or not, it’s up to an organization leader to convince their members to assign some organization slots to the said organization. Last but not least, enforcing an organization core slot assignment shouldn’t be a prerequisite: not all organizations have a purpose of sharing constructs, and we want to let the organization system be flexible in this regard.
  Suggestion: putting a maximum amount of organization core slots being assigned per member to one specifically organization? (beyond the 10 automatically assigned, like 25 max)

Limiting organization slots assigned per organization will just have the same effect as the suggestion above: if a player wants to keep organization slots for personal use, they will still find a way to do so by creating several organizations for personal use. Beside, as some of you may be wary of potential opponents infiltrating an org, letting the option of having the maximum amount of organization core slots assigned to one organization should be useful to make sure that even in big organizations,  you might have a significant amount of organization core slots with just a small team of trusted people.
 
Will we have a way to disassemble or deactivate easily and quickly a Construct to avoid taking hours to just remove the Constructs in excess of the Core slot limitation? (for example, an ability to compactify a larger variety of constructs in a way that retains their mass and volume, so you can basically box away ships - or even buildings - not currently in use to avoid the core count cost)

This kind of feature is on the roadmap. While we’ll try our best, we cannot guarantee it will be delivered before the activation of the automatic abandonment feature for core units in excess owned by an organization.  
Will there be in-game assistance from GMs in deleting or dismantling the constructs?
 
As we plan to extend beyond 1 month for the inactivity of the automatic abandonment feature as mentioned above, we aim at developing a tool to make it easier to disassemble or deactivate Constructs using the Core Units in excess. We’ll keep you informed on the topic once we’ll have more information about it.
 
What do you think about limiting to each player to be a member of 5 orgs maximum?

That could be an idea, but being aware of how frustration is accumulating after many limitations, we don’t want to push more limitations than the ones really needed.
  How long would it take to train all the talents to max them and reach the maximum limitation?
 
Currently we estimate to maximise all the talents from nothing, will take approximately 6 to 7 months.
However there is a curve, the last few talents take the longest:
- In 30 days, you should be able to reach around 60 slots total.
- In 60 days, you should be able to reach around 90 slots total.
- In 90 days, you should be able to reach around 130 slots total.
- In 120 days, you should be able to reach around 170 slots total.
The remaining slots will take considerable time.
Remember you will also have a partial refund of talent points, which should speed up quite significantly your training in the new talents.
 
If cores were tokenized will they count towards the cap? So if I was to tokenize 90% of a HUGE station? that might save it? Technically they wouldn't be my core right? Might be a legit way to save larger projects. Then hand out tokens to people who buy / already own... These tokens expire after 3 months or something. Tokens are always inactive, so server wise not as much load? Boom, in game tradable property token market aka NFT's (without being able to buy these with USD but they would be considered as "Non-Fungible Tokens"). 
 
While tokenized, constructs still count towards the organization they belong to until the token is claimed. And transferred ownership is to another owner.
 
 
That's all for now, but if you have additional feedback on the upcoming changes, let us know in this discussion thread!
 
The Novaquark team.

Hey Noveans! 
 
If you want to react on the Developer team reply to the Core Slots limitation Community feedback, please discuss it below!
 
Best regards,
Nyzaltar.
 
 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
 

Hi everyone!
 
Just to let you know:
The reply to your feedback posted during the weekend and the past two days is taking a bit longer than expected (we're trying to reply to as many suggestions you made as possible), and should be released tomorrow or Thursday, February 3rd.
 
Best Regards,
Nyzaltar.
 
@Warlander
 
You've clearly crossed a line with this kind of statement here.
The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything. 
There are forum rules, and you're clearly ignoring some of them. Inciting to devs harassment and/or see them fired? Not the kind of behavior accepted on this forum. Your forum posting rights are now revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer.
 
@LeeRoyINC
 
... Except there isn't currently any financial issue in the company. The budget is tight but Novaquark is in no danger at the moment. The current limitations that are going to be implemented in game are meant for long term sustainability of the game (more info on that in the next reply from the dev team).
Due to the agressive tone, the intent to spread misleading information and blatant lies, and the lack of the most elementary respect for Novaquark staff, your forum posting rights are revoked. You may appeal to this decision by reaching out to community@novaquark.com or the Customer Support, but unless you change drastically your mindset, don't expect any positive answer. The fact that you may be frustrated about the current situation is understandable, but that doesn't excuse everything.