PTR Changelog 2017-08-27: shards API
-
It is kinda logical though.
Else we'd have the same issues on all shard where there the ticks will slow down extremely fast due to every player being in each shard.
-
Thanks for the API!
-
@artch Could you consider having a base bucket of 500 in each shard that slowly regens? That way your script can execute for a few ticks in the other shards when a creep portals over, giving us enough time to allocate more cpu.
Don't allow code to be executed if the user doesn't have anything (owned creeps or structs) in the shard.
-
@davaned He said in this post that you get a bucket and no cpu, so you have 10K cpu to use, unless you set cpu.
-
@dissi the 10cpu should be a drop in the bucket. The only way it would cause slow tick speeds is if the shards were grossly under provisioned.
-
I definitely agree with keeping the one-world aspect here, but unfortunately I'm not following on how having a base 10cpu will help this. Yes, it would incentivize people to colonize new shards, but only enough for each person to get their free extra 10 CPU. Turning being a multi-sharded empire into an obligation for anyone wanting to use all available resources isn't something I'd support. It would favor codebases which work in small, separate outposts, and giving extra resources to specificly-minded codebases would hurt the aspect of "play the game however you want".
With the battles/response you were mentioning earlier, I don't see how the shard API is a limiter here. One needs CPU to respond to battles in the same shard, why should it be different for inter-shard wars?
-
I'm not sure why all the fuss ?
If you intend to send creeps on a different shard, just allocate some cpu to it before ? now that we have the api it shouldn't be an issue right ?
-
The UI doesn't allow completely control- like it's impossible for me to set it to "210", only "209" and "211".
-
It looks like shard-portals are currently fully closed on the ptr?
-
@w4rl0ck All walls have been removed just now.
