Sword of Moonlight Extension Library

From Wiki

Jump to: navigation, search

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

Version history

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 1.1.1.7 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 1.1.1.8 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.

Breaking changes

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.

  • Games should include a special counter called "Ex". This ensures the broken game clock is fixed by detecting Game Over (when all counters are reset to 0) and resetting the clock if nothing else. A game should set this counter to 3 and advance the event to see if it gets set back to 1 or 2. Otherwise the game should show a message to the player warning that the game can become corrupt if saved. As of version 1.1.2.10 "Ex" is no longer necessary for the in-game clock to work. It's other uses are on schedule to be phased out as well.
  • 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.
  • The library will attempt to generate default equipment to ensure that the player is always equipped. This is important so that the gauges and presentation remain consistent. New control features may be broken if this requirement cannot be met. At the minimum three item IDs must remain unused. Although it is possible to designate your own items to act as the defaults so that is not necessary to generate them.
  • 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[1].

See also

Subpages

Retrieved from "http://en.swordofmoonlight.org/w/index.php?title=Sword_of_Moonlight_Extension_Library&oldid=2336"