I found some time this weekend to begin working on a utility that will activate përses and spöb defense fleets in a plugin without starting a new pilot. I immediately ran into a few problems in planning the thing out. Here are the issues, and I'm hoping people can offer constructive criticism/advice:
1.) In its simplest form, this utility (tenatively being called BitChanger) reads through the plugins, determines whether there are përs or spöb resources in them. If there are përs resources, the bits in the pilot file for those pilots would be toggled to 1 and if there are spöbs, the defense fleet data is read from the resource and put into the appropriate part in the pilot file. This is problematic for a few reasons. First, if the player has been attacking a planet that is altered in a subtle way by the plugin, the defense fleet will be reset. Also, this method would activate any përs it finds in any plugin in the plugin folder. A modified version of this would be for the application to ask which plugin to examine and then have it look only at data in that plugin. Because the .rez data format has not been released, this means this method would not be able to be used on Windows.
2.) The plugin author could use a hypothetical utility called BitChangerAuthor. This application would allow the plugin maker to make a data set of përses and spöbs they want activated by BitChanger. This data could then be stored either as a resource in the plugin they make (cbďt) or as a text file (with a .cbit suffix). BitChanger would then look either for a text file with the .cbit sufifx or cbďt resources in plugins, at which point bitChanger would modify the pilot file as specified by the cbit data. Because it could exist as a text file, this means the BitChanger utility would work on windows. The cbit format for the text file would also be in human editable form, meaning one could generate it using a spreadsheet if one wanted. This does not eliminate the possibility of reloading previously modified spob or pers data (i.e. you use BitChanger to activate pers resources found in plugin 1, then put in plugin 2 and run bitChanger again, which reactivates perses in plugin 1 and activates the peres in plugin 2).
3.) A potential solution to this is to write novel data to the pilot file as to what plugins have been activated. For example, if one had the plugin 'MyCoolPlug' which added 3 perses, BitChanger would make a STR# resource in the pilot file that would record the name 'MyCoolPlug'. Then, if BitChanger was launched again, it would skip the plugin MyCoolPlug (unless a mod key was held down, forcing it to load all available cbit data).
I'm definitely leaning toward the text file cbit idea as it would be the easiest to implement on mac and win and would be easy for plug developers to setup. It also suggests a method by which the engine itself can be modified so as to rectify this new pers/spob problem.
A final note: pilot files record whether the player has seen the intro screen or not. The engine seems to ignore this data, though, and assumes that if you loaded a file, you've seen the intro screen. I imagine that plug makers could think of all kinds of cool uses for sending the player to the introscreen when a pilot is loaded (chapters in a story, depending on what plugin is loaded). If there is interest, I will include the ability to toggle this bit on the assumption that plug developers might be able to convince Ambrosia that this is a feature that would be well worth adding if there are going to be any new updates to the engine.
Let me know what you think, please.
-STH
------------------
"Create enigmas, not explanations." -Robert Smithson