A few issues:

• You can deal on an order of 5 of a resource for 0.001.  This is because utils.roundCredits does not round up due to usage of toFixed.  Deal cost is calculated correctly (except on subscription tokens, see below).
• There are several unnecessary utils.roundCredits when calculating the deal cost.  This is because you are already rounding up the value prior to passing it into utils.roundCredits.
• Orders on subscription tokens are rounded, not rounded up, because this is the only place the dealCost was NOT rounded up prior to sending it into utils.roundCredits.

I'd PR these, but I do not know what your intentions are for these (and the last time I tried to post something about a bug to the repo, I got yelled at ) so I'll let you handle them.

Which is TOTALLY why I'm asking if this is something the community can help with.  It's just never worked right, but is super important to see what happened in a room previously.

"There are some known technical issues" has been a response to the replay system being broken, going back to September of last year.  Obviously this isn't getting worked on.

What can we do to help make this a priority?  Is this a code issue that we the community can look at to help improve, or is it something with your hardware?

Except it doesn't happen all the time.  The behavior is very inconsistent.  More often than not it will fail on transferring one tick despite the OK, and then try again next tick.

Nope, still happening, caught one within the last 20 minutes.

In my log, I have:

This means that at tick 19213488 and 19213498 both, I got a return of "OK" for trying to do a deal on this.  Since the attempts are 10 ticks apart, I can safely assume that the cooldown was initiated.  When the cooldown is NOT initiated, the attempts are at most 2 ticks apart, depending on my current CPU/bucket situation.

However, when I view my market history:

You can see here that only the 19213498 attempt went through successfully.  So why did the 19213488 attempt trigger the cooldown?  I don't think it should if the order does not actually go through.

@ags131 Not sure what you mean. Values are not involved in what I'm seeing. I'm seeing a transaction return OK, the cooldown get triggered, but because maybe someone else got to the order before me I don't really make the transaction. To be fair, I'm not looking for these, so I don't really know how often it happens, but I definitely saw it happen shortly after this patch was released. It might be fine now?

I've noticed that sometimes a terminal transaction returns OK but doesn't actually do anything.  Now, with the terminal cooldown, it can sometimes trigger that cooldown even though the terminal does nothing.  This really hurts, hopefully this can be fixed?

Yeah, that's why I mentioned the deal with the broader issue.  They should definitely look into the CPU fluctuations, but the current symptom should also be addressed because it could have rather catastrophic consequences, ie: losing 5 ticks in a battle could be devastating.

This is very similar to this request, but for creeps instead of rooms: http://screeps.com/forum/topic/287/Creep-overrideable-info-string-for-display-on-info-panel

I like both requests.

At the very least, the hard timeout rules need to change.

The devs are likely thinking that when a player is shown to use more than 1000 CPU a tick that the player is automatically in the wrong, and they should get punished for 5 ticks.  In actuality, the player has been averaging near their CPU limit, but this huge spike that happens once or twice a day is really caused by something on the server, and only ever happens in one consecutive tick.  The rule should be changed to instead look for a number of large "hard resets" several times in a row or within a certain small period of time, and THEN punish them, perhaps even with harsher restrictions than just 5 ticks off.

We've already seen the devs err on the side of the players, for instance the reset storms that happen 4 times a day where we're constantly getting resets, and the server compensates the players with occasional 1000 CPU bucket gifts.  I think the same philosophy needs to come into play with these hard resets.

The broader issue however is inconsistent CPU usage.  I can go hours with a full bucket, and I can go hours in or near a bucket crisis (which I define to be < 9000 bucket), and all without changing my code or any parameters in memory.  For a couple hours before the most recent series of resets, I had no problem keeping a full bucket, and every time I have a full bucket I do a full market query, and those queries were barely scratching my CPU.  After the resets, my empire fell into a bucket crisis, and while watching it try to recover, I'd see it make some headway only to have an unexplained 350 CPU event knock it back down into crisis mode.

I've actually had to reduce the amount of remote mining I've been doing in response to degrading server performance over the past month or two, and really hope that this is just something temporary, but I am close to being in coteyr's shoes here and moving on.  I really enjoy this game, but these random fluctuations have been rather frustrating.