001_SYSTEM block

[SYSTEM]

The system block may be easily overlooked but it's actually one of the most important parts of the database. Especially when you play to export the data to systems such as Lua, JSON or whatever you can think of, this block is where it counts.

You simply start the [SYSTEM] block by typing "[SYSTEM]" in the database and start a new line. ;)

Basically all you do is define system variables here. The syntax is the same for all variables:

varname = value

Please note spaces deemed irrelevant will be "trimmed" so that leaves you room for identing or making a "more beautiful look" to these definitions all the more easier. Now note, that only a small set of variables can be set here, all variables MyData doesn't know will simply be ignored in this version (the BlitzMax version throws an error on that). Of course, this can leave you room to create your own set of variables if you were ever to create your own version of MyData, but please keep in mind that I may also add variables in the future to MyData myself and I hope you don't mind that I consider my version the standard, so best is to PREFIX any variables you may need yourself with a UNIQUE prefix.

NOTE: All system variable names are case INSENSITIVE in the Mono version of MyData, and that's what I want them to be in all versions of MyData to come.

Output____Base and Output___Rec

One note is to be made about all variables prefixed with "Output" and suffixed with either "Base" or "Rec". These variables are used by the export routine to determine in which folder to put the target exported files. Please note that MyData will overwrite any existing files mercilessly (assuming it's an outdated file MyData export) whenever modifications require it to do so. Best is to use these folders only for MyData output and not to put any other files in here! "Base" requires an actual file (with full pathname) and MyData will dump the entire database into that file. "Rec" requires a folder and MyData will then create a seperate file for each record in the database. Which method is best? Hard to answer and it depends on your own way of weighting these things. In my RPG games for example, each action a playable character can take in combat contains lots of data, so I decided (to shorten loading times) to only load those in the game the first time a player wants to use them. For this purpose, I made those export to Lua in Rec form so I could load each Lua file when the game actually needed them. However, all worldmap hubs were also set up in MyData, and then they only had to contain a location name, the link to the map file and the starting point and a few other smaller things. Putting all that in small files would not be efficient, at least, I don't think so, and that's why I made MyData export all that data into one big Lua file. I'm pretty sure you can make your own decissions on this one, eh?

If you want to export to Lua you can define that like this:

OutputLuaRec   = /My/Export/Folder/
OutputLuaBase  = /My/Export/File.lua

Outputting to Python just goes the same way:

OutputPythonRec  = /My/Export/Folder/
OutputPythonBase = /My/Export/File.py

When you load a database in MyData which wants to export to a format for which no exporter is yet present you'll get an error message, however MyData won't crash, but the exports will be ignored further on.

Other variables

These are variables the system can use for various reasons:

• License
  • MyData will add a remark to each file it outputs with this license message
  • That is providing the syntax of the export language supports comments (which JSON for example does not).
• AutoOutput
  • If set to "YES" all exports take place automatically
  • This variable has been deprecated for the BlitzMax version, and will therefore be ignored in the Mono version, it's only documented to make sure your database is backwards compatible if you desire.
• RemoveNonExistentFields
  • If set to "YES" all fields without a value will not be exported.
  • JavaScript's class style of working makes it safer though to make JSON exports assign "null" to these variables, which will happen unless you've set NoNull.
• NoNull
  • If set to "YES" any 'null' exports will be ignored. Only a few exports (such a JSON) will require this variable to be set (Most exports don't need this. For example: Lua considers every non-existent field to be 'nil' so the entire export of those and extra config would be pretty useless there).
• EOL
  • By default MyData saves and exports all files in Unix format, meaning that only byte 0A will be used to end lines in the database and exported files. Some Windows text file editors are not compatible with the Unix format which can lead to very very funny results when you use these editors to view the code. If you set this variable to either "DOS" or "WINDOWS" MyData will write the bytes 0D 0A which is the Windows standard.
  • Please note, if you use IDEs to view (or edit) these files (such as Eclipse, Geany, Atom, and many more) I wouldn't bother as regardless if you run Windows or a Unix based system, these editors will be able to handle this anyway. But if you are dealing with very (unsophisticated) tools (like notepad) this can be an issue.
• Hash
  • When set to "ALWAYS" the system will in rec-to-rec output check the hash of the file to output, and overwrite when it differs.
  • When set to "NEVER" the system will just not bother
  • When set to "ASK" the system will ask when the hash differs
  • NOTES:
    • This variable has been put in place in order to keep backward compatibility with the BlitzMax version for awhile, as the BlitzMax version will throw errors when it finds the hashes to check.
    • For now "NEVER" is assumed the standard value, but that is a deprecated setting from the start. In a few years "ASK" will be the default value, and that will be the 'official mark' for the death of the BlitzMax version.