FOClassic v2

FOnline and FOClassic are now fully open-source projects.

• restored loading of worldsaves and characters created by FOnline r412, and possibly older revisions (depends which file format version is used)
  • support for loading legacy files will be kept only until first change of their format (eg. changing format of worldsave will disable loading legacy worldsave and characters)
  • wordsave/characters files format changes are not planned during migration stage
  • loading has been briefly tested against real server state (thanks Kilgore)
• when checking server status, number of currently connected players is returned instead of characters ingame; this should give more realistic numbers, especially on servers which uses NoLogout maps
• configuration files / command line rework
  • application settings are loaded from disk only once, and cached in memory
  • all command line options has been renamed to use --CamelCase format; those which does not follow this scheme (eg. --some-weird-option) are intended for internal use and might be changed/removed without notice
  • all command line options uses same names as in configuration files
  • Client
    • removed setting UserPass; character password can still be provided by using --UserPass in command line
    • renamed setting FonlineDataPath to DataPath
    • if setting requires changes at runtime (eg. invalid Language in config file), it's done in memory only, without updating config file on disk
    • all boolean settings are false by default
  • Mapper
    • settings moved to Mapper section
    • Client/Server settings can be overwritten in Mapper.cfg, see below
  • Server:
    • settings moved to Server section
    • added setting Languages containing list of all languages supported
      • if Languages list is empty/not set, Language_N is used; it will continue to work until further notice
      • if Languages list is non-empty, Language_N entries are ignored
      • see bottom of changelog for config file fragment
  • settings reading logic
    • application starts, config file is parsed, all settings are stored in memory as strings
    • Client/Mapper: detail section is handled; example for GL application using App as its main section:
      • detail section (AppGL) settings are copied into main section (App) overwriting old entries or creating new ones
      • detail section (AppGL) is removed from memory
      • unused section (AppDX) is removed from memory
    • Mapper
      • Client configuration is loaded and parsed using same logic as in previous point
      • Server configuration is loaded
      • note: as Mapper has been using multiple config files, non-Mapper settings can be now be added inside Mapper.cfg - when loading non-Mapper configuration, setting will not be overwritten during loading step, but they might be overwritten during sections merge step; consider following scenario:
        • Mapper.cfg contains [Client] -> ScreenWidth = 5000
        • Client.cfg contains [Client] -> ScreenWidth = 1000
        • Client.cfg contains [ClientDX] -> ScreenWidth = 2000
        • Mapper loads Mapper.cfg: ScreenWidth = 5000 is used
        • Mapper loads Client.cfg: ScreenWidth = 5000 is used, as such setting already exists
        • Client's detail section is merged into main section: ScreenWidth = 2000 is used
        • making sure that mapper uses correct values can be enforced by either using detail section(s) in Mapper.cfg for non-Mapper settings, or not using detail section(s) at all in Client/Server config files
    • settings in cache are applied to GameOptions
      • default value is applied
      • value in config file is applied, if present
      • value in comand line is applied, if present
      • (integers) value is checked agains allowed minimum/maximum; if it's out of range, default value is applied
    • additional configuration based on setings not stored in GameOptions
    • summary: detail sections, together with sections merging, should allows fine-tuning applications to individual developers needs without need for creating or editing multiple files between playing and developing sessions - that change is affecting Mapper the most, as it have very little own settings
  • main section name is the same as original filename, without any suffix
    • exception: Client still uses Game options, instead of Client, for compatibility with FOConfig; it will be changed in future version together with introducing config tool changes
  • detail sections names are always the same as applications original filenames
• extensions
  • uint8 Critter::Access - const removed
• scripts
  • added global define __VERSION, for compatibility with FOnline
  • int Critter::GetAccess() changed to uint8 Critter::GetAccess()
  • added void Critter::SetAccess( uint8 access ) for changing players access level
    • works for player characters only
    • player_getaccess() is not called
    • custom access level (access > ACCESS_ADMIN) are not allowed to use RunServerScript()
• additional info
  • project has been integrated with AppVeyor service, and configured to prepare (pre)release packages after succesful compilation; that allows anyone interested to use development version of each and all applications without waiting for official releases - which, from this version, will use binaries compiled by external services
    https://ci.appveyor.com/project/rotators/foclassic/
    • binaries can be found under Image: Visual Studio 2013 -> Artifacts; despite of the image name, Visual Studio 2010 is used for compilation
    • Image: Visual Studio 2017 is used for checking if engine is ready for migration to VS2017; it most likely will take some time, so it can be safely ignored currently
    • binaries are available for six month since they have been created; see artifacts retention policy

Server.cfg fragment

# List of all supported languages separated by whitespace; if empty/unset, Language_0/1/... is used
# First language on list is used as default
# Length of each language name must be exactly four letters
Languages = engl russ