Map Cell Type Setting

Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=426

Each map cell consists of the following:
- 'gat' - 1 byte storing the cell's terrain type (unchanging, value is 0 to 10 or so)
- 'cell' - 1 byte storing a bitfield of various attributes (temporary, value represents all attributes of the cell)
- 'cell_bl' - (optionally) 1 byte storing the number of objects on this specific cell

There are functions that get and set these things. They do it in a mixed fashion - you tell what exactly to do, and they perform the corresponding actions on the related variables (either lookup or modification). One odd quirk is that map_setcell() normally modifies 'cell'; but if you feed it an unknown action value, it takes it and dumps it into 'gat'.

There are enums for performing get/set, and then there's a batch of #defines representing the various bitmask values for 'cell'. There is no enum for 'gat' - the values for various types are hardcoded (e.g. for wall, water, etc).

What I want to report is

• all those enum values and such are very confusing and error-prone; there should be some unified way of handling this
• no maps: 64MB, all maps: 195MB, all w/o 'cell': 140MB. A LOT of memory goes into those gat/cell arrays. Maybe they should be merged into some hybrid value/bitfield pair like eA code does in multiple places already. And the get- function already treats the map data as if it were merged.
• the const.txt entry for cell_novending (introduced in r11572) is missing
• in r1557, celest added some values to const.txt, but they became totally wrong after Skotlex added his 'tweak' - r3969

I blame Skotlex (IMG:style_emoticons/default/tongue.gif)
Was there any special reasoning behind that particular change (except for making the components separate)? 50+MB is a heavy penalty for this...

This post has been edited by theultramage: Nov 16 2007, 02:29 PM