Repository navigation
Mod to Mod communication
Mod-to-Mod communication is where 2 or more mods talk to eachother. That means that they share data or inform others of certain things.
Not all mods work with all mods. But mod-to-mod communication can allow mods to acknowledge eachother and try to work well together.
Here are the methods:
You can make a function global or a variable global and mods can use that function to communicate or use the variable to alert eachother.
CelLuAPI has a way for mod-to-mod communcation that is pretty simple. Mods, in their return table, can put a property called onModSignalRecieved which is a function that gets 2 parameters, the signal sender (aka where the signal claims it was from) and the signal itself (the data sent).
You can also send one using sendSignal(whereItCameFrom, whereItMustGo, theSignalData) or broadcastSignal(whereItCameFrom, theSignalData). broadcastSignal sends it to all mods btw.
But, maybe the built-in signaling is too difficult? Well, there is the Synapse API that is an improvement of the signalling API. It is a part of CelLuAPI, its in the libs folder.
This documentation is based off of the latest version of Synapse, the one that was added as a built in version into the API.
Synapse is not that similar to the built-in signaling API, but it is still pretty intuitive.
The global Synapse object is a table containing functions.
The functions are:
- addListener
- removeListener
- setListener
- createMessageBlock
- isListener
- connect
- getCachedConnection
Synapse.addListener
It takes 2 arguments, the id and a callback function.
The callback function gets two parameters: the message sent and the type of message sent. It can also return a response.
Synapse.removeListener
It takes id, and removes the listener.
Synapse.setListener
It takes id and new callback. Overrides callback based off of id.
Synapse.createMessageBlock
It takes 2 arguments, message and status code, and gives a table with 2 properties, msg (the message) and code (the status). The status code can be literally anything, so can the message.
Synapse.isListener
It takes 1 argument, the id, and returns if there is a listener with that id. Note: all listener IDs must be unique.
Synapse.connect
It takes 2 arguments, the listener connecting and the listener to connect to. It also has a optional argument, the connection data, to help the listener you are connecting to understand the connection better.
If there is a Synapse listener to connect to, it notifies it about a "connection-start" event, where the message is the connector, tho it also gets in this case a 3rd argument passed in, the connection data, that is passed through the Synapse.connect function. The listener you are connecting to can return false as its response to signify that the connection has been cancelled. If the connection is cancelled, Synapse.connect is going to return nil as the connection and nil as the connection ID.
It returns a table representing the connection and a number representing the id of the connection. That table's main properties are signal, signalVanilla and dispose.
The signal function is a function that signals the other listener. It also returns the response of the other listener. This makes it very similar to REST APIs, if you have worked with them.
The signalVanilla function is a function that uses the built-in signaling API to signal the mod of the same name as the connected.
The dispose function is pretty interesting. All connections are cached, and if you have their ID you can get the connection uses Synapse.getCachedConnection. The dispose function removes it from the connections table, but doesn't neccesarily make the connection unusable. This could be done to avoid other mods from getting the connection and messing with it, to keep the connection an internal thing.
Synapse.getCachedConnection
It takes the id of the connection and returns the connection with that ID. Returns nil if there is none.