@axis said in Workflow tips and prioritization for new players?:

What problems did you focus on early?

Static mining, road, rampart, and wall repairs, multiple rooms

Or looking back what do you wish you had planned ahead for?

Remotes, should've not waited till GCL7 with them Was a big game changer.

The amount of things to consider is substantial and I’m not even totally clear about what’s most important at each RCL ?

Below RCL 8 -- getting to RCL8. At RCL8 -- getting more rooms to RCL8.

Is it better to just have poor code up on the main server asap to chip away at GCL or are there a few bare minimum things you recommend before heading into the wilderness?

Bare minimum. I develop my code on Live, makes it more fun. Dropped in immediately with just tutorial code.

Are there particular design patterns or concepts that you’ve found work well for you?

Early returns. Also, lodash is love, lodash is life.

At some point I’ll have to spend some time studying the source of popular bots and see how certain problems have been solved there, but interested to hear your thoughts.

Personally, I try not to study the code of others too much. Instead, I normally talk to the people on the slack (highly recommend joining if you haven't yet) to get higher end concepts and ideas on how they do things, then adapting and implementing them myself as appropriate. Also observing other's code out in the wild. Some interesting observations can be made that way.

@manvsrice Windows 7 here too. And another friend has also confirmed this happening on their system as well, Windows 7. Could it be Win7-specific behaviour? Nvm.

@o4kapuk said in Why is Screeps Steam client leaving gigabytes of trash in Temp?:

@orlet does it crash for you often? As far as I can see the client indeed is 'nice enough to clean up after itself' on normal shutdown (just checked it). As for leaving temp files on crashes, it's a known issue of the nw.js engine.

Nope, it doesn't crash often, if at all.

The client has generated 11 new folders since I posted this thread. And I haven't been actually relaunching the client much. But it's about equal to 1 new folder per every new launch of the client. All of the exits were clean as far as I saw, i.e. I closed the client via the X button.

These are in C:\Users\<user>\AppData\Local\Temp. Clarified that in the main post too.

I've noticed that the Steam client is leaving lots and lots of temporary folders named nw2772_25710 and similar in windows Temp (normally C:\Users\<user>\AppData\Local\Temp) folder. Each folder contains nwjs executables and libraries, however, none of them appear to be launched by the actual Screeps client. Each folder weighs at about 26 to 28MiB, however, Screeps client appears to be generating a new unique folder every time you launch it, and never cleans up the mess after itself. This means that after a couple of days playing Screeps the Temp folder grows to a gigabyte or sometimes more!

I am aware gigabyte of itself doesn't sound like a lot, however, this is a temp on system drive, and many of us have relatively small system SSD drives, which are a fair bit more expensive per gigabyte than HDD storage. And in the end it unnecessarily litters the drive with files that are being only used once. Not everyone of us monitors their Temp folder and if you are to check it now, you might be up for a pretty nasty surprise.

Anyways, a question to the developers: why is this happening, and can it be rectified? Can't the client just use one folder for its temp trash and, maybe, be nice enough to clean up after itself?

The XXYY are the first tile in the path, rather than the starting point. So, basically, the right next time in the D direction from starting point.

@4nytime no, it can be. Just .createCreep() is an obsoleted method, you should use .spawnCreep() instead.

I have monkey-patched Creep.move() and Creep.moveTo() methods, first one to save the creep's intended move direction, and second one to inject different defaults (reusePath: 50 and ignoreCreeps: true), as well as use custom CostMatrix callback so I can mark some specific creeps as unwalkable at some specific situations.

Then after all the creep logic has run its course I run another loop of collision resolver, that checks if there's a creep in the creep's intended move direction, whether it is moving or not, and tries to move the blocker creep out of the way, with some role-specific overrides provided, too.

Took me a few hours to code, a couple of days to iron all the edge cases, but now it works pretty well for 99.8% of cases. The remaining 0.02% result in some weird creep dancing, but tend to resolve themselves in a few ticks on their own.

Can confirm, I am not receiving the allocated CPU into bucket on inactive shards either.

My situation:

1. I have colonies on shard1 and shard3.
2. I am intermittently sending creeps (trade convoys or attack parties to harass bots) from shard to shard, passing through shard2.The creeps are spending 50 ticks maximum on shard2 (as long as it takes them to pop out of portal, remember who they are, and scamper over to the next portal).
3. I have allocated 1 CPU to the shard2, and like 98% of the time the shard has no creeps or other owned objects on it and code is not running. I was expecting that extra 1 CPU to go into the bucket and slowly replenish it over time, so I don't have to jump a gazillion hoops and re-assign cpu every time I need a convoy run.

I am not receiving bucket replenishment from that allocated spare CPU.

@artch said in Enabling power on rooms:

A new Operator power will be added soon:

PWR_FORTIFY Makes a rampart or wall invulnerable to attacks for 1/2/3/4/5 ticks. Cooldown 5 ticks. Range 4 squares. Consumes 5 ops. Upgrade on level: 0/2/7/14/22

On max level it will allow to maintain one rampart/wall tile in fully invulnerable state, but with huge ops consumption: 6 times more than one Operator generates. So you either need to store up ops in this room or import it from other rooms (but don't forget about vulnerability to DISRUPT_TERMINAL).

Fortify a rampart before nuke hits. No repair cost!