Seems to be the portal model. Creep never goes to position 9.

Hi there,

I didn't find any good description of exactly how inter room movements occurs. This would be a great addition to the documentation, as it is the source of a lot of WTF

In general I think we need to know if the "portal" at the room edges and those in the wild acts as "Portal" or "Teleporter".

Here is how I would describe the differences:

Goal: crossing from room A to room B
assuming rooms of size 10 and height 1.
room A [0123456789][0123456789] room B

Inter room coordinates: 89][01
89 are right coordinates of room A
01 are left coordinates of room B
9 and 0 are inter room "portals"

C is a creep
x is a portal
. is an empty cell

T.0 means tick 0
C->9 means Creep intend to move to pos 9

Portal scenario

Move between rooms is immediate.
If you attempt to move on a portal and your intent is satisfied, you appear on the other side on the next tick

T.0     T.1     T.2

8901

Cxx.    .xC.    .xxC 
C->9    C->1    at 1

T.0 (C)reep intend to move to pos 9
T.1 (C)reep moved to pos 9 but appears immediately on pos 0 (and was never on pos 9). It intend to move to pos 1.
T.2 (C)reep moved to pos 1

Teleporter scenario

Move between rooms takes a tick If you are on a portal at the end of tick then you will appear on the other side on the next tick

T.0     T.1     T.2    T.3

8901

Cxx.    .Cx.    .xC.   .xxC  
C->9    idle    C->1    at 1

T.0 (C)reep intend to move to pos 9
T.1 (C)reep moved to pos 9 and wait to be teleported to pos 0
T.2 (C)reep was teleported to pos 0 and intend to move to pos 1
T.3 (C)reep moved to pos 1

So which is it ?

And is the inter room behavior the same than for portals ? Have a great day.

Same here with Linux Mint 18.1

IsActive() on Link structure return True while the structure is not active.
(Due to room level degradation)

In room E41S48
Link 5825b46c995ae8292897b33f (top left)
is inactive (marked in red)
as my room goes from level 8 to level 7.

But calling the function isActive() on the link return true.
Expected behavior: return false.

This makes it very hard to properly handle the situation.

---
Is there any other way to discriminate that a structure is not active than calling isActive() ?

Here below is the documentation for the method :

Hi Artem,
I have an infrastructure question.
Can you confirm or infirm this assumption:
* Every player code run in isolation as separated process (V8 instances)
This means that the garbage collection we have to face is almost completely due to our own codebase (And a bit due to the API codebase.) since every process have they own GC tracker. 

If true, then it is worth to try to keep the garbage to a minimum (object pooling etc).
If not, then there is a possibility to be very mean to other players by doing nasty stuff like allocating huge memory buffer at the end of the tick, which will most probably triggers Garbage Collection call for ANOTHER player while having a very small cpu overhead to our tick turn.

Thanks Artem, I'll look into this further.
The extra time on the first loads could be due to V8 hidden classes compilation.
I'll try to roll out a consistent test, if this is the case, there is nothing you could do about it I guess.
But WE could do something about it, consistency pay off in javascript

Placing an extension manually using the web interface reduce the amount of available extension by more than the number of extension placed.

Steps to reproduce:
(using chrome browser)
* select build structure (the box on the top bar)
* select extension (assume you have 10 available)
* click on the map to add an extension
* click on the map to add a second extension
--> Expected result: 8 more extensions available
--> Result: 5 extensions available (or less)

Reloading the page fixes the available extension count
But placing extensions stay bugged.

So you have to refresh 3 to 4 times to be able to place 10 extensions manually.

You rocks !
Thank you !

Errata:
If I profile the memory explicitely:

var log = console.log;
var stringified = JSON.stringify(Memory);
var startCpu = Game.cpu.getUsed();

var memory = null;
var count = 10;

for (var i = 0; i < count; i++) {
memory = JSON.parse(stringified);
}
var endCpu = Game.cpu.getUsed();
log('CPU spent on Memory parsing:', + (endCpu - startCpu) / count);


I have a consistent time which is half the time of my initial parse triggered when accessing memory for the first time.
This means, 2.3 vs 4.6 on average.

@artem Could you check that you don't parse the memory twice for some reason ?
Sounds silly but ... 

@dissi mine is relatively steady.
Doesn't look to be a db fetch issue.
Peaks on my case are pbly GC related or process slowdown/switch server side.