Data Compression/Storage Functions |
0 | ||
Most of you regular players like myself won't be able to utilize these as we aren't allowed to save any data, but for those of you with official modules or aspiring to become official modules, you'll need a reliable way to store player data if you should choose to save any (which is a good idea, as it draws people to the game). Why would you need to compact your data? You only get 1 save per player, and only 2000 bytes each. You only get 100 global files, and only 65000 bytes each. You used to have to store player data in global files, leaving scaling up to fate should enough players play your game that you can no longer handle them all. Now you can save data per player, and that problem is gone with the wind and replaced with a new problem: very small file size. These functions should help with that, allowing you to save all kinds of data. save_id represents the save ID of the current module (seamlessly works with both PlayerData and files) readPDMulti / writePDMulti [code] The PDMulti format for PlayerData allows you to manage data for each player for multiple modules. If you ever plan to save player data for more than one module, you should use this so that you can keep track later. Note that this is for managing data strings. You will still have to parse and save player data as necessary for each module. Sample usage: --loading save_id=1 player={} player.name="Fxie" player.globalData=readPDMulti(system.loadPlayerData(player.name)) player.saveData=player.globalData[save_id] loadData(player, player.saveData) --saving player.saveData=saveData(player) player.globalData[save_id]=player.saveData system.savePlayerData(player.globalData) fRead / fCompress [code] WARNING - Lua byte functions use US-ASCII encoding, this won't work with numbers above 127 This is an old fixed-width compression format I made that probably hasn't been used or known about since it was originally made a year ago. This will compact data as minimally as possible, but as a result has its limits. This format saves 1, 2, 3, or 4 byte positive numbers. How much data a number takes up depends on how big it *might* be (you have to decide what the highest values will be). 1 byte, max # 256^1-1 = 255 2 byte, max # 256^2-1 = 65535 3 byte, max # 256^3-1 = 16777215 4 byte, max # 256^4-1 = 4294967295 Say you have player={ __wins=1000, __loses=500, __points=100000 } "wins" will probably not exceed 65535, so you can make it 2 bytes "loses" will probably not exceed 65535, so you can make it 2 bytes "points" exceeds 65535, but probably not 4294967295, so you can make it 3 bytes So, we can do playerStatBytes={2, 2, 3} playerStatNames={"wins", "loses", "points"} To save our data saveData=fCompress({player.wins, player.loses}, playerStatBytes) To load our data loadData=fRead(saveData, playerStatBytes) for i, stat in ipairs(playerStatNames) do __player[stat]=loadData end Others I'll probably make a few more for different situations (variable width data, etc.) because it's fun. Will post them here if and when I do. Dernière modification le 1402673520000 |
Fluffyshine « Citoyen » 1398454260000
| 0 | ||
I had no idea how those system.save stuff worked, this will help me a lot! Thanks for your work. :> |
Williamkang 1402345980000
| | ||
[Modéré par Katburger, raison : Unnecessary.] |
Benbirkralm « Citoyen » 1402381260000
| 0 | ||
I participate FluffyShine. Yeah, I know; Lua has got a system.savePlayerData and system.loadPlayerData but I don't know how to use it. Thank you :3 |
Abdeltif « Citoyen » 1402490100000
| 0 | ||
Thanks for the tuto fxie ( and for the functions ) I didin't know how those functions work (system.savePlayerData .. ) but thanks for explaining (Ehm, can you explain the event related to this too ? [eventPlayerDataLoaded]) |
Leafileaf « Citoyen » 1402580460000
| 0 | ||
Abdeltif a dit : When you call system.loadPlayerData, the server takes a little bit of time to process the request and retrieve the data. Thus, when you call system.loadPlayerData, the function just returns nothing. This is to prevent runtime from going too high. When the data is finally at hand, the Virtual Machine calls the function eventPlayerDataLoaded with the playerName and data. |