4. Container sizing

Container sizing

  • AYCE

    I support the idea but the breaking change would be an issue my idea linked below would solve the issue adding a new structure similar to the existing extractor with a built in container. Maybe storage capacity of 5k-10k

    https://screeps.com/forum/topic/2772/static-source-farmer-structure/7


  • You're both wrong with regards to breaking changes. This is why we have a storeCapacity property and CONTAINER_CAPACITY constants. If a user has hard-coded these numbers into their code without using the constants or the actual object's capacity then they have made a mistake. In no other circumstance would changing that value break anything.

    👍☝

  • It's a change to a constant. If someone's code breaks, it's probably because they aren't handling constants and instead hardcoded shit. There's no point in having constants if we're just going to ignore them. Basically, if your code breaks, then you deserve to have your code break.


  • Even when only changing the constants, it would be needed to adjust Code. For example, I use Containers as Buffers for different purpouses, and when the capacity changes, the amount of buffered energy would be inefficient, when i use 0.25 Times of Capacity for example as a Low limit, it would be to much with the value change. If i did different, i would have hardcoded numbers. Both cases, Code would work, but not optimal.

    1 Reply

  • @saruss A minor inconvenience is not a reason to never rebalance things.

    Also maybe consider moving away from a hardcoded modifier.. If you use 0.25 because it's 500 energy, write it as 500 / CONTAINER_CAPACITY, and then figure out where your buffer amount of 500 is calculated from, because it's probably dependent on room or empire factors.

    1 Reply

  • The devs should be free to change constants.

    However, it should be done carefully. Constants that have never changed have a tendency to become assumptions elsewhere in code. Imagine a creep maintaining a container, it's sized for CONTAINER_CAPACITY/2 => 20 CARRY. Suddenly the constant is 4x larger now the creep needs to be 80 CARRY and stops spawning.

    ☝☺

  • I would certainly find the game less fiddly if container sizes were increased. There are all sorts of problems I have to solve because the container size doesn't map well to the size of cpu-efficient tranport creeps, and it means I have quite strict timing requirements to collect energy from containers. These are difficult and interesting albeit fiddly problems to solve. If we got made containers much bigger, it would remove these difficulties and make harvesting gathering an easier task.

    It would open up some new solutions to energy retrieval such as boosted transporters or even trains, but it would generally simplify the problem of retrieving harvested minerals.

    Would the game be better if this happened? I'm not sure.

    I'm don't see how this in any significant way changes risk / reward. The biggest change is to how you size and programme your miners.


  • @warinternal than there would be that constant of 500, thats what i meant; then i could directly use the magic 500. Of course some things depend on room/empire Status, but i just wanted to explain that with each aproach, changing the capacity would need some adjustments in code. I had no problem with it, as soon with the store change there is much to change nontheless.

    But the only argument for now is that bigger Containers would make the game easier. Then, i am against a change. If you make everthing just easier, the game is just less a challenge and so, more boring. It would make coding good harvest/hauler code less rewarding. I know that in my lastest Code Version, i have/had problems to supply my upgraders container with energy. While bigger containers would make this easier, i totally liked the challenge.


  • I can't decide if larger containers would make things easier or harder. Right now there's a few solutions to container mining, and most people either go for "haulers tied to a route and sized for the distance" or "wild haulers which can pull from any source container and are full sized". The former being a bit wasteful on CPU, but easier to code and less liable to edge cases screwing things up.

    With larger containers (eg. 3k+) we'd add a few more options. You'd be able to harvest out a source into the container without worrying about spillover and move on to a new source. That'd make harvest boost better. It'd also make carry boost better. I also may add new harvesting techniques based off harvest boost and unboost.

    Other constant changes would have similar effects. Bigger links would let you use them as sinks for remote haulers more easily. Longer source regen times (and correspondingly larger amounts) might help with roaming harvesters. etc. etc. etc.

    In general though I think the game is too far along in development to change such fundamental values that may break codes that haven't been touched in years.


  • I've changed my mind I don't think container up sizing is worth the disruption. However, double the number of containers might allow for some new and interesting solutions, especially in SK rooms.

    10 remote containers cost 5 energy per tick to upkeep, but allows for more CPU efficient hauling. I think that is an interesting tradeoff.

    Currently you need 8 sources in range to feed a T3 boosted 40 CARRY. Double the number of containers means you could feed it with 4 single source rooms where each source has 8 containers. Running the hauler less often is easier but efficiently mining out a source into 8 containers as worthy trade off.

    Caravans have two problems. One is buffering between trips. But I find the second to be a bigger issue. Caravans don't offer any advantages over 5 single haulers. If we tweaked the pulling mechanic to allow for single intent caravan movement that would give me a reason to use caravans.


  • I still would fancy to bump up the containers to 2x since it would allow to mine a entire source plus a bit of leeway for lets say "minor inconveniences on the road"
    I also agree with @deft-code tweaking the pull mechanic.
    Maybe with something like a optional {hook:true} so that all "hooked" screeps are slaved to the master until they use a move intent.
    This way the only CPU cost would be the initial "hooking up" and the move intend from the master it is also non invasiv and shouldn't brake things to much.