list of extensions

This page is a list of Sword of Moonlight Extension Library extensions by section. Each extension is a named key and value pair belonging in a section following INI format rules.

Extensions

There are some basic style decisions in terms of the extension syntax. The most dominant is extensions which begin with do_ are yes/no (either on or off) extensions. Extensions beginning with do_not_ indicate that the extension normally goes into effect unless disabled. Most such extensions are dependent upon other extensions which must be first enabled. The #Option section includes only do_ extensions which act as a master switch for many extensions (the extensions in the #Detail section are all explicitly tied to the Option section).

Other distinctions exist but should just be picked up upon through personal experience. This page is not a guideline for filling out a so-called Ex.ini file. Nor is it official documentation. Many extensions may be officially undocumented early in their life or perhaps forever, probably with good reason. These extensions can be documented here or elsewhere, but their officially undocumented status should be conveyed to the reader.

Sections

Anything not recognized as an extension is ignored. Normally this is a non-fatal error, however there is an "unnamed" section which exists implicitly before the first section. The only extension recognized inside is C. It may be set to an ISO-639 language code and ISO-3166 country code pair in order to change the locale of the file itself. The default locale is C, named after the C programming language. It is language neutral more or less.

Note: The file itself is Unicode (UTF16) or ANSI. Changing the locale is something a translator might do if they wanted their audience to be 100% comfortable editing the file in a particular language.

The extension library C locale reserves the right to 6 letter ASCII section names with or without numbers immediately appended. Modules may use any other combination of characters.

An asterisk (*) indicates an extension is undocumented (within this page)
A "binary statement" means a representation of 1 or 0. It may be the Arabic numerals 1 or 0, yes or no, on or off, and some additional semantical operations not elaborated upon here.
A "real number" is Arabic digits with an optional decimal point. So named because they are the foil to "imaginary" numbers, even though there is nothing particularly real about a partial number. C style scientific notation will also probably work, but is not recommended.
A "whole number" is Arabic digits no more no less. It can't represent a half of something for example.
A positive real or whole number excludes negative numbers (elusive evil twin anti-numbers).
Unless required to be positive, real and whole numbers can be made negative by adding a single minus (-) sign to the front. Effects may vary.
A "string of text" means anything in your wildest imagination you can type into a text editor.
As for "hexadecimal", see Hexadecimal. Numerals a~f must be lowercase.
A colour is a hexadecimal value (must be lowercase) which can include between 1 and 8 digits. Depending upon how many digits are provided the colour will be interpreted differently. Examples follow.

1 digit colour is one of 16 predefined brushes. The brushes are the same as a Microsoft Window's cmd.exe console.

2 digit colour is 4bit opacity + brush. Opacity ranges from 0 (fully transparent) to f (fully opaque).

3 digit colour is a 4bit RGB colour. Each colour plane ranges from 0 (black) to f (saturated).

4 digit colour is 4bit opacity + 4bit RGB colour.

5 digit colour is not allowed.

6 digit colour is an 8bit RGB colour. Each colour plane ranges from 00 (black) to ff (saturated).

7 digit colour is not allowed.

8 digit colour is 8bit opacity + 8bit RGB colour. Opacity ranges from 00 (fully transparent) to ff (fully opaque).

Adjust

bob_distance_multiplier

Introduced around 1.0.0.1, this extension multiplies the walking effect experienced by the player. Values are limited to real numbers.

draw_distance_multiplier

Introduced around 1.0.0.1, this extension multiplies the draw distance uniformly across maps. Values are limited to positive real numbers.

fog_pullback_factor

Introduced around 1.0.0.1, this extension pulls the fog to the player as the value approaches 1. It is then averaged with #fog_pushback_factor to determine where fog will begin. Values are limited to real numbers.

fog_pushback_factor

Introduced around 1.0.0.1, this extension pushes the fog away from the player arriving at the draw distance when the value reaches 1. It is then averaged with #fog_pullback_factor to determine where fog will begin. Values are limited to positive real numbers.

fog_saturate_multiplier

Introduced around 1.0.0.1, this extension multiplies the distance at which fog becomes fully saturated. Values are limited to positive real numbers.

pov_baseline_in_meters

Introduced around 1.0.0.1, this extension adds to the player's eye level -- as of 1.0.0.1 arms are not yet adjusted accordingly. Values are limited to real numbers.

pov_baseline_in_meters was originally setup for Trismegistus. Trismegistus does away with combat elements, and therefore the arm thing funnily enough was not a problem. Nevertheless the arms are an oversight.

sky_ambience_factor

Introduced around 1.0.0.1, this extension colorizes the sky to match the global ambient light at 1. Values are limited to real numbers.

sky_emissive_factor

This extension is planned but not yet implemented. It will brighten the sky above 1 and darkens it below 1. It's meant to balance out the colours produced by #sky_ambience_factor.

sky_distance_multiplier

Introduced around 1.0.0.1, this extension works like #draw_distance_multiplier, however it only applies to maps with skies. It supersedes draw_distance_multiplier. Values are limited to positive real numbers.

sky_fadeline_multiplier

Introduced around 1.0.0.1, this extension determines a point between the fog saturation distance at 0 and the sky distance at 1 and smoothly blends things beyond that point into the sky. As if the sky is a second layer of fog beyond the first. Values are limited to real numbers between 0 and 1.

Author

Extensions in this section are intended to be filled out by the author. #international_production_title and #international_translation_title are important to fill out. Every full game Ex.ini file should include these. #software_company_name should also be considered.

Sometimes this information may be printed out in places. In a teletype-style display or an "About" window for instance. It's also good to provide the information if possible so people can find it when reading or modifying the Ex.ini file that would come with your game. It can also easily be automatically entered into a database of games or kept on file.

When translating a game into another language it's important to faithfully include all information in this section, and to not translate any of it.

email_address_of_contact

Introduced around 1.0.0.1, this extension indicates the email address of the company or author who is prepared to receive email from any and all parties who have anything to say or ask about the game. Don't fill it out unless you are up to this task. Consider using an account which can safely abandon if the interest in your game becomes overwhelming or undesirable. Values are limited to an email address.

hours_in_which_to_phone

Introduced around 1.0.0.1, this extension indicates the hours you're available to be phoned if you provide a phone number. You can put anything here, indicate your timezone, or anything else. An additional timezone neutral extension would also be helpful however no such thing exists yet. Values are limited to any string of text.

international_production_title

Introduced around 1.0.0.1, this extension indicates the title you want for your game internationally. It should be the title you originally conceived for the game in your language of choice. Though you can use any title. An English title for instance. If you think recognizability is more important. Players may want to translate your game including its title to their own language. Except this title remains the same. Values are limited to any string of text.

international_translation_title

Introduced around 1.0.0.1, this extension is a simplified version of #international_translation_title. It must be entirely composed of ASCII characters and cannot include any characters which might be illegal in file names in some computing environments. In general, be spare with special characters. ASCII includes basic/modern Latin characters only. You can translate your title into a Latin script language of your choice, or reproduce your title phonetically. Values are limited to an ASCII only POSIX and NTFS legal file name.

online_website_to_visit

Introduced around 1.0.0.1, this extension indicates the website for information and other things regarding your game. Values are limited to World Wide Web addresses.

phone_number_of_contact

Introduced around 1.0.0.1, this extension indicates a phone number where you are prepared to receive phone calls in regards to your game. Indicate the region of the world where the number is located. Values are limited to any string of text.

software_company_name

Introduced around 1.0.0.1, this extension indicates the name of the organization responsible for the game. It can be the name of or a pseudonym of the author or the title of a group etc. It will be used for sorting things like the Microsoft Windows Start menu links to your games and the location of keys your game will require in the Windows registry. Values are limited to an NTFS legal file name.

street_address_of_contact

Introduced around 1.0.0.1, this extension indicates where you want to receive mail and or visitors regarding your game. Practice caution in providing this kind of information. Values are limited to any string of text.

the_authority_to_contact

Introduced around 1.0.0.1, this extension indicates who someone should address when phoning or mailing about your game. A secretary, or yourself for instance. Values are limited to any string of text.

Boxart

Extensions in this section convey information about your game. It's not intended to be an exhaustive list of credits. You should limit the information to principal participants, celebrities you'd like to give billing too in order to make your game stand out, or just anyone of relative importance to the production of the game. For a small team there's probably room for everyone. For a mostly "one man" team, consider using #game_auteur in order to credit "the man". Information in this section is used in much the same way as that of the #Author section, however it is never functions in a non-superficial way, and translators are encouraged to translate it where applicable.

Note: you can provide any information you like via a single extension. For instance if there are more than one lead production artist on more or less equal footing, feel free to mention both of them in whatever way makes sense to you.

game_artist

Introduced around 1.0.0.1, this extension indicates the lead production artist. Values are limited to any string of text.

game_auteur

Introduced around 1.0.0.1, this extension indicates the visionary or any one person without which the game just wouldn't exist. Any role not specified will be assumed to fall upon this individuals shoulders. Values are limited to any string of text.

game_based_upon

Introduced around 1.0.0.1, this extension indicates some existing work or art if any which your game is meant to literally draw upon in some way, vividly or darkly. Values are limited to any string of text.

game_caretaker

Introduced around 1.0.0.1, this extension indicates the any domestic worker responsible for keeping the team behind the game on life support throughout its production. Values are limited to any string of text.

game_company

Introduced around 1.0.0.1, this extension indicates the title of the company behind the game. Values are limited to any string of text.

game_concept

Introduced around 1.0.0.1, this extension indicates the lead concept artist. Values are limited to any string of text.

game_dedication

Introduced around 1.0.0.1, this extension indicates who or what you'd like to dedicate the game to. Maybe your goldfish died during production for example. Values are limited to any string of text.

game_designer

Introduced around 1.0.0.1, this extension indicates the lead game design person. Values are limited to any string of text.

game_director

Introduced around 1.0.0.1, this extension indicates the lead game directing person. Values are limited to any string of text.

game_disclaimer

Introduced around 1.0.0.1, this extension indicates any kind of legal liability or whatever you'd like to assuage. Values are limited to any string of text.

game_distributor

Introduced around 1.0.0.1, this extension indicates the distributor of this game. Values are limited to any string of text.

game_edition

Introduced around 1.0.0.1, this extension indicates the edition of this game. Values are limited to any string of text.

game_features

Introduced around 1.0.0.1, this extension indicates any features you'd like to promote. Like joystick support etc. Values are limited to any string of text.

game_first_edition_date

Introduced around 1.0.0.1, this extension indicates the long date of the first edition of this game. Values are limited to any string of text.

game_first_edition_year

Introduced around 1.0.0.1, this extension indicates the year of the first edition of this game. It should be a number in the common era. Values are limited to any string of text; a whole number is best.

game_format

Introduced around 1.0.0.1, this extension indicates the medium or environment, eg. operating system, in which this game is able to function. Values are limited to any string of text.

game_label

Introduced around 1.0.0.1, this extension indicates the promotional/managerial label to which the game or peoples responsible for the game are signed. Values are limited to any string of text.

game_legal

Introduced around 1.0.0.1, this extension indicates any long text legal mumbo jumbo deemed necessary for inclusion. Values are limited to any string of text.

game_license

Introduced around 1.0.0.1, this extension indicates any content or technology licenses the game is in adherence with. Values are limited to any string of text.

game_mascot

Introduced around 1.0.0.1, this extension indicates a pet, personality, or fictional character you'd like to associate the game with. Values are limited to any string of text.

game_music

Introduced around 1.0.0.1, this extension indicates the singular person responsible for the games musical arrangements. Values are limited to any string of text.

game_musing

Introduced around 1.0.0.1, this extension indicates anything at all you'd like to include in addition to everything else. Values are limited to any string of text.

game_original

Introduced around 1.0.0.1, this extension indicates the game which this game is a remake or remix of. Values are limited to any string of text.

game_partners

Introduced around 1.0.0.1, this extension indicates those who bore chief financial responsibility during the development of the game proper. Values are limited to any string of text.

game_planner

Introduced around 1.0.0.1, this extension indicates the lead game planner. Values are limited to any string of text.

game_presented_by

Introduced around 1.0.0.1, this extension indicates the association presenting the game. Values are limited to any string of text.

game_presenters

Introduced around 1.0.0.1, this extension indicates individuals presenting the game. Values are limited to any string of text.

game_producer

Introduced around 1.0.0.1, this extension indicates the game producer, company or individual. Values are limited to any string of text.

game_programmer

Introduced around 1.0.0.1, this extension indicates the lead game programmer. Values are limited to any string of text.

game_project

Introduced around 1.0.0.1, this extension indicates the project codename or whatever before an official title was established or announced. It may be related to the edition of the game as well if the project is a remake or remix effort. Values are limited to any string of text.

game_publisher

Introduced around 1.0.0.1, this extension indicates the lead game programmer. Values are limited to any string of text.

game_publishing_date

Introduced around 1.0.0.1, this extension indicates the long date of this edition. Values are limited to any string of text.

game_rating

Introduced around 1.0.0.1, this extension indicates any kind of content ratings you'd like to apply to the game in whatever rating system seems appropriate. Values are limited to any string of text.

game_region

Introduced around 1.0.0.1, this extension indicates the global region this translation of this game has in mind. Use whatever system or scope makes sense with respect to other translations of the game in circulation or underway. Values are limited to any string of text.

game_series

Introduced around 1.0.0.1, this extension indicates the series this game is part of. Eg. KING'S FIELD II is part of the KING'S FIELD series. Values are limited to any string of text.

game_soundsuite

Introduced around 1.0.0.1, this extension indicates the composer or troop responsible for the sound effects audible in the game. Values are limited to any string of text.

game_soundtrack

Introduced around 1.0.0.1, this extension indicates the composer or troop responsible for the game soundtrack, if there is any one entity. Values are limited to any string of text.

game_studio

Introduced around 1.0.0.1, this extension indicates the name of the studio who developed the game. Values are limited to any string of text.

game_sub_series

Introduced around 1.0.0.1, this extension indicates the series within a larger series in which the game is a part of. Sometimes called a 'gaiden', though not necessarily the same thing. Values are limited to any string of text.

game_subteam

Introduced around 1.0.0.1, this extension indicates the team within a larger studio or collective who is largely responsible for the development of the game. Values are limited to any string of text.

game_subtitle

Introduced around 1.0.0.1, this extension indicates the title that usually appears in smaller letters below the main title. Values are limited to any string of text.

game_suggested_retail_price

Introduced around 1.0.0.1, this extension indicates, whether applicable or not, what you think your game should be sold for on store shelves, or what you would sell it for if you could. Players feel free to regard this value as a suggested donation. Values are limited to any string of text.

game_super_title

Introduced around 1.0.0.1, this extension indicates the title that usually appears in smaller letters above the main title. Values are limited to any string of text.

game_thanks

Introduced around 1.0.0.1, this extension indicates any thanks the game makers would like to confer. Thanks to From Software for instance. Values are limited to any string of text.

game_title_with_sequel

Introduced around 1.0.0.1, this extension indicates the title which includes the sequel number. This title may be shorthand. The sequel need not appear in the main title. It's probably best to render the sequel in Arabic numeral form to avoid any confusion. Values are limited to any string of text.

game_version

Introduced around 1.0.0.1, this extension indicates the version of the game. For instance if the game has been patched or is not intended to ever be finalized. Values are limited to any string of text.

game_writer

Introduced around 1.0.0.1, this extension indicates the lead writer. This is the script writer. Values are limited to any string of text.

game_year_published

Introduced around 1.0.0.1, this extension indicates the year of this edition. It should be a number in the common era. Values are limited to any string of text; a whole number is best.

Bugfix

Extensions in this section correct bugs in the unextended product. Some extensions in other sections may depend upon these extensions and refuse to work otherwise, other extensions may supersede these extensions. How extensions interact is decided on a case by case basis.

do_fix_any_experimental

Introduced around 1.0.0.1, this extension is equivalent to to setting all experimental Bugfix extensions. This will not set undocumented extensions. Values are limited to binary statements.

do_fix_any_nontrivial

Introduced around 1.0.0.1, this extension is equivalent to to setting all nontrivial Bugfix extensions. Nontrivial means the extensions come at some non-negligible performance overhead. Values are limited to binary statements.

do_fix_any_trivial

Introduced around 1.0.0.1, this extension is equivalent to to setting all trivial Bugfix extensions. Trivial means the extensions is negligible or free in terms of performance overhead. Values are limited to binary statements.

do_fix_asynchronous_sound

Introduced around 1.0.0.1, this extension is classified a nontrivial fix. It ensures sound effects are synchronized with the source of the sound. Values are limited to binary statements.

do_fix_clipping_item_display

Introduced around 1.0.0.1, this extension is classified a nontrivial fix. It ensures item geometry as displayed in menus does not intersect geometry that is part of the background in a non-picture menu. Values are limited to binary statements.

do_fix_controller_configuration

Introduced around 1.0.0.1, this extension is classified a trivial fix. It maps the game controller settings in the game's INI file to correct values. Values are limited to binary statements.

do_fix_elapsed_time

Introduced around 1.0.0.1, this extension is classified a trivial fix. It currently hides the elapsed time in the menu screens. It does so because the time is more often than not incorrect. As soon as someone figures out how, it will be made to display the correct time. Values are limited to binary statements.

do_fix_fov_in_memory

Introduced around 1.0.0.1, this extension is classified a trivial fix. It ensures the correct field of view values exist in memory. For example, without this fix, graphics may disappear mysteriously along the edges of the screen under some display resolutions -- it may also be necessary to enable #do_fov in order to achieve this effect. Values are limited to binary statements.

Note: may not work as expected if #do_fov is not enabled.

do_fix_graphics_device_interfacing

Introduced around 1.0.0.1, this extension is classified a nontrivial fix. For example, Sword of Moonlight instantiates a font in memory every time it redraws the screen. This can happen several times a second. This fix manages a pool of GDI resources which are reused wherever applicable and recycled as necessary. This should improve performance and conserve memory. Values are limited to binary statements.

do_fix_lighting_dropout

Introduced around 1.0.0.1, this extension is classified a nontrivial fix. Normally object lighting is turned off if you change display settings in the game menu. This extension fixes that behavior indirectly by doing the equivalent of turning on #do_lights with the number of lamps set to 3. 3 is believed to be the maximum number of lamps Sword of Moonlight will apply to an object. Setting do_lights to yes will supersede this extension. Values are limited to binary statements.

do_fix_out_of_range_config_values

Introduced around 1.0.0.1, this extension is classified a trivial fix. It clamps the possible values in the games INI file to suitable ranges and filters out impossible and or troublesome values. Values are limited to binary statements.

do_fix_oversized_compass_needle

Introduced around 1.0.0.1, this extension is classified a nontrivial fix. Sometimes the compass needle is gigantic compared to the compass. This should correct that, hopefully without any side effects. Values are limited to binary statements.

It is nontrivial because of a slight chance of side effects cropping up in menu elements if mistaken for the needle.

do_fix_slowdown_on_save_data_select

Introduced around 1.0.0.1, this extension is classified a trivial fix... because it's more work not to fix and the fix is relatively simple. In Save/Load menus every time Sword of Moonlight redraws the screen (several times a second) it tries to open 99 files in your save folder. This is hard on any disk, however on a modern hard disk drive you may not notice. On any kind of external storage disk the game will grind to a crawl. The player may not even be able to get out of the game. This extension fixes this behavior. Values are limited to binary statements.

do_fix_spelling_of_english_words

Introduced around 1.0.0.1, this extension is classified a trivial fix. Sword of Moonlight is/was a Japanese product first. Originally it contains some English words which are not always spelled correctly. This extension fixes these instances wherever applicable, so your game should appear more professional to players versed in English. Values are limited to binary statements.

Detail

*alphafog_skyflood_constant

*alphafog_skyfloor_constant

*ambient_contribution

*cursor_presentation_timeout

*lights_ambient_multiplier

*lights_calibration_factor

*lights_constant_attenuation

*lights_diffuse_multiplier

*lights_distance_multiplier

*lights_exponent_multiplier

*lights_linear_attenuation

*lights_maximum_lamp_lights

*lights_quadratic_attenuation

*lights_vs_1_x_unroll_x

*mipmaps_maximum_anisotropy

*mouse_...th_button_action

*mouse_deadzone_multiplier

*mouse_horizontal_multiplier

*mouse_left_button_action

*mouse_menu_button_action

*mouse_middle_button_action

*mouse_right_button_action

*mouse_saturate_multiplier

*mouse_tilt_left_action

*mouse_tilt_right_action

*mouse_vertical_multiplier

*numlock_initial_state

*numlock_key

*pause_button_default

*wasd_and_mouse_mode

Editor

Extensions in this section deal exclusively with the editing tools which authors use to make new Sword of Moonlight games. For the most part other sections pertain to tools only in so far as if and when a tool includes previews of in game elements; extensions affecting the project should apply, however in practice this may not always be the case.

do_hide_direct3d_hardware_devices

Introduced around 1.1.1.3, this extension will hide any hardware accelerated display devices from Sword of Moonlight tools. If there is no pure software device available then there will be a failure to acquire a device. Use this as a last resort when having compatibility problems. Values are limited to binary statements.

This extension is not intended to be necessary under any circumstances. It is a temporary fallback. If you find yourself needing to use it, please report the difficulties you are experiencing to someone who is in a position to resolve your issue.

language_pack_to_use

Introduced around 1.0.0.1, this extension selects a language pack from the text folder; not the lang folder! A language pack in the text folder is normally a compressed .zip archive. It can also be a directory if uncompressed. You should specify the name of the language pack file, without the .zip extension. Values are limited to a legal NTFS file title.

A language pack is a translation (into another language) of the various editing tools which make up Sword of Moonlight. See #Locale for game translation extensions.

Folder

Extensions in this section provide some flexibility to the Sword of Moonlight install/runtime environment.

alternative_data_folder

Introduced around 1.0.0.1, this extension specifies a folder to use in place of the data folder. For editing tools and projects it applies to the install data folder. For a runtime it applies to the game's data folder. Values are limited to a legal NTFS address.

alternative_font_folder

Introduced around 1.0.0.1, this extension specifies a folder to use in place of the font folder. For editing tools and projects it applies to the install font folder. For a runtime it applies to the game's font folder. Values are limited to a legal NTFS address.

alternative_lang_folder

Introduced around 1.0.0.1, this extension specifies a folder to use in place of the lang folder. For editing tools and projects it applies to the install lang folder. For a runtime it applies to the game's lang folder. Values are limited to a legal NTFS address.

alternative_text_folder

Introduced around 1.0.0.1, this extension specifies a folder to use in place of the text folder. For editing tools and projects it applies to the install data folder. A runtime should not include a text folder. Values are limited to a legal NTFS address.

alternative_tool_folder

Introduced around 1.0.0.1, this extension specifies a folder to use in place of the tool folder. For editing tools and projects it applies to the install tool folder. A runtime should not include a tool folder. Values are limited to a legal NTFS address.

do_use_users_saved_games_folder

Introduced around 1.0.0.1, this extension in the affirmative indicates that files generated by the player should be saved to the special folder where Windows saves games. The special folder is different depending upon the version of Windows. For a read only game (eg. a CD-ROM) this extension kicks in automatically and cannot be overridden.

Inside this folder, there will be a folder named after the game, or the software company responsible for the game; in which case the folder named after the game will be inside that folder. In the folder named after the game you will find the save folder and the game's INI file.

As of SomEx.dll ver. 1.0.0.1 this feature is not fully implemented. Future releases should defer to this folder whenever possible in looking for fonts and translation information and any files the player should be able to modify in order to customize their experience. Values are limited to binary statements.

You may use any folder you like in place of the one Windows has established. See #saved_games_folder.

saved_games_folder

Introduced around 1.0.0.1, this extension specifies a folder to use instead of the folder Window's saves saved games to. See #do_use_users_saved_games_folder for details. Values are limited to a legal NTFS address.

Note: this extension takes its name from the "Saved Games" folder introduced by Windows Vista. Ie. it does not map directly to the save folder.

Joypad

Keygen

Launch

Locale

Option

Extensions in this section are generally fairly noteworthy. They act like master switches, usually for fairly major extension complexes. As a rule-of-thumb you can usually fine tune the extensions via the extensions in the #Detail section, which are all named according to the extensions in this section. There are however no actual rules regarding how extensions may interplay with one another, and it is very often the case Option extensions will dictate or interact with extensions found in other sections.

Note: Updating SomEx.dll has a greater likelihood of affecting the effects exhibited by these extensions than with other extensions. As of SomEx.dll ver. 1.0.0.1 it is not possible to indicate the version of SomEx.dll an Ex.ini file is tailored to. A future release will probably make that a reality, however even in such an event there is no guarantee.

Please bear in mind. The wording for most or all of these extensions can be a bit strained because in reality they are directives which give permission to related extensions to go ahead and do what they do. Sometimes the functionality is built in and just needs the go ahead, other times there is no built in functionality and the extension just acts as a permission slip for other extensions. It's handy to think of the Option section like the circuit breaker for the larger extension framework. Most extensions are tied into it, but not all. Many are not.

do_alphafog

Introduced around 1.0.0.1, this extension in the affirmative corrects the blending of fog and other transparent visual elements. As of SomEx.dll ver. 1.0.0.1 in order to blend shadows and fog the shadow textures must be marked for shadow correction (correct=shadow) in the images key. You may mark custom textures this way in order to create your own shadows. See #Keygen for details. Values are limited to binary statements.

do_ambient

Introduced around 1.0.0.1, this extension in the affirmative effects ambient and diffuse lighting. As of SomEx.dll ver. 1.0.0.1 by default it borrows from diffuse light and contributes a proportional amount of ambient light. This generally has the effect of creating more natural lighting, simulating how photons scatter as their energy is absorbed by surrounding materials. Values are limited to binary statements.

do_analog

Introduced around 1.0.0.1, this extension in the affirmative allows for analog play in terms of player movement etc. As of SomEx.dll ver. 1.0.0.1 this is still largely experimental. Mouse controls support analog like behavior but they are bumpy around the edges. The #Joypad section can be used to setup an analog controller which are also bumpy. Without doing so a controller in game will not produce analog behavior. Traditionally analog controls are achieved by feathering the digital inputs. With some smoothing of the players point of view this will probably be a viable option. Another simple technique is to modulate the speed of the player while otherwise offering 8-way digital movement. It's unclear at this point what kind of approach will ultimately amount to the best analog experience. Values are limited to binary statements.

do_anisotropy

Introduced around 1.0.0.1, this extension in the affirmative repurposes the "Texture Mode" setting in the options menu. It will read "Anisotropy" instead. The 3 settings then change the anisotropic filtering state. In order for anisotropic filtering to be effective, #do_mipmaps should also be enabled. Values are limited to binary statements.

do_antialias

Introduced around 1.0.0.1, this extension in the affirmative enables hardware antialiasing if available. You may be able to produce nice screenshots with this extension, the implementation however is not yet final, and therefore cannot yet be recommended for play. Values are limited to binary statements.

do_cursor

Introduced around 1.0.0.1, this extension in the affirmative results in a much more expressive cursor when the mouse is hovered over the game window. This extension is generally recommended for window play. Values are limited to binary statements.

A minimal cursor will appear in window mode even if this extension is not enabled.

do_dither

Introduced around 1.0.0.1, this extension in the affirmative causes a hardware dither effect to be applied in 16bit colour modes. Sword of Moonlight requests (of the graphics hardware/drivers) dithering in 16bpp mode, however almost no modern hardware will accommodate the request. Therefore this extension restores a little piece of Sword of Moonlight lost to the eons. Classic KING'S FIELD games have all been dithered. And the dithering better compliments the 15bit textures which come with Sword of Moonlight. It's arguably better looking than a linear filter which tends to stretch texels out and make the 16bit colours look flat. Print media has used dithering for centuries.

It's recommended you combine this extension with #do_highcolor since that will force all modes into a 16bit colour mode. By default do_dither has no effect when playing in 32bpp (True Color) modes. Values are limited to binary statements.

If anyone would like to supply their own custom dither mask, this kind of feature can be facilitated in short order on demand.

do_fov

Introduced around 1.0.0.1, this extension is a little different. If it's not enabled field of view parameters will probably be the same as what you would expect from Sword of Moonlight. If it is enabled various extensions will make their own judgments about what kind of field of view parameters are acceptable. Enabling also enables field of view override extensions, in case you'd like to control field of view manually. You may need to enable this extension to see any effect from important extensions such as #do_fix_fov_in_memory. Values are limited to binary statements.

do_gamma

Introduced around 1.0.0.1, this extension in the affirmative uses modern shader technology to reproduce the gamma ramps employed by Sword of Moonlight. Reproducing the effect perfectly is computationally fairly expensive. If there is much demand for this extension, in the future the default behavior will probably be to approximate the ramps via a parametric function of some kind. At present there is no extension in the #Detail section to indicate you don't want an approximation. Values are limited to binary statements.

The Sword of Moonlight Extension Library generally speaking always defers to Sword of Moonlight's unextended behavior in lieu of an extension, however this is one of the few cases where doing so is just neither practical nor ideal.

do_green

Introduced around 1.0.0.1, this extension in the affirmative uses the 565 High Color model. 565 means 5 red bits, 6 green bits, and 5 blue bits. This is the model Sword of Moonlight uses in 16bit mode. However the Sword of Moonlight Extension Library uses 555 by default. The extra green bit is said to add a great deal more realism to a picture, however it tends to shift color to the green spectrum, especially at low light levels, resulting in an all around sickly hue, and somewhat psychedelic banding in the lower strata of colors. Its not bad if you want a green hue or more psychedelic coloring. However the textures that come on the Sword of Moonlight compact disc are all 555 like the PlayStation, so 555 color seems like a better fit. It's unclear why the Sword of Moonlight runtimes look for 565, it may have been a more standard or more popular color mode when dithering was commonly implemented in hardware. Modern day hardware has dropped dithering support almost universally, making banding artifacts the norm for older games.

See #do_dither for a dithering extension. And see #do_highcolor for an extension that lets the player choose which mode they prefer. Values are limited to binary statements.

do_hdr

Introduced around 1.0.0.1, this extension in the affirmative enables "High Dynamic Range" lighting. What the opposite means is when you take a perfect white light and shine it on a 3D graphic with a texture applied, the pixels intersecting the graphic on screen can never be brighter than the texture itself. With HDR lighting, the pixels can go over white, meaning a very bright white light will make any texel in the texture that is not perfect black eventually reach perfect white... in other words the colour is not clamped at 1. For a long time color was always clamped at 1 because frame buffers that store video images were assumed to be at most 1 byte per colour channel. 1 byte can be at most 255, which meant perfect white. 255 still means perfect white, except nowadays we can store numbers larger than 255 in memory, so microchips are able to do calculations outside that limited range, and that's what HDR means.

Without HRD lights may interact in very unnatural ways, even by real-time lighting standards. Values are limited to binary statements.

do_highcolor

Introduced around 1.0.0.1, this extension in the affirmative repurposes the "Colors" setting in the options menu. It will read "High Color" instead. 32bpp will no longer be available. The player will get the option of 5:5:5 and 5:6:5, for 555 High Color and 565 High Color respectively.

This setting is generally recommended. Especially in combination with #do_dither. Add #do_anisotropy to give your game a uniform appearance regardless of display settings. Values are limited to binary statements.

do_invert

Introduced around 1.0.0.1, this extension in the affirmative flips the Sword of Moonlight Extension Library brightness model in the following way. Normally the brightness of every pixel is calculated when the pixel is being drawn. Sometimes pixels are drawn many times over, which can be especially problematic for transparent pixels because the brightness tends to double down. When inverted everything is drawn without regard for brightness, then in the end the whole screen is brightened. Menus and other elements meant to be unaffected by brightness changes are darkened so when the screen is brightened they are restored to their original levels.

This extension is generally recommended and should yield better performance if anything performance wise. It does have some side effects which come into play at the ends of the colour spectrum. Mainly when darkened pixels can never be perfectly white, and when brightened pixels can never be perfectly dark. The discrepancy will depend upon the level of the adjustment. Any black mattes will still be perfect black.

A "Deep Color" buffer if available could be used to prevent the loss of information. There is however no extension implementing a deep colour buffer and it might not be worth it unless there were other deep colour extensions already at play. Values are limited to binary statements.

do_lights

Introduced around 1.0.0.1, this extension in the affirmative will take Sword of Moonlight out of the business of object lighting (lamps) completely. This is computationally fairly intensive, however it is generally recommended because Sword of Moonlight is generally not reliable in the object lighting dept. Mainly if the player changes the display settings, object lighting will go way at least until the player crosses over into a new map. This is considered an undesirable bug, in which case the alternative is do_lights. #do_fix_lighting_dropout is a round about way of turning on do_lights and setting #lights_maximum_lamp_lights to 3.

The default behavior of do_lights is to support as many simultaneous lamp lights as necessary. The current hard limit is around 16 per object. The Sword of Moonlight Extension Library currently has no model for knowing or guessing what lights Sword of Moonlight would normally apply to an object, so it just applies all lights that overlap with the object. The lighting will be different if there are many light sources involved. If this produces unnatural results, consider #do_hdr and or adjusting the lighting (see #Details)

The Extension Library decides which lights to turn off and on per object (in reality chunks of pieces of objects) by building a database of bounding boxes which it matches to various characteristics of the objects being displayed. In the future the Extension Library may more and more take over the responsibility of rendering things altogether. In which case some of the database and object recognition business will become obsolete or at least less round about.

In the future there will be unified lighting models where the map pieces are lit with the same lights as the objects. In this future do_lights will apply to map pieces in the same way it does to objects. Values are limited to binary statements.

do_log

Introduced around 1.0.0.1, this extension in the affirmative enables logging. A file will be written to the tool or game folder. For the runtimes for example, db.log would apply to som_db.exe and rt.log to som_rt.exe. Main.log for SOM_MAIN and so on. The same events which would be written to the log in the future will also be sent to the SOM_EX console with or without do_log. You can change the log levels in the #Output section. The log levels apply to console output as well. This extension however refers to writing to files. You can disable console output via #do_console or doing something like log_bar=-1 in the Output section. Values are limited to binary statements.

do_mipmaps

Introduced around 1.0.0.1, this extension in the affirmative generates mipmaps for all textures on the fly. This is generally a very good idea. It's also required if you want to take advantage of the images key (see #Keygen for details). Values are limited to binary statements.

Sword of Moonlight TXR files seem to include mipmap data. However none of the textures which come with Sword of Moonlight do. In general Sword of Moonlight mipmaps look really bad, mainly because anisotropic filtering is not managed. Not having mipmaps is really bad, because its slow and creates "shimmering" artifacts. Having mipmaps without anisotropic filtering is also bad, because the unfiltered mipmaps become infinitely blurry at more oblique angles. Use #do_anisotropy to let the player adjust anisotropic filtering to their preference. It can be a real trade off in terms of performance and quality. Indiscriminate anisotropic filtering can be costly. Unfortunately there is no real practical way to tweak things on a situational basis. You can however use the images key to tweak things on a per texture basis. See #Keygen for details}}

A little trivia, the "Trilinear" texture mode in the options screen actually means a linear filter with a linear mipmap filter.

do_mouse

Introduced around 1.0.0.1, this extension in the affirmative adds a universal mouse to the mix. This mouse is simple to configure via the #Detail section. More sophisticated mouse support is meant to be facilitated via the #Joypad sections. Values are limited to binary statements.

do_pause

Introduced around 1.0.0.1, this extension in the affirmative adds a pause feature to the mix. This extension comes highly recommended. It's a good idea to take advantage of #do_auto_pause_window_while_inactive while you are at it. Values are limited to binary statements.

do_rangefog

Introduced around 1.0.0.1, this extension in the affirmative uses a different kind of fog model which is based on distance rather than depth. Without it the fog at a certain point will appear to change as the player turns around. Values are limited to binary statements.

do_smooth

Introduced around 1.0.0.1, this extension in the affirmative performs a fairly inexpensive kind of smoothing over every pixel on a given screen. Under most circumstances there comes a point where a screen buffer must be copied over the entire screen in order to perform some effects in screen space. Without do_smooth the pixels will be mapped one to one during this copy for a crisp presentation. With do_smooth the pixels will be mapped in the middle, so all pixels will be a blend of their surrounding pixels.

Whether your prefer your vision crisp or smooth, where smoothing really pays off is around objects in the far distance. It creates a kind of "depth of field" effect on the horizon, but more dramatically for spindly things like grass in the distance, the effect adds a kind of fullness which arguably amounts to a more natural rendering. See for yourself. It's a trade-off but the pros usually outweigh the cons. Values are limited to binary statements.

do_sounds

Introduced around 1.0.0.1, this extension in the affirmative ensures that virtually all sound effects are played to completion. Normally Sword of Moonlight will play a very small number of sounds at one time (figure needed) and drop the rest. Currently this extension supports up to 8 instances of a single sound effect being played simultaneously before any sounds of the same sound effect will be dropped.

The limit can be increased if required, however 8 instances of the same sound usually means adding one more will not be distinguishable. However if the 8 instances are far away and the sounds being dropped are nearby a stronger case can be made. Unfortunately prioritizing like sounds according to distance does not really help unless you are willing to allow sounds to be cutoff midway through. Values are limited to binary statements.

do_syncbgm

Introduced around 1.0.0.1, this extension in the affirmative synchronizes background music (BGM) as with sound effects. Note that this extension will probably have no effect if #do_fix_asynchronous_sound is not applied. This is handy if your BGM is meant to correspond to real-time happenings in your game world, or if you want to use timers to determine when music should change. And for the record do_syncbgm recreates the way the BGM works in KING'S FIELD II.

This means menu and message screens will not play BGM. There is currently no extension to play an alternative BGM in menus. You can however play BGM over message screens (for dramatic effect) if you start the BGM in the same event that displays the message. In the future it might be possible to not pause BGM during messages, however doing so would negate the real-time synchronization benefits of the extension. An alternative could be adding more popup messages. No extensions exist for that yet, but one could definitely be added if need be. Values are limited to binary statements.

do_wasd

Introduced around 1.0.0.1, this extension in the affirmative adds "WASD" walking controls to the keyboard as if they were always there (meaning you can then remap them via the #Keymap) and mirrors "PL;'" controls for left handed players. Values are limited to binary statements.

Accessibility features are one of the few non-optional changes imposed by the Sword of Moonlight Extension Library. Ie. some of Sword of Moonlight's keys have been changed around to accommodate left handed players. See Sword of Moonlight Extension Library#Accessibility for more information.

Output

...log_..._bar

Introduced around 1.0.0.1, this extension has a variable syntax and can be specified as many times as necessary. The parts are A_log_B_C_bar where A_ B_ and C_ are optional. The simplest form, log_bar sets the bar which non-debug log events must pass below (less than or equal to) in order to be included in the log or console output.

There is more than one log and more than one bar per log, in fact there are probably hundreds. You can set a particular log's bars via A_. Eg. SOM_MAIN's log is main.log, so main_log_bar will set the bars for only SOM_MAIN. With B_ you can set the bars for events originating in a single "translation unit" or any units which match B_ up to the end of B_; all legal non-alphanumeric characters are treated as underscores. Finally C_ can set particular kinds of bars. Eg. log_debug_bar sets the debug bars only, which is useful because debug bars are unaffected by default. The default setting for bars is 0, except for debug bars which default to -1. Values are limited to whole numbers between +/-65534.

Note: The A_log_B_C_bar syntax is actually shorthand. It has some deficiencies. For example, log_som_debug_bar is ambiguous, because it can mean the debug bars for translation units beginning with "som" or it can mean the "som.debug" translation unit. The match is greedy, so it will mean the latter, and the former will be impossible to specify. A longform syntax has been devised but is not yet implemented as of SomEx ver. 1.0.0.1.

A "translation unit" is a source code object, like SomEx.cpp. SOM_EX should include a comprehensive detailing of logging and console output.

*do_missing_file_dialog_ok

*...function_overlay_contrast

*...function_overlay_eclipse

*...function_overlay_mask

*...function_overlay_tint

Script

*system_fonts_to_use

*fonts_to_use_instead_of_...

System

Window

directx_version_to_use_for_window

Introduced around 1.0.0.1, this extension conveys the version of Direct3D desired for visual presentation stuff. The version is in terms of DirectX versions. It will default to 7 if the number used is incompatible. The recommended setting however is 9, for DirectX/3D 9. 7 is like a safe-mode; graphical extensions are not always implemented or even feasible in 7 mode, and 7 is more likely to have bugs or outstanding issues, because generally speaking it's only ever worked with for completeness sake.

7 is considered an obsolete technology but will likely remain the default for the foreseeable future because it is what Sword of Moonlight uses, and therefore requires the least amount of modification to make things work, and is therefore technically safer, though not necessarily more likely to be glitch free. Values are limited to positive whole numbers.

Other versions may work with debug builds (not normally/easily available to the public) for research and development purposes.

do_auto_pause_window_while_inactive

Introduced around 1.0.0.1, this extension pauses the game automatically whenever the window loses focus. This is generally speaking a highly recommended extension. Most people will want to use this extension, so if not using it causes problems, chances are no one has noticed! Do not use at your own risk. Values are limited to binary statements.

do_center_picture_for_fixed_display

Introduced around 1.0.0.1, this extension prevents scaling which would be done by your display device. Ideally the picture will end up in the middle of your display at whatever resolution your game is set to. It should have no effect if #do_force_fullscreen_inside_window is on. Values are limited to binary statements.

do_force_fullscreen_inside_window

Introduced around 1.0.0.1, this extension makes your game act like a normal "windowed" application. Changes to resolution will not affect your desktop resolution. If the resolution is less than your desktop resolution in both dimensions it will have a window frame. Otherwise it will be undecorated (frameless) with black mattes filling out negative space.

Authors should probably assume that players will prefer this be the case by default. Values are limited to binary statements.

do_force_immediate_vertical_refresh

Introduced around 1.0.0.1, this extension is the traditional "vsync" disabler. Basically the game will just refresh as soon as it can without regard for the state of the display device. This generally results in tearing which some gamers do not so much mind. Their reward is a generally better frame rate, sometimes a ridiculous frame rate, ie. several times greater than is even humanly perceivable. In which case most frames would never even make it to the display device before being replaced by another. Values are limited to binary statements.

Note: some authors may be tempted to enable this for players in order to ensure the best frame rate for their game. You really really don't want to do this. The effects can be very different for different stations and peoples attitudes. Normally players can use their display adapters control panel to force games to play this way if they want to.

do_force_refresh_on_vertical_blank

Introduced around 1.0.0.1, this extension should guarantee that there is no "tearing" due to the game being out of sync with the display refresh rate. Historically video drivers are supposed to guarantee this, but in reality this has become more or less no longer the case. Therefore this extension is generally speaking highly recommended.

Vista Aero does do a good job of not tearing. This extension is mainly for non-Aero play. The current implementation appears to not affect Aero, therefore authors can probably not worry about turning this on indiscriminately for players.

Your game will probably be slower than it normally would be with this on, because the game must wait for the display's "vertical blank" period in order to proceed. Triple buffering scenarios, if available, may out-mode this extension in the future.

#do_force_immediate_vertical_refresh supersedes this extension. Values are limited to binary statements.

do_not_compromise_fullscreen_mode

Introduced around 1.0.0.1, this extension puts the game in exclusive full screen mode. Like games of yore this is how Sword of Moonlight games originally played. There may or may not be any benefit in playing this way. This is not the default behavior of the Sword of Moonlight Extension Library however, because in modern Microsoft windows environments transitioning into this mode tends to very disruptive; usually meaning your monitor will behave spastically for some moments, and if in Vista "Aero" mode you will be kicked in and out of "Basic" mode. Any background apps wanting your attention will cause serious disruptions, and if something goes wrong you might have to restart your computer. In other words, use this one at your own risk. Values are limited to binary statements.

The Extension Library default behavior is to change the desktop resolution to the game resolution and create a full screen spanning window in which to play in. This feels like a full screen experience and is only slightly disruptive. If you want to have your game at a lower resolution than your desktop but want it to fill the entire display this might be what you want. Otherwise you might want to check out #do_force_fullscreen_inside_window.

Note: in the future there will probably be a maximize button extension for window play which will allow you to stretch the game out without ever changing the desktop resolution.

do_not_hide_window_on_startup

Introduced around 1.0.0.1, this extension will force the window to appear immediately. It makes your game feel more responsive on launch, but is usually not very pretty. The default behavior in window mode (and possibly other modes) is to wait until at least one frame is available before revealing the window.

The only problem is sometimes things don't go right and the window never appears. Ideally this only happens in development scenarios. This extensions ensures that this will not happen, however the window is not guaranteed to be responsive, at least there is a visual indicator that an application is running. Values are limited to binary statements.

do_scale_640x480_modes_to_setting

Introduced around 1.0.0.1, this extension prevents Sword of Moonlight from switching into 640x480 mode for intro screens and movies, and possibly in other types of contexts. This behavior is generally not fun. Especially in full screen mode. Almost needless to say, this extension is highly recommended. Values are limited to binary statements.

do_use_interlaced_scanline_ordering

Introduced around 1.0.0.1, this extension might help if you have an interlaced television, or a display that only supports 1080i and not 1080p. It should only do anything if it does anything at all in exclusive full screen mode. See #do_not_compromise_fullscreen_mode. And it will only work on versions of Windows including Vista and later. It requires Direct3D9Ex support. Values are limited to binary statements.

restrict_aspect_ratio_to

Introduced around 1.0.0.1, this extension restricts the aspect ratio, for example 4:3 for standard definition, and 13:9 for (high definition) widescreen. Historically this was used because Sword of Moonlight was designed with 4:3 in mind, and exhibits visual artifacts in any other mode - some even with 4:3 pictures. You can now however use #do_fov and #do_fix_fov_in_memory to eliminate these artifacts, so there's probably no reason to ever use 4:3 again!

The future of this extension is likely to include 13:9 if and when an author desires to build their game strictly around a 720 or 1080 presentation. You might want to do this in order to synchronize movies with in the game visuals or just because your desire total control over how your audience will experience your work. Values are limited to the text string, 4:3.

restrict_frame_rate_to

This extension is currently unimplemented. Once ready it will set a hard speed limit for frame rates.

shader_compatability_level

Introduced around 1.0.0.1, this extension is used to manually control the kind of shader scenarios which are possible. Generally speaking the settings represent degrees of fallback which a player or author would experience if a given shader is incompatible with their computing environment.

0 will force use of the "fixed function" shading framework. This is basically controlled by drivers. It seeks to emulate versions of Direct3D prior to the wholesale adoption of shaders as the only way to do things.

1 will force the built in pixel shaders in versions of Direct3D 9 and up. The default behavior is to use the custom shaders provided by the Som half of SomEx.

2 will use built in vertex shaders along with the built in pixel shaders. 2 is reserved but not currently implemented. It's equivalent to 1 for the time being.

Any number higher that the last defined level is equivalent to not using this extension. More levels may be staked out in the future. This is not an extension which should be deployed by games, but authors are encouraged to use it in order to see what their games will look like if everything does not go smoothly for the player shader support wise.

This is extension is mainly used by developers in order to work on the fallback shaders. Values are limited to positive whole numbers.

shader_model_to_use

Introduced around 1.0.0.1, this extension conveys the desired DirectX "shader model"; see Shader#Models. At present 3 and 2 are available. Support for 1 would be ideal, but due to its highly deprecated nature, this has proved so far elusive. If you set it to a higher model number than what is possible, the next lowest model will be used and so on. In other words, if 3 is not available, 2 will be used if available.

Authors should consider setting this to the highest shader model number with which they are personally familiar. You can set it even higher or leave it unset, but you don't know for sure what the results might be for your game once the higher model numbers becomes available. The default behavior is to start with the highest model number available to the display device.

Generally speaking, built in extensions try to accommodate all models whenever possible. Custom shaders provided by authors or modules are not required to be so rigorous. Authors should test what their games will look like with different shader models. Values are limited to positive whole numbers.

window_title_to_use

Introduced around 1.0.0.1, this extension is the final authority in regards to what will appear in the game window's caption text. If not provided explicitly the Sword of Moonlight Extension Library will try to come up with its own title based on a longish list of candidate places to look.

Markup is allowed in this title. As of SomEx.dll ver. 1.0.0.1 only <fps/> is supported. For example, wherever <fps/> appears in the title the current (averaged) frame rate (frames per second) will be printed instead. The plan for the future is to add some basic stats so a player could play without any "heads up display" elements if so desired. Values are limited to any string of text.