Sword of Moonlight Extension Library

From Wiki

Jump to: navigation, search

The Sword of Moonlight Extension Library or SomEx (short for SomEx.dll, pronounced like Psalm X) is an unofficial Sword of Moonlight 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.6 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.
  • 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.

See also

Subpages

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