Thanks!

The API documentation lists the function (correctly) as:

deal(orderId, amount, [targetRoomName])

However the variable order in the example snip in the API is:

Game.market.deal(orders[i].id, "W1N1", amountToBuy);

Using the format in the example code returned -10 (invalid arguments).  Reversing amountToBuy and the room name to match the API worked fine.

Yeah, I watched for a bit - they don't even bother shooting things that are at range 3 from them.  That's definitely odd behavior.

Do they actually stay in their holes if you try to mine the source?  I've seen plenty rooms where they park until someone gets close.  They only engage targets that are within about a distance of ~3 from the source they're protecting.

EDIT: Actually checking the room, yes, they do.  Ok, that's weird.

This is a good suggestion, though I'd argue both real-time and per-X-ticks are useful data.  If anything, add a multiple of 10,000 ticks and keep the current data as well.

Real-time values allow you to answer questions such as: "How long before this room's RCL increases?" and "What day should I be planning on claiming a new room?"

Tick-time values allow you to answer questions such as: "Did my latest revision actually improve performance, or is the server just moving faster?" and "Will I be gaining a GCL before this now-vacant room's RCL decays to zero?"

It may be because you cached it before you had vision of the room?  That would result in an array of valid room objects ... just with a bunch of those fields pointing to "undefined", which would cause exactly the result you saw.

And no problem, glad I was able to help.

It might not be this.pos that it's failing to read, I'm guessing findClosestByRange() also needs to look at the pos value of every entity in the array it's passed, and then it's dying inside the findClosestByRange function.  How are you populating "sources"?

You could probably use the FIND_SOURCES constant instead, and it looks like that's probably what you wanted to do.

Concatenating together a list of the different roomobjects could work fine.  However, your array (finds) does not contain all the hostile creeps, hostile structures, etc.  What it actually contains are the constants mapped to each of those find conditions.  According to https://screeps.com/a/constants.js ,that would be:
    FIND_HOSTILE_CREEPS: 103,
    FIND_HOSTILE_STRUCTURES: 109,
    FIND_HOSTILE_SPAWNS: 113,
    FIND_HOSTILE_CONSTRUCTION_SITES: 115

So you're not handing it an array of all the hostile targets in the room, you're handing it an array with the content: [103, 109, 113, 115].  Since findClosestByPath will accept either a constant (representing one of those find conditions) or an array of roomobjects, it tries to process it as an array of roomobjects and fails.

I'm in the same boat as Stybbe; I'm running 8 rooms and the test code in the link Dissi posted (updated to use Game.cpu.getUsed() instead of Game.getUsedCPU() ) shows me burning less than an average of 0.7 CPU per tick, with a highest value of 1.9.  Visually watching the data, most ticks are around 0.5.  At < 1% of my total available CPU, that's really not a problem yet.  I would not be surprised if it becomes a problem later... but as Dissi pointed out, that's an end-game optimization concern, and it provides a new challenge there.

Using flags as binary flags is an interesting solution I'd been considering from an ease-of-modification standpoint and I should move to that so I don't have to make a full commit just to toggle on/off debug output.  I haven't actually implemented any of that yet though; I'm just running off direct memory accesses.

Though one thing I should acknowledge - being able to zoom out on the world map DOES make things significantly easier.  Working off room locations as a coordinate map with no other data was a bit disorienting.  Being able to step back and see the world map as a whole gave me a much better concept of where on the rim I was looking at, or what the center of the world looks like, and which of the big empires are where.  That's less of a concern for finding a starting room (where your goals basically consist of: "can I get to RCL3 and build a tower in < 20,000 ticks?" and "am I completely screwed if the guy next to me also succeeds at that goal?").  In that case I really do think it's more a problem of not being able to find the space rather than it not existing.