Posts made by Xenofix

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.

I've got the same problem with chrome just recently. But hardware acceleration does work with firefox.

Is anything happening about this issue?

Luckily I know A* very well. But I always thought there are two implementations in screeps. One PathFinder written in C++ by General and a JS JPS version, which is the default in moveTo. The C++ PathFinder could be activated as default for moveTo by PathFinder.use(true), which is deprecated now. Did something change here? Is JPS still the default path finder or is it all PathFinder only now?

Right now overhealing is supported, but damage is applied first, then it's healed. What if it would be swapped, heal first, then damage. You would always know exactly how much to heal to make perfect use of the tough-parts. It's a small change with almost no impact for basic players and high impact for high end players.

Yes, some players already know this one. At another position is a check to set the invaderGoal to 100k if it is 0. It was surely not intended this way, but it also has never been fixed. I would also prefer to choose either invaderGoal *= Math.random() > 0.5 ? 2 : 0; to document clearly that the current behaviour is intended or to change it to invaderGoal = Math.floor(invaderGoal * (Math.random() > 0.5 ? 2 : 0.5 )); and announce that change.

Another problem: JSON.stringify(new RoomPosition(18,49,'E54S19').findPathTo(new RoomPosition(0,44,'E54S19'),{maxOps:100000})) returns [] every second tick and a path every other second tick. It seems to depend on https://screeps.com/a/#!/history/shard2/E54S19?t=20105689 Every time when the creep at 18,49 is in the room, that expression returns [] (tested in the console). The result is, that the creep doesn't move at all.

Detail: The creep calls moveTo with the pathOptions: { visualizePathStyle: { stroke: '#ff0000' }, ignoreCreeps: false, reusePath: 0, maxOps: 100000 }

Thanks Tigga. That's really interesting. It shouldn't fail like this, should it? I guess my problem is solved.

However the problem is still there for other players: I believe that it should always be possible to find a path inside of one room without any extra options. Most newbies rely on it. Maybe someone increases the default maxOps?

Recently I've found some of my creeps unable to reach their targets using moveTo. So I've tried to reproduce at shard2:

JSON.stringify(new RoomPosition(42,19,'E51S18').findPathTo(new RoomPosition(34,12,'E51S18'))) returns: [{"x":41,"y":20,"dx":-1,"dy":1,"direction":6}] another time it returns: [{"x":41,"y":20,"dx":-1,"dy":1,"direction":6},{"x":34,"y":12,"dx":-7,"dy":-8,"direction":8}]

Obviously an unexpected result.

Or this one: JSON.stringify(new RoomPosition(1,44,'E54S19').findPathTo(new RoomPosition(4,11,'E54S19'))) returns [{"x":0,"y":43,"dx":-1,"dy":-1,"direction":8}]

Maybe someone has a look?

(Edited: Nothing passed a wall, but the paths are incomplete)

Bug in Replay here

First Bug: In this replay you can see a room under attack of an invader and the first tower is just finished the next tick. But instead the tower is invisible. However, the invisible tower can be clicked and inspected.

Second Bug: After death of the invader after t=16691971, clicking the back button tick by tick, the invader does not reappear in time.

Third Bug: The creep RangeHarvesterS24_6 who will be refilling the tower is missing in the replay until t=16692000, going backwards from there, you can see the tower and that he was refilling the tower after t=16691968

Maybe market system changes should be discussed in a separate threat. I'm also not a friend of order fees and I'm more a friend of transaction fees, but it would be too offtopic to deepen this topic now.

The current changes show what we'll expect but there is still something missing:

• The regional commodities need different resources, so their production cost varies a lot between different regions. What will be the market prices for these commodities?
• How much ops will OPERATE_FACTORY need for which effect duration? ( I know proposed is 100 ops for 1000 ticks, but they are "still considering other timings too" )