CON mutator: Difference between revisions
Hendricks266 (talk | contribs) No edit summary |
Hendricks266 (talk | contribs) No edit summary |
||
Line 3: | Line 3: | ||
CON '''mutators''' are a specific kind of CON module that meets certain guidelines in order to be interoperable and compatible with base CON files and other mutators. Mutators can be used to alter game functionality in certain ways or provide "libraries" of sorts containing additional code assets for mappers, to name a few example uses. | CON '''mutators''' are a specific kind of CON module that meets certain guidelines in order to be interoperable and compatible with base CON files and other mutators. Mutators can be used to alter game functionality in certain ways or provide "libraries" of sorts containing additional code assets for mappers, to name a few example uses. | ||
==Replacing Actor Code== | ==Mechanics== | ||
===Replacing Actor Code=== | |||
Each time an [[actor]] or [[useractor]] block is created, its contents completely overwrite any others for the same tilenum above its position in CON compilation order. This is useful if you want to completely change an existing actor, and may be necessary for some changes albeit having to duplicate the code. | Each time an [[actor]] or [[useractor]] block is created, its contents completely overwrite any others for the same tilenum above its position in CON compilation order. This is useful if you want to completely change an existing actor, and may be necessary for some changes albeit having to duplicate the code. | ||
==Supplementing Actor Code and Event Code== | ===Supplementing Actor Code and Event Code=== | ||
Unlike actors, [[event]]s work in an additive fashion. All instances of EVENT blocks are compiled and used by the game. This allows for true "mutators". [[EVENT_GAME]] allows coders to modify actor code without completely replacing it as [[actor]] blocks do. | Unlike actors, [[event]]s work in an additive fashion. All instances of EVENT blocks are compiled and used by the game. This allows for true "mutators". [[EVENT_GAME]] allows coders to modify actor code without completely replacing it as [[actor]] blocks do. | ||
==Namespacing Variables== | ==Guidelines== | ||
For your mutator to be properly interoperable, any variables that are expected to retain | |||
===Namespacing Variables=== | |||
For your mutator to be properly interoperable, any variables that are expected to retain values from one tic to the next should be given a name with a prefix unique to your mutator. A variable like "temp" which is used and discarded immediately will only generate a warning if it is duplicated and may serve as an optimization to keep the total number of variables low. |
Revision as of 16:21, 23 May 2012
Introduced in EDuke32 are the concept of CON modules, which can be used with the -mx command line parameter. These are standalone CON files that make adjustments and additions to the code and can work in tandem with other modules.
CON mutators are a specific kind of CON module that meets certain guidelines in order to be interoperable and compatible with base CON files and other mutators. Mutators can be used to alter game functionality in certain ways or provide "libraries" of sorts containing additional code assets for mappers, to name a few example uses.
Mechanics
Replacing Actor Code
Each time an actor or useractor block is created, its contents completely overwrite any others for the same tilenum above its position in CON compilation order. This is useful if you want to completely change an existing actor, and may be necessary for some changes albeit having to duplicate the code.
Supplementing Actor Code and Event Code
Unlike actors, events work in an additive fashion. All instances of EVENT blocks are compiled and used by the game. This allows for true "mutators". EVENT_GAME allows coders to modify actor code without completely replacing it as actor blocks do.
Guidelines
Namespacing Variables
For your mutator to be properly interoperable, any variables that are expected to retain values from one tic to the next should be given a name with a prefix unique to your mutator. A variable like "temp" which is used and discarded immediately will only generate a warning if it is duplicated and may serve as an optimization to keep the total number of variables low.