Offset on Tile.ID

[Arahil]

Offset on Tile.ID

on every instance of the class Tile there is an offset of 0x4000 on the ID-property. with this offset the id points to the index in tiledata.mul - which is in my point of view completely unneccessary, because every time the id is accessed there are binary operations to "reduce" the id back to the real value.

so, why is this offset on the id-property?

 

[Phantom]

on every instance of the class Tile there is an offset of 0x4000 on the ID-property. with this offset the id points to the index in tiledata.mul - which is in my point of view completely unneccessary, because every time the id is accessed there are binary operations to "reduce" the id back to the real value.

so, why is this offset on the id-property?

Because thats how the mul file is setup?

What does it matter....exactly?

 

[Arahil]

i found it while moving the size restriction of tiledatato a higher value, since we have way to much new graphics on our shard, an with our custom client it is no problem to support such a high number of graphics.

i was just curious why this offset is there - maybe there's a reason i do not see yet...

 

[Phantom]

i found it while moving the size restriction of tiledatato a higher value, since we have way to much new graphics on our shard, an with our custom client it is no problem to support such a high number of graphics.

i was just curious why this offset is there - maybe there's a reason i do not see yet...

Its the mul file...I hope you understand if you release your client and are using code from RunUO the client has to be under the GPL license

 

[punt59]

terrain and art tiles

The first 0x4000 tiles in tiledata are the terrain tiles, and their tiledata record structure is different then the art tile data structures in the mul file.. In addition, the artidx.mul is in terms of absolute tile ids.

 

[Arahil]

the client does not use runuo code in any way.


i know the file format of the tiledata.mul and about the landtiles. i also do know, that Tile.ID obviously points to the index in tiledata.mul, i just do not really get why, since every time Tile.ID is used (for example, to fetch information from the tiledata) the array is accessed with index Tile.ID & 0x3FFF.
the problem is, that i do not see any sense in this offset.

 

[punt59]

end of file

the problem is, that i do not see any sense in this offset.

Ok, undertand your question better. I guess Runuo could check to ensure it doesn't go past the tiledata end of file instead. The OSI tiledata going past 0x3fff would exceed, and you would get an error on the seek() to the file. Clearly one could check there as well I suppose.