@artch said in StructureSpawn causing "circular structure" error on JSON.stringify():

We can add RawMemory.autoCreateObjects boolean property which is true by default, but you can change it to false before accessing Memory first time on the tick.

I think it should be false by default, but if there were an option I can use to prevent this, I would be absolutely ecstatic.

It would also prevent debugging by serializing it to the console, as identified by the global.ex() function by @WarInternal that I mentioned in a previous post. I use that in the console frequently to debug, and that was why I was and still am against that option. I am still a proponent of the console.log() inside of the .toJSON() function, warning about what they are doing. Player education over player coddling...

Another major issue with this is in allowing a full game object be serialized successfully into Memory, It will add excessive bloat to a player's Memory, especially in the beginning phase of learning how to play the game when they're most vulnerable to CPU waste. Imagine a newbie seeing this is a thing, and saving all of the creeps in their room in Memory. that's easily 500 characters per creep, and think of all of the nested objects caused by it that would exacerbate the CPU penalty to using the new parser...

I understand that this would be less of an impact with IVM, but we still need to keep in mind the multiple global resets due to development and multiple code pushes in a short period of time. 10 CPU'ers would also be heavily impacted by this addition, as they may only have 0.5 CPU spare per tick to recover their bucket.

@artch ok, so I finally got around to testing adding a function as a 2nd param to JSON.parse for creating Memory... I used the same test code above, except for editing runTest(). below are my results, and the edited portion of the test code. Although the CPU usage is not as awful as the stringify, its still pretty bad...

number of tests: 50
avg without parser: 12.5632
avg with parser: 22.9115
avg difference: 10.3483

global.parser = function parser(key, val) {
	return ((_.isObject(val) && val.id) ? Game.getObjectById(val.id) : val);
};
global.runTest = function runTest(){
	if(!global.statTest)global.statTest=[];
	var stat = [];

	/* no replacer test */
	var start=Game.cpu.getUsed();
	JSON.parse(RawMemory.get());
	stat.push(Game.cpu.getUsed()-start);

	/* replacer test */
	start=Game.cpu.getUsed();
	JSON.parse(RawMemory.get(), parser);
	stat.push(Game.cpu.getUsed()-start);
	statTest.push(stat);
};

iirc, the existing engine code prevents the creation of test invaders if there are multiple players in the room. if it's succeeding in creating test invaders via the client, maybe this talk should migrate over to bug reports. @o4kapuk, @dissi can either of you confirm that's how its supposed to operate?

yeah, when i read it earlier today, i imagined that there might be some cheesing it. imagine alliance mates keeping standing 1M creeps in each others' SK rooms to prevent those awful invader spawns...

at the same time though, i think it would be a beneficial mod to create for priv serv's like SWC or BotArena...

btw, while we're still discussing the whole objects in Memory thing, I submitted a PR for the error described in my original post... https://github.com/screeps/engine/pull/92

@artch I still feel like your solution causes undue CPU usage for all players. This only enables bad behavior (saving game objects in memory) instead of preventing it or educating the players that it is the wrong thing to do.

I really like that option. That would not penalize players that do not store game objects in Memory, and would negligibly affect the CPU of players who do. It would also alert newer players that they are doing something they shouldn't, allowing for player education.

That being said, this option would also affect players who are using the mem hack to prevent parsing on any tick that is not a global reset. I know @o4kapuk mentioned in slack that you are looking at implementing that on the backend too.