I can bypass statement count filter with my code.
Will you close this possibility, or is it a bonus for those who can find it?
As I discover statement types that fail to get a statement count increment inserted by the transpiler, I’ll put it on my list to fix them. In your example, the d++ isn’t getting counted properly, but everything else is, so I don’t think you’ll be able to do too much with it. I’ll track that over here. Thanks for the heads up!
By the way, when we do our verification round and inspect top solutions, any egregiously hacky behavior may get disqualified. (I would tell you in advance what’s kosher if I knew what the hacks were.) If in doubt, it’s a good idea to ask. You can also private message me or email us.
Main question is about Array methods. In my example d++ is not counted properly only if it is inside a function that is passed in something like forEach. Don’t know if i can try using something like eval() or other things.
Actually the way of limiting the statements forces users to use the slowest built-in functions. For example, quick distance approximation uses several bitwise shift operators like >> or <<, but it will be counted as 10 or more operations. So now everybody will use Math.sqrt things since they are counted as a single operation. I wound also think about something like MMX when several addition/multiplication operations are done with single command.
I also worried about function calls. Each function call can be counted as creating vars in stack, managing scope and so on. What about functions provided in ‘this’ api? Are they counted as custom functions?
All of that requires writing very ugly code with a lot of copy/paste.
I guess it will all end with some kind of autogenerated code where all functions are actually macros that are replaced with something unreadable. Is this approach with inserting generated code into the editor allowed?
Hmm, are you sure that doing the operations inside a forEach actually affects whether the statements are counted? To my knowledge, d++ never is counted, regardless of function nesting level, and normal statements are counted whether they’re in a nested function or not.
It is sad that you lose points for using something fast compared to the slow Math.sqrt. I will look forward to assigning a higher cost to that function.
API methods are currently just counted as one statement, right.
The statement counter really is a very crude tool right now designed to prevent players from submitting code that will have their opponents waiting forever to simulate matches against them.
How would these macros work to avoid the current statement counter?
- Regarding forEach:
if i write
for(var i = 0; i < 2000; i++){
},
then the limit is exceeded.
If i increment something like this.d inside a forEach, then it is also exceeded.
So some of the expressions inside forEach are ignored by the statement counter, some aren’t.
You can see my current solution for humans - I’m sure that it is rather slow, but in most of the frames limit is not exceeded. In previous solution i also had to use forEach because without it it’s hard to implement anything exceeding the simple value=bountyGold/distance formula.
- Regarding macros:
they will not help to exceed the limit, they will help to remove the code that is needed only for human readability.
For example, you can write:
var CONSTANT =2;
var somethingImportant = y+z;
var somethingElse = somethingImportant + CONSTANT;
You can see that two first vars are just useless memory allocation, they can be easily removed. The same for functions - many functions like calculating distance are usually implemented with #define or with ‘inline’ directive in C++ to prevent the overhead of actual function calls.