Posts made by Zyzyzyryxy

Hello, I am facing similar issue as reported a few months ago: room.energyCapacityAvailable returns null due to corrupted spawn store

I am running local server using steam and developing new version of my code there. Frequently I see errors caused by room.energyAvailable being null. Spawn is displayed as having 0/0 energy when this happens, and I use system.resetAllData() to resume testing.

Contrary to issue mentioned above, I do not pass energy structures to spawnCreep call.

Not sure how to reproduce - I guess it might be connected to either pausing / restarting the code and/or editing the code in external editor while server is running, but didn;t pinpoint any specific scenario yet.

I see in the docs that ruins are walkable. What about building on top of them? Is it allowed or not?

There was (and probably still is, thought I did not check) an option not to send errers that happen when you are logged in. I don't think it works correctly though.

Will pull mechanics guarantee that pulled creep will take position of pulling creep when multiple creeps try to move into the same spot? (Think attacker - healer pair being separated by enemy creep)

Will invader defenders be allowed to go outside ramparts? Killing them regularly might be a significant source of boosts, especially with lvl5 core and 50-tick spawning time.

@o4kapuk said in Draft: NPC Strongholds:

No, controllers in a Stronghold room will be reserved by Invaders Core preventing players from capturing/reserving it.

(it is actually my point 5)

Will a player be able to attackController to remove reservation, then claimController? What will happen in that case?

@o4kapuk ad 4: It's about additional cores in rooms reserved by player, not the stronghold room.

In the original description: "it will attack controllers to remove player's reservation, then start to reserve the controller itself." So the reservation wasn't supposed to disappear immediately? What you just wrote contradicts that.

According to original description, if core happens to appear when I have a reserver creep present in the room, I think I might have a few ticks to claim the controller after core's appearance. Not sure about attackController's timing and detailed effects. Will it allow me to claim in the first tick after core's appearance?

Generally I like the idea. I see some issues though:

1. "Stronghold's structures do not decay over time" and "Those containers on pictures are not regular containers with 2000 capacity, they can have any needed capacity, up to millions units." After killing the stronghold, a few undecaying, large-capacity containers will be left? Is it intended so that winner can claim that room and use those for his purposes?
2. Transferring energy is barely profitable, unless it is meant to be used on-site, again by claiming the room after destroying the outpost. Are there any plans to change that so that energy is a real reward from tier 1 outpost without claiming the room and using it to build the base?
3. "a middle-level Stronghold is able to spawn additional cores in another room; the additional core can't grow into another Stronghold [...]" What will happen after destroying the outpost that spawned additional cores? Will they still not be able to create an outpost or will one of them be promoted to outpost in place of the destroyed one? (Possibly letting a player quickly populate the sector with bases equipped with extra-large storage in place, see previous points?)
4. Will a player be able to claim the controller in a room with the Invader Core (eg as an immediate reaction to core appearance, assuming reserver creep is already present and next to the controller)? What will happen then if it will be possible? Will those cores attackController until such room is declaimed? Will it be possible to use safemode in that case? What would be effects of that?
5. Will a player be allowed to claim controller in the outpost room itself, eg to start safe mode, possibly making the outpost destruction easier?

As understand it, ENERGY part would only recycle itself 100%. So you can build 25MOVE 25ENERGY creeps to recycle them at target, thus transferring more energy with less CPU and no boosts, but at increased spawn pressure.

I too think problem lies with CARRY part, not HEAL part. Specifically with how much energy CARRY can carry. And I agree that balancing should break as little code as possible.

So my proposition is: add another part that can only carry energy, but can carry more of it. Nobody gets his code broken (everything works as before), transition to new, more economical part can be pretty easy for everybody and HEAL mules becomes a lot less attractive.

I'm not sure what parameters should new part have exactly, but it should allow carrying more energy than it and MOVE parts cost, so that transporting energy over large distances (when only one round trip is possible) would still be economical. Probably making CARRY+MOVE only creeps live longer would do the trick too.

Hmm, that gives me another idea - make HEAL creeps live shorter, similar to CLAIM parts mechanics? (That one is game breaking though)

@tedivm Looks like documentation issues are not the highest priority though... https://github.com/screeps/docs/issues/72 13 days without answer and counting. So I guess the question about how to report issues so that they are seen is a valid one. @o4kapuk can you comment on that? Are devs just busy working on higher priorities or nobody watches those without any poke from somewhere else? Not that I am particularly interested in this issue, but I have some more waiting to be reported when I get to know how to do it with any effect.

I think I had similar problem some time ago. Since then I am using a code posted below as a workaround for all creeps that move between the rooms and might be the first to enter the room:

        if (creep.pos.x == 0) {
            creep.move(RIGHT);
            creep.heal(creep);
        } else if (creep.pos.x == 49) {
            creep.move(LEFT);
            creep.heal(creep);
        } else if (creep.pos.y == 0) {
            creep.move(BOTTOM);
            creep.heal(creep);
        } else if (creep.pos.y == 49) {
            creep.move(TOP);
            creep.heal(creep);
        } else {
//regular move code here
        }

My creeps never stuck after I started doing this, so either this works or the bug is gone.

i just noticed that documentation at http://docs.screeps.com/api/#Creep still has outdated description of CLAIM part.

Also, what is the best way to report documentation errors? I've created an issue in github about other thing, but it seems that nobody noticed for a week now (https://github.com/screeps/docs/issues/72)