Posts made by Xenofix

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" )

Maybe a non-general-purpose and multiple-resource structure needs capacityFor of e.g. {G:5000,energy:250000}.

capacity, getUsedCapacity() and getFreeCapacity() just makes sense for general-purpose (Storage, ...) and single-resource structures (Tower, Extension, ...). For all structures with mixed resources (powerSpawn, lab, nuke, ...) there needs to be more methods. Maybe getCapacityFor(resourceType), getUsedCapacityFor(resourceType), getFreeCapacityFor(resourceType). These can be implemented for general-purpose Store, too. So that the API for both types is the same.

I also welcome the API change but without deprecation of energy. If energy must be deprecated, then please make sure they are configurable to deactivate any warnings.

I think professional players already know how to overwrite prototypes and have aliases and getters for their needs already. Everyone can already model a unified store, and properties for energy and whatever. Keeping that in mind, the API change is mainly for newbies and those who cannot change prototypes using typescript or have found ugly ways around the inconsistent API which they like to simplify.

As a newbie I did often access creep.energy directly instead of creep.carry.energy. The same for storages, it was just so annoying that I always have to access either carry.energy or store.energy or energy when at first all I care about is just simple energy. The tower has no store, the creep has no energy and no store but carry instead; just not consistent. But I can make it consistent with prototypes. So yes, this change would not really help me, but it will help other newbies. One store for all kind of objects is a great change for the API.

About the database change: Please just choose the most efficient model.

I think every high-level player at 300 cpu cap and those who are looking forward to be one agrees with me that performance is more important than convenience. The database is hidden from us, so I prefer an efficient database model over a simple engine code. I have no idea if your proposed database change will have a positive or negative impact on overall performance, but I just fear that it's a negative impact because it looks more complex than before. In my eyes, the API and the database change are two different changes.

In the end these proposed convenience changes should meet the following requirements:

1. one store for every relevant object to allow a unified way to access energy and resources for convenience.
2. It shall not increase overall tick rate, better decrease it.
3. It shall not significantly decrease the free memory we can use
4. It shall not increase our cpu consumption, better decrease it.

If that's all met, then I believe every single player in the community will be happy about this change.