PTR Changelog 2016-03-16
-
This post describes the changes on the Public Test Realm.
- Increased containers decay to 5,000 hits per 100 ticks.
- Increased containers hits to 250,000.
- Decreased containers capacity to 1,000.
- Increased containers construction cost to 5,000.
- `Creep.drop` and `Creep.harvest` methods put resources into the container on the same tile automatically when dropped (containers are passable structures).
-
Would it be possible to increase the capacity to 2k and put the limit on containers to 3 instead of 5?
-
This way the decay rate should be increased 2 times as well. Building 2 adjacent containers doesn't work?
The reason behind having many small containers instead of a few big ones, is that you can adjust it to your needs without maintaining more than you wish to spend on repair. 1K capacity is basically the amount of energy harvested during one full trip by a courier to an adjacent remote room (100 squares distance).
-
1k isn't a very large amount though if the point of this structure is to keep carriers from having to sit at miners waiting. 5k was great, 2k is probably the lower limit. Not to mention with boosts, isn't the idea to get larger carriers so the average carrier size will go up?
I could just add more carry to my miners and fulfill the same purpose at almost the same cost and not incur the .2 cpu cost of transferring into and out of the container.
I'm just not seeing enough benefit from this structure in its current state to push me to code for it and utilize it.
-
Just want to add to what Hernanduer said, I can see the intention of what you're trying to do with container, but 20 CARRY parts will have the same effect, at .67 energy/tick (comparing to container .50/tick). Which makes the container improvement very marginal.
Also, with the old design of container at 5k (with or without the old maintenance price, I'm not sure yet), there are more interactions to be done with remote mining (one really big creeps collecting energy at 2 sources in a room). I think that's an interesting choice to be made. That's not something possible with too small container like current.
-
> not incur the .2 cpu cost of transferring into and out of the container.
You don't have to transfer resources into the container, it will drop into it automatically on Creep.harvest (see the changelog above)
> 20 CARRY parts will have the same effect, at .67 energy/tick (comparing to container .50/tick). Which makes the container improvement very marginal.
Well, there is also the MOVE parts cost for that creep.
> That's not something possible with too small container like current.
You can build 2 or even 3 containers close to your harvest point.
-
> Well, there is also the MOVE parts cost for that creep.
You don't need MOVE part for CARRY of miner (which is the case we are discussing), since miner doesn't move after they reach the source, and CARRY without energy doesn't need MOVE part.
-
>You don't have to transfer resources into the container, it will drop into it automatically on Creep.harvest (see the changelog above)
That's only true for the one right on top of it, right?
So if I built one immediately adjacent to another, I'd still have to transfer to it and I'd still have to have carry on my miner because the container can't do the transfer itself.
That's part of why a couple of big ones is better than a bunch of small ones.
