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:

[*]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&#39;t blow away existing mods? The most naive way (and the way I&#39;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&#39; settings.

I&#39;d like to suggest creating a mod registry of sorts. This registry can be as simple a thread on this forum or perhaps it&#39;s a local file in FQ. Mod author would need to update the registry with at least the following information:

[*]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&#39;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.