There are awesome detailed articles by Red Blob Games:
They are really helpful for understanding A*, tuning in-game PF and even implementing you own path-finding. Actually, built-in PF is pretty nice, but its parameters should be chosen carefully.
@maey, there was an official announcement about indexing and caching.
Yep, plain (not-a-callback-like) filter will work much faster.
Definitely strange it isn't mentioned in documentation 
@artch, I like the tunnels idea! Some thoughts:
Should it be allowed to build tunnels at rooms edges? I guess it's very tricky to implement and make compatible with current path finding.
Not neccessarily. It might open some interesting tactics in neutral rooms too.
...and not only neutral, but even enemy rooms! As a neutral structure like roads (with neutral construction sites?) tunnels can make possible some powerful "backdoor" siege tactics.
Still, I guess, tunnels will become very high-level and late-game feature and for high-level players only, so it's questionable is it worth to implement. Well, but as a community contribution and for some tokens (like awesome super fancy Tombstones) -- why not? 
@joykill, you cannot push code from you code, obviously) See the topic issue:
Is there a way to force a global reset from within the game loop with the iVM architecture?
const heap_bomb = () => { new Uint32Array(8*1024*1024); heap_bomb(); };
heap_bomb();
I've tried this code -- works fine, but takes 2 ticks to reset global. As I see, for now the only way to force global reset is "heap overflow" or critical error, but one does not simply throw a critical error from sandbox 
UPD: well, nope, it takes ~10 ticks, jeez 
(at least on PTR):
[3:38:10 PM][shard0]GAME TIME 24980814
const heap_bomb = () => { new Uint32Array(8*1024*1024); heap_bomb(); }; heap_bomb();
[3:38:25 PM][shard0]Script execution timed out ungracefully
[3:38:32 PM][shard0]Script execution timed out ungracefully, restarting virtual machine
[3:38:35 PM][shard0]GAME TIME 24980823
Suggested getTerrainOfRoom() is very minor, but useful function: instead of 2500 calls of getTerrainAt() to acquire static terrain data user now can call getTerrainOfRoom() once to get copy of runtimeData.staticTerrainData[roomName] typed array.
There are TERRAIN_MASK_* constants within existing API which can be used for future analysis of this Uint8Array: distance transform, skeletonization, convolution with CostMatrices, transferring to WASM etc. IMHO, terrain data acquiring and transferring is pretty expensive now to try some advanced path/map techniques.
const room = Game.rooms[Object.keys(Game.rooms)[0]];
let t = 0;
t = Game.cpu.getUsed();
const arr = Game.map.getTerrainOfRoom(room);
t = Game.cpu.getUsed() - t;
console.log(`getTerrainOfRoom = ${t.toFixed(6)} CPU`);
t = Game.cpu.getUsed();
const own = new Uint8Array(2500);
for(let i = 0; i < 50; ++i)
for(let j = 0; j < 50; ++j)
own[i + 50*j] = Game.map.getTerrainAt(i, j, room.name).charCodeAt(0);
t = Game.cpu.getUsed() - t;
console.log(`getTerrainAt 2500x = ${t.toFixed(6)} CPU`);
Typical performance tests:
[5:42:29 PM]getTerrainAt 2500x = 0.988422 CPU
[5:42:30 PM]getTerrainOfRoom = 0.015738 CPU
Need reply to ensure there aren't security underwater rocks here (constructor or accessors rewriting?) Now I'm investigating it as well.
Pull request: https://github.com/screeps/engine/pull/83
NOTE: there is a typo inside function (.roomName instead of .name if argument is a Room object), it'll be fixed before merging.
variable reaction time just looks reasonable and should have been implemented from the start
Yes, I agree, that's good point indeed. Such a pity some legacy improvements sometime so... painful.
Well, it was just my personal opinion, lets see community feedback. If only "3.5 anonymous" will be affected... well, it's time for just one more code rework, I guess.
@artch, not only economical optimal, but even surviving critical in some cases, I guess.
I posted out this personal "know-how" to Slack thread just to demonstrate one of the most optimal and advanced cook solution. Not sure how many players use such an approach, put this is an example of very timing sensitive layout.
The official blog post said about lab effectiveness and forced people to use effective solution, and now... well, personally just don't fully understand background, maybe.
UPD: @artch sorry, I missed some points:
On the other hand, reducing T3 bonuses could break someone who rely on their hardcoded effectiveness in dealing with SKs, for example, creeps will just start to die out of sudden.
Emh... Every effectiveness already represented within existing constants, so players already can build their creeps to satisfy damage/heal/tough requirements. And -- are there any players using boost for SK mining?! Crazy bastards 
@artch, thanks, I see. Well, I don't think reaction time balancing is much more simpler than percentages balance (and, as I pointed out, it may affect layouts (!) due to proxy capacities and chaining optimization).
By the way, did you think about just... X sources regeneration time huge increasing, for example? Moreover, it can be applied for out favorite Z mineral, and others
Were there any thoughts from @wtfrank about requested effectivenesses table update? My main idea is that there still lots of balancing possibilities without some pretty breaking changes like different reaction times.
@artch, you mentioned @wtfrank post, but there was nothing about reaction time, but about percentages. Moreover, I can't find any ideas about reaction times inside the whole mentioned topic.
Instead of suggested percentage balancing, it decided to break all da chain lab layouts logic. And I expect future reaction time tuning, which will affect previously effective layouts as well. Hooray!
Still don't understand, why it's necessary to change reaction times instead of change boost effectiveness.
And, as was pointed out inside Slack, lab code is already one of the most difficult challenge for beginners, and now it may become even more hardcore ¯\(ツ)/¯