SUBSIM Radio Room Forums - View Single Post

Commander Gizmo · 09-23-09, 08:10 AM

I feel I should point out that I am mostly offering to build the UI for all of this, which would then accept plugins to handle the actual grunt work. I would be happy to write the main plugins for the app, but the community could create their own as well.

For those of you unfamiliar with how programming with plugins works, here is a quick review: The application exposes an interface which specifies what commands it will accept. A plugin can either give commands, handle commands, or both.

For example, if someone wrote a plugin that knew how to parse and change the data in a *.dat file for SH5, it would register to handle commands sent to the application for that data type. However, if the plugin wanted to create some dynamic data prior to loading the game (such as randomizing a value like the crush depth), it would send the command to the application to edit a particular file, at which point the application would call the plugin that knows how to handle that file. That could even be the same plugin (though I would hope whoever writes them knows enough to separate them as they should).

Another plugin type could simply request data from the application about certain files in order to verify that they match what is desired. This would permit someone to write code to find particular issues or problems commonly experienced by users and then resolve the issue. An example: The flat sun fix. Many users report an issue with a flat sun and the cause is known. In the process of installing a mod or resolving common issues for a user, it could ask if they are experiencing this issue and then change the values accordingly to resolve it.

These are simply a few ways that this sort of open ended modular design permits. Because the software does not limit what changes occur, but rather just exposes the data to be altered a user can set up things however they want. And because the software simply exposes the data in a modifiable form with automation available, it would be possible to programmaticly handle just about whatever you wanted to do with that data. Basically turning the SH3 data files into a database.

What is more, the intent is to make the application COM accessible (why not?) which means that it would accept a basic command set from other software should someone care to make use of it.

09-23-09, 08:10 AM	#2
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	A bit more detail perhaps? I feel I should point out that I am mostly offering to build the UI for all of this, which would then accept plugins to handle the actual grunt work. I would be happy to write the main plugins for the app, but the community could create their own as well. For those of you unfamiliar with how programming with plugins works, here is a quick review: The application exposes an interface which specifies what commands it will accept. A plugin can either give commands, handle commands, or both. For example, if someone wrote a plugin that knew how to parse and change the data in a *.dat file for SH5, it would register to handle commands sent to the application for that data type. However, if the plugin wanted to create some dynamic data prior to loading the game (such as randomizing a value like the crush depth), it would send the command to the application to edit a particular file, at which point the application would call the plugin that knows how to handle that file. That could even be the same plugin (though I would hope whoever writes them knows enough to separate them as they should). Another plugin type could simply request data from the application about certain files in order to verify that they match what is desired. This would permit someone to write code to find particular issues or problems commonly experienced by users and then resolve the issue. An example: The flat sun fix. Many users report an issue with a flat sun and the cause is known. In the process of installing a mod or resolving common issues for a user, it could ask if they are experiencing this issue and then change the values accordingly to resolve it. These are simply a few ways that this sort of open ended modular design permits. Because the software does not limit what changes occur, but rather just exposes the data to be altered a user can set up things however they want. And because the software simply exposes the data in a modifiable form with automation available, it would be possible to programmaticly handle just about whatever you wanted to do with that data. Basically turning the SH3 data files into a database. What is more, the intent is to make the application COM accessible (why not?) which means that it would accept a basic command set from other software should someone care to make use of it.