The point is that he is the Community Manager & Advocate ... and he is eliminating players. How can he be an advocate for people he is wiping off the map?
Here is a sample of the exchange from him:
XyzzyPrime: Thank you for helping me see the true nature of the game ... it is just for the "groups of players" that have been here for a long time. Newbies not welcome. Yesterday at 1:48:03 PM
o4kapuk: You're welcome.
Excellent Advocate ... NOT!
Dear Community,
This is a good joke on all of you ... putting the new Community Manager as the Hatchet Man in the game. He just let his Creeps go on my rooms and started the process of destroying each room.
Great helper of the community ... NOT.
Advocate for the Community ... NOT.
Killer of the Community is a better title.
He did this in the name of "making the map smaller". Well, he will get his wish ... I will no longer play the game and the game will lose my subscription $$$ and the map is smaller.
I expect this post to be deleted almost immediately since he has the ability to do that.
I just hope the Devs get to see it before he deletes it so they know that he is actually costing them money each time he does this.
What a joke "community manager & advocate".
Not everyone uses `grunt`
And since you understand it so completely... could you use your own advice and thus solve the problem for everyone no matter how they choose to run their code.
MODE_SIMULATION: "simulation",
MODE_SURVIVAL: "survival",
MODE_WORLD: "world",
MODE_ARENA: "arena",
Add:
MODE_PTR: "PTR",
**NOTE** there is an error in the return for the code (it returns "world" in PTR and WORLD):
Game.rooms['W##S##'].mode
Cool use for grunt though ... I have ideas to use your example for something else.
Is seems that resets for CPU and hard resets have diminished somewhat (feels that way, but I have not data to support it).
It would still be useful to have a process to save data as it is produced so that no code issues would destroy it.
Could the Dev's give us any available methods that they know of to effect this "save of data".
@Tedivm ... good point ... so to dispell your objection, then only allow the smallest invader and only 1 in reserved rooms.
It is all code, after all, and those options could be coded to only allow for small Invaders (in reserved rooms). Also, there is probably no need for User Created Invaders to have a 1500 tick lifespan anyway.
And by the way Tedivm, I like the way you think about using the Invaders as a defense.
IMHO, a Storage structure should work normally for all players, not just the owner in all circumstances.
If a player abandons or is killed off in a room, the structures containing energy should be available to take by either the new player or the old owner.
If you reclaim the room, then it should go back to everything working.
Using the Create an Invader sidebar function is great for testing code.
It is not available in Reserved rooms, just in Controller owned rooms.
Please make it available in the Reserved rooms as well. There needs to be a testing method in those rooms like the other owned rooms. Testing the ability to attack reserved room invaders is important also.
Thanks
On the point of alternating or grouping, there are points to either.
One thing to consider ... if you have a creep that is down to just one part (the last one before death) then what should it be? IMHO, Heal. That way it has a potential that if it was saved just at the brink of being killed, then it will heal itself back to full.
Next, what is the next to last part? IMHO, RANGED_ATTACK. If it is down to the end, it will want to go out swinging. Ranged is the only one that is guaranteed to be able to attack at any range.
So overall, start with the end and work backward to full body parts to determine best. Create the logic and then you have the order no matter the size or parts.
I have seen some Players that group parts like Tough, Ranged, Move, Heal or TRH*M* ... some have the last Heal at the end like I mention above. Some players use the mixed groups and repeat. Like your example.
Overall, your description is excellent and the other posts added great options as well.
Thanks for the post.
Does this mean that we can put something like:
process.on('SIGINT', () => {
console.log('Received SIGINT. Press Control-D to exit.');
/* User Code to save state here */
exit();
});in our code and save whatever we like to Memory, then on the next Tick, check for it and do something?
Code from https://nodejs.org/api/process.html#process_signal_events
This comment is a little confusing (from breakOnSigint ), could someone explain it a little better: "Existing handlers for the event that have been attached via process.on("SIGINT") will be disabled during script execution, but will continue to work after that." [emphasis added]