Posts made by Xenofix

From the Steam announcements: "Season #7 is open! The season will last for two months, from September 1st until November 1st."

So the Season 7 ended.

Another tip on performance: Trying to move to the center of the room new RoomPosition(25,25,roomName) can lead to a very high cpu usage if there are walls at and around that position, because you can never reach that position so that the search is quite exhaustive to find a route. Better moveTo the target position directly. Also don't forget to add the range option to each goal that is in the wall (like controller, source) because of the same reason. For a source range:1 is enough.

If the creep stops in the other room, then maybe you don't call moveTo to the same target position anymore.

That makes sense as there is another opening some tiles down. It routes to the next room and a few tiles down back again. If you keep moving to the same target position and stop changing the target depending on the current room, then this works fine. If you do not want that other rooms are taken into account, then add to the options maxRooms:1

There is some help on discord #cpu-clinic. A link from there is:

https://github.com/bonzaiferroni/screepswiki/wiki/%23cpu-clinic-faq#javascript-performance-links

The mentioned profiler can help to identify where your cpu goes:

https://github.com/screepers/screeps-profiler

You can also copy attributes into an object. e.g. sources: _.map(roomSources, s=>{id:s.id,pos:s.pos})

As a tip: It is really easier to just moveTo the target position instead of doing special cases for different rooms and border positions. But you've done is what I've done as well. The problem arises near the border because the path sometimes moves one step to the border. But the creep would end up in the wrong room and the logic would repath to the sources in that room then.

What helped to me as a workaround was to return if I end up in the wrong room by mistake. What's the best solution is to moveTo the target directly. What I didn't know at the beginning is: You can moveTo any RoomPosition, even from rooms which you do not have sight on. So I would just store the positions of the sources in Memory and then directly move to that position. It can be multiple rooms away and PathFinder will find a way. In complex rooms you might hit a limit, then you need to increase the ops in the options.

You could also create your own CostMatrix to wall off the borders with the value 255. Then the path will never end up at the border tile.

So the actual bug is that the path uses border tiles without being necessary. It can also be counted as inconvenience. If you move to the target source directly using a RoomPosition then this won't be an issue.

Usually you get quick help on discord in #world-help

The Memory object is stringified to JSON at the end of your tick, so you can only add objects that can be stringified. I never add any GameObjects, instead I add their id and resolve them later with Game.getObjectById. So I would map the ids of the roomSources: sources: _.map(roomSources, s=>s.id).

var existingData = Game.rooms[creep.memory.home].memory.roomData;

assuming that roomData is an array and initialized somewhere else, you should be able to push to it.

Later you can access the sources from Memory by mapping them back again:

var roomSources = _.map(roomData.sources, s=>Game.getObjectById(s));

Keep in mind that getObjectById only works for objects that your bot can see. You would need a creep in the remote room to see the sources. That's why I also like to store the position for pathing without sight.

I've just encountered the problem that I've got -16 cpu token. In my automatic market code there is a condition like if (!Game.resources[itemName]) continue;. my cpuToken are 0 all times. Yesterday evening at around 22 p.m. (CET) my script suddenly sells cpuUnlocks which I do not own., so that now I have -16 cpuUnlock.

The actual code is:

const globalResources = ['cpuUnlock', 'pixel', 'accessKey'];
...
        for (var itemName of globalResources) {
            if (!Game.resources[itemName]) continue;
...
if (Game.market.deal(bestOrder.id, Math.min(Game.resources[itemName], bestOrder.amount)) === OK)
...

So the engine must have delivered some Game.resources for cpuUnlock that were not existing, whatever evaluates to false after given to the ! operator. Even then Game.market.deal should have refused the deal because no cpuUnlock are owned to sell, instead it returned OK.

My market code runs on shard2.

@chencreep you can recreate the missing properties with Memory.creeps={} and Memory.rooms={} and Memory.spawns={} In your main.js you can write if (!_.isPlainObject(Memory.rooms)) Memory.rooms = {}; for rooms, creeps, spawns to automatically fix issues like this.

This question was answered before: https://screeps.com/forum/topic/2968/creep-move-order

You can look here: https://github.com/screeps/engine/blob/master/src/processor/intents/movement.js https://github.com/screeps/engine/blob/master/src/processor/intents/creeps/move.js

I've seen a strange bug happened. Somehow one pixel has been bought for 10000000000000.000. My code is failsafe about expensive orders and I didn't have enough credits anyways. But somehow this happened.

Edit: Maybe the attacker did offer cheap pixels and then changed the price. If the timing is right, maybe it's possible to pass all validation with the cheap price and have the expensive price during execution. It's just an idea. In this case either change the id if the price changes or block all deals for one tick.

Oh and of course please undo this order, because my code never ever dealt an order with that price.

Edit 2: I do a Game.notify for every deal. In my mail is 9 times "BOUGHT pixel for 1000 x 1".

I cleared the cache. I can't reproduce with these steps anymore. I hope this is fixed.

It's actually very easy to loose your seasonal code, it happened to me once before and is very frustrating to write all the code again. Reproduction with Chrome:

1. Have your main tab open on shardSeason: https://screeps.com/season/#!/room/shardSeason/W15N38
2. click a link from an attack message from your email, e.g.: https://screeps.com/a/#!/room/shardSeason/W11N36
3. now the code in Tab 1 will be your mmo code after a short delay.
4. modify and/or save in Tab 1. all seasonal code is overwritten with mmo code.

What I expect: the code in seasonal tab is always seasonal code and never changed into mmo code just because another tab opens mmo. I also expect attack messages to link correctly.

I got to know about this change by coincidence on slack #general, a week after it was already live. It didn't break my code, so I didn't catch it - but only because I usually use just half of my cpu per tick.

I believe generating pixel should be easy, the 2 liner to generate them is even in the api documentation to make it easy for everyone. An easy way to use wasted cpu is an incentive to waste less cpu. It has been a very welcoming feature for non-optimized users, because a good bot would use all cpu to create more energy or credits. A less advanced bot just has much cpu to waste and can generate pixel easily by wasting less cpu.

I believe there are also not too many pixel. If you try to collect golden decorations, you'll need to spend a lot of pixel. At 13th November I created 312 decorations and got zero golden decorations.

If creating pixel is challenging, then less people care about them at all, leading to the old behaviour to use as much as possible from your cpu with mostly unnecessary calculations. A good example in my humble code base of the optimizations I did after the pixel feature came out:

1. towers scan the room only every 41 ticks for damaged structures
2. market code runs only every 11 ticks instead of every tick.
3. use more reusePath instead of recalculating each path every tick, saves also something.
4. collecting room statistics and market statistics every minute instead of every tick.
5. disable logging HTML room statistics while I'm offline.
6. disable map visuals and room visuals while i'm offline.
7. sharing energy across rooms by terminal every 32 ticks instead of every tick.
8. more would be possible, but with over 100 cpu saved per tick it has been already enough.

Without the pixel feature, I would still run unoptimized code and I think many other players also optimized their code to create more pixel. No need to make this feature more challenging, it's ok to be an non-challenging incentive for optimization.

For me it was the other way around, from steam inventory back to screeps. I'm always checking transfers now, I didn't loose anything else, yet. The G-00066:DE:E still didn't reappear anywhere.

Happens to me as well often with the steam client. A fix would be nice. This also happens less often with Chrome, usually if I'm on the map and want to access the console quickly. I would click on any room and switch to console before everything is loaded. If I'm too quick, then this bug happens. Maybe it's easier to reproduce on a slow machine.

Recently the preview to place new decorations is broken. It shows all decorations of all rooms at once for every room.

EDIT: The same problem with Firefox and Steam Client.

Additionally, owned rooms and unreserved rooms doesn't have controller.reservation.

I've lost a rare grafiti G-00066:DE:E somehow.

Unfortunately I don't know exactly when and how.

It was last seen at 22.06 on steam and most likely lost during transfer back to my screeps account at 22.06.

In the steam history can be seen that I took the sell offer back. I've never converted any grafiti item back to 400 pixel resources, so it had been lost in transfer.