Part 1 : Edif
First of all, I'd like to announce my new SDK for MMF2 extension development. It's called Edif - "Extension Development Is Fun".
Extension development has always been very much centred around tedious population of the info tables, resources, menus and jump tables, with a low proportion of the time actually spent on writing the code.
In 2007, Villy and I made an attempt to rectify this with a new, macro-based SDK for MMF2 based on some earlier work by Turboferret, called rSDK. Although rSDK sped up extension development a lot (nearly all of my extensions have been rSDK extensions, and that's around thirty now) it introduced a new set of problems of its own.
rSDK extensions didn't work with Visual Studio's intellisense due to heavily use (abuse, maybe) of macros. They were also impossible to translate since the strings weren't part of the resources (all official CT extensions are translated to French, so I haven't been able to use rSDK for, say, the Mochi extensions), and many bugs have been dug up over the years, such as crashes in nested expressions. rSDK also didn't solve the problem of the LPRDATA (rdPtr) structure not being allocated properly, so you still had to store everything as pointers, create them in CreateRunObject, and delete them in DestroyRunObject.
Another problem common to the normal SDK and rSDK is that code reuse is impossible, without writing your extension in a class and having the actions/conditions/expressions as simple wrappers (more tedious wrapping work). Actions/conditions/expressions can't call other actions/conditions/expressions, because the parameters aren't real C++ parameters - they're provided via special functions (CNC_GetParameter*, wrapper with Param() and ExParam() in rSDK).
Edif is my attempt to solve this situation. With Edif:
* Your extension is a simple C++ class. Actions, conditions and expressions are member functions, with real parameters and real return types. They can call each other (obviously) and you link them to be used as the actions/conditions/expressions by calling, for example, LinkExpression(0, MyExpression) in the constructor of your extension class, to link the member function MyExpression to expression ID 0.
If MyExpression took a float parameter and an integer parameter and returned a float of the two added together, it'd look like this:
All the GetParameter stuff, setting the flags, and giving the return value back to MMF, is handled by Edif. It uses assembler code to dynamically push the action arguments so that they arrive as real function arguments, and call the action function in the Extension class.
float Extension::MyExpression(float MyFirstParameter, int MySecondParameter)
return MyFirstParameter + MySecondParameter;
* Since your extension is a real C++ class, you simply add what you want to store at runtime (which would normally go in rdPtr) as class members. The constructors/destructors will be called properly, and you can access them without putting rdPtr-> everywhere in your actions, conditions and expressions.
* The Extension class (and the edittime stuff, which is the same in Edif as the normal SDK or rSDK) is the only thing inside the MFX file. Edif extensions also have an external JSON file (well, it's actually a slightly modified JSON syntax that doesn't require commas) which contains the object name, description, etc, and a description of each individual action/condition/expression and its parameters. It also contains the menu in a JSON-ified form.
All the strings in the JSON file can easily be specified in multiple languages using a special syntax, and Edif will automatically detect if the current version of MMF is English or French, and choose the appropriate string. UTF-8 support for the Unicode version of MMF is planned.
This leads on to...
Part 2 : AS Dynamics
If you're a user of Flash runtime, you've probably been following/waiting for my AS Dynamics object, the "custom ActionScript" object.
You'll probably be disappointed to hear that you're never going to see it. Here's why you shouldn't be.
Flash Player can not interpret AS 3.0 at runtime. This means that an object along the lines of the Lua objects but for ActionScript is completely impossible. Any AS 3.0 code must be written at edittime and compiled into the SWF.
To get around this and allow people to write custom AS code, I got Yves/Francois to add a special feature to build 250. The way the SWF exporter works is that it extracts the entire runtime source to a temporary directory, adds in all the extensions, and then invokes the Flex compiler to build it into a SWF. The new feature means that it's now possible for an extension to hook into this build process and modify the contents of that temp folder before the Flex compiler gets invoked.
The AS Dynamics object let you write an ActionScript file, and then call functions from it in a manner similar to the Lua objects (push argument, call function, etc) at runtime. It did this by modifying the AS Dynamics extension ActionScript at build time, to tell it to import this ActionScript file and how it was allowed to call it.
When this was nearly finished, I got assigned the task of writing the Newgrounds API object. After five or ten minutes with the standard SDK, I began to wonder whether it'd take much longer to write a new, quick to use SDK and implement the object in that. That's where Edif came from.
Edif deprecated AS Dynamics, before it was even released. Because all the information about the extension is external to the MFX file, if you don't mind your extension doing nothing in the C++ version, you can just copy-paste a precompiled Edif MFX, write new JSON to describe the extension and its actions/conditions/expressions, and then implement them in ActionScript only. You can make an extension for the Flash runtime without even having a C++ compiler installed, let alone touching a line of C++. Extension development is now open to anyone who can code ActionScript - at least, when some tutorials have been written, anyway.
Edif topic is over here