Tional

NQ please address the lag and the slowdown people are seeing since Panacea. Some are seeing up to 80% slowdown in atmosphere, where you'll be cruising along at 1000 km/h according to the UI, but if you make a lua script that compares position versus time, then it shows you're moving at downwards of 200 km/h (while cruising)...
 
Also my fans spin up whenever I'm piloting my hauler, and my FPS tanks. In addition to the slowdown mentioned above... I used to only see this slowdown/lag on Thades, but now I see it on Alioth too, and I am not alone.
 
People have been reporting it on the Discord for a day or two now, but there's radio silence from the NQ staff that typically hang out and keep an eye on us.

Yes the slots can exceed the capacity limit, in practice an organization can only have 1625 constructs due to the limit. It can however have say 10000 slots, this allows for an organization to have some buffer for gains and loses over time.
 
 
We are not telling you to tear down your builds, not at all. Quite the opposite, we love seeing players buildings in the game. 
What we are saying is that we need you to find a way to support your builds that exceed what we can grant and support you with as a single contributing member of our community.
 
I wish you all a wonderful weekend, and look forward to reading more feedback on monday.
 
Sincerely,
- Deckard

While this may be off topic for this thread, I believe NQ is missing something here. Many orgs will "promote" members to legate becasue there is NO OTHER rank that would give a member extended options/rights within the org. We really need to have a better org structure as in, have different roles that allow different options in orgs beyond what RDMS can provide.

But this really is a discussion for a different topic.. 

Following some research we found that a lot of smaller organizations tend to assign legates quite liberally. We believe that could be in part due to the inability to deploy constructs in name of an organization directly. However we found there are some inconsistencies and a new right dedicated to the allocation of constructs to organizations seemed to be the right choice.
So with that, you are correct, this is a new RDMS right we will be implementing. That gives organizations the ability to grant construct assignment capability to members.
This will cover both tokenization and deployment of new cores in the name of the organization. 
 
 
This is indeed currently the case, with the ability to create sub orgs branching from the primary orgs to extend beyond that. And thus this was also part of the problem we faced.
As such we are still reviewing this at this time, and will likely monitor the impact of construct slots before any changes to the maximum player org membership are considered.
 
 
Things can always change in the future. However currently, for Panacea, these numbers won't change.
 
 
As I've heard some confusion about this in a few places, I'd like to take a moment to reiterate that the old organization talents that we will be refunding, do not grant you slots.
They simply act as an overarching limit to the absolute maximum amount of constructs permitted inside a single organization.
 
These talents will remain the same in terms of talent point investment cost, however the bonus they apply has been scaled up significantly.
Only the legate with the highest talent benefit apply, and the organization starts with a limit of 0 constructs.
The first tier of talents awards an increase of the organizations limit by 25 per level, brining the maximum up to 125 at 5 talent levels invested. The second tier of talents awards an increase of the organizations limit by 75 per level, brining the maximum up to 500 at 5 talent levels invested. The third tier of talents awards an increase of the organizations limit by 225 per level, bringing the maximum up to 1625 at 5 talent levels invested.  
So bringing your second tier talent to level 2, will effectively set your organizations limit up to the pre-Panacea maximum limit.
 
I hope this answers most of your questions about the upcoming changes and brings you all more understanding.
 
- Deckard

Have you read ... anything? Even the disastrous first version of this made it clear there was at least a month before stuff started getting destroyed, and now it's 2-3 months at least, in the very post you're replying to.
 

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.

Hello everyone, thank you for all the feedback so far.

We will be reviewing the feedback tomorrow and there will likely be some adjustments. However that will have to be seen tomorrow.

Keep it constructive so its useful to us and it will be seen. 
 
We will have more news on todays article for you soon.

I agree to jump the gun and say your done and leaving is counter intuitive. If you want things to be fixed you have to be part of the solution not jump ship the moment it smells funny. We all have to be willing to lug a few buckets of water off the ship. If every sailor doesn't pitch in the ship will go down and we only have our selves to blame. 

In DU I believe Ive found the game Ive been looking for for almost 4 decades, Ive played little else since starting here many months ago and have seen a great number of changes, some good, some bad, but ultimately it was for the good of the game.
Not so with this proposed change to core counts.
I totally understand that the nested org issue needs a fix and that the push should be in the direction of  the player but this game has always been about creating amazing things both epic and minutely complex.
Reducing the number of cores available to me and my fellow players is going to result in a major reverse in progress, one that is likely going to see people leaving the game.
As a ship /Static builder / seller, I dont see a way forward.
We spent a significant amount of time producing our showroom, we make a good DU living, a significant amount of which is pumped back into the community on various projects.
I cannot understand why you would do this without some detailed explanation of what you're aiming for.
Its beginning to feel like a path of self destruction and that would a very great shame.
We love your game, yes a lot of players complain but they still play.
Dont make this an excuse for the playerbase to reduce further. 
Give us some transparency on these decisions, maybe we can help or suggest alternative strategies.
Thanks for reading
 
-A concerned Novean

Here's my feedback in video form, I tried to keep it short. 

This effectively kills my ship shop going forward, had just spent months building it up with Skyexplorer and a couple friends in preperation for new sexy voxel tools to make a new, exciting ships- and have a place to display them. Even if we all committed ALL of our accounts and alts, it'd not be enough. and none of us would have any personal cores to use.

I'm officially in protest of these changes and won't be playing much until this is sorted/finalized. This is the only change since playin at beta start that has elicited this strong of a reaction.

I've been playing DU for a good long time now and I'm convinced that the developers don't play their own game.  They have accounts, but they have a very different perspective about DU than most of us do.  Announcements like this one make that painfully obvious.  It seems like this core limit announcement is not so much the problem, but a symptom of the bigger problem which is lack of meaningful communication between player and developer.
 
Dual Universe needs to have a player council made up of people from a cross section of play styles - miners - haulers - builders - pvp players - factory owners and so on.  If the community, via a player council, had the opportunity to discuss changes like this with the development team before announcements like this drop, it would at least give them a chance to consider the ramifications of their decisions without immediately pissing everybody off.  We do have this message board, but so much of it is just people complaining.  We need a meaningful dialog between the players and the developers and a player council would do just that.  I've seen it in other games and while it isn't a cure all, it certainly improves communication between us rabble who play and love the game and the rabble up there in that ivory tower who love and develop the game.

My primary feedback is that it's unfair to refund only skill points that were already invested in construct management - when, realistically, if this had existed months or years ago, players would likely have already took these skills instead of others that they are now locked into
 
 
This is a common theme that NQ keeps doing; adding mining units?  Reset mining talents!
But that doesn't help people that didn't previously have mining talents, but now want them in their new form.  Just like resetting construct capacity talents from before, doesn't help anyone who wants the new talents and would have invested in them if they had always been like this
 
 
Big talent tree changes should involve full talent tree refunds

As a small 3 player org, we went through all updates since the beginning of the beta.
 
But this one will be a real pain if not a show stopper for us.
 
We are doing our own mining, 1-7 tiles per ore, 1 construct per tile because deploying a L core at the intersection of three tiles is not an option and we are forced to place one core per tile.
 
Bauxite - 7 tiles, 7 constructs
Coal - 7 tiles, 7 constructs
Hematite - 7 tiles, 7 constructs
Quartz - 4 tiles, 4 constructs
 
Chromite - 7 tiles, 3 constructs
Limestone - 7 tiles, 7 constructs
Malachite - 7 tiles, 7 constructs
Natron - 4 tiles, 4 constructs
 
Acanthite - 7 tiles, 7 constructs
Garnierite - 7 tiles - TODO
Petalite - 5 tiles - TODO
Pyrite - 1 tile, 1 construct
 
Cobaltite - 6 tiles - TODO
Cryolite - 5 tiles - TODO
Gold - 4 tiles, 4 constructs
Kolbeckite - 7 tiles - TODO
 
Columbite - TODO
Ilmenite - 4 tiles, 0 constructs (shared with the natron)
Rhodonite - TODO
Vanadinite - TODO
 
That is 54 constructs
Still 37 to deploy.
 
We are purchasing ore on markets but we need part of our supply to be controlled to not depends on inflation/deflation.
 
We are in space and our main space station has 16 constructs.
 
On each planet of the solar system, we have one space station, a small planet to station hauler and a tri-scanner. 12 planets, 36 constructs.
 
We are managing a store on Utopia Station. 1 construct
 
We are building a huge space store. 26 constructs + 10 constructs for the demo ships we want to sell.
 
The organisation owns a few ship. 10-20 constructs
 
We are doing some scavenging, we need some slots for the constructs we are requisitionning. 10 constructs
 
At some point, we want to do some PVP, we will need an extra 3-4 constructs.
 
And a 5-10 voxel libraries.

That's a total of about 225 constructs,
 
I'm just in the corner crying now.

Let's assume that I have spent an insane amount of my precious talent points to max out ALL of my cores.  15 personal and 25 org for a total of 40.
Now you want me to pay taxes on my tiles, and you expect most players to run mining units to pay those taxes.  That eats into a lot of my cores.  Then add in a few for a factory, a few for a handful of ships...  Honestly, this isn't enough AT ALL.  I'm apparently not allowed to have a ship collection anymore, despite my love for people's ship designs.  I also intend on selling ships in the near future.  I guess I'm not allowed to spare any cores for a showroom, am I?
 
I run a huge mining setup with multiple players and I needed to literally run my org cores to the max (200+) just to be able to handle it all.  Now all of those players and myself are going to have to invest a ton of talent points just to run shy and now I'm going to lose a percentage of my mining setup.
 
This doesn't even account for the ships needed to move this ore around and factories to process it.
 
These numbers ARE IN SERIOUS NEED OF RE-EVALUATION.  If I start losing stuff because of this, I am likely to simply stop playing.  I have worked too hard on building and making things to start losing large chunks of it from a rules change.
 
This is such a badly thought out issue that affects me so hard that I actually took the time to actually sign in on the forum to voice my opinion on the topic.

QUOTE: "Several months ago, we suggested a way to address the issue of cascading organizations being created as a way to circumvent the soft limitations of construct and territory numbers. Players raised some valid concerns about the proposal, citing that it would adversely affect how they managed their organizations’ holdings. In consideration of that feedback, we temporarily tabled the proposed changes and went back to the drawing board.
 
The problem remains and needs to be resolved sooner rather than later to avoid a myriad of issues in the future. DU simply can’t support an infinite number of constructs per player. It’s why we have construct allowances in the first place. We needed a solution that would support community projects for organizations of any size without penalizing those that are prolific. After all, one of the core features of DU is to build lots of cool stuff."
 
 
Then actually address the issue of nested orgs, rather then nerf a small aspect of them that is not significantly related to the issue stated. The current construct allowances are sufficient to support the game as intended.
 
The proposed core limit will effectively end the personal builder profession, as there will simply not be the core allowance to provide example ships in showrooms for them to advertise effectively.
It will also impact 'collective' orgs of all sizes, as core allocations will need to be managed manually, rather then by passive application of talents of the orgs legates. This will mean that at any point in time the org could loose core allocations and constructs, simply from ONE person opting to leave the org - or even from vindictive action.
 
Core allocation for orgs needs to be controlled by the legates of those orgs, not by the membership. So instead of penalising the entire player-base, and adversely the builder community that NQ so want to be a core feature of the game, I suggest that the fix that needs to be implemented is REMOVING THE ABILITY TO CREATE NESTED ORGS.

i've been playing since alpha.
i always tried to create content and give back a lot to the community via new fancy stuff ( like hagboards or boats etc.) and i operate a showroom with all ships on display and a marina where i try to keep a copy of each boat/sailboat using my lua for people to walk around in and enjoy the creations.
additionally i have to make some money and operate mining units on around 20 cores. then i have an industry and need a LOT of cores for prototypes and my own ships.
when i am selling tokens i often have to place new temporary cores.
so with all this even after cleaning up every so often i operate around 260 cores in my construct org.
even if i massively reduce stuff, i still would have to remove most of the stuff. so basically this would end my career in this game.
even if NQ would reconsider and go to 100 cores it would be constant struggle of which stuff i would have to remove.
i never used nested orgs ( which was basically more in those past mining days to claim tiles) but still i create content, i have a life in this game and i want to grow. so this could honestly be the final nail in the coffin for DU.
NQ always talked about the visions where they create the plattform and we the players fill it with life and content. but HOW?

If this is about server space or network traffic i would rather pay 1$ more per month to end this stupid plan.

 

This is indeed a step in the right direction.

Would it have been better to have listened to the community earlier, yes absolutely, many of the changes you are implemented were suggested during the Public Test for Demeter. That's what player testing is for, to listen, adapt, and then implement, not push through something regardless of feedback.

I hope in the future you follow the feedback before you implement something your player base is warning you about. 

That said, good work, keep raising the bar.

Calibration grace 48 > 72 hours
 
Done.

The fact that Industry can run on offline hexes is a saving grace for many people and new players. You no longer have to mine in order to produce stuff - Good.
Less Calibrating - Also Good.
Higher Numbers of Charges to allow for more casual miners - also a good change.
Animation speed up - good.
Less Tax - Sure.
Trying to remedy boring harvesting of rocks? - I'll wait for news on this one.
Talents for harvesting - actually more important now that Demeter is a thing.

I'm happy. I'm sure many people are also pleased with this. Well done NQ.

 

Greetings Noveans!
 
We would like to hear your feedback in this thread on the Devblog explaining the adjustments that will be deployed tomorrow and later with the Panacea update!

Best Regards,
Nyzaltar

Mission runners hit those places more than once a week so it's hard to imagine them going because of this.  They'll probably get bigger and uglier though -- if my construct is temporary and might despawn if I get bored I'm probably going to make it out of a ton of 'container L' to keep the price down and not bother to use voxel.

Mission runners might even start using modular ships where they pick up one container bundle, dock it and drop another as they go around so they'll probably look like they were thrown off the side of a ship rather than being nicely placed under the pads.

You hit it, it destroys most of your ship, and then you go spinning off in some random direction in a death spiral that's a total nightmare to recover from. 
 
From experience.

No good way of stopping them, but the mechanic will solve most of the issue and at least put a good amount of work and risk of losing their stuff in the hands of the people who clutter the market. And hopefully the feeling that they harm the game with their "I have a new ship and everybody should see it even if it kills the game" attitude.

The asteroid spawning is entirely automated. It got interrupted by a situation which was supposedly impossible but is not. We will sneak in a patch at next minor release to prevent this from happening again. Meanwhile this was manually fixed and asteroids are spawning again, yay.

The Dual Universe roadmap has been expanded with the Panacea update, which is currently in production and brings with it a plethora of new features, tools, and improvements that will be particularly interesting for builders, scavengers, and Lua aficionados.
 
WHAT’S IN IT
 
A follow-up to the changes introduced in the Selene and Demeter updates, the Vertex Precision Tool will provide a powerful, intuitive way to fine-tune your builds. Particularly for those who are new to voxelmancy, this tool will be invaluable. Watch this video to get a taste of what it can do.
 
The introduction of shipwrecks in space will open a variety of lucrative opportunities for players who seek them out. Sell them as-is, salvage them for parts, create missions for other players to bring you the ship or its parts, or simply fetch a handsome price by selling the location information.
 
Other new features and improvements include: 
Camera Lua API: get access to information about the in-game camera Talents UI improvements: a more efficient way to view Talents RDMS UI polish: a cleaner interface for the management of RDMS  
To reduce clutter and keep Alioth beautiful, we are implementing inactive constructs requisitioning, an automated system for the abandonment of constructs owned by unsubscribed players and organizations to aid in keeping overcrowded public market areas clear.
Organization construct ownership (construct slots): a new way of assigning available construct limits to organizations. Disabling element stacking or overlapping: the final step in preventing the element stacking exploit.  
WHAT’S IN A NAME
 
Choosing the name for this update, Panacea, the goddess of remedy, is a reference to our renewed dedication to taking player feedback into greater consideration.
 
In reflecting on the aftermath of the Demeter release, we recognized that we fell short in this area. We read your feedback but did not make the adjustments we could and should have. We pledge to be better about working hand-in-hand with the community by implementing a plan to increase two-way communication and making some important tweaks and balancing to the game that will address some of the pain points as much as we’re able.
 
As a first step, beginning January 12th, we will postpone the next territory upkeep pay period for two weeks. This will allow the Design team time to revisit the tax rate, which many community members said was too steep. The purpose and functions of the upkeep system go beyond limiting “landgrabbing” and are more complex than they may appear on the surface. Many factors and interdependencies need to be taken into consideration.
 
WHAT’S NEXT
 
A series of devblogs will be published soon to reveal more information about the Panacea update. Additionally, we will be sharing a new roadmap soon. We hope that you’ll like what you see, and we encourage you to share your constructive feedback about our ideas as you read each article. 
Let’s chat!