@bazsi1224 Hu?... Guess I suck at reading then.
Posts made by TwoThe
-
RE: Unexpected Syntax error
-
RE: Unexpected Syntax error
Thanks, that seems to work. Maybe the API docs should be updated to reflect this.
-
Unexpected Syntax error
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)
-
RE: Power Era has begun!
A better documentation would have been great, but I lost the hope for that a long time ago anyways...
-
RE: PTR Changelog 2017-09-25: WebAssembly support
@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.
-
RE: I think it's time to say good by
@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.
-
RE: I think it's time to say good by
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.
-
RE: CPU timeout history and server data
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.
-
Return actually helpful error messages
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?
-
RE: Pathing ignores walls on room edge
Not for this function, that is plain ol' creep.moveTo.
-
RE: Pathing ignores walls on room edge
The screep was not on the exit square, the terrain wall was. The screep just bumped into that wall over and over again.
-
RE: Pathing ignores walls on room edge
It was a standard terrain wall as randomly generated. It was also placed at the exact same spot as the exit, which I think caused the error.
The path was calculated by the Map.findRoute function.
-
RE: Able to use towers below RCL 3?
I can't think of any reason where I wouldn't want to defend my controller, or is there any?
-
RE: Pathing ignores walls on room edge
I had this issue yesterday on the production server. Several of my creeps did a long range pathing (old pathing code) and got all stuck in a terrain wall that was placed at the edge of a map where supposedly also an exit was placed. Since I had the moveTo line displayed, I can with absolute certainty say that this was a pathing issue of the live game version.
-
RE: Able to use towers below RCL 3?
RCL just restricts building not using.
-
RE: findPathTo happily paths into obstacles
MoveTo does not actually move the creep, it schedules a move attempt and returns OK if that attempt was successfully scheduled.
However I agree that the current situation is very annoying for scripting as you essentially need to track whether or not your creep has actually moved, and if not figure out why.
-
RE: Simulator broken since update
The simulator is different from the real thing in various aspects. For example global does not exist, or the browser version runs a different JavaScript version.
I would also consider the simulator broken in its current form, as code running on the simulator does not necessarily work on world and vice versa.
-
RE: findPathTo throwing error
Imo pathing should work with structs similar to RoomPosition, as otherwise GC gets busy cleaning up all those RoomPosition objects.
-
Pathing ignores walls on room edge
When requesting a path to an exit any pathing attempt will ignore walls at the edge of the room, causing the creep to bounce against the wall infinitely.
This can currently only be solved by an additional look request for the exit destination to check for structures or terrain walls.
-
RE: During safe mode, Creep.attack() returns ERR_NO_BODYPART
Yeah I stumbled upon the same issue. However checking for safemode is required anyways and safes you a lot of find calls worst case, so I would consider this a lower priority.