Mod Communication (1 Viewer)

[ModGuy]

In an attempt to empower mod developers, a need for communication between mods became apparent.
Here's the current idea behind the implementation:

var api:Dictionary = new Dictionary();

const propPersists:String = "apiPersists";
const propReset:String = "apiReset";
const propRegister:String = "apiRegister";
const propNotify:String = "apiNotify";

function registerAPI(apiName:String, apiDict:Dictionary, persists:Boolean = false):void
{
	api[apiName] = apiDict;
	api[apiName][propPersists] = persists;
	for (var key:String in api)
		if (key != apiName && api[key][propRegister])
				api[key][propRegister](apiName, apiDict);
}
function resetAPIs(force:Boolean = false):void
{
	for (var key:String in api)
		if (!api[key][propPersists] || force)
		{
			if(api[key][propReset])
				api[key][propReset]();
			delete api[key];
		}
}
function checkAPI(apiName:String):Boolean
{
	if(api[apiName]) return true;
	return false;
}
function getAPI(apiName:String):Dictionary
{
	if(checkAPI(apiName))
		return api[apiName];
	return null;
}

...

if (modRef.hasOwnProperty("init"))
	modRef.init();
if (modRef.hasOwnProperty("initl"))
	modRef.initl(this);
if (modRef.hasOwnProperty(propNotify))
	modRef[propNotify]();

...

You create some dictionary that contains methods and properties you wish to expose to other mods.
This is then passed to registerAPI("SOME_ID", THE_DICT, PERSISTS);
After the dictionary is registered, all other registered dicts are queried for the "apiRegister" method. If it exists it is called. This basically means that already loaded mods will be aware that this new mod has been loaded.
In the same way, if a mod contains the method "apiNotify" it is called after init or initl. Not sure what params should be passed in here tbh.
Registered dicts or "APIs" can be unregistered using resetAPIs. This ignores persistent entries unless the boolean value true is passed in.
You can freely check and request APIs using the ID string.


Now on to actual discussion. What else does this need?
I'm sure version info is important but that's a trivial addition to the registered dictionary and needs no action on my part.

 

[Doomknight]

So something like creating a C++ Library in a header/implementation file that could be used by multiple modders.

 

[ModGuy]

From the response this is getting, either the code is perfect or the idea is too vague to comment on.
The former is impossible so an elaboration is probably due:

Loader mods add functionality to SDT and users tend to stack multiple for more features.
There is currently no interplay between mods, at least no clean implementation. This idea will allow mods to expose variables and methods to other mods such that functionality can be shared or mods can become "aware" of one another.
For example:

One mod plays back Recording.txt files and provides user control for selecting which to play.
A different mod adds dialogue functionality and triggers.

If the dialogue mod exposed a method to add triggers at runtime then it would be possible to have some recording playback on trigger.
Likewise, when a recording reaches a certain frame of playback it would be possible to cue dialogue lines.

Of course, this is just one of a huge number of capabilities that would become available since you'd essentially be expanding the available functionality at runtime through dependencies.
Hope that clears this up.

 

[Pim_gd]

What can you communicate? Can I send instances of my custom class over?

 

[ModGuy]

The structure being used is a dictionary, you can put anything in it.
Flash doesn't seem to enforce strictly typed dictionaries so you're not bound to one type or class.

EDIT:
Loader with mod comms implemented. Example included.
Note: This is useless for the average user and adds no other features. Don't use this unless you plan to develop for the loader.

EDIT2:
Removed.

 

[Zalord]

What made the need for this apparent? Can you provide a specific example of an issue that this fixes? Not just a generic example, but an actual existing mod that would benefit from this?

 

[ModGuy]

What made the need for this apparent? Can you provide a specific example of an issue that this fixes? Not just a generic example, but an actual existing mod that would benefit from this?

One such example was raised by Pim in an effort to have Dante's mod react to gameplay.
Dante created a head for the him model but it remains fairly static in relation to the rest of the assets. In order to provide it with more behaviours Pim suggested that dialogue triggers manipulate the head to respond to game events. Without explicitly including the functionality this is not feasible from either end.
By allowing communication between mods it becomes possible for the head to register new dialogue triggers or listen for existing ones and execute procedures based on them.
Other mods would be able to do the same in a completely modular fashion, the ability to "extend" other mods without having to directly integrate a million functions in to one giant mod like... animtools or DA allows for:

Addons for addons, include what you want, remove what you don't.
Mod interplay, provide a graphical front end for a code based mod or an interactive hud for debugging.
Code reuse, my personal interest, you can invoke methods and grab properties from other mods without having to reimplement the same functionality. That's a great reason by itself.

 

[aztlan]

Having Him Heads interact with DA would be great.

 

[Zalord]

Does this mean you could essentially write "library" mods which provide new functions that can be used by other mods?

 

[ModGuy]

That's a possible application, yeah.

 

[Zalord]

Awesome. Can't wait to play around with this.