Auto-Assemble Modifications

Auto-Assemble scripts can be used to provide extra functionality to Stored Addresses (see Auto-Assembler). This is typically used to allow an alternative method for locking values but is not limited to such functionality.

Auto-Assemble Used to Change an In-Game Constant

There are 3 sections in Auto-Assemble scripts used with Stored Addresses: [GLOBAL], [ENABLE], and [DISABLE]. The default section is [GLOBAL]. Sections may appear in any order within the script, but the resulting code may not be desirable if the sections are not followed immediately by a label.

The first time a section appears, the code in the section begins at address the address of the Stored Value unless a label is used to specify otherwise. All code in a single section (even if interrupted by another section and resumed later) is sequential unless labels are used to specify non-sequential addresses. For example, if the [ENABLE] section has 4 commands, then the [DISABLE] section begins and has 4 more commands, then another [ENABLE] section appears, the code added to the second [ENABLE] section is ultimately added to the end of the code in the first [ENABLE] section. The second [ENABLE] section does not resume where the [DISABLE] section ended, but where the previous [ENABLE] section ended.



The Auto-Assemble script is not used unless Use Auto-Assembler for Locking is checked. If not checked, the script is verified and compiled but not injected. If the Auto-Assembler script is used, regular locking mechanisms are disabled, leaving only the script to perform locking and unlocking.

The Preview button allows you to verify the script and to see a preview of what will be injected. Note that if the same script is applied to many Stored Addresses at once, and if the script allocates memory, each of the Stored Addresses will have memory allocated and so each script will be using different addresses for some things, so the preview will only be accurate for one of the items, but should suffice.

If multiple Stored Addresses are being edited at once, the supplied script will be applied to each of them. You may leave the edit area blank to allow each Stored Address to keep its current script. This means that it is not possible to remove the script from multiple Stored Addresses at once. If the edit area is blank and only one Stored Address is being edited, the script for that item is removed. Set the Use Auto-Assembler for Locking to indeterminate to allow each item to keep their current settings for using the script or not.



This is the default section. The code in this section is injected as long as the Stored Address is using Auto-Assemble for locking, whether the actual item itself is locked or not.

The code starts in this section and remains until another section is specified. You can use the [GLOBAL] tag in the script to return to this section later. As mentioned above, all [GLOBAL] sections resume where the previous [GLOBAL] section left off.



The code in this section is injected once when the item is locked. This is not uninjected when the item is unlocked, unless the [DISABLE] section has code to manually uninject it.



The code in this section is injected once when the item is unlocked. This is typically used to clean up any messes made by the [ENABLE] code.



Other Auto-Assemble commands such as Alloc() and DeAlloc() work the same way as with regular Auto-Assembler scripts. Allocations are only made once when the script is compiled and are only deallocated when the script is fully closed (the Stored Address is deleted or MHS detaches from the target process).

In any case where the script is discarded, the script cleans up after itself with the exception of allocated addresses that have not been used in a DeAlloc() command. All modified RAM, however, is reset to what it was before the script was used. The script is discarded when the Stored Address is removed from the main list, a new script is written for it, or when MHS detaches from the target process for any reason.

Copyright © 2006 Shawn (L. Spiro) Wilcoxen