The new Room.Terrain.get() function seems to be "missing" a constant for the return of a Plain. The function it is replacing had clear returns of each type of terrain.

In the documentation it says it is returning values 0-1-2 and that there are constants describing walls and swamps, but there is no constant for the return of a plain. This makes it easy to check if a terrain is a swamp, but to check if the terrain is a plain i have to check if the functions return a vale of 0. This makes me use "magic numbers" in my code which i prefer to aviod. I can of course create my own constant and compare this, but why then is it defined for the two other two return values and just not for the first value? Also, if this return is ever changed for whatever reason by the server, by creating my own constant i would not evaluate the return correctly. If i used the accompanying constants my code would not care if the raw number returned was changed.

As i understod, the used constants "TERRAIN_MASK_WALL" and "TERRAIN_MASK_SWAMP" is used for bit masking and since the value 0 is not checkable with a bit mask it has no constant. However the return of this function does not appear to have multiple possibilities, the return is always either 0-1-2, so no need for a bit mask?

It just feels a bit inconsistent to provide constants for 2 of the 3 return values. Maybe we could get a new set of constants that describes the terrain types returned?

Update: After i started removing all left over structures in my remotes i am hardly getting any more "Isolate was disposed during execution due to memory limit". Before i removed all enemy structures in remotes my global lasted on average 50-100 ticks before the limit was reached. After i aggressively started clearing all abandoned rooms near me (ive cleared 70+ rooms now), the problem is as good as gone, my global can last for thousands+ of ticks again, mostly resetting when i upload code. This further strengthens the theory that it is the game objects that is a big problem when you have vision in many rooms, not player code. My heap graphs are still very noisy, but it is no longer reaching the limit randomly.

I started clearing the abandoned rooms the 7/19 and did no code changes relating to optimizing globals since then.

+1

My heap is reached so fast and its really confusing as to what is taking up all that space. I tried to count up what variables i have stored on global and reach only a few mb's. Some way of debugging it would be great help also.

I would like to see a seasonal shard, wiped every 2-3 months or so, preferably also a fresh GCL start.

same issue that have been reported here i guess: https://screeps.com/forum/topic/2257/creep-moveto-almost-always-returning-2

Basically the terrain is "wall" where it should not be. Seen a lot of people reporting this.

I found that if i disable my Observers scanning function my heap memory is no longer exceeded nearly so often. My observer scanning worked sort of like a radar, they would sweep the nearby rooms and enable vision in a room i could not currently see. Currently with the scanning active my heap was reset (memory exceeded) every ~25-100 ticks. With the scanning disabled i again can reach thousands of ticks on the same heap. ( It is still fluctuating a lot, but not going over the limit all the time).

Normally i have vision in about 230 rooms and when adding the Observer scanning, which means 30 more rooms will be added/removed each tick obviously had a huge impact. Without this scanning of rooms my heap is now much more stable. To me it seems like there is an issue when many rooms will be added/removed for only a tick at a time?

Calling gc(true) did cost a lot less, but it does not give me any noticeable effect (it was cleaning ~1mb for ~1 cpu). Calling gc() does clean my graphs (cleaning 10-50mb, for 60-90 cpu), but it cost so much that my bucket crashes pretty fast and the graphs was still not as smooth as it used to be. I could not let it run longer, because my bucket was emptied.

Is it possible that the game was calling some other gc function in the background before and that it is free when the game calls this as opposed to the player calling it?

09:15 - 09:35 calling gc(true), 09:35-09:38 calling gc(), 09:45-09-50 calling gc()

@Gankdalf I have no idea, it sounds plausible, but my graphs were atleast not showing this. I attempted to run gc() every tick to see if this worked like you suggested, but it destroys my bucket, the call costs 70-90 cpu. Is there a different version that is running in the background?

@artch said in IVM heap usage & game objects:

result were showing heap usage of up to 80% with no code running.

Again, it seems normal. Garbage collection may start running approximately at this point.

I still think that running garbage collection every second tick even when my code is not running seems excessive, especially when it was running thousands of ticks without triggering at all before the change that increased the total heap available. It might be random and a coincidence, but to me it seems like it was introduced at that change, as shown in my previous posts.

I did not see any errors during my empty Main, but the errors were sporadic before. I left it for a while, but this short time already reduced my creep count from 1000 to 800, i did not want to continue running this test as the result were showing heap usage of up to 80% with no code running.

My issue is that the heap was perfectly stable before the heap limit was increased. I do get that we have to take care of the heap usage in code, but if it was fine before the limit was increased, why is it now hitting the ceiling once it should have even more room?