const is block scoped and won't show up on global, like you were attempting to use it. If you want to use it from the command line you either have to put it on global or type it on the command line itself.

That did it. Thanks

@o4kapuk Steam version, haven't tested the npm version

@o4kapuk MMO appears working now, but steam private server showing v3.3.2 and.. event now shows the associated number (12) but the constant EVENT_TRANSFER is not in global scope.

Updated to steam PS version 3.3.1, EVENT_TRANSFER is still not defined. Not seeing it on MMO either.

Hi, I'd like to know if we could pass in a position and maybe zoom as url parameters to links, so we can more easily focus a specific position in our links. Something like #!/room/shard0/E59S39?x=5&y=16&zoom=3, maybe?

I'd like to see transfer and withdraw events separated into two constants, please.

In the current implementation only object and target id are reversed, and you still have to run a series of convoluted checks to figure out what happened, which is exactly what it's trying to prevent.

Used here, https://github.com/screeps/engine/blob/master/src/processor/intents/creeps/withdraw.js#L93

But isn't actually defined anywhere.

Currently if you call setActiveForeignSegment and there's nothing there your RawMemory.foreignSegment will be entirely undefined. But if there's a public segment there you get the username, id, and data of the segment in an object. I'd like to request that if you have a foreign segment assigned and there isn't one there, that we return the same object format. username, id, and data would be null or undefined.

It looks like in order to load them we'd need to touch driver.evalCode and engine's requireFn to make a new requireFn for each module (far as I'm aware it's the only way to keep track of the current filepath for the module). This would happen only when a module is a loaded. Cache hits would return the existing module still. Path resolution would occur each call to require(), so there would be a little extra overhead but I don't think it'd be significant.

To further complicate this, we can't use node native modules directly in the engine, so we might have to write our own copy of the path functions we want to use. ..Annoying but hardly the end of the world.

I'm toying with some code but ultimately it's an experiment or proof-of-concept, and would require the devs to implement the gui and code-upload portions.