• Idea to Improve the new TC Building Decay System - (Long Read Warning)
    6 replies, posted
Base Repair Queue - Idea to Improve the new TC Building Decay System FacePunch would create a Base Repair Queue, where the TC would simply be the mechanism to submit your resources to the queue.  This is how it could work: You would load resources into the TC slots to be allocated for base repair/upkeep. Once you have loaded resources into the slots, you would click a button to submit the resources to the Base Repair Queue.   Once submitted to the Base Repair Queue, the resources would be locked for that purpose and would function as  follows: The resources would show up grayed out in the slots when you open the TC and would not be removable.  You would still be constrained by the number of slots in the TC.  Therefore, submitting additional resource to the  Base Repair Queue would be limited by the number of open slots you have remaining in the TC.  Any resources in  the Repair Queue would still occupy a slot, even though they are grayed out.   Destroying the TC would not drop resources, because the resources would already be submitted to the Base Repair Queue and locked in for that purpose.  They are not stored in the TC, only submitted through the TC. Destroying the TC would not cause the base to rapid decay unless there were no resources in the Base Repair Queue.  With this suggestion, the TC is simply the method to submit resources to the queue.  Therefore, if the TC is  destroyed, the resources in the queue would still be intact.  Once those resources are depleted though, the base would start to decay according to the decay timers. If someone takes over a base, destroys the TC and places a new one, the new TC would still show any resources  remaining in the Base Repair Queue.  As noted above, they would appear grayed out and would not able to be removed. I believe I understand the goal that FacePunch is trying to achieve with this new system, but I’m concerned that it will drive away the casual player and will empty servers (at least until FP gets to their no-wipe goal).  I feel the approach above, would achieve their goal, but at the same time would offer a good balance for the different player logistics.  Pros and Cons follow: Pros: Abandoned bases would still decay once the Base Repair Queue is empty.  This will help clean up abandoned entities on the server, which will support FacePunch’s eventual goal of a no-wipe environment. Players who get offline raided, would still potentially have a base standing the next day which they can rebuild from.  Currently, when they get offline raided and the TC is destroyed, their bases are completely decayed and gone.  If it is  later in the wipe cycle, they get frustrated and leave until next wipe.  You now have a server that empties quickly. Raiding by using the new “destroy the TC and wait for the base to decay method” now becomes more difficult, because  the raiders would have to take control of the base and wait for the Base Repair Queue to deplete.  This to me, sets up the potential for awesome battles for base control and the opportunity for those raided to fight for control of their base  again. Cons: I can’t really think of any, but would be curious about your thoughts?
Problems on a base upgrade.
What do you see as the problems?
have wood base - fill wood. Upgrade to stone - ooops.
Ah yes, I understand now, very good point! Perhaps the system would allow you to replace/upgrade a resource already in the queue as long as you are going to a higher tier. For example: If you open the TC and see 1000 wood in slot #1, you can upgrade the resource in that slot with stone or metal. However, you would lose the 1000 wood (or whatever was left) that already occupied that slot.
way to decoy raiding ;)
Or perhaps once base upgraded and requires stone you can withdraw the wood at 50% lost but you would still get a reasonable amount back besides if you have a wooden 2x2 I highly doubt anyone would fill TC full of wood propably max 3 k
Sorry, you need to Log In to post a reply to this thread.