@iamanoob
kore already supports gzip compression, read more about it
here
sli wrote: Kore field pack is 1.29 megs with gzip compression. Not to shabby.
The aliasing is also done by the client, therefore there are no .gat & .rsw files for each of these mapnames.
That this reduces the size of data is merely a side effect for us, tho was most likely gravity's intention in the first place.
I've discussed this with kLabMouse and in the future there will be a table file for map aliasing.
(unless there is a better idea)
Refactoring table files system
We could do some refactoring in the tables to improve maintainability and to support pservers with custom items.
Because, what we can copy straight from the client is less error-prone.
Where does these table's data come from btw? Its not documented anywhere, tho important to know.
There are different types of tables, namely those that contain data which is:
1) hardcoded in the client (directions.txt, headgears.txt, recvpackets.txt, map aliases, ...)
2) found inside the .grf or data folder (skillsdescriptions.txt, itemslots.txt, ...)
3) used by kore to translate an ID into a human readable name.(monsters.txt -> generated from received packets)
4) used by kore to determine: wether a map is a (city, field, dungeon), the type of a skill (area, spell, ...), ...
5) used by kore to store/obtain server specific (npc) information (npcs.txt, portals.txt, ...)
*) a combination of some the above (skills.txt, ...)
These are some idea's/questions specific to these table types:
1) can be extracted from the client like with recvpackets (packetlenghts)?
2) copy-paste (and don't touch it)
3)
4) we could use flags (possibly bitflags like .fld2) for skilltypes and map/monster properties etc.
5)
*) these tables could be splitted into one of the above types if found usefull (ex. skills.txt into 2 and 3)
openkore todo