Posts made by UnFleshedOne

To support move events and other expensive ones, would it make sense technically to provide each user their own logs based on which events were requested on the previous tick. Will be slower than giving each client the same data, but you can charge CPU back to the client, since client can chose not to request data and not be charged?

Another vote for slack, mainly because of NSFW nature of discord.

PTR seems to be extremely slow to reload code? Something in my code was causing timeout errors, so I cutting out bigger and bigger chunks of code, sometimes it was running, most of the time I had timeouts and very often ticks would simply stop for extended time.

Script execution timed out ungracefully, restarting virtual machine

Now I'm down to this and there are no ticks at all:

/* eslint-disable */
'use strict';

Object.defineProperty(exports, '__esModule', { value: true });

function loop() {
    console.log("running");
}

exports.loop = loop;
//# sourceMappingURL=main.js.map

Don't know if this was mentioned, but running contracts at the end of the tick might be problematic. More flexible way would be allowing contracts to be listed and executed as part of main tick (maybe as an option, default being at the end of the tick). This will allow better CPU handling (especially in the context of an OS). Contracts can then make executing frequency to be a requirement if it matters. Host can run contracts before own optional and expensive code.

An option for exposing some clearly separated host code would be nice too. Then players can define and implement interfaces for basic things like creep spawning. We already have POSIS (a solution waiting for a problem currently :)) that is implemented by several people and can be easily implemented by anyone running an OS.

For example contract can take in a context object provided by the host. It would be up to contact writer and host to negotiate exact details.

let context = {};

Game.contracts.forEach((c) => c.execute(context));

@artch OpenGL might make sense actually -- rendering room map to a texture, running shaders on it (I'm sure many image processing and computer vision algorithms can be done this way) then exposing resulting texture to the main script. Shared tenancy on GPU might be a problem though.

(Not that I'm saying we need openGL support, but that people will try to use it if it is available, and that's another resource that will need to be charged to CPU)

Nice, this is definitely something I would use if it ever makes it in. Finally my work experience apply to something that matters!

WebAssembly says it does or will eventually support pthreads, OpenGL and other system libraries. Will those be available in screeps and how would pthreads for example impact CPU usage? (haven't had a chance to actually try it on PTR yet)

Would .wasm file size would count against max script size I assume?

There is a mod to adjust tick rate: https://github.com/ScreepsMods/screepsmod-tickrate

@artch no console errors, but game-field-container element has width of 0 (and what looks like full window height).

< div class="game-field-container" ng:class="{'pan-active': Room.panActive}" >

Also works fine on the same machine in Vivaldi 1.10.867.38 (Stable channel) (32-bit).

I have Screeps-SC extension in broken browser (https://github.com/stybbe/Screeps-SC), but disabling it doesn't change anything.

Another variation on shrinking map:

• start with tall map, say 5 rooms wide, 2 sectors tall.
• after a settle down period start disabling rooms from one of the long sides of the map (randomly selected for the round) and add new ones on the other side, making a conveyor belt of habitable space.
• gradually reduce number of rooms added (maybe making them highway rooms so nobody gets stuck on the edges), clinching all bots into the center until just a strip a few rooms tall remains.

There should be enough time for edge room to reach RCL 8 and work for short time pumping out armies before being eaten by the map.

Rolling map would reduce advantage of bots spawned in the center. Adding rooms in reverse arrow shape would reduce placement advantage even more (see illustration below, red rooms are all lava).

(please delete this post if a screeps bot ever becomes self aware and goes after its tormentors)

Works great on the same machine in Opera 47.0.2631.80 (PGO).

BTW, Chrome is broken the same way even when I go back to main server now (with more hard reloads).

I don't see room map at all -- haven't changed any settings yet -- I see word map, but when I click on a room, I get code editor in full screen, not even "code/console/memory" tabs.

I did "empty cache and hard reload" in chrome (Version 60.0.3112.113 (Official Build) (64-bit)).

There are a lot of ways of writing into it from any number of shards. It’s a coding challenge of how to implement it effectively. I recommend some reading about mutexes to get more info on the matter.

Ah, I guess the write itself is at least atomic and all shards will be presented with consistent state at all times (which one being undefined), so a lock is easy to write. I was imagining partial writes and other horrors. Nevermind then, sync is not a problem.

re: CPU -- it would be nice to be able to set this in script. To avoid excessive synchronization maybe have one shard be a CPU-master (whoever claims that status first) and be able to allocate CPU for own and all other shards. If script wants another shard to be master, current master must relinquish the status first.

re: segment sync -- there absolutely needs to be a way of synchronizing this, currently I don't see a way of writing into it from more than one shard. At the very least we need 2 independent segments as tedivm said.