Jump to content

DEVBLOG: REVISITING CONSTRUCT SLOT CHANGES - Discussion Thread


NQ-Deckard
 Share

Recommended Posts

Thanks for listening NQ. The new limit numbers sounds like they will hurt a little for both NQ and for players, which means they are probably a good compromise.

 

But at the same time NQ also REALLY needs to take a serious look in the mirror and investigate how they where able to conclude that the previous limit numbers where sensible in any way shape or form. It is VERY worrying that NQ appear to be this far out of step with the players in this game, and ever worse the lack of understanding what is needed to make this game work.

Link to comment
Share on other sites

50 minutes ago, Doombad said:

Who cares. Focus on the outcome. This is far better then what was proposed and workable. 

The problem that if this was pre-planned, then NQ are playing us for fools with their initial proposals, knowing that a supposed 'compromise' on the counts was always going to be the final offering and players would look at it as a 'better deal' and be thankful for NQ 'listening to the playerbase' - when in fact they are playing a dangerous game of tactical psychology that will eventually backfire.

Link to comment
Share on other sites

56 minutes ago, LosNopales said:

Sorry I really dont see the issue.  I look at donated cores.  Look at who gave ,  I see 200 coming from people that I know/thrust.  I see another 400 from people that are dubious ,  unknown, etc..   I now know that I better not go over 200.  Kind of like a bank that gives you a 500$ overdraft,  it does not mean you should use it,  it's always going to hand up costing you.  Leave within your means applies to the cores.   

I see that, and that is how orgs will have to deal with this system, but for large orgs or orgs that NEED large core counts, like creators for ship showrooms, or community projects like Utopia, IC - even Legion or NG - not using core slots will likely not be a viable option in order to keep functioning.

Link to comment
Share on other sites

Before rolling out this change, would you consider implementing Tools to help player transit to that update? With this new constraint, we will need to dismantles constructs, and/or merge constructs that were on separate cores - because of older contraints (like the parenting before it was fixed). It is a lot of boring work, for no plus value for the players (other than conforming to Panacea). You can help make that transition less painfull by:

- Add tools to disassemble a construct in the current container, instead of removing everything 1 by 1

- Increase the copy-paste volume size if possible

- Enable copy-paste of elements

- A tool to offset everything in the building zone

- A way to align constructs, especially when using blueprints

- Would you consider a tool to "upgrade" i.e. replace a core with a larger one?

- Would you consider XL cores or cores with different shapes? A lot of our constructs are just tarmacs, ramps, parking space, voxel libraries, etc. They barely contains elements. Because of the small core, a lot of us endup with a box-style base. We used other smaller cores to build outside the base itself, just for aesthetic - and mitigate the box-like base. With more room, we can still keep the same base, but integrate the aestetic extras inside the same core.

 

With all these tools, we could rearrange things around, and reduce the core counts (which is the intended goal). Please notice, that a lot of times, we are stuck with a higher core count because of previous game limitations. Example: We created parking space very far away from each other, with multiple core inbetween because of the bad parenting (that is now fixed - thank you). 

 

Link to comment
Share on other sites

4 minutes ago, Dracostan said:

The problem that if this was pre-planned, then NQ are playing us for fools with their initial proposals, knowing that a supposed 'compromise' on the counts was always going to be the final offering and players would look at it as a 'better deal' and be thankful for NQ 'listening to the playerbase' - when in fact they are playing a dangerous game of tactical psychology that will eventually backfire.

"Never ascribe to malice that which is adequately explained by incompetence"

Link to comment
Share on other sites

I don't want to trample on anyone's larger public projects but the numbers do seem a tad high. I think a compromise between proposal #1 and proposal #2 would be best (closer to #2)

 

The right number should be one that the average player doesn't have to worry but the power player would have to slim down or at least be conscientious about their core usage -- and the public projects should be exactly that, require cores from the community to progress.

Link to comment
Share on other sites

This seems a bit excessive in the opposite direction and I really hop ethi is not going to bite NQ in the long run. 
But it covers probably most of the concerns raised previously and so.. fair enough.. 

Moving on..

Link to comment
Share on other sites

Thank you for listening to your community NQ

 

The 100 personal (with skills) for me is fantastic.  I think I have 13 or so now and am getting by so that's great.

 

The org core changes are also good. 

 

Again, thank you for listening and being flexible.  I'm sure other issues will come out as it deploys and you can adjust.

 

Can you clarify one thing though, let's say an org wants to "lease" a core in its pool to a player, to run a shop, or anything like that, can it be accomplished through RDMS like it is now?

Link to comment
Share on other sites

43 minutes ago, Dracostan said:

The problem that if this was pre-planned, then NQ are playing us for fools with their initial proposals,

 

I do not think this was pre-planned, I think NQ just lacks the skillset to handle these things correctly and has a not so great internal line of communication management which causes this to happen.

 

The second devblog is really showing they have no real idea what is going on in game and just run numbers by averaging a lot, same happened with the taxes. If they actually do not have in depth data on what players are doing in game (or worse, they do but have no way to interpret them correctly), that is a concern.

 

The second point for me was that it seems NQ tends to still go by "you do not understand" or " you seem to be confused", which is really not the case. 

 

Then in the end they massively overplay their hand with their second "offer", a typical sign of a weak position and trying to end the discussion/negotiation by offering what you can, not where you'd like to end up. The difference between 42 and 200 is just too much.

 

But I think we should move on. Knowing we will be at a similar point of discussion again (unfortunately).

 

Link to comment
Share on other sites

I think this compromise works best for everyone. Locking core counts behind a long training period will incentivize careful management of core counts while also allowing the people who truly need those core counts to attain them.

Link to comment
Share on other sites

51 minutes ago, P4rty_Boy said:

Before rolling out this change, would you consider implementing Tools to help player transit to that update? With this new constraint, we will need to dismantles constructs, and/or merge constructs that were on separate cores - because of older contraints (like the parenting before it was fixed). It is a lot of boring work, for no plus value for the players (other than conforming to Panacea). You can help make that transition less painfull by:

- Add tools to disassemble a construct in the current container, instead of removing everything 1 by 1

- Increase the copy-paste volume size if possible

- Enable copy-paste of elements

- A tool to offset everything in the building zone

- A way to align constructs, especially when using blueprints

- Would you consider a tool to "upgrade" i.e. replace a core with a larger one?

- Would you consider XL cores or cores with different shapes? A lot of our constructs are just tarmacs, ramps, parking space, voxel libraries, etc. They barely contains elements. Because of the small core, a lot of us endup with a box-style base. We used other smaller cores to build outside the base itself, just for aesthetic - and mitigate the box-like base. With more room, we can still keep the same base, but integrate the aestetic extras inside the same core.

 

With all these tools, we could rearrange things around, and reduce the core counts (which is the intended goal). Please notice, that a lot of times, we are stuck with a higher core count because of previous game limitations. Example: We created parking space very far away from each other, with multiple core inbetween because of the bad parenting (that is now fixed - thank you). 

 

 

The forums won't let me like any more posts today, so I'll just quote yours instead. 95% agree. XL cores aren't coming any time soon (NQ has said repeatedly it's a technical limitation).

 

Also, adding the ability to 'compactify' dynamic constructs, ships, regardless of size/elements, while maintaining their volume and mass, would be a huge improvement. And was requested repeatedly yesterday. Even if it doesn't happen with Panacea, it would be really nice to acknowledge the request and consider it for the future. 

Link to comment
Share on other sites

The numbers proposed here are much more reasonable. Also, I like that you are giving builders a path to specialize in. Do more of that please. My only major worry is players still having the power to reduce an org's slots. Even with the time buffers this will be used to troll orgs via mass exodus and suddenly reducing core slots limits. When this happens the only way that org can cope is to recruit and hope the new recruits agree give over core slots or get an army of alts. Please look into ways to give org leaders the power to mitigate this. 

Link to comment
Share on other sites

2 hours ago, Koruzarius said:

Also, the 100 core count does really open the door for malicious usage of core counts against an org. I like the idea, but with the possibility (and in fact, certainty) of losing a massive amount of possible cores across the game, and the hours upon hours of effort it takes to tear down those cores, people are going to lose constructs because they literally do not have the person-power to dismantle them fast enough after a massive shift. A small group of infiltrators could boost an orgs core limit by a few hundred, and then remove them on the day before a two week period begins, leaving an org to scramble to dismantle literally hundreds of constructs in 14 days.

 

I'm gonna get on my soap box again and reiterate that the ability to compactify constructs, and/or the ability to dismantle them with a single click (even if it takes a few minutes on a large many element core) would do a *lot* to alleviate this risk.

I think this disconnect comes from NQ not doing this stuff manually very often. It takes a lonnnng time to build and even deconstruct a complex large core. I have a vision of suddenly 2 or 3 people leave your org without warning and suddenly the active org members have to scramble to cope with the loss of a couple hundred cores. Players having the ability to take away core slots from an org is fundamentally flawed imo. I think this should be done through a separate org leveling/talent system. When you give players power they will abuse it. 

Link to comment
Share on other sites

Hello

It seems reasonable enough, might i also ask to to maybe revisit some other options that might solve issues regarding construct slots such as the possibility to have miners on 1 construct but different territories, having the possibility to rent/or everybody can have (i would go for some kind of rend maybe) personal/org RDMS enable storage on Market / Mission givers so we dont have to keep containers around this locations, and such other options

keep up the good work and burn some incents to keep away the bad idea spirits  :)

 

 

Link to comment
Share on other sites

3 hours ago, Mncdk1 said:

The art of the deal.

 

Propose something so outlandish and gamebreaking, that the "nerfed nerf" will seem awesome in comparison.

;)

 

This was my first thought last night. It does work too. Although I hope that's not what went on here.

 

However It would be nice if the Super could donate their personal core slots to the org as well. To help prevent abuse in players pulling out or dropping subs.  

Link to comment
Share on other sites

I was thinking about leaving, but not anymore with this direction. 

100 private cores are enough to wait 2-3 years for the XL static/space cores. Then we can talk again. 

Thanks NQ for taking a step back here. 

Link to comment
Share on other sites

If this had been your first iteration of these changes I wouldn't have had to pack up my organization's constructs. Too late now, it is done.

Yet again you came in hard with drastic measures that damaged some of us severely so even if you are now making it a softer change, the damage is done.

You did this with severe schematics changes which you then had to make softer, the taxes which you have now made softer, and this time the organization construct slots.

I am looking for a new game because I have had enough of you pulling the rug out from under our feet, even if you do put some of the rug back after we've fallen over.

Why don't you make the initial changes much softer in future so that it is not a complete rug-pull when you make the initial changes?

 

The mining unit calibrations are still terrible, the only good thing about them is looking around for piles of big rocks after several weeks of calibrations on multiple units, they were at least pretty and spread out, now that you're putting them all under the mining units you've taken that away too.

 

 

Link to comment
Share on other sites

Another idea would be sub-cores. 
 

Things like shops all need additional cores for ever vendor of a shop just so they can get their coin. 
 

This should also work for miners. 
 

say 1 core overlapping 3 tiles, but MUs placed on sub cores one for each tile.

 

I am sure we can think of many other uses. 
 

please do something to help us “remove all” form a core.
With DRM would be best to have a way to restore constructs that have to be removed due to core limitations. Like the compact.

 

Just my 2 cents

Link to comment
Share on other sites

Saying no construct is subject to abandonment "for at least a month" isn't accurate. You're proposing 2 wks from the warning. (To take advantage of the full month we'd have to monitor our construction slots constantly to know if an org member has left, unsubbed, reallocated their slots to another org...) From the first automated warning we'd only have 2 wks. Which raises the question why the warning isn't as soon as a player leaves?

Edited by Megabosslord
Link to comment
Share on other sites

A full respec should be offered so that those of us that build can sacrifice our other talents to be able to support our primary gameplay loop rather than being stuck ripping apart in development builds to get under the core limits while we wait whatever period of time it will take to get our core counts up high enough again.

Link to comment
Share on other sites

@NQ-Deckard Great update. 10/10. Talents are for those that want to invest and specialize in a certain direction and builders need lots of cores to be a builder. Or have massive space ports or showrooms or puzzles or have a huge junkyard of defeated enemy ships to show off.

 

This system still allows those fresh off the arkship to ban together and put down a decent number of cores (I still disagree with the gated core size placement talents but that is a different discussion)

 

Panacea update is looking more and more like its namesake rather than a Burst Pancreas.

 

 

Edit: For those worried about players leaving orgs in the lurch on core counts: there will be other players that will sell their core slots temporarily to keep the org afloat without losing anything. If there is a market, there will be those that fill that market.

Link to comment
Share on other sites

  • NQ-Nyzaltar changed the title to DEVBLOG: REVISITING CONSTRUCT SLOT CHAhttps://board.dualthegame.com/index.php?/topic/24304-devblog-revisiting-construct-slot-changes-discussion-thread/NGES - Discussion Thread
  • NQ-Deckard changed the title to DEVBLOG: REVISITING CONSTRUCT SLOT CHANGES - Discussion Thread
  • NQ-Nyzaltar unpinned this topic

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...