Posts made by Spite

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.

Re: Xeiken - One of the biggest problems I ran into with spawning initially (and after my first base got torn up because I procrastinated on building a tower until AFTER my RCL3 extensions were up...)  was actually that the "find another room" button didn't seem to do anything to prioritize rooms with two sources; it kept pointing me at empty rooms that were wedged between two other players, or had one source, etc.

Having a way to filter room searches while spawning would be helpful.  Even if that was something that required (or allowed) writing your own script to filter it (which would be totally in the spirit of the game, but also a feature most-used by people who are still getting their feet on the ground...).

Hey everyone,

A bunch of us noticed that while Screeps is open, instant messages from friends on steam doesn't create the usual "ping" noise.  A friend (rpzip) came up with a quick fix: On your steam games library, right click Screeps, go to properties, and under the "general" tab, uncheck "Enable the Steam Overlay while in-game."  If the client is currently open, you will need to relaunch it for the change to take effect.  This has been a significant convenience for our group so I thought I'd pass the word along.

-Spite

I couldn't get the replay to load on my tablet, so I apologize if I'm interpreting the situation incorrectly.

If he's claiming a room when your army gets there, you could try sending a CLAIM creep ahead to place a reservation on the room before your main force gets there?  It would still be possible for him to claim when the CLAIM creep enters the room, but it means you're putting a 650-cost creep into the DMZ instead of a full military wave.

It sounds like your best recourse is going to end up being waiting out his attention span (chain-claiming/respawning isn't overly productive for gaining GCL).  It's a lame tactic but I don't think there's much else I can suggest to handle it.