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 "string of text" means anything in your wildest imagination you can type into a text editor.
A "language and country code pair" is an ISO-639 language code and ISO-3166 country code pair. For example Sword of Moonlight's pair is ja_JP for Japanese in Japan.

As of 1.1.2.1 a "number" has a special meaning. Refer to SomEx/list_of_numbers and #Number. Additionally a number must be able to be reevaluated continuously. Meaning it can change at any time. It is a 32bit floating point value subject to calculations. Each extension places an upper and lower limit on its accepted values, and has a default behavior in case the number is a not-a-number value. Extensions can be further subdivided into the following older categories:

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).

A few extensions have been reclassified as numerals or numeric codes as they are not subject to continuous reevaluation.
As for "hexadecimal", refer to Hexadecimal. Numerals a~f must be lowercase. Note: that these values no longer meet the requirements of #numbers.
A "hexadecimal color code" is a hexadecimal value (must be lowercase) which can include between 1 and 8 digits. Depending upon how many digits are provided the color will be interpreted differently. Examples follow.

1 digit color is one of 16 predefined brushes. The brushes are the same as a Microsoft Window's cmd.exe console.
2 digit color is 4bit opacity + brush. Opacity ranges from 0 (fully transparent) to f (fully opaque).
3 digit color is a 4bit RGB color. Each color plane ranges from 0 (black) to f (saturated).
4 digit color is 4bit opacity + 4bit RGB color.
5 digit color is not allowed.
6 digit color is an 8bit RGB color. Each color plane ranges from 00 (black) to ff (saturated).
7 digit color is not allowed.
8 digit color is 8bit opacity + 8bit RGB color. Opacity ranges from 00 (fully transparent) to ff (fully opaque).

A "keyboard key" is a context insensitive Direct Input Key code. Extended codes also exist; including ~~ANALOG, JUMP, CORKSCREW, DASH, DUCK, and JOG~~ no longer. Extended codes must first be assigned to one or more of the #Keymap, #Keypad, #Button, or #Joypad extensions. The codes can be a 2 digit hexadecimal number or the ASCII identifier with the DIK_ part not included.
A "keyboard macro" is a context sensitive combination and or sequence of #keyboard keys as described above. A complex macro syntax has not been forthcoming. Consequently only context-free single code macros can be described by the INI file for the time being. A keyboard macro can also be an alias. Refer to the #Action section for details.
A "pseudo button" is a whole number greater than zero (0) representing the buttons on a human interface device or a virtual button when the number exceeds the number of buttons on a device. Game controllers use the Direct Input numbering shown in the Windows Control Panel. Non-button features, analog sticks and point-of-view hats for instance, are assigned pseudo buttons. Pseudo buttons are assigned keyboard macros.
A "synthetic font" is a description of a hybrid font constructed out of one or more typefaces assigned to one or more Unicode character ranges. At present when there are multiple typefaces they must be separated by commas. A typeface has four parts separated by spaces. Each part is optional.

The first part is a scale factor in the form of a percentage. It must be a positive whole number including a percent sign, ie. 120% scales the typeface by 120 percent.
The second part is a number between 0 and 1000 that specifies the weight (or boldness) of the typeface. Sword of Moonlight uses 1000 or maximum boldness for its MS Mincho fonts.
The third part is the name of a font. The name is embedded in a font file. Usually a file has more than one name per font stored in the file. For non-English non-Unicode fonts there is often an ANSI name using the native language of the font as well as an ASCII name. Names are sometimes permitted to be incomplete also. The name can be placed in double (") or single (') quotes to resolve ambiguities just in case, however it is probably unnecessary to do so, even if the name has spaces in it.
The fourth part maps the typeface to one or more Unicode character ranges. It looks like U+0000-007F. In this example the typeface is mapped to characters 0 through 127 or the ASCII character range.

An "identifier" is a number that uses SomEx/list_of_numbers#id to encode one or more integer identifiers. Base 256 identifiers are commonly used to encode 24-bit/8-bits-per-component True Color values. These differ from extensions that accept a "hexadecimal color code" in that the color cannot contain an "alpha" opacity component, and that its value can be changed in real-time; for instance by a game's internal logic. For example, id(255,0,0) expresses a pure red color. Note that all three numbers must be present, as the base is not explicitly expressed in this example. Refer to id.

Action

Main article: action extensions

Extensions in this section take the form of an arbitrary string of text on the left of the equal (=) sign and a keyboard macro on the right.

The usefulness of this is three-fold:

To define and or declare keywords in a single place to be substitutes for keyboard macros that would appear elsewhere in the INI file.
To be able to redefine an action and have the new definition automatically propagate throughout the file(s). Note that if you were to do a "Find and Replace" operation with a text editor, keys have different semantics in different contexts, and so the operation could easily have undesirable side effects.
To attach in-game semantics to the keys of the keyboard. For example: Attack=LSHIFT attaches an "Attack" semantic to the the left Shift key.

If an Action keyword appears to be a keyboard macro the interpretation is undefined. In other words, it could go either way, so make sure that that does not happen.

Authors use the #Keymap section to establish a keyboard layout for their games. A player uses the #Keypad section to customize the keyboard for play. Technically other input devices, game controllers, computer mice, are configured by way of mapping buttons and other features to the keyboard inputs. In other words no device is able to do anything that cannot be done with the keyboard.

Adjust

Main article: adjust extensions

Restructuring of [Adjust]

The old version of this section is available here[1]. Many extensions changed with SomEx ver. 1.2.0.8.

The map setting extensions were combined into the fov_ group and simplified as much as possible.

The pc_..._speed_multiplier group was removed. See the #Number section for how to directly set the _WALK, _DASH, and _TURN constants.

The pov_baseline_adjustment extension was replace by #player_character_stature.

The sway and bob_..._multiplier extensions were removed along with do_sway. The sway can now be directly set by #player_character_bob2 however bob_frequency_multiplier is still awaiting its replacement.

The menu and onscreen display element ..._opacity_multiplier extensions were removed. The ..._opacity_adjustment extensions need to reproduce the math taking into account the incoming opacity values.

abyss_depth

Introduced around 1.2.0.8, this extension establishes the depth below a map tile that cannot be passed upon penalty of death, ie. game over. By default it is -10. This replaces abyss_event_adjustment. Values are limited to real numbers.[#]

2017 note: Does Som2k work this way? In practice the -10 death point rarely triggers and or may only apply to tile types that are marked as special "pits."

blackened_tint...

Introduced around 1.1.1.5, this extension replaces the color of the black tint that is a backdrop for text and menus. The default value is 80000000, or half black. Note that there is a second black tint that is applied over the first black tint. Refer to #blackened_tint2. Values are limited to hexadecimal color codes.[#]

blackened_tint2 Introduced around 1.1.1.5, this extension replaces the color of the second layer of black tint. Refer to #blackened_tint. The default value is 64000000, or quarter black. Note that this is the tint that is used by #do_pause when the game is paused. Values are limited to hexadecimal color codes.[#]

blue_flash_tint

Introduced around 1.1.1.5, this extension replaces the color of the blue flash that is triggered by in game events. The default value is ff0000ff, or pure blue. Note that the flash begins fully opaque and then tails off. The blending mode is not based on the alpha component, but the color is divided by the alpha component as a courtesy, and if the color is fully transparent, the flash will not appear. Values are limited to hexadecimal color codes.[#]

character_identifier

Introduced around 1.2.1.14, this extension generates custom character identifiers to be used as parameters to other extensions and to be included by pc. This number receives an input (a parameter) that is encoded by id. These are default identifiers. The purpose of this extension is to remap and or combine identifiers.

Historically Sword of Moonlight segregates would-be characters into four classes. These classes are enemy, NPC, object, and PC. Unless this segregation is by some method obliterated, then this extension will receive a two-part number to be decoded by 4096di and 4097di in order to obtain a SOM_PRM item number and character class, respectively. Class number 0 is enemies; 1 NPCs; 2 objects; 3 the PC.

There is a second parameter that is the SOM_MAP content identifier, which may be used to further specialize character identifiers.

The PC's number is 12288, since their item number is 0. In a multi-PC scenario this extension could, for example, take a counter into consideration. Values are limited to real numbers.[#]

fov_fogline_saturation

Introduced around 1.2.0.8, this extension overrides the color of the level's fog. As of 1.2.0.8 there isn't a way to retrieve the current level's fog parameters, so if this extension is used the fog's color setting in SOM_MAP should be disregarded. Values are limited to base 256 identifiers.[#]

fov_fogline_adjustment...

Introduced around 1.2.0.8, this extension specifies the beginning and effective end of the fog. When the part after adjustment is omitted, the starting point of the fog is specified in terms of meters. Note that in SOM_MAP this is represented by a fraction of the way to the back of the fog; not so here. The unadjusted value is provided.

fov_fogline_adjustment2 specifies the end point of the fog. If the level does not have a sky/backdrop then the in game scene shall comes to an end at this point. The unadjusted value is provided. This value is equivalent to SOM_MAP's per map visibility setting. Refer to #fov_skyline_adjustment2. Values are limited to positive real numbers.[#]

fov_frustum_multiplier

Since 1.2.0.8 the default is 1.2. The default will revert back to 1 as soon as this makeshift extension is no longer of general use.

Introduced around 1.1.1.5, this extension multiplies the horizontal angle of what is visible to Sword of Moonlight in game. It can be game dependent, but you may need to increase this (from 1) to create gutters along the sides of the field of vision if you notice map tiles disappearing (along the sides) especially when moving quickly with analog controls. Generally the higher the turn speed the more you might need to lean on this. Note that this is not a fix for problems of this nature in widescreen mode. See #do_fix_fov_in_memory (or #do_fix_any_trivial) in that case. Values are limited to real numbers.[#]

This can also be a means to work with map tiles that have "eaves" far outside of 2x2 meters (the natural size of a single tile) however generally speaking this is not recommended in terms of best practices.

fov_sky_and_fog_minima...

Introduced around 1.2.0.8, this extension is expressed as a fraction of the end of both the fog and the sky/backdrop so that it should cover the same amount of pixels at any given distance. By default it is 0.025 and cannot be made less that this. This is to ensure that there is always a soft transition where the end of the fog and sky blend into the scenery. The sky transition is dependent upon #do_alphafog, which is also enabled by #do_fog. Values are limited to real numbers between 0.025 and 1.[#]

fov_sky_and_fog_minima2
Introduced around 1.2.0.10, this extension is available to set the fog minimum independent of the sky/backdrop minimum. If not explicitly set, it is identical to #fov_sky_and_fog_minima. Values are limited to real numbers between 0.025 and 1.[#]

fov_sky_and_fog_powers...

Introduced around 1.2.0.10, this extension exponentiates the sky/backdrop and fog. By default it is 1, or linear. Values around 0.5, or the square root, produce a sharp cutoff along the fog horizon, and so are not recommended. Values above 1 create an ever thicker fog. At present this extension must be set to a constant value, and so values between 0.75 and 1.5 are recommended. Furthermore it only applies to per pixel fog using the recommended custom Sword of Moonlight "shaders". Since 1.2.1.8 the fog exponent can be set independently of the sky/backdrop's with fov_sky_and_fog_powers2. (1.2.1.8 corrects a bug that reversed the values in the "shader.") If it is not explicitly set it is identical to #fov_sky_and_fog_power. Values are limited to positive real numbers.[#]

fov_skyline_adjustment...

Introduced around 1.2.0.8, this extension specifies the beginning and effective end of the sky. When the part after adjustment is omitted, the starting point of the sky is specified in terms of meters. The unadjusted value is provided. Note that by default the start of the sky is equal to the end of the sky.

fov_skyline_adjustment2 specifies the end point of the sky. If the level does not have a sky/backdrop both fov_skyline_adjustment and fov_skyline_adjustment2 should be disregarded. Otherwise #fov_fogline_adjustment2 cannot be greater than fov_skyline_adjustment2 and so will be scaled back if necessary. Refer to #fov_sky_and_fog_minima. Values are limited to positive real numbers.[#]

green_flash_tint

Introduced around 1.1.1.5, this extension replaces the color of the green flash that is triggered by in game events. The default value is ff00ff00, or pure green. Note that the flash begins fully opaque and then tails off. The blending mode is not based on the alpha component, but the color is divided by the alpha component as a courtesy, and if the color is fully transparent, the flash will not appear. Values are limited to hexadecimal color codes.[#]

highlight_opacity_adjustment

Introduced around 1.2.0.8, this extension adjusts the opacity of the flashing menu paneling. The unadjusted opacity is supplied. Values are limited to real numbers between 0.06 and 1.[#]

hud_gauge_depleted_half_tint

Introduced around 1.1.1.5, this extension replaces the color of the gauges when emptied. The default is unspecified, as of 1.1.1.5 it is 55808080. To emulate Sword of Moonlight you can use a value of 00 to make only the filled portions of the gauges visible. Values are limited to hexadecimal color codes.[#]

The depleted gauges were needed by #do_st to emulate Shadow Tower. It is simpler to just leave them as a permanent fixture. Plus it just looks nice.

hud_gauge_opacity_adjustment

Introduced around 1.2.0.8, this extension adjusts the opacity of the HUD (heads up display) gauges. Note that the emptied halves of the gauges are unaffected. Refer to #hud_gauge_depleted_half_tint. The unadjusted opacity is supplied. Values are limited to real numbers between 0 and 1.[#]

lettering_contrast

Introduced around 1.1.1.5, this extension replaces the color of the in-game text's "shadows". The default color is 464646. Partial transparency is not supported as of 1.1.1.5. Refer to #lettering_tint. Values are limited to hexadecimal color codes.[#]

What this actually does is recolor text that is the color of Sword of Moonlight's shadows. Refer to #system_fonts_contrast and #status_fonts_contrast.

Tip: this is the only way to change the default color for dialogue text and subtitles. Just avoid making the system and status fonts the same color and you can recolor all three independently.

lettering_tint

Introduced around 1.1.1.5, this extension replaces the color of the in-game text. The default color is dcdcdc. Partial transparency is not supported as of 1.1.1.5. Refer to #lettering_contrast. Values are limited to hexadecimal color codes.[#]

What this actually does is recolor text that is the color of Sword of Moonlight's text. Refer to #system_fonts_tint and #status_fonts_tint.

Tip: this is the only way to change the default shadow color for dialogue text and subtitles. Just avoid making the system and status fonts the same color and you can recolor all three independently.

npc_shadows_modulation

Introduced around 1.2.0.8, this extension scales the opacity of the NPC-style shadows. By default it is -1 (note: not 1; positive values are reserved for per red, green, blue factors) and if set to 0 the shadows will be invisible — however DO NOT DO THIS as a way to hide the shadows. Use #npc_shadows_multiplier instead so that you might benefit your frame rate. Values are limited to negative real numbers.[#]

npc_shadows_multiplier

Introduced around 1.2.0.8, this extension scales the NPC-style shadows. By default it is 1. To disable these shadows it's correct to set this extension to 0. Refer to #player_character_shadow. Values are limited to positive real numbers.[#]

npc_shadows_saturation

Introduced around 1.2.0.8, this extension overrides the color of the NPC-style shadows. By default it is id(0,0,0) or 0 or black. Values are limited to base 256 identifiers.[#]

paneling_opacity_adjustment

Introduced around 1.2.1.14, this extension adjusts the opacity of the menu paneling. The unadjusted opacity is supplied. Historically this value is always 0.5. Values are limited to real numbers between 0 and 1.[#]

red_flash_tint

Introduced around 1.1.1.5, this extension replaces the color of the red flash that is triggered by in game events. The default value is ffff0000, or pure red. Note that the flash begins fully opaque and then tails off. The blending mode is not based on the alpha component but the color is divided by the alpha component as a courtesy, and if the color is fully transparent, the flash will not appear. Values are limited to hexadecimal color codes.[#]

Sword of Moonlight displays this flash if the player character receives damage in order to elicit a sensation of pain from the player. If interested in modulating this effect, refer first to #do_red.

start_blackout_factor

Introduced around 1.1.1.5, this extension changes the way the title screen options are masked. As the value approaches 1 the transparency effect is replaced by a darkening effect. This is especially useful if the title screen is not a flat color behind the text. Note that as of 1.1.1.5 the title screen elements, pushstart.bmp etc., have black pixels knocked out like every other texture. Values are limited to real numbers.[#]

If you are considering your options. It is recommended that you first see if #do_start is implemented or not (it is not as of 1.1.1.5) and use that if so. It simply uses text in place of images. Text is much less work for translators to deal with. It is not clear how or if start_blackout_factor will interplay with do_start.

start_tint

Introduced around 1.1.2.?, this extension replaces the color of the start menu text or image. Refer to #do_start. Values are limited to hexadecimal color codes.[#]

Analog

Main article: analog extensions

This section is available since 1.1.1.6.

Caution: as of 1.1.1.8 it is recommended that this section not be present in the Ex.ini file so that everything will be figured automatically. Refer to #error_clearance. That said, defaults assume human walking speeds. Refer to #error_impedance and #error_allowance.

Extensions in this section fine tune so-called "analog" settings. This section does not pertain to computer mice and game controllers or analog input devices in other words. Sword of Moonlight itself is digital. It only has one speed. The analog extensions do not exceed this speed, however other extensions may adjust the speed itself independently.

Half speed is achieved by taking every other opportunity to take a step. Just as some 3rd party game controllers would pause and unpause a game quickly to create the illusion of playing in slow motion. Finally the picture the player sees is not the picture Sword of Moonlight has of itself. The Extension Library shows the player an analog picture. You can think of this picture like a dog on a leash.

error_allowance...

Introduced around 1.1.1.6, this extension takes a small fractional number in meters. Any deviation outside of this figure is accounted for. Any deviation inside of this figure is ignored for purposes of correcting for error. The default is 0.02 meters. If a means is ever found for automatically determining an ideal value this extension will be obsolete.

The purpose of this extension is to counteract a small whiplash effect which sometimes occurs as a movement comes to a stop. Instead of a whiplash the movement will simply stop once the deviation is accounted for. Ideally you want to minimize the number while preventing the apparent whiplash. Neither condition is ideal.

Values in the range of 0.01 and 0.02 are recommended. It may be possible to go lower or necessary to go higher dependent upon movement speeds and other factors. This extension applies to linear movements only. Refer to #error_allowance2. Values are limited to positive real numbers.[#]

error_allowance2 Introduced around 1.1.1.6, this extension takes a small fractional number in radians and applies to rotational movements only. Values in the neighborhood of 0.04, or about a couple degrees, is as good a place as any to start. The default is 0.04 radians. Refer to #error_allowance. Values are limited to positive real numbers.[#]

error_clearance

Caution: as of 1.1.1.8 it is recommended that this extension not be set, or set to 0, so that it is automatically figured based on the walking speed.

Introduced around 1.1.1.6, this extension takes a fractional number in meters. Any deviation outside of this figure fully counteracts walking effects. You can determine this number using the F6 function overlay. Press perpendicularly against a square wall as far as you can and then allow the player character to come to a rest. Subtract the two positions from one another to arrive at an approximate value. The default value is an arbitrarily large number. If a means is ever found for automatically determining an ideal value this extension will be obsolete. This figure must be larger than #error_tolerance. Values are limited to positive real numbers.[#]

error_impedance...

Introduced around 1.1.1.8, this extension corrects for error. The default is 8. Error is introduced when the player character's movement from point A to point B is obstructed by an obstacle. The error is the difference between where the player character is and where they would be if not for the obstacle. In other words, correction prevents the character from getting away, in a graduated way.

The greater the impedance the more quickly the correction will kick in and vice versa. The separation at the limits of the correction is a function of #player_character_shape and the dimensions of the game's picture as if shot by a virtual camera lens and projected onto the player's video display.

At extreme walking speeds the leaning, or push, into obstacles can appear unnatural or glitched. If so, adjusting this figure may be of help. This extension applies to linear movements only. Refer to #error_impedance2. Values are limited to positive real numbers.[#]

error_impedance2 Introduced around 1.1.1.8, this extension corrects for error in rotational movement. The default is 4. You want some error to make motion graduated. Higher numbers result in quicker error correction, and vice versa. There is always a small amount of error present, however for rotation, what correction boils down to, is how quickly the view bounces back when automatically centered or pushed beyond #player_character_nod. Refer to #error_impedance. Values are limited to positive real numbers.[#]

error_parachute

Introduced around 1.1.1.6, this extension takes a fractional number in meters to be subtracted from the vertical component of the error calculation. The default value is 0. Larger values help to sustain the walking effects per #error_clearance when scaling an incline; especially while dashing.

Note that it is desirable for walking effects to be affected by inclines to some degree. Very small values result in the player character sliding down (and up) slopes (as if falling) while moving at high speeds. Values are limited to positive real numbers.[#]

error_tolerance

Caution: as of 1.1.1.8 it is recommended that this extension not be set, or set to 0, so that it is automatically figured based on the walking speed.

Introduced around 1.1.1.6, this extension takes a fractional number in meters. Any deviation outside of this figure begins to gradually counteract walking effects. This figure must be smaller than #error_clearance but not so low that moving about freely interferes with the walking effects. Half is as good a place as any to start. The default value is an arbitrarily large number. If a means is ever found for automatically determining an ideal value this extension will be obsolete. Values are limited to positive real numbers.[#]

Author

Main article: author extensions

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_production_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

Main article: boxart extensions

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 differs in that the information provided is merely superficial and translators are encouraged to translate the information where applicable.

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 publisher. 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

Main article: bugfix extensions

As of 1.1.1.7 some extensions in this section are switched on by default. Refer to #do_fix_any_vital.

Extensions in this section address software bugs that afflict games that use the original Sword of Moonlight debug and release game programs, som_db.exe and som_rt.exe. Projects are tested with som_db.exe. Games use som_rt.exe renamed GAME.exe. When using the Extension Library with a standalone game a BIN file in the EX folder takes the place of som_rt.exe. The BIN file is treated as if it is identical to the last version of som_rt.exe released by From Software.

Note: if the Bugfix section is absent from all of the INI files involved the new default behavior, as of around 1.1.1.5, is to fix every bug. However in practice some fixes may slip through the cracks, therefore it is still recommended that you include a Bugfix section along with #do_fix_any_trivial and #do_fix_any_nontrivial in your projects.

Tip: about 1 out of 10 bugs affecting the game program(s) are represented here in the form of extensions. It would be nice to have documentation for every single bug addressed, but it is probably already too late for that. Bugs are given consideration for extension on the basis of controversy, notoriety, complexity, performance concerns, and potential and or unknowable side effects.

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_any_vital

Introduced around 1.1.1.7, this extension is equivalent to to setting all vital Bugfix extensions. Vital means the extensions are switched on by default because the bugs they address are either crash prone, may interfere with extension, or resource intensive, eg. attempt to access 100 files or create and destroy a font resource every 15 or so milliseconds! You can switch these off if you want to experience the bugs for yourself. Values are limited to binary statements.[#]

do_fix_asynchronous_input

This fix was classified nontrivial prior to 1.1.1.7 (it's actually really trivial.)

Introduced around 1.1.1.6, this extension is classified a vital fix. It fixes a bug that can disable input when picking up items and saving the game at save points. Usually the bug just makes input very difficult. Sometimes the bug is barely if even noticeable. It is not well understood but it seems to depend on various timing factors which can depend on the game and the player's computer.

This fix also addresses a, likely unrelated yet very similar, bug affecting games with polling, or "always on", events where for each event the game will query the inputs (keyboard and game controller) and needlessly update the game to reflect the inputs an additional time. It is not known to what extent this behavior is detrimental to the game. However minimal (or not) it is easy to imagine how this can complicate extension. Extensions (should be robust, but) should not account for interaction with this bug. Values are limited to binary statements.[#]

Note: this extension is new and not exactly a precision fix. It just seems to work for everyone who has tried it so far. Regardless this fix is being considered for mandatory inclusion.

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_boxed_events

Introduced around 1.1.1.7, this extension is classified a trivial fix. Without this fix events associated with objects (ie. not items or NPCs) with a 3d box (ie. not a 2d cylinder) shape that are triggered by pressing the SPACE #keyboard key, or "Action" button, use the height of the box where the depth ought to be used. Values are limited to binary statements.[#]

do_fix_clipping_player_character

Introduced around 1.2.0.6, this extension is classified a trivial fix. It, among other things, adds ceilings to the list of things the player character (PC) is not permitted to pass through. Sword of Moonlight (2000) generally neglects to do this.

A whole host of other clipper issues are included in this fix, not limited to: making objects behave like MHM polygons (of which the world is generally made of), including giving them a buffer, correcting for the round edges around boxes, considering them while the PC is climbing, and sorting objects for climbing; fixing the places where sloping MHM polygons meet flat ground MHM polygons so that the PC does not sink into the ground; making upside down slopes (basically arches) behave better; standardizing the climbing height when climbing two or more objects or MHM polygons; and preventing climbing where there is nothing to grab hold of. Values are limited to binary statements.[#]

Core extensions depend on this fix. A few of these are jumping, clinging, auto-squatting.

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_damage_calculus

Introduced around 1.1.2.2, this extension is classified a trivial fix. It works around bugs and bug-like logical inconsistencies in the classical Sword of Moonlight damage calculus by instituting replacement default formulas for hit-point damage resolution and stat based bonuses to hit-point attack and defense ratings. Refer to #Damage. Values are limited to binary statements.[#]

do_fix_elapsed_time

Introduced around 1.0.0.1, this extension is classified a trivial fix. Prior to ver. 1.1.1.3 this extension hid all of the clocks in the menus from the player. After 1.1.1.3 a fully functional clock can be achieved by somehow adding a counter named "Ex" to the project (if need be, such a counter can be added by editing the SYS.DAT file) otherwise the clocks will be hidden. In fact 1.1.1.3 goes further and hides the clocks in the save/load menus. 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_fov is deprecated as of ver. 1.1.1.5)

do_fix_lifetime_of_gdi_objects

This fix was classified nontrivial prior to 1.1.1.7.

Formerly do_fix_graphics_device_interfacing up to 1.1.1.7 (it took some time to brainstorm the wording.)

Introduced around 1.0.0.1, this extension is classified a vital 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

This fix was classified nontrivial prior to 1.1.1.7.

Introduced around 1.0.0.1, this extension is classified a vital 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.[#]

do_fix_widescreen_font_height

Introduced around 1.1.1.5, this extension is classified a trivial fix. For whatever reason the creators of Sword of Moonlight decided that the height of fonts should be proportional to the horizontal resolution. Circa 2000 we used more or less square CRT displays, so no one would have noticed the preposterousness of this decision and or oversight. CRTs turned out to be a 20th century thing. Nowadays displays are almost always widescreen; so this extension simply flips the formula around to accommodate any and all screens, and may or may not also entail additional adjustments such as the centering of text. It is recommended for readability sake. Values are limited to binary statements.[#]

do_fix_zbuffer_abuse

Introduced around 1.2.0.8, this extension is classified a trivial fix. Historically the depth/z-buffer is reset (it has as many elements as there are pixels onscreen) twice per screen, and thrice if the swinging arm avatar is onscreen, and four times if #do_fix_clipping_item_display is in use and an item is displayed. This isn't a bug per se, but it is provided here as an extension for documentation purposes. This fix causes the z-buffer to be reset once at the top of the animation frame. The avatar and item display share a small partition in the front of the z-buffer, that can result in overlap. The second reset seems to be completely unnecessary, potentially related to the sky model, which isn't always present, even though the reset always occurs. The third reset is especially problematic since it can pull the frame rate down when the avatar appears on screen. Overall this should improve performance and may allow GPU chip drivers to make certain optimizations. Values are limited to binary statements.[#]

Button

Main article: button extensions

This section is available as of 1.1.1.6.

Extensions in this section take the form of a #pseudo button on the left of the equal (=) sign and a #keyboard macro on the right. This section can be used to assign actions to the buttons of the game controller when not using #Joypad sections. Game authors may use this section to prioritize functions provided by extensions such as #do_pause and #do_escape, or just add arbitrary buttons to assist in testing their games. Players may use it to manually set their buttons and or put buttons 9 through 16 of their game controller to use.

More actions can be assigned to 0, 9000, 18000, and 27000, corresponding to the controller's first point-of-view hat. Refer to #pseudo_pov_hat_....

Note: that buttons 1 through 8 are configured by Sword of Moonlight in game. If you assign actions to them the in-game configuration for that button will be ignored. Authors should not do this on behalf of players because PC game controllers are all very different.

Pause & Select by default

Some time ago buttons 9 and 10 were assigned to PAUSE and ESCAPE respectively. They must be reassigned in order to change this behavior. PAUSE pauses a game. ESCAPE changes the analog mode, or escapes out of menus. 10 is a "select" button on many controllers. This makes that button select the analog mode, making it easier for players to discover its functionality. Refer to #do_pause and #do_escape.

XInput note for Xbox devices

Xbox style controllers have analog trigger buttons that need to be moved into DirectInput positions 7 and 8 so they are among the buttons that are configurable in the classical game menu. Unfortunately this means buttons 7 & 8 must be moved up by two, to the 9 & 10 positions; and so any higher buttons must also be moved up. As of 1.2.1.14 only 4 buttons are moved, so to cover PlayStation's L3 and R3 buttons. More buttons are not envisioned.

Damage

Main article: damage extensions

This section is available since 1.1.2.2.

Extensions in this section govern "damage". Which boils down to a kind of sport, often a virtual blood sport in violent video games. You basically have a tit-for-tat until one side falls or loses.

In a classical game of Sword of Moonlight the player wields weapons with different damage ratings, and monsters have built in "attacks" that are analogous to these weapons which may be mitigated by various pieces of armor worn by the player. Monsters have built in defenses. Blows are exchanged. Each time so-called hit points are rewarded until one side can bear no more and loses the game.

Where P is hit-points, and Q is the hit-point offset, or defense. The classical formula for calculating damage is equal to max(0,P-Q)+inf(P*P/(Q*2),0) and the new formula per #do_fix_damage_calculus is P-max(0,Q-P*P/(Q*2)). In both cases the result is clamped to the range [0,infinity]. The inf is a bug in the classical formula based on undefined behavior. The value of infinity arises when Q is 0. Becoming 0 when converted to an integer representation.

In the example above, in the case of the player, P and Q are subject to bonuses that are a function of the player's "stats" or characteristics such as Strength that accumulate over the course of a game as the player repeatedly performs certain actions. The classical bonus formula is Strength/5. However if P is 0 the bonus is 0. For Q the bonus is not zeroed out. The new bonus formula per do_fix_damage_calculus is P or Q*(Strength/#player_character_weight).

Finally do_fix_damage_calculus also factors in the scale of the player and monster. For monsters this scale is set when placing the monster onto its game map. For players the extension #player_character_scale is consulted. So when computing P where S is the scale, and weight is 50, P becomes P*(Strength/50)*S.⁺

⁺Prior to 1.2.1.14 the formula had been P*(1+Strength/50)*S in keeping with being a strict bonus. Ever since it is geometric, so that no "strength" equates to no "damage." This change is first and foremost to let NPCs and PCs draw from the same pool of "magical" effects, since NPCs may be less efficacious.

Since 1.2.1.14 most "damage" sources can have the two "stats" traditionally related to Strength and Magic. In these cases, the #do_fix_damage_calculus formula uses the value 50, that is the default of #player_character_weight, only so that there is a standard scale. In order to replicate this or do otherwise pc is amended to include a character_identifier.

do_not_harm_defenseless_characters

Introduced around 1.1.2.2, this extension in the affirmative protects passive non-player characters from the attacks of aggressive non-player characters aimed at a player character. It does not protect the character from player character born attacks. Values are limited to binary statements.[#]

Word of warning, because SOM segregates "enemies" and "NPCs" and "objects" scenarios might choose to make destructible elements out of NPCs. In that case, this easy fix can make progress impossible. An alternative fix is to identify said objects (by ID) in the final damage calculus.

hit_handicap_quantifier

Introduced around 1.1.2.2, this extension quantifies the final "hit point" damage. It accepts one input parameter: the aggregated sum of #hit_outcome_quantifier per each exchange. The default behavior is to round 0 up to 1 not changing anything otherwise, or not(1_,1).

The pc variable refers to the defender. Values are limited to positive real numbers.[#]

Note: that if the output is 0 the stun animation is not triggered. In other words a 0 output exchange appears to miss its mark.

hit_offset_quantifier...

Since 1.2.1.14 hit_offset_quantifier defers to #hit_point_quantifier so it can be omitted where equivalent.

Introduced around 1.1.2.2, this extension quantifies the second input parameter of #hit_outcome_quantifier. It has three input parameters of its own: the damage rating of a character's defenses, a modifier associated with evasive maneuvers, and the affinity index of the damage rating; this number is 0 for the first rating, 1 for the second, and so on. Up to 7.

The default behavior depends on #do_fix_damage_calculus. Refer to the opening remarks of #Damage for details.

The default behavior of #hit_offset_quantifier2 is to defer to hit_offset_quantifier. Its function is dependent upon #hit_point_mode. However by default it is used for secondary ratings. By default these are ratings 4 through 8; traditionally associated with "magical" elemental forces: fire, water, and so on.

The pc variable refers to the defender. Values are limited to positive real numbers.[#]

hit_outcome_quantifier

Since 1.1.2.2 there is a bug that rendered this extension useless: it had clobbered the previous rating with each in succession.

Introduced around 1.2.1.14, this extension quantifies the damage done by a single damage rating. It accepts three input parameters. The first comes from #hit_point_quantifier. The second comes from #hit_offset_quantifier. And the third is the affinity index of the damage rating. Refer to hit_point_quantifier for details.

The default behavior depends on #do_fix_damage_calculus. Refer to the opening remarks of #Damage for details.

The outputs are converted to integer magnitudes⁺ (absolute value) clamped to the range of [0,65535] to be summed together per damage rating. This sum is then inputted into #hit_handicap_quantifier in order to arrive at the ultimate "hit point" damage to the defending character.

⁺Since 1.2.1.14 negative outcomes are understood to be damage (HP lost.) Outputs should be either always positive or always negative, depending on what is preferred or natural, unless they can go either way. (To be clear, positive outcomes are also HP lost; HP is never gained.)

The pc variable refers to the defender. Values are limited to real numbers.[#]

hit_penalty_quantifier

This extension did not make it into 1.1.2.2. It is to govern damage born of residual factors; poisons for example.

hit_point_mode

Introduced around 1.1.2.2, this extension augments the behavior of #hit_point_quantifier and #hit_offset_quantifier. The default is 0. The default behavior is unspecified. Historically the default behavior is identical to 1. The behavior of 1 is to use #hit_point_quantifier2 and #hit_offset_quantifier2 for ratings 4 through 8. Classical Sword of Moonlight aligns these with "magical" elemental forces.

The behavior of 2⁺ is to use hit_point_quantifier2 and hit_offset_quantifier2 for indirect exchanges. Values are limited to numerical codes.[#]

⁺Prior to 1.2.1.14 the built-in formulas had not implemented mode 2.

hit_point_model

This extension did not make it into 1.1.2.2. It is to be used to select from a menu of alternative damage models. The simplest kind of model is +1, which says to shift the the dividing line between primary and secondary, aka. physical and magical, damage ratings up by 1 so that the fourth rating is changed from secondary to primary (in this example.)

hit_point_quantifier...

Introduced around 1.1.2.2, this extension quantifies the first input parameter of #hit_outcome_quantifier. It has three input parameters of its own: the damage rating of a weapon or more broadly speaking an "attack", a modifier used by #hit_offset_quantifier, and damage rating index; this number is 0 for the first rating, 1 for the second, and so on. Up to 7.

The default behavior depends on #do_fix_damage_calculus. Refer to the opening remarks of #Damage for details.

The default behavior of #hit_point_quantifier2 is to defer to hit_point_quantifier. Its function is dependent upon #hit_point_mode. However by default it is used for secondary ratings. By default these are ratings 4 through 8; traditionally associated with "magical" elemental forces: fire, water, and so on.

The pc variable refers to the attacker. Values are limited to positive real numbers.[#]

Detail

Main article: detail extensions

Extensions in this section complement those of the #Option section. Each Option extension takes the form do_..., where each Detail extension takes the form ..._... where the first parts (...) are identical to one another. If the Option extension is switched off the corresponding Detail extensions have no part to play.

alphafog_skyflood_constant

Since 1.2.0.8 this setting need not be "constant". It is due to be changed.

Introduced around 1.0.0.1, this extension is part of an effect that blends the horizon into the sky domes that are part of Sword of Moonlight. The sky is fully transparent at #alphafog_skyfloor_constant and becomes fully opaque as the vertical distance from the floor approaches 1 in sky model coordinates.

This constant can be thought of as scaling the sky along the vertical axis, so that the larger the scaling the slighter the gradient. The default value is 8.

~~Note that internally this value simply sets a shader preprocessor macro that is used by the default shader set~~. Values are limited to real numbers.[#]

Note: in order to fully disable this effect it is necessary to set this extension to a value of 0. Recall that the default behavior is particular to Sword of Moonlight sky domes. Care must be given to custom sky models.

alphafog_skyfloor_constant

Prior to 1.2.2.8 this setting is unable to be set because its minimum value had been mistakenly set to positive infinity. Since 1.2.0.8 this setting need not be "constant". It is due to be changed.

Introduced around 1.0.0.1, this extension is part of an effect that blends the horizon into the sky domes that are part of Sword of Moonlight. The default value is -0.125 or the lowest point of the sky domes. Any part of the sky below this point will be made completely invisible as it blends into the horizon. Refer to #alphafog_skyflood_constant.

~~Note that internally this value simply sets a shader preprocessor macro that is used by the default shader set.~~ Care must be given to custom sky models. Values are limited to real numbers.[#]

ambient_contribution

Introduced around 1.0.0.1, this extension sets the percentage of a lamp that is converted from diffuse to ambient light. The default percentage is not specified. Historically it is and has been 0.15, or 15%. This is unlikely to change, however it doesn't hurt to set this manually, even if 15% is alright with you. Some caution should be observed. Refer to #do_ambient. Values are limited to real numbers between 0 and 1.[#]

cursor_hourglass_ms_timeout

Introduced around 1.0.0.1, this extension establishes the number of milliseconds that a game may be "unresponsive" before an "hourglass" icon will be made to appear to indicate that the game is working behind the scene.

The default value is 0. Which is converted into an internal default timeout that has historically been fixed at 250ms, or a quarter of a second. You might need to use a larger value if the icon is a nuisance. Values are limited to positive whole numbers.[#]

Note that the game may or may not be working or may only be partially working. The real intent is to make the game appear responsive to put the player at ease and stop the Windows "not responding" protocol.

dash_jogging_gait

Introduced around 1.1.1.7, this extension establishes the dashing gait used when the player character is said to be jogging. The default gait is 3, or 50% speed. Once jogging the power gauge refills after a period of #tap_or_hold_ms_timeout during which the higher gaits up to but not including the final gait coalesce onto the jogging gait.

This gait also happens to be used when dashing sideways with a depleted power gauge. Similarly backwards dashing is a function of dash_jogging_gait minus dash_jogging_gait-1-dash_stealth_gait, or 1 by default. Otherwise jogging refers to forward movement only. Values are limited to whole numbers.[#]

The Caps Lock key is available for digital input devices, eg. keyboards and simple game controllers. Caps Lock is mapped to button 10 by default. In this mode the player will jog when the SPACE #keyboard key, or "Action" button, is pressed.

dash_running_gait

Introduced around 1.1.1.7, this extension establishes the dashing gait used when running. The default gait is 5, or roughly 70% speed. The player character is said to be running when moving forward at the maximum input gait, or 7, with an empty power gauge. Ie. no longer dashing. Values are limited to whole numbers.[#]

dash_stealth_gait

Introduced around 1.1.1.7, this extension establishes the dashing gait used when moving discreetly. The default gait is 0, or 1/6th speed. Gaits numbered 0 and below (0, -1, -2, etc.) are lower than the lowest gait available to analog controllers.

Dashing gaits below the jogging gait are available for precision movements. In this mode the power gauge drains just as if running until dash_stealth_gait is entered on empty. Like jogging and running this gait refers to forward movement only, however it also happens to be factored into backwards movement. Refer to #dash_jogging_gait. Values are limited to whole numbers.[#]

The Caps Lock key is available for digital input devices, eg. keyboards and simple game controllers. Caps Lock is mapped to button 10 by default.

Tip: it is recommended that there be at least two stealth gaits so that attentive players are able to see (or hear) when they have entered the gait neighboring the jogging gait and react accordingly.

escape_analog_gaits

Introduced around 1.1.1.5, this extension calibrates the sensitivity of Sword of Moonlight's game controller. Note that this extension is overshadowed by #Joypad sections. Refer to #..._analog_gaits.

This extension has 7 parts that must be separated in a way that is unambiguous. Any part not specified defaults to: 0.2, 0.333333, 0.5, 0.666666, 0.75, 0.875, and 0.95 respectively. This is a perfect linear mapping. A game controller may use a nonlinear mapping. In example, a DualShock controller is very biased; .2 .25 .3 .4 .55 .75 .95 gives a greater sense of control over its sticks by flattening out the windows between the gaits.

Note that this is not a mechanism for calibrating imbalance or fighting in a stick. That is done with the Windows Control Panel calibration feature.

The first and last numbers in the series are unique. An input below the first number is ignored. This is important because sticks usually require a wide "dead zone" so not to appear cocked when left still. An input above the last number is taken to be full tilt. A calibrated stick should achieve full tilt. An expanded window lessens the need to force a stick to full tilt.

If a number is less than or equal to the number before it results are undefined. The option to merge gaits will be visited at a later date. Values are limited to series of real numbers between 0 and 1.[#]

escape_analog_modes

Introduced around 1.1.1.5, this extension describes the modes available to #do_escape. The defaults are uz, enabling a single analog mode equivalent to Sword of Moonlight's axis based movement controls; moving forward and backward and turning left and right. The non-axis based movement controls are button based; moving sideways and looking up and down.

An analog mode can be up to eight (8) letters long comprised of x, y, z, u, and v, denoting lateral, vertical, forward and backward, turning, and looking movement respectively. Each letter can be capitalized, X, Y, Z, U, and V, in order to invert the axis. However it is not necessary to add an additional mode solely to invert the looking movement, as inverted look modes will be generated automatically.

The letters correspond to axes of the game controller. An axis can be knocked out using a dash (-) place holder. So to add a 2nd and 3rd (automatically generated inverted) mode uz, xzuv-v is a start. These modes should add a dual thumb stick set-up compatible with most DualShock like controllers and adapters that the player can access by pressing the Esc (escape) key once in game. Values are limited to series of analog modes as described above.

Note: in the future #do_system will be required to bypass the new system menu which will make the "Analog Mode" approach obsolete for all but the most stubborn and curious. In the meantime this extension is absolutely essential to beginners and avid players will want to familiarize themselves with the #Joypad section.

g

Introduced around 1.1.1.7, this extension sets the game wide gravity constant. The default is 9.8, meters per second per second, or Earth like gravity. Where the instantaneous velocity is equal to g times the time spent in freefall. Values are limited to real numbers.[#]

lights_lamps_limit

Introduced around 1.?.?.?, this extension establishes the maximum number of lamps per lit element. The default is 0; Which is interpreted to mean as many lamps as is both practical and possible. Values are limited to positive whole numbers.[#]

log_initial_timeout

Introduced around 1.0.0.1, this extension sets the number of refresh frames to log to a log file before logging is no longer performed. This is a diagnostic tool. A log file can grow very large and logging can make a game unplayable under different circumstances. The default setting is 0. The default behavior is to log until manually disabled. Refer to #log_subsequent_timeout. Values are limited to positive whole numbers.[#]

log_subsequent_timeout

Introduced around 1.0.0.1, this extension sets the number of refresh frames to log whenever logging is manually enabled before automatically disabling logging. The default setting is 0. The default behavior is to enable logging until manually disabled. Refer to #log_initial_timeout. Values are limited to positive whole numbers.[#]

mipmaps_samples_limit

Formerly mipmaps_maximum_anisotropy prior to 1.1.1.6

Introduced around 1.0.0.1, this extension takes the maximum number of anisotropic filtering samples. The default is 0. This will use the maximum number of samples supported by the video adapter. Use 1 to disable anisotropic filtering. Note that when #do_anisotropy is switched on players are able to directly set this up in the Options menu. Values are limited to positive whole numbers.[#]

mouse_...th_button_action

Introduced around 1.0.0.1, this extension assigns an action to any additional buttons that a computer mouse may support beyond the standard left, right, and middle buttons. The part before th_button_action must be a number between 4 and 8 distinguishing the 4th, 5th, 6th, 7th, and 8th button respectively. Values are limited to keyboard macros.[#]

mouse_deadzone_ms_timeout

Introduced around 1.1.1.6, this extension counts the number of milliseconds that computer mice may be left still within the "dead zone" before the mouse position is returned to the center of the dead zone. Refer to #mouse_deadzone_multiplier. The default value is 0. Which is converted into an internal default timeout that has historically been fixed at 250ms, or a quarter of a second. Values are limited to positive whole numbers.[#]

mouse_deadzone_multiplier

Introduced around 1.0.0.1, this extension multiplies the inner region of what is conceptually a virtual mouse pad that acts like a thumb stick of a game controller that does not pull itself back to center. Any movement within the "dead zone" is treated as free-looking. Once the virtual mouse leaves this region it behaves exactly as a thumb stick does so that you can turn without having to pick the computer mouse up off its mouse pad and place it back in the center over and over and over...

The dead zone is 50% of the area, which itself is 100% of the size of the game window. Refer to #mouse_saturate_multiplier. Values are limited to real numbers between 0 and 2.[#]

Note that as of 1.1.1.5 when certain antagonistic movement keys are pressed together (either with the keyboard or by way of the game controller configuration) the mouse will center itself either horizontally or vertically in the dead zone. Vertical centering will change the player character's perspective. Horizontal centering will not be noticed when inside the dead zone. Holding the horizontal centering combo creates a temporary 100% dead zone area so that free-looking is not interrupted. This feature still requires some work before the keys can be pressed together without timing becoming an issue. Still it is pretty handy and sure beats nothing.

mouse_horizontal_multiplier

Introduced around 1.0.0.1, this extension multiplies the sensitivity of the computer mouse with respect to side to side motion. Negative numbers also invert the motion. Values are limited to real numbers.[#]

mouse_left_button_action

Introduced around 1.0.0.1, this extension assigns an action to the left computer mouse button. If the player has indicated they are left handed the action may or may not be swapped with the #mouse_right_button_action. Values are limited to keyboard macros.[#]

mouse_menu_button_action

Introduced around 1.0.0.1, this extension assigns an action to take when the left and mouse buttons are held down together for a short period of time. If #wasd_and_mouse_mode indicates a one-handed control scheme this button may be assigned a default action. Otherwise the default action is to do nothing. Values are limited to keyboard macros.[#]

mouse_middle_button_action

Introduced around 1.0.0.1, this extension assigns an action to the middle computer mouse button. Note that not all mice will feature a middle button and when present the button can be combined with a wheel making it comparatively more awkward to utilize. Values are limited to keyboard macros.[#]

mouse_right_button_action

Introduced around 1.0.0.1, this extension assigns an action to the right computer mouse button. If the player has indicated they are left handed the action may or may not be swapped with the #mouse_left_button_action. Values are limited to keyboard macros.[#]

mouse_saturate_multiplier

Introduced around 1.0.0.1, this extension multiplies what is conceptually a virtual mouse pad with the same dimensions as the game window with the goal of producing a one-to-one relationship between the computer mouse and in-game motion. Refer to #mouse_deadzone_multiplier, and #mouse_horizontal_multiplier and #mouse_vertical_multiplier. Values are limited to positive real numbers.[#]

mouse_tilt_..._action

Introduced around 1.0.0.1, this extension assigns an action to a feature many computer mice have in the form of either an additional wheel or the ability to nudge the mouse wheel to the left and right. The part before _action must be one of left or right. Note that Windows' handling of this feature is very limited. It is essentially restricted to scrolling text sideways in such a way that is very very clunky in any other context. That said you can work with it. You can even move sideways with it if you don't mind the lurch. Values are limited to keyboard macros.[#]

mouse_vertical_multiplier

Introduced around 1.0.0.1, this extension multiplies the sensitivity of the computer mouse with respect to up and down motion. Negative numbers also invert the motion. Values are limited to real numbers.[#]

numlock_status

Introduced around 1.1.1.6, this extension determines the Num Lock status at start-up when #do_numlock is switched on. Values are limited to binary statements.[#]

red_multiplier

Introduced around 1.1.1.5, this extension multiplies the intensity of the red flash effect when the player character receives damage. Maximum intensity is reached when an NPC attack deals 50% damage. For example, if 25% damage is considered a critical hit then you will want to set this to 2. Note that a Game Over hit is always displayed at maximum intensity. Refer to #red_flash_tint. Values are limited to real numbers.[#]

st_margin_multiplier

Introduced around 1.1.1.6, this extension multiplies the margin around the #do_st onscreen elements. The default margin is half of the font's height. Values are limited to real numbers.[#]

st_status_mode

Introduced around 1.1.1.6, this extension changes how the "Status Display" onscreen elements are arranged. The default is 0. No default behavior is specified. Mode 1 places HP in the top-left corner and MP in the top-right. Mode 2 trades the places of mode 1. The places are subject to reversal by any extension that results in the player character being left handed. Values are limited to 0, 1, or 2.

start_mode

Introduced around 1.1.2.14, this extension changes the text and behavior of the start menu. Mode 0 emulates Sword of Moonlight. Mode 1 emulates King's Field on the PlayStation. Modes 2 and 3 do likewise emulating the sequels. Mode 4 emulates Shadow Tower. The default mode is 2, however when combined with #do_st the default mode is 4. The addition of future extensions that are like do_st will affect the default mode. Values are limited to 0 through 4.

Mode 3 has no "START" prompt text, so it is bypassed. Mode 1 has no text whatsoever, so a new game is begun every time, after which the player can load a saved game to continue on if they so choose.

All mode text except for mode 2 is English in all caps. Mode 2 text is translated by #do_use_builtin_english_by_default. At present it is not possible to translate this text via the game script file (the eventual implementation is likely to repurpose the messages' plural-forms.)

Mode	*built-in English (Mode 2)
0	PUSH ANY KEY	NEW GAME	CONTINUE
2	ＳＴＡＲＴ	はじめる	ロードする
*	START	Begin	Load Game
3		NEW	CONTINUE
4	PUSH START	NEW	LOAD

u2_hardness

Introduced around 1.2.0.10, this extension eliminates smoothing when used with #do_u2. By default it is 0, or full smoothing. As it approaches 1 smoothing is completely eliminated. Smoothing is performed over gait transitions as a function of time. Values are limited to real numbers between 0 and 1.[#]

u2_power

Introduced around 1.2.0.10, this extension exponentiates turning and looking speeds with respect to the analog gaits when used with #do_u2. This permits fine movements with an analog controller that would not be possible with a strictly linear mapping. By default it is 1.5. 1 is strictly linear. 2 is the linear gait squared. Gaits range from 0 to 1 such that the fastest gait squared is still 1. Because the gaits are fractional numbers, squaring them yields a smaller number, ever smaller with each successive lower gait. Values are limited to real numbers between 1 and 2.[#]

wasd_and_mouse_mode

Introduced around 1.0.0.1, this extension determines the default configuration of the "WASD" key group on a Qwerty keyboard and computer mouse. There are two modes, one (1) handed, and two (2) handed. If #do_mouse and #do_wasd are both in play the default mode is two handed. If not the default mode is one handed.

One handed is ideal for puzzle games that won't involve combat or high stakes action. A free hand can also be less stressful in a game's development stage. Mice with only three buttons may require further configuration to be truly one handed.

Basically one handed modes always use turning movements where two handed modes will use sideways movements. One handed uses the mouse buttons to move forward and backward and does not use the attack and magic buttons. There are other differences in terms of how spare buttons get prioritized, all of which are subject to change. Values are limited to 1 or 2.

Editor

Main article: editor extensions

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.

assorted...

Introduced around 1.1.2.3, this extension complements #sort_.... Profiles that were not sorted into categories are listed towards the end of the menus in SOM_PRM. With this extension a heading may be applied to these unsorted, or assorted, profiles. The part after assorted may be an underscore (_). Refer to #sort_.... Values are limited to any string of text.[#]

black_saturation

Introduced around 1.2.2.2, this extension is established mainly so end-users may change the contrast levels of text that is overlaid onto background and button graphics. By default the text appears as pure black text over pure white text, separated by 1x1 pixel offsets. The effect is pleasing if monitors have control over "sharpness" and are not set to be overly sharp. Otherwise, reducing the contrast by making black more gray and or white less brilliant is facilitated by black_saturation and #white_saturation, if and when reducing sharpness is either not possible or not desirable.

The color can be made different for buttons by examining the first parameter, that is "NaN" (not-a-number) for background text, and not-so for button text. This parameter might indicate the button's graphic, or it might not; in which case it is the number 0. Historically button graphics are darker than background graphics, and so might benefit from increased contrast.

These extensions can also be used to experiment with novel themes via the "theme and language package" framework. The functionality is limited right now, but will be expanded to meet demand as it is an appropriate application of these extensions. Values are limited to base 256 identifiers.[#]

clip_volume_multiplier

Introduced around 1.1.1.3, this extension scales the clip volume in the windows where 3D graphics are on display. Scaling by values less than 1 will make objects appear larger, or closer, and scaling above 1 vice versa. 0.5 works very well in SOM_PRM. Values are limited to real numbers.[#]

Note: This extension is currently limited to SOM_PRM.

default_pixel_value...

Introduced around 1.1.1.3, this extension changes the background color (normally black) in the windows where 3D graphics are on display. Values are limited to hexadecimal color codes.[#]

default_pixel_value2 Introduced around 1.2.2.4, this extension changes the background color of the new profile (see: PRF, PRT) editor tools (normally blue) when opened outside the context of SOM_PRM or in the smaller thumbnail sketch view. If this value is made to be 0, or pure black, it is as if it is the same value as #default_pixel_value. Values are limited to hexadecimal color codes.[#]

do_hide_direct3d_hardware

Formerly do_hide_direct3d_hardware_devices prior to 1.1.1.5

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 relying upon it, please report the difficulties you are experiencing to someone who is in a position to resolve your issue.

do_overwrite_project

Introduced around 1.1.1.4, this extension is nothing fancy. It will let you have Sword of Moonlight create a new project on top of an existing folder where a project may already be found. The normal project template will simply be written over whatever files and folders are in the target folder. Sword of Moonlight will not complain or refuse to do your bidding, neither will you be warned of the impending overwrite. Values are limited to binary statements.[#]

do_overwrite_runtime

Introduced around 1.1.1.4, this extension is nothing fancy. It will let you have Sword of Moonlight create a new runtime on top of an existing folder where a runtime may already be found. Your project will simply be converted and deposited on top of whatever files and folders are in the target folder. Sword of Moonlight will not complain or refuse to do your bidding, neither will you be warned of the impending overwrite. Values are limited to binary statements.[#]

do_subdivide_polygons

It is recommended that this extension NOT be used. It is provided just in case.

Introduced around 1.2.0.8, this extension reinstates the older/original behavior of subdividing level geometry that is beneath lamps. To enable the use of #do_aa the map compiler is made to subdivide everything equally, and because presently per-vertex-lighting is required: maximally. Values are limited to binary statements.[#]

height_adjustment

Introduced around 1.2.2.4, this extension adjust the height of the fonts, thereby making tools larger. The first parameter is the default font height in terms of pixels. The second parameter is a numeric code that identifies individual tools, that is reserved for advanced use cases. This extension came about because the PlayStation VR makes text appear fuzzy, in which case it may become illegible. The new height is limited to the size of the original font or two times the original font's size. Making the fonts 1.3 times larger is recommended for the original tools, using the MS Gothic font. Different sizes can produce layouts that are the same size but do not achieve the largest possible font, therefore it's recommended to find the desired layout, and then increase the size as high as it can go within that layout, to ensure the font is as robust as can be. An unintended upside of larger fonts is 2D or 3D model areas are made more spacious. The main downside is imperfections that appear if the original layout was handcrafted so not to have imperfections. This is unavoidable since the enlargement process isn't precise down to individual pixels. Values are limited to positive real numbers.[#]

sort_...

Introduced around 1.1.2.3, this extension sorts profiles in SOM_PRM into categories based on SET files. The part after sort_ must be one or more sets separated by underscores (_). An additional underscore may appear after the final set to indicate that a space ( ) should not be appended to the end of the category heading.

By default a space (_) is appended to the heading, and the profile's description follows the space. %s can be written in order to embed the description directly within the heading. Categories appear in the order in which they appear in the INI files. Refer to #assorted.... Values are limited to any string of text.[#]

Since 1.1.2.8 there is limit on the number of sets in play, although this is an implementation detail. And there are two new ways to use sort_:

sort_x or sort_x= where nothing follows the equal sign (=) causes "x" to be effectively appended to subsequent sort_ directives. To clear the "appendix" just use sort_ by itself; or in other words, append nothing.
sort_=x causes a separator to be inserted into the resulting categories. If nothing exists between two separators then the first separator will not appear. Separators should be used, and used consistently if so.

Tip: two new examples of how all of this works: [2][3]

time_machine_mode

Introduced around 1.2.2.2, this extension when set to 2000, disables some extensions in order to demonstrate the classic "look & feel" of Som2k. This is intended to demonstrate some esthetic characteristics to researchers, historians, and their ilk, by offering a middle ground between installing a period specific virtual machine loaded with Sword of Moonlight's original CD-ROM's materials. Values are limited to whole numbers; 0, 2000.[#]

texture_subsamples

Introduced around 1.1.1.3, this extension blows up textures, smoothing them out in the process. So if set to 2, a 256x256 texture will become a 512x512 texture in memory. Sword of Moonlight alone will try to blow textures up to the maximum size allowed by the display device. With modern hardware that is quite dangerous, since 8192x8192 or better is common, which is a 256MB texture. The Sword of Moonlight Extension Library by default uses 256x256 textures. Values are limited to whole numbers; 1, 2, 4.[#]

It's not clear why Sword of Moonlight tools exhibit this behavior. One theory is the tools would in their day require software emulation under most circumstances to display graphics inside popup windows. Since filtering the texture on screen would be slower for a software rasterizer, blowing the texture up achieves the same effect while consuming considerably more memory.

The Extension Library ensures the texture is sampled in "halftone" mode. Sword of Moonlight neglects to do so and therefore where that is not the default behavior will likely consume about 16⁺ times the memory required without any positive effect.

⁺based on standard legacy software device numbers (1024x1024)

white_saturation

Introduced around 1.2.2.2, this extension is established mainly so end-users may change the contrast levels of text that is overlaid onto background and button graphics. Refer to #black_saturation. black_saturation has more to say on this subject. Values are limited to base 256 identifiers.[#]

Joypad

Main article: joypad extensions

Extensions in this section take the form of a #pseudo button on the left of the equal (=) sign and a #keyboard macro on the right. Refer to #Action. This section is to be used by players to configure a game controller. An author may supply a modified default configuration database, however it is recommended that a stock configuration database be used.

A button in this section can be assigned a "reaction" so that if it represents a joystick axes for example, then when the axes is tilted in its negative direction the alternative action is taken. To assign a reaction prefix the button with an underscore (_) or use the formal 1st_button_action and 1st_button_reaction constructions where 1 is a button number and anything goes between it and _button_action or _button_reaction.

Note: as of 1.1.1.5 the addition of this section to the Ex.ini file will make game controllers not appear in the in-game Options menu. This is by design. The following extensions are in addition to the button configuration extension pattern explained in the paragraph above.

..._analog_gaits

Introduced around 1.1.1.5, this extension calibrates the sensitivity of the 8 axes. The part before _analog_gaits must be one of: axis, for the 1st, 2nd, and 3rd axes; axis2, for the 4th, 5th, and 6th axes; slider, for the the 7th axis; and slider2, for the 8th axis. Refer to #pseudo_..._axis, #pseudo_..._axis2, #pseudo_slider, and #pseudo_slider2 respectively.

This extension has 7 parts that must be separated in a way that is unambiguous. Any part not specified defaults to: 0.2, 0.333333, 0.5, 0.666666, 0.75, 0.875, and 0.95 respectively. This is a perfect linear mapping. A game controller may use a nonlinear mapping. In example, a DualShock controller is very biased; .2 .25 .3 .4 .55 .75 .95 gives a greater sense of control over its sticks by flattening out the windows between the gaits.

Note that this is not a mechanism for calibrating imbalance or fighting in a stick. That is done with the Windows Control Panel calibration feature.

The first and last numbers in the series are unique. An input below the first number is ignored. This is important because sticks usually require a wide "dead zone" so not to appear cocked when left still. An input above the last number is taken to be full tilt. A calibrated stick should achieve full tilt. An expanded window lessens the need to force a stick to full tilt.

If a number is less than or equal to the number before it results are undefined. The option to merge gaits will be visited at a later date. Values are limited to series of real numbers between 0 and 1.[#]

do_not_associate_pov_hat_diagonals

Introduced around 1.0.0.1, this extension in the affirmative disables the default behavior of treating a point-of-view hat as if it is an 8 direction-pad where pressing the diagonal directions of the pad is equivalent to simultaneously pressing the pseudo buttons assigned to the two non-diagonal directions on either side of the diagonal. Values are limited to binary statements.[#]

joypad_to_use_for_play

Introduced around 1.0.0.1, this extension selects the game controller or other device to be configured by the enclosing #Joypad section.

You can discover the name of your game controller either by looking for it in the Windows Control Panel, or looking for it in-game while playing a Sword of Moonlight game; note that whenever a Joypad section is present all controllers will appear to be unplugged in game.

You can even change the name of your controller via the Control Panel, however if you unplug the controller the name will revert to the factory default. Doing so can be useful if you have two controllers of the same make and model. The default behavior is to use the next available controller.

It is not necessary to specify the entire name. An asterisk (*) can be used in place of any portion of the name. A question mark (?) can take the place of a single character. Values are limited to MS-DOS wildcard expressions matching the device name of one of your plugged in game controllers.[#]

In the future it will be possible to specify a Windows GUID. However GUIDs are usually only useful to programs like Excellector.

pov_hat_to_use_for_play

Introduced around 1.0.0.1, this extension selects a point-of-view hat to be configured. A game controller may have multiple hats, but only one is able to be configured by #pseudo_pov_hat_.... Values are limited to positive whole numbers.[#]

pseudo_..._axis

Introduced around 1.0.0.1, this extension assigns an action and reaction pseudo button pair to the first 3 analog stick axes. This extension comes in 6 forms. The part between pseudo_ and _axis can be one of x, y, or z, for the 1st, 2nd, and 3rd axis respectively. Values are limited to pseudo buttons.[#]

pseudo_..._axis2

Introduced around 1.0.0.1, this extension assigns an action and reaction pseudo button pair to the second 3 analog stick axes. This extension comes in 6 forms. The part between pseudo_ and _axis can be one of x, y, or z, for the 4st, 5th, and 6th axis respectively. Values are limited to pseudo buttons.[#]

pseudo_pov_hat_...

Introduced around 1.0.0.1, this extension assigns an action or reaction pseudo button to one of the major angles of the point-of-view hat. Refer to #pov_hat_to_use_for_play.

The part after pseudo_pov_hat_ can be one of 0, 9000, 18000, 27000 for up, right, down, left respectively. And if #do_not_associate_pov_hat_diagonals 4500, 13500, 22500, 31500 for up right, bottom right, bottom left, up left respectively. Values are limited to pseudo buttons.[#]

pseudo_slider

Introduced around 1.0.0.1, this extension assigns an action and reaction pseudo button pair to the 7th analog stick axes. Values are limited to pseudo buttons.[#]

pseudo_slider2

Introduced around 1.0.0.1, this extension assigns an action and reaction pseudo button pair to the 8th analog stick axes. Values are limited to pseudo buttons.[#]

Keygen

Main article: keygen extensions

Since 2017 there is an effort to phase out this framework. Its days are numbered.

Extensions in this section control a "key" system that was originally developed to be able to apply corrections to certain Sword of Moonlight textures that proved incompatible with Direct3D 9. The key system generates hashes, or serial numbers, for each texture as it is loaded into memory. Corrections and other kinds of tweaks are associated with the hashes via INI files like IMAGES.INI. Keys can be stored in the Windows registry to improve load times and or work directly with them.

The key system is expected to become increasingly obsolete over time. However it will remain a powerful way to organize tweaks to individual resources, and therefore will probably have somethings to offer for some time to come. There is a "models" key under the hood. And a "sounds" key is expected to come online before the end of 2013. The term key was consciously chosen to be eponymous with the prominent appearance of keys in King's Field games, keys in the Windows registry, and keys as a way of classifying information.

Note: adding a Keygen section alone will change nothing. Furthermore Keygen sections have no business in a game's Ex.ini file. It is something to use only if you are working on a project of some sort. Remember that you can blot out an entire section by modifying its name. Adding a period (.) to the front of the name is the recommended means of doing so.

do_disable_keygen_auditing

Introduced around 1.0.0.1, this extension in the affirmative turns off "auditing" when som_db.exe is playing a game with #do_enable_keygen_automation switched on. Refer to #keygen_audit_folder. Values are limited to binary statements.[#]

do_enable_keygen_auditing

Introduced around 1.0.0.1, this extension in the affirmative turns on "auditing" when som_rt.exe is playing a game with #do_enable_keygen_automation switched on. Refer to #keygen_audit_folder. Values are limited to binary statements.[#]

do_enable_keygen_automation

Introduced around 1.0.0.1, this extension in the affirmative turns on key generation. The generated keys are stored within the Windows registry. Refer to #keygen_toplevel_subkey_in_registry and #keygen_automatic_filter.

Note that by default generation is only performed when a game is being debugged, or play tested, with som_db.exe. Refer to SOM_SYS for an explanation of what it means to debug a Sword of Moonlight project. Refer to #do_somdb_keygen_defaults. Values are limited to binary statements.[#]

do_somdb_keygen_defaults

Introduced around 1.0.0.1, this extension in the affirmative causes the Keygen extensions to behave as if som_db.exe is being used. This is helpful if you need to generate keys for a standalone game. Values are limited to binary statements.[#]

keygen_audit_folder

Introduced around 1.0.0.1, this extension provides an alternative file folder address for the purpose of "auditing". Auditing is a lot like "ripping". In example: for textures, each image is saved as a DirectDraw .dds file format image to the audit folder. You can then open the folder in Windows Explorer and look through the thumbnail images to find the image that you are interested in, and then use that image's file name to find the matching key in the Windows registry.

The default folder is the data/key folder relative to the local installation of Sword of Moonlight. #alternative_data_folder does not effect the location of the default folder. Values are limited to absolute paths on the local file system.

keygen_automatic_filter

Introduced around 1.0.0.1, this extension provides the name of the Windows registry key under which #do_enable_keygen_automation generates keys. The default key name is public. Values are limited to valid Windows registry key names.

Note that the filters "public" and "private" have special meaning when loading a key from an INI file. However in this context you are simply changing where the keys will end up in the registry. A common reason for changing this is to avoid overwriting keys being used by other projects past present or future. Refer to #keygen_image_file.

keygen_image_file

Introduced around 1.0.0.1, this extension provides an alternative INI file from which to load the images key. The default behavior for projects is to look for IMAGES.INI in the project folder. For standalone games IMAGES.KEY is looked for in the EX/KEYS folder. The file extension is changed so players will not be tempted to bother with the file. Values are limited to paths on the local file system.

keygen_toplevel_subkey_in_registry

Introduced around 1.0.0.1, this extension provides the name of the Windows registry key under which the entire Keygen system operates. The default key is Software/FROMSOFTWARE/SOM/EX/KEYS under HKEY_CURRENT_USER. Values are limited to valid Windows registry key names.

Keymap

Main article: keymap extensions

Extensions in this section take the form of #keyboard key on the left of the equal (=) sign and a #keyboard key on the right. The right may also be a single key keyboard macro. Refer to #Action. This section is to be used by authors to establish the game's keyboard layout. Players should use the #Keypad section to reassign the keys of their keyboard.

The key on the left of the equation is the key being remapped. The key on the right is the key that the key is being mapped to. Remapping a key to zero (0) will disable that key.

Note: if a key is remapped more than once the two mappings will interfere yielding an undefined result.

Keypad

Main article: keypad extensions

Extensions in this section take the form of a #keyboard macro on the left of the equal (=) sign and a #keyboard macro on the right. This section is to be used by players to reassign the keys of their keyboard. Authors should use the #Keymap section to establish the game's keyboard layouts.

Assigning a key to zero (0) will disable that key.

Launch

Main article: launch extensions

Extensions in this section pertain to the game launch phase that is handled by a separate "launcher" application. The launcher prepares the shell environment and loads the executable image into program memory in a suspended state before editing it and resuming execution.

do_without_the_extension_library

Introduced around 1.1.1.3, this extension in the affirmative is equivalent to playing a game without the aid of the Sword of Moonlight Extension Library. Values are limited to binary statements.[#]

Note: for standalone games with the Project.DAT file in the EX folder the file must be moved to the game's root folder or the game will fail to start. It is safe to try this as long as you don't save your game. Even still a game may be so dependent upon extensions that it will not be playable or may even refuse to play. Whether or not it is safe for your computer and or its components is another story!

Important! in later versions of the Extension Library it is not necessary to set do_... form extensions. This extension must be explicitly set to work. eg. do_without_the_extension_library=yes. This is because Microsoft's GetPrivateProfileString API ignores unset INI values (whereas GetPrivateProfileSection does not.) This should be remedied when there is enough reasons to update SOM_EX.exe.

launch_image_to_use

Introduced around 1.0.0.1, this extension manually specifies the executable image relative to the game's root folder. The default behavior is to look in the EX folder and use the first file found with a .bin file extension. It is recommended that you only use the final patched version of som_rt.exe released by From Software without making any edits to the file whatsoever. Special care should be taken to ensure that you are indeed using the correct file[4].

When converting a project into a standalone game SOM_RUN copies the som_rt.exe file in the tool folder and changes the name to GAME.EXE. It is recommended that you delete this file or move it to the EX folder and change the name to the name of the game, or something similar, using only ASCII characters and then change the extension part to .bin. Values are limited to legal ASCII file names.

launch_title_to_use

Introduced around 1.0.0.1, this extension provides a title for your game. The default behavior is to use the name of the launcher executable file without the file extension part. This title should not be overly long but neither should it be incomplete or shorthand. Using either the main title or the subtitle, but not both, is probably best. Refer to #window_title_to_use. Values are limited to any string of text.[#]

Locale

Main article: locale extensions

Sword of Moonlight Extension Library / locale extensions

Number

Main article: number extensions

This section is available since 1.1.2.1. Refer to SomEx / list of numbers.

Extensions in this section take the form of custom #numbers which can then be used to assign values to extensions that accept "numbers". Often these extensions will end with _factor or _multiplier. If their numbers accept input parameters they end with _quantifier. An extension that ends with _identifier accepts a positive whole 24bit number or a packed series of numbers setup with id. Such extensions may or may not accept input parameters.

The name of an extension in this section is limited to a 30 character name, a subscript in the range of [0-65534], and a 30 character label, all separated by a single underscore (_). A name is required. If the subscript is unspecified then 0 is assumed. Labels cannot include equal signs (=) and cannot be applied when the subscript is omitted, as the subscript separates the name from the label.

A trailing underscore (_) is interpreted as an incomplete label. The value to the right of the equal sign (=) is taken to be the label. Just the same a number can be specified without being assigned to. Doing so will simply apply a label. It is not necessary to declare numbers in advance. Therefore applying labels is the only reason to omit the assignment. Numbers are not assigned in any particular order accept where _$ appears.

All-lowercase names for numbers are reserved. Both for the numbers of SomEx / list of numbers and future extensions of the #Number section. This does not mean you cannot use such names, however you should think twice before doing so. Furthermore all symbolic Unicode character codes are reserved. In other words, the names of custom numbers should be limited to Unicode script only. These restrictions do not apply to labels. However labels are advised to avoid the = and [] characters, however [ and ] can be used if matched and in that order.

Note: that it would be ideal if where multiple Ex.ini files are in use assignment is encapsulated, or occurs before moving onto the next file by default. However this behavior has not yet been put into effect as of 1.1.2.1.

Option

Main article: option extensions

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.

do_2k

Formerly do_som prior to 1.1.2.12. Formerly do_2000 prior to 1.2.0.8.

Introduced around 1.2.0.8, this extension in the affirmative enables emulation of Sword of Moonlight 2000. This exists solely for diagnosing software issues originating within som_db.exe, however because only game play mechanics are affected, do_2k can (in theory) be used to play a game as From Software's Sword of Moonlight development personnel intended. Refer to #do_without_the_extension_library. Values are limited to binary statements.[#]

Tip: The Alt+Alt (your keyboard must have both left and right Alt keys) #keyboard macro turns emulation on and off. This can be invaluable to artists and programmers alike. Emulation can be turned on when not using do_2k. In the F5 system function overlay screen an "emu" icon will appear beside "fps" when emulation is in use.

do_aa

Prior to 1.2.0.8 do_aa enabled MSAA.

Introduced around 1.2.0.8, this extension in the affirmative enables an astonishing graphical effect that may be hereunto unique to Sword of Moonlight. In brief it makes the jagged edges of video games simply go away. This is done without impacting the frame rate, by utilizing the computer display's refresh rate to superimpose various permutations of the jagged edges over time, so that the viewer's eye may synthesize a jagged edge free image. The "aa" in do_aa comes from the popular concept: "anti-aliasing"; however it can be said that this represents an aliasing free technique, and so to say AA may, in a sense, be a misnomer. Refer to #do_lap.

It is important to also turn on #do_lap so that the effect can be pushed to full power without noticeable side effects. Without do_lap the effect must be isolated to the joints of the jagged edges in order to minimize the unwanted side effects. Values are limited to binary statements.[#]

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.~~ As of ver. 1.2.0.8 this is unnecessary, however it's still recommended the texture be replaced using the aging image key system. You may mark custom textures this way in order to create your own shadows. See #Keygen for details. Refer to #do_fog. 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.[#]

Note: ambient lighting is non-reflective. It will appear on the outside of doors even when the light source itself is on the inside. Care must be taken to not situate lamps near doors just as lamps will normally illuminate objects on the opposite side of a thin wall.

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_bpp

Introduced around 1.1.1.5, this extension in the affirmative simply changes the terms for 16bpp and 32bpp in the Options menu's Colors setting to High Color and True Color respectively. This is merely a technical correction as bpp stands for bits per pixel which may or may not be 16 or 32 depending on the extensions in play. In practice both modes are usually 32bpp, where High Color is emulated for some effect. Values are limited to binary statements.[#]

If and when "Deep Color" becomes available and is enabled and is supported by the player's device environment this extension will advertise True Color and Deep Color respectively. Note that #do_highcolor and possibly other extensions hijack the Colors setting superseding the utility of this extension.

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_dash

Introduced around 1.1.1.5, this extension in the affirmative enables management of dashing. Dashing happens when the player holds down the "action" button if dashing is not currently disabled. Specifically do_dash slows the player down when dashing sideways and more so going backwards. #do_walk does the same while walking. When the two are combined the effect is spread across both extensions so that no additional slowdown is incurred overall. Values are limited to binary statements.[#]

do_disasm

Introduced around 1.1.1.3, this extension in the affirmative turns on the disassembler. In earlier versions disassembly could occasionally lead to crashes so this extensions was invented since disassembly is not always required. It was probably a good idea however because the Sword of Moonlight EULA makes a point to forbid disassembly, though it is unlikely this is precisely what the lawyers had in mind. Still if you want to adhere strictly to the EULA you should not switch this on.

When do_disasm is on, assuming things do not crash, you can see the disassembled code in the memory inspector overlay (F11) if available (see #Output) and extensions which depend upon the disassembler can work their magic. Values are limited to binary statements.[#]

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_escape

Introduced around 1.1.1.5, this extension in the affirmative adds the Escape key, aka. Esc: usually the top-left most key, to the keyboard. As of 1.1.1.5 pressing the Esc key when in-game and not in the title screens or menus changes the "Analog Mode" with respect to #escape_analog_modes.

Eventually (ideally sometime in 2013) pressing Esc will open a new System menu that will make the Analog Mode function obsolete. The original menu will no longer be available. By default it will be replaced by a Save or Load menu depending on if the game allows save anywhere-anytime. Save/load functionality should also be provided by the new menu as soon as possible. In which case authors will probably want to put something else in that slot. A Journal (beastiary etc.) menu for example. #do_system is provided to keep the original menu. Values are limited to binary statements.[#]

do_fog

Introduced around 1.1.1.5, this extension is equivalent to setting #do_alphafog and #do_rangefog (both are highly recommended) independently. Note that extensions in the #Detail section still begin with alphafog_ and rangefog_ respectively, and that do_fog may assume additional meaning in the future. Values are limited to binary statements.[#]

do_g

Introduced around 1.1.1.7, this extension in the affirmative causes freefall to be be governed by a simple model of gravity. Refer to #g.

In addition to gravity do_g translates the G and J keys into the JUMP extended key code. Jumping is impossible to facilitate without gravity. Refer to #player_character_fence.... Values are limited to binary statements.[#]

Note: only the player character is guaranteed to be affected, and only when not supported by a platform. Where applicable items, projectiles, and NPCs fall accordingly.

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 original 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 HDR 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_hit...

Introduced around 1.1.2.12, this extension in the affirmative makes player characters respond to being "hit". There is currently no way to customize the behavior of this extension, and the behavior is subject to change. It only guarantees that the player is able to tell that they have been hit without the aid of any onscreen displays. Guidelines call for the default behavior to mirror the default behavior of non-player characters.

The do_hit extension is a prerequisite for #do_hit2, however it is not necessary to turn them both on, as do_hit2 automatically turns on do_hit. Likewise turning off do_hit automatically turns off do_hit2.

The do_hit extension affords the hit character a period of invincibility, during which they are immune to subsequent hits. This period lasts for the duration of the response. Generally do_hit2 is recommended on the grounds that the invincibility period interrupts "multi-hit" attacks.

do_hit2 in the affirmative automatically turns on #do_hit and eliminates the invincibility period so that "hits" become accumulative. Superficial features of the hit response that would be distracting if repeated in short succession should behave as if the player character is invincible.

Generally do_hit2 is recommended over #do_hit because the invincibility period interrupts "multi-hit" attacks. 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_ko

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to allow the player to be knocked out when being knocked back by the #do_pedal extension. The knockout effect itself will be identical to #do_palsy except that the duration will be dependent upon the force of the knockout hit.

Since the player cannot move while knocked out, it opens up the possibility of increasing the movement speed temporarily so that the player character can be thrown around at a rate faster than would otherwise be possible.

do_lap

Introduced around 1.2.0.8, this extension in the affirmative overlaps frames by way of either an interlaced stencil or dueling scene buffers. Early versions simply did a non-biased motion/temporal blur like effect with the stencil approach. Later in the same release cycle the effect was adapted to work with the new version of #do_aa which was incompatible with the stencil technique. The new approach adds the scene buffer to the previous scene's buffer at half intensity.

The stencil buffer approach is retained in dither modes if do_aa is not enabled, however this practice may be phased out because in theory foils automatic mipmap coordinate generation. The simpler functionality will remain until this theory is confirmed. 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 object lighting business.

As of 1.0.2.8 this is much more efficient than it had previously been. Before long there should be a high-level scheme for optimize lighting, but right now it's recommended that maps not include an overly abundant number of light sources (since every light is compared against every visible object until then. But not every piece of the objects. And objects that are within a meter or so of one another may benefit from being considered a single cluster of objects.)

Because of #do_fix_lighting_dropout SOM cannot be relied on to do lighting. This extension is effectively equivalent to the bug fix but allows for a greater number of light sources per object than the original amount of 3. The light selection is not known to be identical to the original, so expect there to be difference if porting Som2k projects. Refer to #do_hdr. Values are limited to binary statements.[#]

do_log

This extension poses problems to the initialization workflow. It is expected to be made obsolete as soon as a dedicated logging solution can be brought online.

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.[#]

Tip: The Alt+grave (`) #keyboard macro turns logging on and off. ~~This will not work if do_log is not switched on~~ (not so since 1.1.1.7.) Refer to #log_initial_timeout.

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)

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. Values are limited to binary statements.[#]

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.

The mouse has two modes of interaction. A strong capture mode and a weak capture mode. The weak mode is only available in-game outside of title screens and menus. It is accessed by clicking the 3D game area of the window. Strong mode is accessed by spinning the mouse wheel until the cursor changes, then clicking anywhere in the window's client (read: non title bar) area. The wheel must then be turned in the opposite direction to exit the strong capture mode. The further the wheel is turned (up to a limit) the stronger the capture.

Strong capture persists inside of menus and does not interact with onscreen elements. The mouse can be "floated" temporarily by pressing the Alt keys or the F10 key. These keys are traditionally used to access a window's File menu. Values are limited to binary statements.[#]

do_numlock

Introduced around 1.1.1.6, this extension in the affirmative emulates Num Lock so that the operating system's state does not interfere with the function overlay. Refer to #Output. Values are limited to binary statements.[#]

Note: if your keyboard does not have a Num Lock key you need to add one to the #Keypad section.

do_palsy

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to replace Sword of Moonlight's Palsy status ailment in order to better incorporate the knock back effects provided by the #do_pedal extension. Specifically it should be possible for the player character to be knocked around while paralyzed.

By default the paralysis will transition to slow status (see #do_slow) once it begins to wear off. Furthermore all in-game (excluding pause and other out-of-game functionality) input will be short circuited. If the player attempts to open the menu a digital clock will appear in the middle of the screen counting down until the menu is able to be accessed; the menu will not be opened automatically when the clock disappears.

In contrast the original Palsy effect permits the player to use magic spells and items, and of course the menu, while paralyzed. Without access to any of these time (or forethought) is the only means of escape in a single player scenario.

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_red

Introduced around 1.1.1.5, this extension in the affirmative modulates the intensity of the red flash if and when the player has taken damage. The default formula will lessen the red flash when the player character is hit for between 0% and 50% of HP. So if 50% (or more) of HP is lost the flash is 100% red. If 1% is lost then the flash is 2% red. Use #red_flash_tint to change the colour and or intensity of the flash itself. Values are limited to binary statements.[#]

do_slow

This extension did not make it into 1.1.1.5. It will be implemented as soon as it is convenient and or necessary to do so. Its purpose is to replace Sword of Moonlight's Slow status ailment in order to better incorporate the knock back effects provided by the #do_pedal extension. Specifically it should be possible for the player character to be knocked around (at full speed) while slowed. Rather than the movement speed being slowed, slowdown is to be implemented at the analog input signal level.

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_st

Introduced around 1.1.1.5, this extension in the affirmative changes the on-screen elements so to emulate Shadow Tower. This can be seen as an esthetic decision, however the ST elements are textual and font based. Only the gauges are graphical. This makes localizing games much easier for translators. And takes the burden of crafting HUD graphics off the back of weary authors. Still this is ultimately a player preference and as such a game should work either way.

Just like Shadow Tower do_st sacrifices the compass. But it adds a damage output indicator. The bad status (or health) indicator can be turned off independently of the gauge/points displays. In future releases the square dot in the map screen will be replaced with a pseudo compass needle so that the player can access a compass that way. It should even be possible to equip a compass in the spare hand, and or glance at the compass in the item or equip menus. A Quick Select extension is even pretty far up on the "todo" list. And the compass itself can even be added back to the status indicator, even if that would be very un Shadow Tower like. Values are limited to binary statements.[#]

do_save

Introduced around 1.2.1.8, this extension in the affirmative enables the in-game Save Game menu item at the start of the game. It does not prevent the game from disabling it from inside of an "event." (A "do_save2" extension will be developed upon request.) It is for testers and anyone with a busy schedule. Values are limited to binary statements.[#]

do_start

Introduced around 1.1.2.14, this extension in the affirmative replaces the bitmap based text in the start menus with actual text. This extension is considered best practice for multiple reasons, not the least of which it makes translation into different world languages straightforward. Refer to #start_mode. Values are limited to binary statements.[#]

do_stipple...

Introduced around 1.2.0.8, this extension in the affirmative automatically enables #do_dither and causes the screen to be shifted like a checkerboard. This provides screen space antialiasing like benefits at no expense and is highly recommended, especially when combined with dithering. The stipple nullifies the folded-paper quality of polygons for a more solid feel. Disabling do_stipple automatically disables do_stipple2. Values are limited to binary statements.[#]

Note: currently do_stipple only works in dithered modes. This is because non-dithered modes are preserved for taking screenshots for development purposes. This is in a state of flux; use #do_highcolor with do_dither to limit players to dithered modes.

do_stipple2 Introduced around 1.2.1.8, this extension in the affirmative automatically enables #do_stipple. This extension had been called variously "do_shuffle" and "do_bicycle" or "do_bike." It is quasi experimental and should not be used as a default setting for any game because vertical and horizontal bars will noticeably throb when it is on, or will on at least some (many) systems. The effect is to alternate the checkerboard of do_stipple every so many "frames" creating a grain effect that further confuses the eye so not to notice computer graphics artifacts. Is interesting to look at. The modern form of #do_aa and #do_lap did not exist when this extension was originally experimented with. 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_system

Introduced around 1.1.1.5, this extension in the affirmative causes #do_escape to revert back to providing an "Analog Mode" function making use of the original System menu (instead of the new menu provided by do_escape) so that everyone can, "have their cake and eat it too." Note that this extension does nothing in 1.1.1.5 but if you don't like the idea of your game changing when the new menu finally comes online then do_system can be enabled in order to prevent that. Values are limited to binary statements.[#]

do_u

Introduced around 1.1.1.7, this extension in the affirmative reprograms From Software's Sword of Moonlight program to decouple the horizontal and vertical turning rates. This technique was developed to allow players to fast turn (around quickly or in circles) without affecting the vertical, or looking, turn rate. Refer to #do_not_corkscrew.

The u in do_u colloquially invokes a "U-turn" although technically it refers to the U turning axis. Because there is only one other turning axis (V) independent modulation is satisfied by do_u alone. In addition do_u interprets the U key as an automatic 180 degree fast turn⁺ and translates the F and K keys into the CORKSCREW extended key code. Values are limited to binary statements.[#]

⁺Implementation of the U key is a low priority that will be attended to once the basic control extension specifications are satisfied.

Note: that do_u is not needed by analog extensions which work based on a digital pulse. However do_u may be used to enable higher fidelity analog one day. Refer to #do_dpad and #Analog.

Code like the following is inserted into two sections of Sword of Moonlight's program. This is the first extension that changes From Software's code in a way that can't be compared to a simple "Game Genie" cheat code. The EULA [5] does appear to explicitly forbid disassembly. Authors are advised to exercise discretion.

;9 bytes for 36 removed 
mov ecx, dword ptr [z]
mov dword ptr[esp+38h], ecx
;now modulate the u axis 
fld dword ptr [esp+18h]
fmul dword ptr [u]
fstp dword ptr [esp+18h]

do_u2

Introduced around 1.2.0.10, this extension turns on high fidelity analog controls. You probably want this; although it is still new (at the time of writing this.) At some point it will probably go away as an option and become standard procedure, not because it's so great, but because there are visual problems without it, that become very apparent when using a lower "field-of-view" that is the new default behavior ever since the ability to do so was added via extension; as the classical viewer that Sword of Moonlight used produces a very distorted image. This level of distortion is not uncommon in video games, however as we are trying to make artistic games, the integrity of the image is paramount; or at least it is by default. This is also important for VR headsets that track movement, since the tracking requires precision. Refer to #u2_power and #u2_hardness. Values are limited to binary statements.[#]

do_walk

Introduced around 1.1.1.5, this extension in the affirmative does the same thing for walking that #do_dash does for dashing. Psychologically it may feel weird when do_walk is not combined with do_dash. A player can always decide otherwise if they feel otherwise. 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

Main article: output extensions

...function_overlay_contrast

Introduced around 1.0.0.1, this extension sets the "drop shadow" colour of the function overlays. The default is 00, or fully transparent, or no contrast. The part before function_overlay_contrast is optional. If present it must be one of f1_ through f12_ in order to set the contrast of the overlays individually. If not present contrast is set for all overlays. Values are limited to hexadecimal colour codes.[#]

...function_overlay_eclipse

Introduced around 1.0.0.1, this extension allows an overlay to suppress, or temporarily turn off other overlays, while it is turned on. This is handy when there is not enough room to display all of the overlays at once for example. The part before function_overlay_mask is optional. If present it must be one of f1_ through f11_ in order to setup the overlay's eclipse mask individually. If not present masks are set for all overlays.

Note that an overlay will not eclipse itself or the F12 overlay. You can use that to your advantage when setting all overlays at once, otherwise you probably want to stick to setting the eclipse masks individually. Refer to #...function_overlay_mask for information and tips with respect to setting up masks. Values are limited to hexadecimal bit masks.[#]

...function_overlay_mask

Introduced around 1.0.0.1, this extension specifies which overlays are initially turned on. The part before function_overlay_mask is optional. If present it must be one of f1_ through f12_ in order to turn overlays off and on individually by specifying 1 for on or 0 for off. If not present the lowest order bit is F12 the next bit is F11 and so on, and all overlays are turned off/on at once. Values are limited to hexadecimal bit masks.[#]

You do not have to understand binary and hexadecimal number systems to set this up. You can just turn on/off everything that you want, and set set the extension to the hexadecimal number displayed by the F12 overlay in the top-right corner. Refer to #...function_overlay_tint to make the overlays accessible. If you want the overlays to be initially hidden, you can either make the right most hexadecimal digit even by subtracting 1. Or just do f12_function_overlay_mask=0.

...function_overlay_tint

Introduced around 1.0.0.1, this extension sets the colour and transparency of the function overlays. The default is 00, or fully transparent, or invisible. If invisible the overlay is considered to be inaccessible. The part before function_overlay_tint is optional. If present it must be one of f1_ through f12_ in order to set the colour of the overlays individually. If not present colour is set for all overlays. Values are limited to hexadecimal colour codes.[#]

Note that if a function overlay is accessible it can be turned off and on with the F1 through F12 keys on a keyboard. The original function of the key must then be accessed by combining an Alt key with the function key.

...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. This is a strong argument for removal of som.debug.cpp. A long form 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

Introduced around 1.0.0.1, this extension in the affirmative disables the pop-up dialog which normally reports when files are discovered to be missing. For games created without the Sword of Moonlight Extension Library this is very handy, as there is likely to be a great many missing files. Regardless it is best practice to satisfy all of these pop-ups and not switch this on so that players are able to report missing files.

Consider "commenting out" the extension to let players know that nuisance pop-ups are able to be hidden. You might even mention it in your game literature. Values are limited to binary statements.[#]

Player

Main article: player extensions

corkscrew_power

Introduced around 1.1.1.7, this extension exponentiates the corkscrew gesture. The gesture is most sensitive at 1. The default power is 2. Refer to #do_not_corkscrew. Values are limited to real numbers.[#]

do_not_corkscrew

Introduced around 1.1.1.7, this extension in the affirmative eliminates the "corkscrew" maneuver that occurs when turning and moving in the same direction resulting in the player character turning at an accelerated rate. When dashing the accelerated turning is accompanied by ducking resulting in a downward spiral, or corkscrew.

It is still possible to corkscrew manually using the CORKSCREW extended #keyboard key code. Values are limited to binary statements.[#]

do_not_dash

Introduced around 1.1.1.7, this extension in the affirmative eliminates dashing maneuvers when pressing the SPACE #keyboard key, or "Action" button. Know that "dashing" includes many kinds of actions not limited to climbing, crouching, and sneaking.

It is still possible to dash manually using the DASH extended keyboard key code. Values are limited to binary statements.[#]

do_not_duck

Introduced around 1.1.1.7, this extension in the affirmative eliminates ducking, or crouching, when pressing the SPACE #keyboard key, or "Action" button.

It is still possible to duck manually using the DUCK extended keyboard key code. Values are limited to binary statements.[#]

do_not_jump

Introduced around 1.1.1.7, this extension in the affirmative eliminates the jumping maneuver that can occur automatically on release of the DASH extended #keyboard key code (including the SPACE keyboard key, or "Action" button, when #do_not_dash is not switched on) under different input scenarios.

It is still possible to jump manually using the JUMP extended keyboard key code. Values are limited to binary statements.[#]

Tip: manual jumping puts the player at a slight disadvantage, and may prove impossible to execute effectively without a game controller.

do_not_rush

Introduced around 1.1.1.7, this extension in the affirmative eliminates the dodging and or rushing maneuver normally experienced when tapping the DASH extended #keyboard key code and the SPACE keyboard key, or "Action" button, when #do_not_dash is not switched on.

This extension is not recommended. It exists in order to remove the ducking behavior facilitated by #player_character_duck, which should itself be set to 0 to fully remove ducking. Ducking corresponds to the acceleration from walking to dashing speed, so without rushing the duck may be short lived, and then appear unnatural or unpleasant.

There are no plans to add a manual rushing feature (via a RUSH extended #keyboard key code) at this time. Values are limited to binary statements.[#]

player_character_arm

Prior to 1.2.0.8 this extension was named do_arm of #Option. It's not clear what this number represents yet. By default it is 4, but it's recommended that it only be set to 0 in order to disable it. This number scales the amount of noise introduced by walking, but is subject to change; both what it is and what it does. If 0 the result is as if do_arm was not enabled.

Introduced around 1.2.0.8, this extension in the affirmative enables management of the player character's arm. Specifically: the shoulder moving independently of the first-person view, as if the viewer is free to look about while attacking; how the arm is displayed, including handheld implements, the appearance of an opposite arm, and auxiliary animations; and abilities. Values are limited to the real number 0.[#]

player_character_bob...

Introduced around 1.1.1.7, this extension establishes the distances covered by bobbing (and derivative) walking effects when moving at peek speeds. The default value was 0.075, or about 3 inches; The notes below describe the new defaults.. Values are limited to positive real numbers.[#]

player_character_bob2

Since 1.2.0.10, unless explicitly assigned, player_character_bob2 is identical to player_character_bob.

Introduced around 1.2.0.8, this extension affects the horizontal swaying effect. The default is the same. This replaces sway_distance_multiplier.. Values are limited to positive real numbers.[#]

Note: since 1.2.0.10 it's possible to use pc[12] to interpolate between the amount of "bob" whether the character is walking or dashing. It's recommended this is done in order to obtain a more desirable overall effect until a better system can be arrived at and standardized.

Note: since 1.2.1.8 if player_character_bob is not specified if is cut in half (0.025) outside of "dashing" mode. 0.05/(2-pc[12]) is the equivalent number. Note, 0.05 is 2/3rds of the original bob effect chosen by From Software.

player_character_dip...

Introduced around 1.1.1.7, this extension establishes how far the player character may dip when landing flat footed. Maximum dip is achieved after a relatively short fall, or even a jump. This effect is not intended to encompass falls from great heights. Refer to #do_buckle.

The part after player_character_ can be omitted or 2. The defaults are 0.3 and 0.532359, or 30 degrees. player_character_dip2 contributes a nodding effect. Refer to #player_character_nod.... Values are limited to positive real numbers.[#]

player_character_duck...

Introduced around 1.1.1.7, this extension establishes how far the player character ducks down when dashing and ducking all of the way down to the ground while remaining flat footed. When dashing the lowest point is reached after #tap_or_hold_ms_timeout.

The part after player_character_ can be omitted or 2 or 3. The defaults are 0.15, 0.5, and 0.75. 2 is for "squat-walking", 3 is reached by doing a standing jump from the lowest point, also known as ducking. Values are limited to positive real numbers.[#]

Note: since 1.2.0.4 player_character_duck is borrowed by the "corkscrew" maneuver, so that it is doubled when dashing.

Note: I've added an explanation for 2 circa 2020. It was added many years ago, no telling what the version number was.

player_character_fence...

Formerly player_character_ascent in 1.1.1.5 and 6.

Introduced around 1.1.1.7, this extension establishes the height of obstacles that the player character is able to pass over. The default is 0.3 meters (prior to 1.2.0.8 it was 0.5) when the part after player_character_fence is omitted. This is the height of platforms that Sword of Moonlight will natively step up onto. It is recommended that this figure be lowered to around 0.3, or about a foot, because 0.5 meters is much higher than a tall person is easily able to step up onto, much less the default 1.6 meter tall player character supplied by Sword of Moonlight.

1.1.1.7 adds four more levels, player_character_fence2, 3, 4, and 5. At level 2 the player must lean into the obstacle and press the SPACE #keyboard key, or "Action" button, to climb up onto and over it. The way the player character climbs is related to #player_character_dip. At level 3 the player character should be able to hang down by their hands from the platform. At level 4 the player character is able to reach the platform by performing a standing jump and grabbing with their hands. Finally level 5 is a standing jump lifting off from #player_character_duck3. Otherwise it works identically to 4.

Note that it may not be possible to grip the platform, or the player may lack the strength, but the player is still able to reach interactive elements placed at levels 3 and 4. As for 4, #do_g (gravity) must be switched on or the player will not be able to jump. Likewise the power of the jump is a function of 4 minus 3 and gravity.

The defaults for 2 through 5 are 1.3, 2.0, 2.3, 0 respectively. Prior to 1.2.0.8 they were all 0. Note that currently only the difference between 3 and 4 matters, as it determines the jumping height. Values are limited to positive real numbers.[#]

Note: that Sword of Moonlight itself uses 0.51. Just in case the 0.01 part is important, 0.01 is automatically added to each fence.

player_character_height...

Introduced around 1.1.1.7, this extension establishes the physical height of the player character for purposes of passing underneath obstacles. When the part after player_character_height is omitted the default height is 1.6 meters, or about 5 foot 3 inches, corresponding to the physical height of the character when standing upright. Refer to #player_character_stature. Values are limited to positive real numbers.[#]

player_character_height2 Introduced around 1.2.0.6, this extension establishes the squatting height of the player character for purposes of passing underneath obstacles. By default it is 1.25 meters. Squatting happens automatically when running underneath overhead obstacles, and can be performed manually by standing up while moving away while in a crouching position. Values are limited to positive real numbers.[#]

player_character_inseam

Introduced around 1.1.1.8, this extension establishes a distance roughly analogous to the difference in the player character's height when squatting down, or straddling the side of the highest ledge possible. The default is 0 meters. In which case #player_character_fence is used where this extension is preferred. This figure is used along with #player_character_shape to alight from platforms, but is not limited to this role. Normally you set it to be somewhere between player_character_fence and player_character_fence2. Values are limited to positive real numbers.[#]

player_character_nod...

Introduced around 1.1.1.7, this extension establishes symmetric angular limits when the player character looks up and down. The default value is 0.785398 radians, or plus or minus 45 degrees, when the part after player_character_nod is omitted. player_character_nod2 sets an outer limit reached by holding down the controls that defaults to 90 degrees. Values are limited to positive real numbers.[#]

player_character_radius...

Prior to 1.1.1.7 "player_character_radius" referred to #player_character_shape.

Introduced around 1.1.1.7, this extension establishes the interaction distances for in game elements. The default is 1.75 meters when the part after player_character_radius is omitted. This distance applies to NPCs, including "enemies", for purpose of event activation. It is the distance preferred by Sword of Moonlight for event activation, not from the center, but as added to the clipping radius of the in game elements its events are associated with. However 1.75 is not the default radius for non-NPC elements including events and built in facilities. That is established by player_character_radius2 which defaults to ~~0.75~~1.0⁺ meters.

Caution: ~~0.75~~1.0⁺ meters is a breaking change instituted by the Extension Library. The figure approximates the length of the default player character's legs, or the combined reach of the arm and upper body as if stretching to touch your toes. Care should be taken with games not originally made with this distance in mind (as elements may be inadvertently placed out of reach.)

⁺SomEx 1.2.2.4 increases this value to 1 meter since the lesser value tended to produce misfires both in screen and VR settings.

Item pickup is established by player_character_radius3. It defaults to player_character_radius2. Unlike other elements items do not take up any space as such, and so the distance is from center to center. Likewise player_character_radius4 applies to money pickup and defaults to player_character_radius3. Values are limited to positive real numbers.[#]

Note: as of 1.1.1.8 doors (as they are not well understood) are handled differently. Their activation distance is a function of player_character_radius plus half the width of the door. Technically half the depth if greater than the width. Doors will behave like any other non-NPC element as soon as sufficient information about them becomes available.

player_character_radius3 (item examination depth)

Since 1.2.2.10 "items" appear closer in menu screens. This is to help with VR so that items don't appear stuck in a wall or other object behind them in terms of stereoscopic depth-perception. It also helps to make items appear to come closer when examined, as opposed to originally appearing to do the opposite, counterintuitively. However, this can make some items appear too close, or to be cut off by the edges of the screen. #player_character_radius3 is used to select a different distance. The new default distance is 1 meter. The original distance was 2 meters. For very small items, like a ring, it may help to position the item even closer, as-if examined closely in hand. The item number is used as a parameter to player_character_radius3 in this context. This distance is not used to determined if the same items are picked up and examined. That standard value is obtain when the item number is unavailable. It's currently a fixed value that is determined at the start of the game player.

Note: The new settings were chosen to emulate the game King's Field II.

player_character_shape...

Formerly player_character_radius prior to 1.1.1.7

Introduced around 1.1.1.7, this extension establishes the player character's shoulder width as measured from the center. Conceptually the classical character is cylindrically shaped, circular around the width and depth. The default radius is 0.25 meters however it should be noted that this is the radius used by Sword of Moonlight. A number of extensions work best with a radius of at least 0.325 meters. 0.5 meters is a good place to start with a new game project.

Since 1.1.1.7 you can set player_character_shape2 to change the "hitbox" radius, however it is unclear whether or not this is best practice, and even if set to near 0 many of Sword of Moonlight's stock monsters have attack radii that will land hits that look like near misses. Their PRF files may require attention. Values are limited to positive real numbers.[#]

Note that technically player_character_shape2 is reserved to set the smallest space that the player character is able to squeeze into. Which is then used as its default "hitbox" radius. It is also used to clip against ceilings, so that the player character does not pass through them.

player_character_shadow

Introduced around 1.2.0.8, this extension establishes the radius of the player character's classical NPC-style shadow. By default it is 0.35 meters. This extension is dependent on Shader Model 3 for support. Values are limited to positive real numbers.[#]

player_character_slip

Introduced around 1.1.1.8, this extension enables a "slip" effect and establishes the ground speed at which the player character will "fly" over platforms below #player_character_fence without losing speed. True to life. Lower speeds are met with ever greater adversity.

The default is 4 meters per second (prior to 1.2.0.8 it was 0.) How this effect works is a more involved than usual. Conceptually two circles exist at the player character's feet. The "slip" goes both ways. They can slip up stairs, for example. Or slip off of a step. Moving more quickly and pushing against obstacles causes one of the circles—lets call it the first—to grow. In the absence of moving and pushing the circle shrinks to a pinpoint. If it rests on a platform the player character does too. If it shrinks down until it no longer does so, then they slip off. At which point the second circle is initially the same size. This circle makes it possible to straddle the edge of the platform so that its side does not behave like a wall.

Fall further than #player_character_inseam and the circle grows to regular size, so that the side of the platform behaves like a wall, and it appears that the player character has taken a tumble. Otherwise the size of the circles do not change while slipping off, or falling, or stepping down, really the description depends upon the context, but the mechanics of the effect remain the same. The second circle grows along with the first as they move away. Values are limited to positive real numbers.[#]

player_character_stature

Introduced around 1.2.0.8, this extension specifies the eye level of the player character. By default it is 1.5 meters. It replaces pov_baseline_adjustment. Values are limited to real numbers.[#]

player_character_stride

Introduced around 1.2.0.10, this extension specifies the distance over which the walking effect completes a single bobbing cycle when walking at full speed. It replaces "bob_frequency_multiplier".

Starting in 1.2.3.4 the walk (_WALK) and dash (_DASH) #Number constants are multiplied by this value so it's unnecessary to change them to speed up or slow down a game's movement speed. Values are limited to real numbers.[#]

player_character_weight...

Introduced around 1.1.1.7, this extension establishes the player character's weight to be added to equipment and or inventory weight where applicable. The default weight is 50 kilograms, or about 110 pounds.

As of 1.1.2.2 player_character_weight is used by the default damage formula of #do_fix_damage_calculus to figure the first stat, aka. Strength, based bonuses. And player_character_weight2 is used to figure the second stat, aka. Magic, based bonuses. In 1.1.2.2 _weight2 defaults to 50. In 1.1.2.3 its default is _weight. Values are limited to positive real numbers.[#]

subtitles_ms_interim

Introduced around 1.1.1.7, this extension establishes the interval between (in fact each subtitle waits for the interval) subtitles. The time is in addition to #tap_or_hold_ms_timeout, and double that if a subtitle is the result of pressing the SPACE #keyboard key, or "Action" button, when #player_character_duck is non-zero and #do_not_dash is not switched on. The default is 300 milliseconds. Values are limited to whole numbers.[#]

Tip: negative times are allowed to subtract from the overall interval.

subtitles_ms_timeout

Introduced around 1.1.1.7, this extension establishes the duration of subtitles. The default is 1300 milliseconds. Note that the default is slightly more than what Sword of Moonlight uses, or 1000. Values are limited to positive whole numbers.[#]

tap_or_hold_ms_timeout

⁺Since about version 1.2.0.8 the default is 375. The previous default and classical value was/is 750.

Introduced around 1.1.1.7, this extension tweaks keyboard and button gesture recognition. A press is determined to be a tap if release occurs before tap_or_hold_ms_timeout milliseconds. A press is determined to be a hold if not released in time.

Taps and holds may often result in different outcomes. The default timeout is 750⁺ milliseconds. This is the timeout used by Sword of Moonlight's dashing game mechanic. If the timeout is shortened the transition from walking to dashing is shortened. Values are limited to positive whole numbers.[#]

Note: that this is an accessibility feature. 500 may make input appear more responsive, but some players may have a difficult time releasing the button with a half second. Sword of Moonlight's 750 figure likely constitutes a compromise. It should also be noted that this setting is roughly analogous to reaction and response times and may be lowered or raised according to in game parameters (eg. "Speed") so that players have the opportunity to train or practice to be able to play faster, or just to find a personal speed.

Script

Main article: script extensions

do_not_show_button_names

Introduced around 1.1.2.28, this extension in the affirmative disables the automatic extension that displays the names of the buttons provided by the game controller on the controls configuration screen alongside textual bullets that look like (1) through (8) and can be translated with the (%d) built-in gettext-style message ID which is also used to identify the controller ports. By enabling this disabling extension you revert to the original behavior of showing ボタン１ through ボタン８. Values are limited to binary statements.[#]

Note: this extension applies to the in-game controller configuration menu which is scheduled to be made obsolete by #do_escape. Refer to #do_system also.

fonts_to_use_instead_of_...

Introduced around 1.0.0.1, this extension takes the part after fonts_to_use_instead_of_ and uses the provided fonts in place of any font that has a name that matches. Underscores (_) are treated as single character wildcards. This kind of extension applies to dialogue text only. To change the menu (and other) fonts refer to #system_fonts_to_use. Values are limited to synthetic fonts.[#]

Note: a font may have multiple aliases even though matching is only done against the alias that was assigned to the text being displayed.

status_fonts_contrast

Introduced around 1.1.1.7, this extension establishes the colour of on-screen element font shadows, excluding subtitles. The default colour is 464646. Partial transparency is not supported as of 1.1.1.5. Refer to #status_fonts_to_use. Values are limited to hexadecimal colour codes.[#]

status_fonts_height

Introduced around 1.1.1.5, this extension establishes the height of on-screen element fonts, excluding subtitles. Refer to #status_fonts_to_use. Values are limited to positive whole numbers.[#]

status_fonts_tint

Introduced around 1.1.1.7, this extension establishes the colour of on-screen element fonts, excluding subtitles. The default colour is dcdcdc. Partial transparency is not supported as of 1.1.1.5. Refer to #status_fonts_to_use. Values are limited to hexadecimal colour codes.[#]

status_fonts_to_use

Introduced around 1.1.1.5, this extension establishes the on-screen element fonts excluding subtitles. The default behavior is to use the menu fonts described by #system_fonts_to_use. Values are limited to synthetic fonts.[#]

Note that Sword of Moonlight's on-screen element text is not font based. #do_st provides an alternative heads-up-display, and #do_pause and #do_escape display notifications to the center of the screen.

system_fonts_contrast

Introduced around 1.1.1.7, this extension replaces the colour of in-game menu text fonts. The default colour is 464646. Partial transparency is not supported as of 1.1.1.5. Refer to #system_fonts_to_use. Values are limited to hexadecimal colour codes.[#]

system_fonts_tint

Introduced around 1.1.1.7, this extension replaces the colour of in-game menu text fonts. The default colour is dcdcdc. Partial transparency is not supported as of 1.1.1.5. Refer to #system_fonts_to_use. Values are limited to hexadecimal colour codes.[#]

system_fonts_to_use

Introduced around 1.0.0.1, this extension replaces the font used by in-game menu text with the provided fonts. Refer to #status_fonts_to_use to target the on-screen element fonts provided by #do_pause, #do_escape, and #do_st specifically. Values are limited to synthetic fonts.[#]

Note: that this extension may also replace the fonts (but not colour) of dialogue and subtitle text which uses the same font as the in-game menus. This behavior is not by design and is subject to change in the future.

Tip: as of 1.1.1.7 you can change the colour of system, status, and subtitle and default dialog text (all one thing, three in total) independent of one another. Refer to #system_fonts_tint, #status_fonts_tint, and #lettering_tint.

Previously of [Locale]

Historical note: prior to 1.1.2.3 the following extensions were originally found in the Locale section. Now deceased.

Extensions in this section pertain to the localization, or translation, of game text. Game text translation is handled differently from the translation of the tools that come with Sword of Moonlight. Refer to the #Editor section for tool translation.

do_use_builtin_english_by_default

Introduced around 1.0.0.1, this extension in the affirmative translates all of Sword of Moonlight's Japanese text into a simplified ASCII English translation whenever a translation is not found with the game's script file. Some symbolic elements may still rely on non-ASCII characters. If the player's locale is ja_JP the original Japanese text is used by default. Note that the built-in English may change between releases. Values are limited to binary statements.[#]

do_use_builtin_locale_date_format

Introduced around 1.0.0.1, this extension in the affirmative uses the international dates and figures settings on the player's computer for the game clock and the save game dates. The locale can be overridden, in a limited way, by #locale_to_use_for_dates_and_figures. Values are limited to binary statements.[#]

locale_to_use_for_dates_and_figures

Introduced around 1.0.0.1, this extension manually sets the locale used by #do_use_builtin_locale_date_format for times and dates. At some point this extension may also effect numeric stats for the few regions of the world that do not use Arabic numerals or decimal points however there would need to be a third extension to enact that behavior. Values are limited to language and country code pairs.[#]

Note that the Windows Control Panel allows very fine grain control over different elements of displaying dates and figures, however this extension is only able to indiscriminately apply the default settings for a particular part of the world to both dates and figures.

locale_to_use_for_play

Introduced around 1.0.0.1, this extension manually specifies the locale to use. If a translation is unavailable then the current user account's locale is tried. And failing that #locale_to_use_for_play_if_not_found is tried. Values are limited to language and country code pairs.[#]

locale_to_use_for_play_if_not_found

Introduced around 1.0.0.1, this extension specifies the default locale to use failing all else. Values are limited to language and country code pairs.[#]

translation_to_use_for_play

Introduced around 1.0.0.1, this extension manually specifies the translation file to use relative to the locale folder with the file's extension stripped off. The default behavior is to use #international_translation_title or else #international_production_title or else script is used (som_db prior to 1.1.2.3.)

The script file is looked for in the lang/ll_CC/LC_MESSAGES folder. Where ll_CC is a #language and country code pair. Values are limited to an ASCII only POSIX and NTFS legal file name.

System

Main article: system extensions

register_...

Introduced around 1.1.1.3, this extension registers a .dll file in the "current user" registry area. When Windows does some things like play a movie, it looks through a list of classified DLL files to see if any of them can fill a role. Ie. decompressing a movie file. Sometimes a user must manually run "regsvr32" on a codec library to make this work. On Vista you must be elevated to "admin" level to do so because regsvr32 will register the DLL in the "local machine" registry area. If an author finds that this is required of the codec they wish to use they might consider using this extension. You can also just place your codec DLL file alongside your other files and register it directly. The end-user will not be required to be doing things in admin mode for the registration to take effect.

The syntax looks like "register_indeo_iv50_codec = ir50_32.dll" where what comes after "register_" is more or less simple notation. You can install the file yourself, or assume it is installed, or just place it directly in the folder where the operative SomEx.dll library resides. Values are limited to any string of text.

This setup is pretty much required to get the movies that come with Sword of Moonlight's KING'S FIELD remake to work reliably. Other codecs may be more reliable. It never hurts to err on the side of caution.

Window

Main article: window extensions

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. Originally this extension defaulted to DirectX 7, however for some time it will only accept 7, which is not recommended since it is very poorly maintained. 7 was used by Sword of Moonlight's original programming (the tools actually use 6, but that does not apply to this section of the INI file.)

9 is the de factor native mode of SomEx. However it too is poorly maintained when forced to operate with the default shaders or DirectX 9's "fixed function" implementation. There simply isn't enough time to devote to backward compatibility modes with the (single person) staff on hand. Just leave this and #shader_compatibility_mode alone unless you have a good reason for doing otherwise. Values are limited to positive whole numbers.[#]

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.1.1.3, 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_hide_splash_screen_on_startup

Introduced around 1.2.0.12, this extension "hides" the first phase of the startup sequence. Traditionally this takes about three seconds. Up until version 1.2.0.10 or so this screen was broken, because the image was corrupted in the original EXE file provided by From Software, so it just appeared to be a black screen if not repaired by the user. This extension is mainly provided for developers, especially low level programmers, to shorten testing cycles. Splash screens may contain copyright information and other considerations which you are responsible for hiding. 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.1.1.3, 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.[#]

shader_compatibility_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 generic Ex pixel shaders for versions of Direct3D 9 and up (the default behavior is to use shaders that have been tailored to Sword of Moonlight.)

2 will force generic Ex vertex shaders. 1 uses fixed function vertex 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

As of 1.2.0.8 there is a bit of a split along shader models, since 2 cannot support the new NPC-style shadows that blend smoothly into terrain and do not stick out into thin air.

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. Values are limited to any string of text.[#]

list of extensions

From Wiki

Extensions

Sections

Contents

Action

Adjust

Restructuring of [Adjust]

abyss_depth

blackened_tint...

blue_flash_tint

character_identifier

fov_fogline_saturation

fov_fogline_adjustment...

fov_frustum_multiplier

fov_sky_and_fog_minima...

fov_sky_and_fog_powers...

fov_skyline_adjustment...

green_flash_tint

highlight_opacity_adjustment

hud_gauge_depleted_half_tint

hud_gauge_opacity_adjustment

lettering_contrast

lettering_tint

npc_shadows_modulation

npc_shadows_multiplier

npc_shadows_saturation

paneling_opacity_adjustment

red_flash_tint

start_blackout_factor

start_tint

Analog

error_allowance...

error_clearance

error_impedance...

error_parachute

error_tolerance

Author

email_address_of_contact

hours_in_which_to_phone

international_production_title

international_translation_title

online_website_to_visit

phone_number_of_contact

software_company_name

street_address_of_contact

the_authority_to_contact

Boxart

game_artist

game_auteur

game_based_upon

game_caretaker

game_company

game_concept

game_dedication

game_designer

game_director

game_disclaimer

game_distributor

game_edition

game_features

game_first_edition_date

game_first_edition_year

game_format

game_label

game_legal

game_license

game_mascot

game_music

game_musing

game_original

game_partners

game_planner

game_presented_by

game_presenters

game_producer

game_programmer

game_project

game_publisher

game_publishing_date