Is this for steam buyers only or completely free?

...I just had the titular tip of the day and although I thought I know the game well, it don't understand that one. Anyone care to elaborate?

Amazing update. Haven't played in a while but reading that makes me itch for it again

Creep.name and StructureSpawn.name properties can now be accessed by other players.

I'm curious what the reasoning behind this change is. any insight?

I'd love having this as well.

mh..  do not underestimate the cpu usage of require. sure, once the code is up and running, it doesn't matter too much, but I had a codebase with a lot of requires at first, and whenever I updated my code it would result in my entire, usually full bucket being completely drained over the next few ticks. Which is annoying if you're the type of coder who likes to do quick iterations, working on live code.

Since I rewrote my code and started concating with grunt instead of requireing everything, this is not happening anymore.

On the bottom of page 1 of this thread, dissi suggested something I wanna repeat so it doesn't get lost:

I think if we can emit events for the game to display:

Game.rooms['someRoom'].displayIcon(SomeRoomPosition, COLOR_BLUE, COLOR_RED, "path.to.memory") // Maybe public/private? vision required!

A lot of people would be happy. Of course you can still choose to use the flags, but at a cost.

I was wondering for quite some time if this would be a possibility: adding methods that let us influence the game rendering, like drawing an icon at a certain position, a line between 2 positions, etc - just to visualize what our scripts are doing, for debug purposes or whatever. so far I've been using flags for that, but that never felt quite right. i don't need actual persistent objects there, i just want some visuals.

hrm.. I'd rather see a cap on reserved rooms as well than a reduction of source capacity, mostly for CPU reasons...

I just ran into an issue where creep.moveTo would throw an exception; but sadly it was not a real exception, catch would just get an empty object or something like that, which was not helpful at all.

After tinkering around an hour or two I finally figured out that it was apparently caused by some error in the costCallback function I gave it. I'm not quite sure what that error had been, might have been an endless loop or something.

point being: errors in the costCallback function are not very well handled. You might wanna look into that.

Not sure if this is a bug report or a feature request, but anyway: 

Today I noticed that my allies can't access my storage (withdraw) because of a rampart beneath it (good) - even if I set that rampart to public (bad). 

I'd kinda expect it to be public when I set it to public.. not just for movement, but also in regards to any other protections a rampart offers.

I was just gonna post about this and stumbled about this thread in the procedure, and I very much agree to what chris said, especially the two examples he gave which I was gonna post myself (damage identifying the source; construction finished - identifying the new structure). I believe something needs to be done to let us REACT to stuff instead of just ACTING - if events aren't possible, some other solution needs to be found. I believe this could potentially even reduce CPU usage overall and thus reduce server load, since we wouldn't need to actively scan and monitor stuff quite as much as we do now. 

and btw:

> Case 1 - it's really not important which of the enemy creeps attacked you, what is important, is their potential for the attack, which you would have to check for anyway.

yes it is important, if those creeps belong to different players, or to a player and invaders, in terms of diplomacy. For example, I might wanna have code that makes sure that my creeps do not attack a certain player unless he attacks me first - which is basically impossible with the current API, because scripts are completely unable to know who attacked.