Pleas read this:
It was all kinda broken
I loved working for your guys! I will still be around to help out wherever I can.
I'm very happy that the CM role is filled in by someone as capable as @o4kapuk. He's the perfect candidate.
Thanks for the last 2 years! It's been amazing.
@Periosa There are currently some issues related to isolated-vm.
We are actively working on fixing this issue.
You can join our slack to get up to date messages about the current state (you can join the #ivm channel to see details of what's happening).
Please beware that the isolated-vm feature is still in the experimental fase and might cause issues like you described earlier.
You can also subscribe to this topic to receive updates: https://screeps.com/forum/topic/2133/changelog-2018-03-05/14
@hyramgraff That's because rangedMassAttack will not attack your own ramparts.
A rangedAttack on the other hand is a directed attack at something in a specific location.
rangedMassAttack will also not damage any of your own buildings while a directed rangedAttack will do that.
I've seen this kind of issue before but thought it was my code that was causing it.
I'd like to help you narrow it down to the events leading up to this bug.
I've had issues with creating flags myself ( Linky ) and I think they might be related
I really like this change.
My old empire used to be able to create defending/attacking boosts to sustain attacks/defenses without buildup of supplies. The entire empire could crank out more X-tiered boosts in single tick than it could consume. With this change I expect it to be more viable to start attacking people again.
The defender is more likely to run out of boosts to defend properly, and in the same way the attacker will need a lot of stored/prepared boosts for attacking. A counterattack after the attacker runs out of boosts is also quite a good strategy now.
In short, I really like the inability to quickly rebuild boost surplus.
As for the change of the
upgradeController boost, I think it could have stayed the same as it, in my opinion, does not directly impact attacking/defending parties. The same is true for harvest/carry boosts.
Sounds like the EVENT_CREEP_DESTROYED functionality is covered by tombstones, so EVENT_STRUCTURE_DESTROYED should suffice and doesn't reveal any user specific information
Which reminds me, It would be nice to have a pile of rubble for some ticks when a building is destroyed. This way you'd have tombstones for structures.
EVENT_STRUCTURE_DESTROYED seems overkill.
I think the event
EVENT_ATTACK would cover most of the issues here. Maybe add
destroyed: true|false could be added so you won't do a
Game.getObjectById(data.targetId) and get null back.
I don't prefer either one.
Most people's workplaces use slack in the office which was one of the big reasons we switched.
That being said, Discord offers more diversity in managing permissions which in turn will make it more easy to manage. We can even link IRC to connect to discord with some setup to make it "work safe".
If we go through with the transition to Discord there will obviously be a Screeps Discord managed by the Screeps team.
leave their movement by plain land as usual, but without dynamic path finding. I.e. the path is calculated once and then reused, and if the keeper is blocked, it will stuck until it kills the blocking creep or die
This makes the logic a lot easier to implement. I also thinks this looks a lot like the current implementation.
What do you mean blocked? Currently they can redo pathfinding if they are blocked, i.e. it's dynamic (with reusePath:50), isn't it?
Yes, basically it means they'll probably be stuck for 50 ticks, and recalculate the path.
Every wall tile should have at least one adjacent plain tile (in order for the creep to be exposed to player melee attackers at any given moment).
If we want to keep it as simple as possible it might be better to only do a getDirectionTo and move that way. And yes, if we want to have the move over the wall requirement it wil require additional logic and getDirectionTo will not suffice.
So that means:
creep.move(TOP) // blocked ->neglected cost <<<<<< this is consuming 0.2 anyway as move is returning OK creep.move(RIGHT) // possible -> 0.2 cost // More code something happens creep.move(DOWN) // possible -> 0.2 cost again
Right? or did I misunderstood something?
The result of this code is 0.6 CPU used. if you get
OK back from the API you will have consumed the CPU.
I'm wrong. Looked at the code and it's only 0.2: https://github.com/screeps/driver/blob/master/lib/runtime/runtime.js#L148
I'll kick off the topic! I had quite a few things that I found difficult to grasp 2 years ago, but here's a few to get started;
What did you guys face early on? What was the most challenging for you?
Was it waiting for energy, or was it the invaders?
Let me know