It's only one room E18N38 in shard0. That room stop working at 12:36 PM ICT (5:36 AM UTC). No room replay after that time and my creeps tickToLive go negative. My others rooms in shard0 are fine. No major error in my code (just some few market code room typo which I already fixed)

There should be something wrong and I don't think my code cause it

Oh, it doesn't an intent behavior? I asked this question in slack a few weeks back and someone told me that this invader behavior have change for a long time. If so, I have to re-enable my remote guards again instead of retreat all miners

It's the same as normal ramparts. Normal ramparts also don't disappear when you .destroy() them

That is UI bug in reassign CPU page. You have to use slider to reassign CPU. It doesn't work if you enter cpu direcly in the textbox. I hope the dev fix it soon, it very annoy for people that don't know this bug. You can use arrow key when slider is focused to do fine cpu adjustment.

You can also change your shards cpu via api too

I think I saw issues regard this bug a while ago. I claim https://screeps.com/a/#!/room/E61N78 but I cannot remove Extractor construction site from that room (both in UI and console). So I cannot harvest mineral.

I like the idea of portal generator but to allow you to open and link it in highway room is a bit convenient. That structure will be used as mean for invade far distance room other than what you intent.

I suggest that portal generator should be build in both our base and target ally room. To maintain portal every tick both party should pay 50 energy, same amount as register power to power spawn (or even more energy to limit it usage). To open portal both players must allow connection so these portals can be connected.

These feature make it more easier to help ally defend their bases and open new way to expand new base in faraway territories.

OH, my mistake. Thanks for point that out

I try to calculate room distance across long distance and found that 

// Return 2
Game.map.getRoomLinearDistance('E19N31', 'S17N32');

if you measure these room distance manually, it should be 37. Is this a bug or it's an intend feature for distance across regions.

This distance also apply for Game.market.calcTransactionCost

You can send a scout to observe that room first, or just send out claimer (if you store last know reservation data first). You can store room reservation information in Memory. The idea is whenever that room is visible update reservation tick to Memory object. If you have no vision on that room you should use information in Memory object. Below are my code for this, it may give you some idea

Room.prototype.reserveRoom = function(creepName, roomName, scoutPath, x, y, time, body, roomTickMem) {
  var room = this;
  if (Game.creeps[creepName]) {
    if (Game.creeps[creepName].room.name == roomName && Game.creeps[creepName].room.controller.reservation) {
      Memory.info[tickMem] = Game.creeps[creepName].room.controller.reservation.ticksToEnd;
    } else {
      Memory.info[tickMem] = undefined;
    }
  } else {
    if (!Memory.info[roomTickMem] || Memory.info[roomTickMem]-- < time) {
      // Create new claimer creep to reserve room
      ...
    }
  }
};

I use creep name to identify it role in which room, ex my reservation creep is named Claimer-E19N32. And for Memory.info object, I've initialized it somewhere in my code before I use it.

If you play further into the game, CPU cost optimization will be your first priority. I suggest that you should try to call Room.find() only if you need it. Some objects can be accessed by alias (and from my knowledge it cost no CPU). Such as Game.flags, Game.structures and Game.constructionSites. Use these alias properly at start to take less optimization work later on.

Another huge CPU usage is moving your creeps. But you will encounter that problem when you reach your CPU limit and look for something to cut down CPU cost.