How Can We Help?
Flowchart
1. Author wants a feature template provides and makes a character using it
2. Author must use template for their own character
3. Author can now use all other characters that use this template.
4. This spreads the collective idea of a template among authors
5. As the template spreads, a higher number of characters that require the template to function will appear, increasing the reasons to use it.
6. With higher amount of interest in the template, it can be further developed to include more features (Backwards compatibility guarantee), causing a feedback loop.
7. The amount of authors using the template increases, reducing the amount of WinMugen only characters
Note that a similar template can be developed for WinMugen if desired, but the secondary goal is to create a template good enough for WinMugen authors to be satisfied.
As a little bit of trivia, there are also winmugen characters that disable winmugen exploits so that’s what I mean about being on left side is all that matters in cheapie wars
Free Memory Read/Write
First, let’s go over one of the most common types of features you can expect from low level WinMugen characters, removing Variable Reading and Variable Writing limits
In short, this allows you to read any game memory and write to any game memory
The lowest effort implementation of such things are used to instantly KO your opponent, (Var(-7) := 0)
But the reading capability is just as important as the writing capability,
This involves an annoying amount of pointers and understanding of offsets for every specific parameter.
Additionally such literal designs very rarely work on both 1.0 and 1.1
Since the offsets changed over time.
To avoid requiring to remember a very high amount of offsets, we can use Words to refer to concepts instead, Custom Triggers
Note that ability to read any memory region is still enabled with this template
If you attempt to read an invalid memory area, the game will crash, but there’s no real security risk in that.
However free writing to any region is deemed a potential risk and is therefore not enabled.
Custom Triggers
The proposed method to bridge the gap between freedom and ease of use (ease of development) involves Custom Triggers
Such triggers are used to represent reading/writing to additional concepts that the game does not support by default.
Since the template is version specific, there is no risk of offset differences when using Words instead of Numbers.
Free Assign Rules
For Custom Triggers to function similarly to Free Variable Writing
All custom triggers must be capable of reading/writing
While there may have been success in trying to emulate the behaviour of Variable Assignment in itself, the main goal is the use of Parenthesized Triggers, as you can read in the Inherited/New Trigger Chapters.
Additionally, because of the new type of Structure
This also allows you to use ‘assignment’ after direction
This was impossible previously.
Writing Alive to 0
Trigger1 = 1 || Alive(0)
Trigger1 = 1 || Enemy(0),Alive(0)
Note that this removes the requirement to use the awkward and limited conditional bug
Trigger1 = 1 || Enemy(0),Cond(0, 0, Alive(0))
In the next Section, Returning/Inherited Triggers and New Triggers
To give an idea of the Returning/Extended Trigger Functionality the template provides.
Other Potential Features
Additionally potential features include
Psuedo Functions
Triggers that take arguments (potentially multiple arguments)
The main planned implementation is to do intensive operations simply
VarCopyID() might copy the variables of the specified Player of ID
Such a thing would include over 100 operations normally but can be reduced The main goal is usually convenience and to reduce clutter, however it can also greatly improve performance speed.
Redirections
Adding new Redirections to find Players with a specific condition
Most importantly is adding a more functional Target redirection however.