Sword of Moonlight Extension Library/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[1] 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.