Core Architecture: Major System: File IO - UA-ScriptEase/scriptease GitHub Wiki

The bureaucracy is expanding to meet the needs of the expanding bureaucracy.

  • Unknown (but best read by Leonard Nimoy in Civilization IV.)

File I/O in ScriptEase II is a broad topic that interacts with several other concepts. That said, there are three major types of files that ScriptEase interacts with.

  1. ScriptEase data files
  2. Game files
  3. Miscellaneous resource files

The bulk of this document will be talking about ScriptEase files. For details on files from a particular game, see that game's specific translator page.

ScriptEase Data

ScriptEase data includes Stories, Libraries, and two types of Dictionaries, detailed below. All ScriptEase data is written in XML and these methods are accessed through scriptease.controller.io.FileIO. Stories and Libraries both have XML Schema Documents (XSDs) that define the file format and those XSDs are stored in the resources directory.

Style Rule: Use XML elements to store actual data, and XML attributes to store metadata (ie. hints on how the reader should proceed) Why? Because that's what they're for.

Stories (.ses)

These are the specific game adventures that the game designer is building. They must never contain code or anything that is general enough to be stored in a translator or library. We want to keep the option open for the ability to swap out a translator on a particular story and have as much as is reasonable function correctly in the new game. For example, taking a story from Neverwinter Nights and migrating it to Neverwinter Nights 2 would ideally be just changing the translator it is referencing.

Libraries(.sel)

Libraries are a storage mechanism for patterns, common items that the source of what the designer can choose from. The API Dictionary dictates a baseline for what's available in as a library, but there may be a feature one day of storing common Cause-Effect or Quest Point structures in a user-defined library.

Dictionaries (.ses)

These are the code-related chunks of a Translator. See API Dictionary and Language Dictionary pages for more on each file.

Resource Files

The bulk of ScriptEase's data is stored in the files above, but there are other resources that it accesses from time to time.

Configuration file (scriptease.ini)

This and the user preference file both use the Java properties file format. This is meant to store installation configuration settings, like where the ScriptEase error-reporting server is or where to look for translators. These properties should not be set per user, and they are for mission-critical data. If they are missing or broken or otherwise wrong, there is no default - they are the default.

User Preferences (user_preferences.ini and default_preferences.ini)

This and the configuration file both use the Java properties file format. As I'm sure you're astutely deducted, user_preferences.ini stores the particular preferences for that user, while default_preferences.ini stores the default template for those preferences. The default file is kept in the jar, while the user-specific file gets created when ScriptEase first runs. Unlike the configuration file, the user file can (and should) be stored in the user's home-directory.

Art

Sometimes you just ... icons. Sometimes.

Internationalization (i18n)

ScriptEase isn't entirely been geared towards Internationalization, but it's been started. With a small bit of work on the code side, it would be completable. The translation would take a while, though. Essentially, each string that gets shown in the GUI would need to be an entry in the I18nResources_<locale_code>.properties file. Instead of GUI classes storing the displayed text constant strings, they store a key and look up the display text in the internationalization file. Translators haven't been designed with this in mind, but it would be feasible to make it work.

Accessing Files when running from a JAR

Common symptom: Can't find a file that is clearly there. I mean, seriously. You are looking right at it. Why is Java being such a dunderhead?!

Cause: Running in a jar makes Java sandbox it somewhere, so it doesn't look in the correct location.

Accessing a file when in a jar is a tricky thing. When we develop, it runs ScriptEase on the raw .class files, not packaged in a jar, which is fine for development. However, when creating a distributable Jar file, we've got a slight problem: files in the jar you're running in isn't part of the file system. To get a file from either the file system or within your running jar, look at FileOp.getFileResource().