tiles[x,y] ?
 

I cant seem to get it to work.

It's meant to set the player chat to "command" whenever you fire the weapon on a normal grass ground, and yes, it is a shovel. I cant think of any other way to do this, and my commands RTF doesnt have tiles[x,y] in it. Is there another one I can get which is upadted?

"127 + 15 * 16" is being treated as a string, not being evaluated.

Try #v(127 + 15 * 16).

Or you can just do
tiles[playerx,playery] == 127 + 15 * 16
although, it's probably better to just use 367 instead of 127 + 15 * 16

Each of the numbers in that statement must have some significance, so it's probably better to leave it in a way you can understand it, rather than use one big magic number :x

Still doesnt work, i've tried it with the #v on both, refuses to work =/

EDIT:
odd, It works now, but the normal grass code is 2047 for some reason, is there any way to verify that?

ah, that's what comments are for okiesmoke =p

Why don't you make the specific tiles in an array?
It'd be alot easier my friend. :0

Why would he need it in an array? He only has one tile to check for =\

comments?! Who need's 'em! :P

Real scripters script everything on one line and have no comments!1!!1

I'm still saying using an array would be alot easier. :)

Explain this theory.

It'd be alot easier, if you ever wanted to add more then just one tile. Future planning

But that doesn't make it any easier to do in the present?

It is not. Ideally you would use a constant like this.TILE_FOOBAR = 127 + 15 * 16;, or at least a function like getTileFromTileset(x, y) if the tile is not really namable. Putting magic numbers and then commenting them is not exactly elegant, and the foo + bar * 16 form at least adds a lot of editability.

Mouseover it in the tile selection frame, and you are going to see the coordinates at the bottom of it. The `code' is x + 16 * y, I think.
Alternatively, write a script to output the `code' of the tile below your mouse cursor or something.

Because it is totally cool to go against generally accepted programming practice for no reason at all.

O-o Haha, all this time I thought it was x + y * 16.

Anyway, I think the original poster is still trying to use #v() somewhere in the equation. You DO NOT need #v() ANYWHERE. The correct way to do it is (tiles[x,y] == number)

And I agree with Fox. Plus, an array with one value isn't an array..
However, I think you should be able to read a variable that's not an array with var[0].

... produces "LINDA LINDA".

The house system on Versus wouldn't read owner[0] if 'owner' didn't have 2 or more entries, so I had to add "(npc-server)"...

y * w + h is how one dimensional arrays are indexed with x and y parameters. (it makes sense, too, after you have one row done, you will add 1 to y, which makes the next row (1*16) = 16 + x)

Why would you want to waste cputime calculating a constant?

Because CPU time is less expensive than scripter time.

If it takes you several hours to perform that calculation, maybe. But then again, if it took you several hours, then you should not script at all.

Wrong answer.

You use CPU time calculating a constant because each of the numbers in the calculation represents something important. Think about it, if you were going to change the tile you wanted to check for in the future, would you rather change one number in an equation, or try to remember the equation you used, and then put the appropriate number back in to it?

The only reason you would use a constant in this case, would be because you are saving yourself from typing (and the CPU calculating) that more than once.

The end result is probably stored as 367 in the bytecode anyway.

Hmm, in an interpreted scripting language? I doubt it :x

No, I just assumed you guys would be clever enough to understand it without be giving multiple paragraphs of answers.

The microseconds it takes the compiler to calculate the number are not even worth mentioning. Assuming that Stefan does not do constant folding at compile time, the microseconds it takes the interpreter to calculate the number are still not enough to worry about it.

We want to write down the whole formula in the script because the trouble I will have with recalculating the number each time I am going to change the tile refering to severly outweights the CPU's trouble calculating it for me. This is about what you said, I think.

But we still want to use a variable holding the number for us instead of putting it down where we use it and just commenting it for its meaning.

We could consider the variable lookup that is going to take a lot more performance, over time then the CPU's calculation will, because gscript does not have C++-style const variables and cannot substitute the variable references with the number at compile time. This could be as simple as having a numeric variable index and using it to index some variables array, but as it is possible to form variable names using the this.("foo" @ "bar) notation at runtime, I assume that we will still have to do a string-search in the this object at runtime.

But I do not care because it is gscript's job to take care of stuff like that. I gladly make that negligible sacrifice to gain more maintainability.

You generally do not want to have random magic numbers in your code. Often, the meaning will not be immediately obvious to someone trying to do maintain your script, either someone else in your NAT, or yourself a week later. This is why we give the number a name, using a variable. This is why we use names in general, we should not make an exception here. Using a comment would only be an ugly workaround, harder to maintain and no one bothers to write comments in production code anyway when code could be self-documenting.

Also, according to Don't repeat yourself, I want to be able to change the constant's value in a single place in my system without having to search my whole script or even set of scripts for uses of that particular equation. I am likely to forget to change it in one place, leading to annoying bugs.

There is more discussion regarding magic numbers on that other wiki.

GScript is compiled to bytecode. Why would there not be constant folding?

If a tiny little ant bit you, it probably would not hurt. If hundreds and thousands of ants bit you...well you know what'd happen.

If you don't want to explain your post, then why bother explaining at all? The reason for using the equation rather than a constant number has nothing to do with the 'expense' of the scripter's time.

I did not say I do not want to. I said I assumed it would not be necessary, perhaps because I spend too much time in #gscript.

Yes it has.
I am so winning this argument.

Your post was extremely vague, if you do not explain, then no one will understand what you meant.

Is that supposed to raise your intelligence-rating? For the record, I am an active member in the #gscript community, and I have not yet seen you actively participating in discussions in the channel.

It doesn't matter that it's being calculated.
What matters is how often it's being calculated.

If it's once, Sure, don't bother to pre-calculate.

If it's hundreds of times a second, I recommend pre-calculating it.

Just put it in a variable at creation, and use that in the script. That will garentee it's only calculated once.

It is being calculated slightly more than once every 0.05 seconds.

But I already explained it.

It is supposed to show why I assumed that the people around me were clever enough to understand my point without the long explanation.

Oh yeah? Well, I am a founding member of the #gscript community :mad:

Can we argue the scripter-time-expense part more?

Yes, After I had told you you were wrong.

And I can tell by the content of your posts the reason why you're not active any more.

For the record, I went ahead and benchmarked this crap because you are all to lazy.

For expressions of numbers versus a single number out of 26 runs:
13 times the expression was faster
13 times the single number was faster

For expressions/single numbers (if you don't understand why I now group these, go away, you are stupid) versus a constant variable look-up in 26 runs:
1 time the constant look-up was faster
25 times the expression was faster

Now we must figure out the meaning of these results:
First, I ran these through 10 consecutive 10000 iteration loops, meaning this is a very extreme case. Second, the difference in timing was thus;
For the first test:
-average difference: .04 seconds
-smallest difference: .01 seconds
-largest difference: .1 seconds
For the second:
-average difference: .2 seconds
-smallest difference: .017 seconds
-largest difference: .37 seconds

None of these numbers are substantial given the context. So it is apparent that giving Graal an expression versus a computed expression makes no difference (as it is bytecoded, I am told by several very reputable sources). It is also true that while giving an expression is more efficient versus using a constant concerning CPU time. However, as Fox has already clarified, using a constant for recurring data is very beneficial to saving programmer time. If you do not understand this, you require more experience. When you use expressions only, and you need to change all instances of that expression in a complex code, then you will be thankful to have used a constant. This is governed by the inevitability that you will miss some instances and require debugging time just to change recurring data.

To summarise, using number expressions will benefit you by removing the abstractness of magic numbers(granted you want this). Using a constant to store recurring data in code will benefit you in programmer lookup and debugging time when you need to change that data.