Sword of Moonlight Extended Warranty
The Sword of Moonlight Extended Warranty or SomEx (short for SomEx.dll, pronounced like Psalm X, or probably more correctly Sum X. Formerly the Sword of Moonlight Extension Library beginning with version 18.104.22.168) is an unofficial Sword of Moonlight (2000) extension framework. It is configured via cascading INI files. The extensions themselves may incorporate other types of files.
Each release includes a version number with four parts separated by periods or dots. If a number is incremented the subsequent numbers start over at 0. Except for the final number which by definition cannot be 0. It starts over at 1 instead, and can appear to skip numbers.
The first number is the major version number, and the second the minor. These numbers are assigned according to arbitrary milestones. The third number should correspond to potential or known issues around compatibility. The fourth and last number is a public build number. A build just means that the program, which at its base is like a textual document, is turned into a file, like the SomEx.dll file. As of version 22.214.171.124 demo builds get odd numbers, and official release builds get even numbers (note that a "build" may see multiple releases, or patches, due to fixes between releases.)
If only two numbers appear it is the third and fourth. In which case the first two numbers are assumed to be contemporaneous. If only one number appears then it is the first. Which is unlikely to happen unless the version numbers become synonymous with Sword of Moonlight, and a "Sword of Moonlight 2" is warranted. Most likely to note a complete severing of compatibility. Version 0 was used by alpha builds.
Version 126.96.36.199 is the minimum recommended version with respect to Sword of Moonlight bugs affecting games. There has not been a concerted effort so far to eliminate bugs from the game making tool suite. But it should basically work as intended on any Windows desktop operating systems from XP and upward.
The following is essential reading for first time users. Or you could say, the short list of things you don't want to find out the hard way on your own time.
- Presently two item slots and a magic slot are reserved for default equipment and magic to be used whenever there is "nothing" equipped. A slot in SOM_SYS's table may also be necessary. This keeps the gauges (on which new control features rely) and presentation consistent. Alternatively a project can manage its own items and magic as the player removes them (装備なし is translated automatically.)
- By default the activation distance is considerably less for inanimate things on non-NPC class game elements. This can make it impossible to reach something in game. Likewise the player character shape may be fatter not allowing it to squeeze into alleyways that might be required to finish a game. And more an old game may depend on a bug that used the height of a box instead of its depth to forward events.
- Players are able to access the debugging features in your game if that is what they want to do. Just the same you needn't be dependent on the debugging version of the game program to do so for yourself. There are no plans to devote time to getting around this. It is a core accessibility feature. Although considerations (within limits) will be made for regulated play one day.
- A game will need to use the script framework to do many things. A script is a file that contains the written text of your game. Just like a manuscript. It is much easier to write for your game this way than to open up sophisticated three dimensional maps and navigate to and through their event driven micro programs to get at bits and pieces of dialogue.
- It is recommended that a natural walking speed be used along with an approximately 3x dashing speed. The turn rate should be calibrated so that a rushing turn turns 90 degrees. If so then a fast turn will turn 180 degrees in the same amount of time. The walking turn rate should be at least 60 degrees per second to satisfy mouse users. A fast turn will then be 360 degrees per second.
- By default the hit-point damage formula including stat bonuses works differently. This is to work around bugs and logical inconsistencies which could be called bugs in the original formulas. When instances of NPCs are scaled up in the MPX map, eg. with SOM_MAP, their attack and defense ratings scale accordingly.
- A project's PR2 files are converted to PRO files. The PR2 files are no longer used and should be discarded. At their base a PRO files are backwards compatible with PR2 files, except the description fields are saved in a language neutral format that is unrecognizable to Sword of Moonlight 2000 tools. Furthermore all profiles are limited to 10 Unicode code points up to but not including the dotted file extensions: .PRF and .PRT. Actually, the limit was shortly relaxed for backwards compatibility with older project spaces. Longer names use a separate and unlimited "longname" storage system, however only the first 30 bytes of the name, and only after being converted to UTF-8, can be used by the PRO files to tell profiles from one another.
- Likewise if a project is edited with SOM_MAP its MAP files become unrecognizable to Sword of Moonlight 2000. Bottom line: it's impractical to go backwards project wise. But who would want to? Games remain backwards compatible (solely as a curiosity.) Actually this doesn't kick in until a project space includes a profile that does not fit into the oldstyle 0000.PRT to 1023.PRT namespace.
- If there are custom PRT files, the 30 byte icon field must be understood to be an immutable universally unique identifier. Authors should inquire into this before moving forward, or transferring a Sword of Moonlight 2000 project over, as complications will arise. A 22 byte Base64 encoded 128-bit UUID is recommended for this purpose. Best to just avoid the 63rd and 64th digits. In any case, @ and $ are recommended. This leaves room for 8 more bytes. Something like 0000.bmp, 0001.bmp, 0002.bmp, and so on is recommended. Altogether this should look something like 4Rp3KfNWHzzZQ9fbmiWfpw0002.bmp.
- A lower zoom angle is used by default in order to minimize distortion. It can be increased to the original angle (of 50) by pressing F3 or Alt+F3 if the function overlay is available (in which case F3 turns on invincibility ostensibly for playtesting purposes.) The selected angle is stored as 'zoom' in the game's INI configuration file.
- /action extensions
- /adjust extensions
- /analog extensions
- /author extensions
- /boxart extensions
- /bugfix extensions
- /button extensions
- /damage extensions
- /detail extensions
- /editor extensions
- /extension legend
- /joypad extensions
- /keygen extensions
- /keymap extensions
- /keypad extensions
- /launch extensions
- /list of extensions
- /list of numbers
- /number extensions
- /option extensions
- /output extensions
- /player extensions
- /sample extensions
- /script extensions
- /system extensions
- /window extensions