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.
Posts made by Xenofix
RE: Quickly switching between console and script tabs leads to them automatically switching themselves
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.
RE: Hi, here's a little code I wrote to generate random room names, but it gives me the following error:
Additionally, owned rooms and unreserved rooms doesn't have
Grafiti lost probably during steam transfer
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.
RE: Steam client "no hardware acceleration available"
I've got the same problem with chrome just recently. But hardware acceleration does work with firefox.
RE: Pathfinder cannot find path within one room
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
RE: Encouraging more combat at high GCL
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.
RE: Math.floor in invader generation
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.