Sword of Moonlight Extension Library

From Wiki

Jump to: navigation, search
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
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.
+
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==
 
==Version history==
Line 12: Line 12:
 
==Breaking changes==
 
==Breaking changes==
 
<!--this section should highlight changes that authors should know about before getting started-->
 
<!--this section should highlight changes that authors should know about before getting started-->
−
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.
+
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 [[/list of counters|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.
+
*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.  
 
*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.
 
*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.
 
*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 [[Wikipedia:Preferred walking speed|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.
 
*It is recommended that a [[Wikipedia:Preferred walking speed|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 file]]s. 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 [[Wikipedia:Unicode|Unicode]] [[Wikipedia:code points|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 file]]s 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 file]]s, the 30 byte icon field must be understood to be an immutable [[Wikipedia:UUID|universally unique identifier]]. Authors should inquire into this before moving forward, or transferring a Sword of Moonlight 2000 project over, as complications <u>will</u> arise. A 22 byte [[Wikipedia:Base64|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[http://www.swordofmoonlight.net/wp-admin/admin.php?page=store].
 +
 +
*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.
  
 
==See also==
 
==See also==
 
*[[Sword of Moonlight/Ex]]
 
*[[Sword of Moonlight/Ex]]
 
*[[/list of extensions]]
 
*[[/list of extensions]]
−
*[[/list of counters]]
+
*[[/list of numbers]]
−
*[[/list of nothings]]
 
  
 
==Subpages==  
 
==Subpages==  

Latest revision as of 08:12, 3 November 2015

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[edit]

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[edit]

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[1].
  • 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.

See also[edit]

Subpages[edit]

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