Posts made by roncli

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.

Your data is coming from memory, which your code must populate from somewhere within your code.  It's not available to other people that aren't using your code base.

This definitely would add another dimension to the game.  I like AMD's "counter-attack" suggestion, too.

Awesome!  This is a very nice addition, thanks for implementing so quickly.

Hope to see some out of bounds drawing in the future as well!

I'd prefer for this to be something to opt into.  ie: you have to set something explicitly in the options of the visual call to make it persist.  I do see this as being handy, and potentially a CPU saver in some scenarios.

You could get fancy, do something like give each visual a "group", and then when you call the clear method pass an optional group name that only clears visuals of that group, or if not passed just clear everything that was persisted.

First of all, FANTASTIC work with the RoomVisual API.  I am really enjoying this feature!

I have a few requests that would make this even more awesome!

1) Allow us to draw "out of bounds"!  I'd love to have some room information not get in the way of the action.

2) I often find I want to see a certain visual no matter what room I'm in, ie: a histograph of CPU usage.  I don't want to draw it in every room.  Could we get a global "RoomVisual" object that overlays no matter what room we're looking at?

"temporarily"

If the CPU whole is greater than the sum of its CPU parts, then I could take it resource-by-resource... is that right, though?  I would figure grabbing the whole thing at once then grabbing it mineral by mineral would be faster.

This is happening to me rather frequently (several times a day), and after some looking into it, it only appears to happen on ticks where I call Game.market.getAllOrders().

I've read elsewhere that this is a poorly-performing server-side function and as a result have set it up to only fire when 1) I don't have market data cached to a global, or 2) I am at max bucket and can afford the CPU hit to refresh the data.  However, it seems silly that calling this just once can hit the CPU limit, even if you cache it and don't call it for minutes at a time, and is making me reconsider using market at all.

Xist, that's my strategy too.  Logging is the first thing to go, that's 15-20 CPU freed up when that is turned off.

It seemed to settle down the 2nd day, and I was under control with logging on again... until I nabbed another room for remote mining ^_^

I've been keeping a close eye on my CPU, and just recently stabilized it with my (rather CPU-expensive) logging module turned on to the point where my bucket was always topped off or close to it.

Since the update/outage this morning, this has changed.  Now my bucket gets slowly drained with my logging module on, and I have to turn it off or else I get "Script execution has been terminated: Temporary blocked due to CPU limit abusing. Please optimize your script in order to prevent reaching the CPU limit too often."

My code hasn't changed in a significant way in 3 days (I only if/else'd out some code that doesn't need to run unless the room is a certain RCL), so what's changed on the server's end that could have caused this?