You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is simply documentation for a feature we could introduce in the future.
It is not currently in the plans as there are no concepts which could leverage it yet.
Problem
One of the feature losses we encountered when moving from the old Event Inspector client to RSProx is that we no longer have the ability to directly communicate with the client. We cannot provide our own custom plugins, nor can we edit anything. Both the client and RSProx are stand-alone tools which do not communicate with one another, only the original network traffic passes through RSProx.
What if we wanted to create a plugin which allowed us to communicate between RSProx and the RuneLite client? An example of this would be Cjay's dialogue plugin that was in the old Event Inspector. It marked NPCs which were already spoken to and requires some features that the official RuneLite does not support for accurate dialogues.
Solution
The RuneLite which RSProx launches enables developer tools and the use of side-loaded plugins, which are normally only possible in a development environment (running via IntelliJ). We could create our own plugins, one on RSProx's side, one on RuneLite's side, and allow them to be "downloaded" via RSProx's GUI, which essentially just copies the necessary jars to RuneLite's side-loaded plugins directory.
The two separate processes could communicate between one another using Unix Sockets and/or Java's WatchService.
This would allow us to pass precise packet-level information from RSProx to RuneLite, allowing the plugin to render and store data as per usual. In order to achieve this nicely, we would need to create a simple-to-use API that both the RSProx plugin and RuneLite plugin could utilize for communications between one another, such as passing primitive data types, strings and even serialized objects. Json would likely be a good fit for data transmission, but a nicer API should still sit on-top to allow calls such as readInt or readObject<Type>.
Note that this issue strictly applies to RuneLite, as we have no way of creating such plugins on the C++ clients.
The text was updated successfully, but these errors were encountered:
Note
This is simply documentation for a feature we could introduce in the future.
It is not currently in the plans as there are no concepts which could leverage it yet.
Problem
One of the feature losses we encountered when moving from the old Event Inspector client to RSProx is that we no longer have the ability to directly communicate with the client. We cannot provide our own custom plugins, nor can we edit anything. Both the client and RSProx are stand-alone tools which do not communicate with one another, only the original network traffic passes through RSProx.
What if we wanted to create a plugin which allowed us to communicate between RSProx and the RuneLite client? An example of this would be Cjay's dialogue plugin that was in the old Event Inspector. It marked NPCs which were already spoken to and requires some features that the official RuneLite does not support for accurate dialogues.
Solution
The RuneLite which RSProx launches enables developer tools and the use of side-loaded plugins, which are normally only possible in a development environment (running via IntelliJ). We could create our own plugins, one on RSProx's side, one on RuneLite's side, and allow them to be "downloaded" via RSProx's GUI, which essentially just copies the necessary jars to RuneLite's side-loaded plugins directory.
The two separate processes could communicate between one another using Unix Sockets and/or Java's WatchService.
This would allow us to pass precise packet-level information from RSProx to RuneLite, allowing the plugin to render and store data as per usual. In order to achieve this nicely, we would need to create a simple-to-use API that both the RSProx plugin and RuneLite plugin could utilize for communications between one another, such as passing primitive data types, strings and even serialized objects. Json would likely be a good fit for data transmission, but a nicer API should still sit on-top to allow calls such as
readInt
orreadObject<Type>
.Note that this issue strictly applies to RuneLite, as we have no way of creating such plugins on the C++ clients.
The text was updated successfully, but these errors were encountered: