Feature_Request_Theme_User_Data

Table of Contents Per-Theme User Data User Data Behavior Some thinktank of other possible (read: optional) features

Per-Theme User Data

This page is a work-in-progress brainstorm of ideas/requirements for theme-based user data.

Key/Value store: Key is always a string. Value can be an integer, boolean, string, or array (LUA table).
LUA Frontend: themers should be able to retrieve data through an extension of PROFILEMAN's exported LUA API. Examples: PROFILEMAN:GetUserData(PLAYER_NUM, "Experience_Stats"), PROFILEMAN:SetUserData(PLAYER_NUM, "Experience_Stats", stats)
static format: data on the backend will be stored on the memory card under UserData/<theme></theme>.xml where <theme></theme> is a sanitized FS-friendly version of the theme name. XML is used so that data is merely parsed and not ran under a LUA VM, which would open up the possibility for exploits.
Since this means that more data will have to be loaded from the memcard, support for theme user data will be a choice for the machine owner. A preference CustomProfileData will be used to determine if the machine supports loading and using user data. Themes should be responsible for checking this setting if it's not supported by the backend.
- TODO: theme name collisions (i.e. recolors keeping the name of the theme to "default")?

The theme/LUA subsystem ("The Frontend") requires only two functions: one for storing and one for retrieving values on a key basis.
All data is stored in the backend under the Profile class. The frontend is not required to explicitly keep track of any data on its own.
Data is committed to the memcard upon saving the profile (a.k.a. after the game is over for the player).

IncrementUserData(PLAYER_NUM, Key) -- under the assumption that the data stored as Key is an integer
Global User Data
- Accessible to all themes
- Would have its own separate API functions