Posts made by ThyReaper

You can write your own profiling code by using Game.cpu.getUsed(). However, many cpu spikes are caused by things largely out of your control, such as garbage collection. If you're only seeing occasional spikes, it's probably nothing to worry about.

Do visuals posted to all rooms that way only incur a single instance of the serialization cost?

It looks like the creep standing on the build site blocked the construction, because storages are not passable.

Creeps can move off of the site during the tick construction is attempted, so the build() call can't know for certain to return a failure code.

I feel like that might be both too strong and too simple. Perhaps as an alternative, we could have doors, which act like a toggleable wall. It increases the involvement of the door owner's scripts, and potentially provides attack opportunities for opponents to exploit mistakes in its programming.

Figured it out. Python's default auth handling expects a specific style of 401 response to the initialize request, which I guess isn't provided by the screeps site.

I just created a script to start using the upload API, but I ran into a problem. Every GET or POST is being met with a 401 "Unauthorized" response, but as far as I can tell the script is functional (through testing it on other sites) and my email and password should be correct.

For reference, here's the python 3.3 script I'm using: https://gist.github.com/ThyReaper/89fb434d413f45a3c033407410ffdfaa 

Any ideas what might be wrong?

I would second having combat notices (specifically relating to other players attacking) separated out. Having separate frequency settings for these would be great as well.

Perhaps also have an option to disable cpu limit notices - usually I'll get a notification email that is just letting me know that, at some point, the cpu limit was breached once.

In one of my mining rooms, I have a group of Invaders that can't quite figure out how to reach my creeps: https://screeps.com/a/#!/history/E5S11?t=10295324

They chase nearby creeps as they pass by, but then get stuck near the border of the room now and then.

I've also seen this issue, but I wasn't sure it wasn't something I was doing wrong. I saw it with a creep trying to move from E3S14 at 46,24 to 47,23. The creep was unable to move into that tile until something caused the invaders to decide to move away from 47,23.

Perhaps the Invaders are trying to move onto the rampart tile while attacking, and that's somehow reserving the tile as if they were succeeding to move there?

It would be very helpful if the room stats page had options to show stats for periods in ticks, rather than (or in addition to) hours and days. This would help minimize the variation that happens as server load changes over time, or when there's downtime due to some issue.

Possibly as an alternative, if the scripts had access to the same sorts of stats that are being aggregated, we could setup our scripts to generate statistic reports to our liking. e.g. room.getStat(STAT_CREEPS_PRODUCED) would return the number of body parts produced in the previous tick.

Thanks for pointing out that file, that'll be helpful. Still, I'd prefer it to be officially documented - otherwise, the constants aren't necessarily guaranteed to be defined going forward.

I brought this up months ago, but I feel it's important enough to bring up again. It would be very helpful to have a list of all constants associated with all the mechanics in the game. Apparently the majority of constants I'd find useful are already defined, but I'm just not aware of them, and I'm sure new players wouldn't be either.

To be clear, I'm referring to things like the range, effect, costs, health, etc of any action or object in the game.

The UI and the createConstructionSite API disagree on whether it should be possible to place a construction site in a location where it cannot be built. For example, placing an extension site on an existing spawn: cannot be done with the UI, can be done with the API.

Because createConstructionSite will return ERR_INVALID_TARGET if the structure cannot be built somewhere, I suspect it's unintended that the API can do this.

That's the same stuff that ended up in my memory.

I believe something happened to my account's memory as well, but I hadn't been attending to the game for some time. Based on a timer that never resets in my memory, it looks like it might've been ~12 days ago. My rooms had all lost various manually set pieces of memory when I checked on them the other day.

I'm also double checking at the moment, my account's memory has data clearly created by another script.

The tutorial may be broken, but the actual game world works with few if any issues.

There is an arrow to the right of the 'Show flags' setting, which shows the 'Flag names' setting.

Their lair will begin spawning a new one when they die, whether through decay or combat. Their combat logic seems to be: move to the nearest source, attack the closest creep. They currently don't seem to move at all after reaching their source.

Your only options would probably be to implement path caching or write your own pathing function. I've found caching to be effective most of the time.

I am rather familiar with scripting languages and their general behaviors in realtime environments, though I'm less familiar with Javascripts' implementations. Spiking during execution is only typical of a Garbage Collection pass for most script languages, but given the nature of the execution environment, I would expect the GC to be disabled - you must be sandboxing everything our scripts produce and deleting it once the script ends anyway, correct?

If that's correct, then if possible, could you tune or disable the GC so that it is unlikely to need to run during the execution of our scripts?

On a semi-related note, the spiking is somewhat mitigated by the bucket, but our scripts don't have enough information to take full advantage of it. Right now, the only data given to the scripts is Game.cpuLimit (ranging from 0-500). Spikes can cause a rather large variance in actual cpu used, so the script needs to stay well out of the way of that limit. Unfortunately, while the limit is at 500, there's no way to tell if the bucket is just above 500 or nearly full.

If there's no way to mitigate the spiking, I would ask that you expose three things:
Game.cpuBucket, So the script can try to keep itself within a consistent cpu limit, but still have the full 500 limit available when needed.
Game.cpuBudget, The limit set by the player, regardless of the moment-to-moment limit available.
Game.setCpuBudget(ms), So the script can dynamically alter how many resources it's being given. This should probably be rate limited, perhaps one change per hour or so.