Question about tiles
 

When echoing tiles[] on a layer with nothing, (Never edited) I get zero, but isn't 0 technically the tile in the top left most part of the tileset? (Left part of grass) How can I get it so I can check to see if tiles[] is really returning 0 or just no value. ( Like -1, when checking for players)

Usually the tiles are a few numbers or something such as 0x1B0...
You'd have to go offline and to the tile array thing..

I've noticed depending if you get it from offline mode, or from online it changes from 0x1B0 to numbers... try..

player.chat=level.tiles[x,y,]; which would probably give you the numbers.. I hope that works.. if you'd like a square you'd have to build up a for loop..

Yea, I have the formula to convert a tileset into it's hexadecimal, my problem basically is that when reading a tile that doesn't exist, it reads it as NULL or zero. Which is actually a tile on the tileset. I was just hoping for a way to differentiate between a NULL tile and the actual tile 0.

Oh.. I get you.. sorta.. it sounds like it is reading the pitch black.. D: but I guess I can't help much here then.. sorry lol..

Try using player.levels.tiles[x, y].type() to check for a difference.

That only checks layer 0, I need to check layers greater than 0.

Alter it to work with tilelayers then...

Yea, I was thinking about storing the layer 0 tile in a var, then set layer 0 to whatever layer tile I want to check, then put everything back... Gotta love Graal work arounds, you have any better ideas?

player.level.tilelayers[n].tiles[x, y].type()

You should really figure out what the actual value for the top-left tile on the tileset is before you make the assumption that it's 0. In the Tile Format it shows up as AA. Checking for 0 might be fine...

Value wise it is 0...

Also using type on any layer but 0 returns -1

His complaint is legit. AA is simply the base64 encoding Graal uses to save the tile data in the .nw format. That format isn't really dealt with in GS2 at all. tiles[] returns integers, and Graal handles hex -> int and vice versa for you. Either way, 0 IS the top-leftmost tile, and not AA(since like I said, base64 is strictly used for saving/loading the levels and nothing else).

He is correct in his problem that Graal does not handle absent tiles correctly. Gonstruct optimizes the saving of layered levels to bring down the file size, so doesn't include nonexistent tiles when it saves. If Graal is reading these tiles as 0, then there is a problem(a non-existent tile isn't rendered in v6 as far as I know, so it's not the same as tile 0, or the half-grass tile).

Well I guess the only thing left to do is make a Feature Request. (I've barely touched tiles, excuse my lack of exp on the topic)

In the short-term I would probably just accept it as a limitation and ignore '0' tiles on tilelayers 1+ then if functionality does get added it shouldn't be a problem to change your tile check function. Would there really be a point to half grass on those layers anyway?

or do could attempt somethign creative with the following:

TTileLayer - object type, parent type is TTileMapObject, cannot be created by script
TServerLevel.tilelayercount - integer
TServerLevel.tilelayers - object (read only)
TTileLayer.gettileanimation(int, int) - returns string
TTileLayer.gettileflags(int, int) - returns string
TTileLayer.gettileframe(int, int) - returns integer
TTileLayer.gettileimagemap(int, int) - returns string
TTileLayer.layerfile - string
TTileLayer.tilecountx - integer
TTileLayer.tilecounty - integer
TTileLayer.tilesizex - float
TTileLayer.tilesizey - float

Hmm cool, seems tiles[] are working on layers today. Iit's now returning -1 one for non-existent tiles.