jjohn
06-22-2003, 03:04 PM
Right now, there are only a few public mods to FQ. Some day, there may be more. *Scripted mods, mods that replace welcome.swf or other core flash files, or even mods that affect the old flat files all need a clean way to be installed on deployed FQ systems. *There are several pitfalls looming:
<ul>
* Scripted events must all modify script_event.c
* New items may (ought) to modify init.c to define the
* * * inventory slots needed
* New items will modify either store_supplies.c or store_security.c
* events, places and items may want to run code in the the maint.c or maint_player.c files.
* stats.c may be modified to reflect new items
* Since church.c is the easiest place to modify, it is a likely place to see conflicting mods
[/list]
How can mods be distributed in a way that doesn't blow away existing mods? *The most naive way (and the way I'm doing it) is to create a zip file with the unique files and a readme that includes instructions on hand modifying common resource files, like the ones mentioned above. *This, of course, makes new mods increasingly risky for admins who may inadvertently overwrite a previous mods' settings.
I'd like to suggest creating a mod registry of sorts. *This registry can be as simple a thread on this forum or perhaps it's a local file in FQ. Mod author would need to update the registry with at least the following information:
<ul>
* new global variables (presumably put in init.c)
* new constants (also put in init.c)
* inventory slots used (remember, there are only 200)
[/list]
I realize that this all seems overly complicated right now with so few mods, but I wanted to raise the issue now so that when it becomes a problem, we'll be that much closer to a solution. *
One unlikely solution is that all mods should be submitted to a central manager who checks for conflicts. *I doubt anyone wants this task though. *Others may publish mods, but the central mod manager offers some level of comfort that the mods he offers have some level of conflict detection done.
<ul>
* Scripted events must all modify script_event.c
* New items may (ought) to modify init.c to define the
* * * inventory slots needed
* New items will modify either store_supplies.c or store_security.c
* events, places and items may want to run code in the the maint.c or maint_player.c files.
* stats.c may be modified to reflect new items
* Since church.c is the easiest place to modify, it is a likely place to see conflicting mods
[/list]
How can mods be distributed in a way that doesn't blow away existing mods? *The most naive way (and the way I'm doing it) is to create a zip file with the unique files and a readme that includes instructions on hand modifying common resource files, like the ones mentioned above. *This, of course, makes new mods increasingly risky for admins who may inadvertently overwrite a previous mods' settings.
I'd like to suggest creating a mod registry of sorts. *This registry can be as simple a thread on this forum or perhaps it's a local file in FQ. Mod author would need to update the registry with at least the following information:
<ul>
* new global variables (presumably put in init.c)
* new constants (also put in init.c)
* inventory slots used (remember, there are only 200)
[/list]
I realize that this all seems overly complicated right now with so few mods, but I wanted to raise the issue now so that when it becomes a problem, we'll be that much closer to a solution. *
One unlikely solution is that all mods should be submitted to a central manager who checks for conflicts. *I doubt anyone wants this task though. *Others may publish mods, but the central mod manager offers some level of comfort that the mods he offers have some level of conflict detection done.