Loving the new WebGL renderer! One minor issue: When a controller is upgraded while watching a room, the new segment appears above the player logo on the controller.

So, my own two cents are that the original balance changes seem like a good idea.  It takes some adjustment in the meantime, but it's not a "breaking" change.  It just means that the current behavior of some AIs would become inefficient or counterproductive.  I like the original plan because it places a natural limit on energy (i.e. a point at which it's impractical or unwise to reserve another room) rather than just implementing a hard cap.  Natural limits are, I think, more interesting from a gameplay perspective.  Viability of remote mining is then limited by how efficient you can make your mining operation, not by some arbitrary number.

Big thanks to Artem so far for engaging with all the feedback, it's great to see you're interested in (and responsive to) our thoughts.  I think some of the concern stems from the fact that, as players, we are all constantly seeking more resources.  This makes the thought of scaling them back both unpalatable and scary, but I totally agree that excessive resource abundance is a gameplay problem right now.  I would much rather experience short term pain in adjusting to a change in how efficient some processes are, then end up with a lot of artifical / arbitrary game limitations in the long run.

This may be a tricky one to replicate, but I have run Game.market.deal() with a round amount, e.g. 2000, but gotten a fulfillment of only 1999.  So far I have only seen this happen when using an amount that is equal to the size of the deal.  I suspect there may be machine rounding or other issues taking place that cause the final integer to get rounded/floored down by 1.

An example of an instance of this occurring was a transaction I made on tick 13559636 for 1999 H.  I entered 2000 when calling Game.market.deal, but only 1999 was fulfilled.

I see, thanks - I incorrectly assumed that the Market object was implemented as a class.  

I had tried your suggested approach earlier, but it didn't work - it turns out this is because I was setting the function outside of the main loop.  This tactic works for modifying other prototypes like the Creep that persist in the global scope, but functions I attached to Game.market outside of the loop do not appear to persist.  Presumably this means that Game.market is created anew each tick and does not persist in the global scope like the prototypes on Creep or Room.

Moving the function definition into the main loop solved my issue.  Thanks for the helpful response, and sorry for the false alarm!

Currently most object prototypes are accessible and can thus be extended by players.  However, the Market prototype is not accessible, which prevents players from creating their own market functions directly on the Market object.  Any attempt to access the Market class is met with errors.

I discovered this when I was trying to create a reverse transaction cost calculator.  Since calcTransactionCost() is already on the Market class, I figured I would extend the prototype with my reverse cost function so that all the transaction cost functions would be in the same place.  However I am unable to do so since I cannot access the Market prototype.

After the most recent patch, creeps were able to walk straight through Room Protection walls and invade room W48S46 while it was still "protected".  You can see this in the room history starting on tick # 12202382.

I suspect this may be related to the "exit tiles don't cost fatigue" change?