@bazsi1224 Hu?... Guess I suck at reading then.

Thanks, that seems to work. Maybe the API docs should be updated to reflect this.

After coming back to Screeps I run my old code and get a repeatable error message that I cannot explain:

const buildPos = RoomPosition.constructor(pos.x + x, pos.y + y, pos.roomName);

Reports

SyntaxError: Unexpected number
    at Function (<anonymous>)
    at getLocationForStructure (constructManager:98:35)

However the input seems to be correct:

pos.x + x=39(number), pos.y + y=28(number), pos.roomName=W21S34(string)

A better documentation would have been great, but I lost the hope for that a long time ago anyways...

@mototroller said in PTR Changelog 2017-09-25: WebAssembly support:

Being inspired by Screeps, I was looking for a scalable, high performance and virtualization-friendly solution for Screeps-like AI environment. The candidates were Lua (provides high performance virtual machine and a simple script language) and WA (extremely high performance + built-in virtualization by design).

I've been in a similar situation recently and when evaluating WA vs Lua I decided for Lua.

WA is definitely a big thing, but in it's current state you are in for a lot of trouble. Even if you ignore security risks - and since this thing is basically still alpha you actually really shouldn't - the issues when trying to get a project done with WA are currently too excessive. Eventually WA will become a reasonable alternative, but that's something far in the future.

The main issue with WA is error handling. Even the best programmer will eventually make a mistake, and at this point you need good debugging and logging to find and fix it. WA makes debugging a nightmare. All tools you are used to from JS debugging will not function, and also all tools you might be used to from C/C++ developing will not function either. You can handle some issues with logging, recompiling and waiting (which is very tedious), but some of the lower-level issues like incorrect memory access, pointer failures, off-by-one errors, all that are a major pain to find and fix when you have zero tools to help you. In the end all you can do is to write extensive test-cases and hope to catch all errors, then spend days debugging those you didn't catch.

And on top of that most JS programmers are not experienced with these kind of bugs, as they simply do not exist (in that way) in JS. Which means that many people will have to learn a completely new language (and all the issues that come with it) first, and in the worst way possible.

Lua was definitely the better choice for my kind of problem. While it is not as fast as native C, it's still much faster than JS and therefore suitable for performance-critical parts. On the other hand debugging and writing code is much simpler, as Lua is much closer to JS than C.

@Atavus If practicability had any influence on the choice of language, then JS would not have been chosen for a server-side software. What other languages would have to offer would be significantly advanced over Node.js and also run a lot faster. That is why I assume that the dev(s) know mostly JS and no alternatives.

My guess is, that the current time measurement simply compares time before and after the script run. If this is the case, then any kind of server overload will also block the thread and cause CPU time to spike, even thought he thread was paused for most of the time. As long as you measure time like this, there is no solution for this issue, because server overloads can happen at any time.

Part of the problem is definitely the choice of language, as JS does come with very poor threading support, lacks basic script-language features, is inherently slow on its own and comes with quirks like sudden GC hickups. If other scripting languages would have been chosen, those issues probably wouldn't exist at all. I.E. Lua has an instruction counter mechanism, that lets you run N instructions then returns to the caller. Proper limiting of execution time would have been a piece of cake with Lua.

But since the devs seem to only know about JS the game will certainly not be rewritten in a different language in any foreseeable future. Which also means that at least some of the issues will stay as they are unfixable thanks to the choice of programming language. Which is in the end kind of a killer argument for me as well.

But at least I get a mail every morning that my bots squished some random noob that thought "what a lovely free area around this guy", which makes me smile.

I also noted in another thread that the current message isn't helpful at all. For example my code runs at an average of 3 ms / tick and it runs fine for 2 weeks, then suddenly I get a message that I reached timeout, but without any further information on the issue. This leaves me with zero information on where to start and no way to test any changes that I would possibly implement. And considering that the code otherwise runs just fine, I will definitely not start poking into the dark.

I just got an email from Screeps saying:

Your script is temporary blocked due to a hard reset inflicted to the runtime process.
Please try to change your code in order to prevent causing hard timeout resets.

Now what am I supposed to do?

Not for this function, that is plain ol' creep.moveTo.