Adding equipment via OXPs
Posted: Fri Apr 21, 2006 10:16 am
I got thinking today and have a couple of suggestions to run by the group for changes to the game engine.
The point of these changes is so people can create new equipment without it having to go into the main game engine, such as winston's targeting system and my flotsam scanner.
I'm guessing the first two suggestions will not be too hard, the third one I'm not so confident about.
1. Bind keys to scripts
OXPs could contain keyconfig.plist files that get added on to the game's own one like other OXP plists.
A new feature of the keyconfig.plist would be the "script" dictionary key, whose value is a script, like this:
There would be problems with two OXPs potentially using the same key, or the user having reconfigured their keyconfig.oxp, so some code would have to be added to check for key usage conflict.
The part of the code that checks for keypresses would change to also search the bound script list, and execute a script bound to a key as soon as that key is pressed.
2. More script interfaces to the ship's onboard systems
Just keep adding new methods for the scripting engine, such as targetNext: scan_class, targetPrevious: scan_class, getTargetInfo: infotype, setTargetScanColour: 0xFFFFFF, etc.
This assumes the ship's systems have more programmatic interfaces than have been revealed before. No Elite-a-like has ever been scriptable so this aspect can be considered to have been just hidden, not unavailable.
3. Allow new equipment.plist entires in OXPs
OXPs can add to the equipment dictionary.
We may need more entries in the OXP equiment.plist file, I'm not sure. How much damage can any given piece of equipment take, for example? Or do we need to define dependencies on other equipment already being installed? Perhaps this can be handled by a set of conditions, which would allow mission variables and other game state to be taken into account when deciding if a piece of equipment should be available.
Anyway, if you combine these entries with the scriptable keystrokes you should end up with a new type of equipment, defined entirely within an OXP. Then it becomes a matter of exposing enough of the engine to the scripting environment to make worthwhile widgets possible.
The point of these changes is so people can create new equipment without it having to go into the main game engine, such as winston's targeting system and my flotsam scanner.
I'm guessing the first two suggestions will not be too hard, the third one I'm not so confident about.
1. Bind keys to scripts
OXPs could contain keyconfig.plist files that get added on to the game's own one like other OXP plists.
A new feature of the keyconfig.plist would be the "script" dictionary key, whose value is a script, like this:
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>scripts</key>
<dict>
<key>121</key>
<array>
<dict>
<key>conditions</key>
<array>
... conditions here
</array>
<key>do</key>
<array>
... actions bound to this key
</array>
</dict>
</array>
</dict>
</dict>
</plist>
The part of the code that checks for keypresses would change to also search the bound script list, and execute a script bound to a key as soon as that key is pressed.
2. More script interfaces to the ship's onboard systems
Just keep adding new methods for the scripting engine, such as targetNext: scan_class, targetPrevious: scan_class, getTargetInfo: infotype, setTargetScanColour: 0xFFFFFF, etc.
This assumes the ship's systems have more programmatic interfaces than have been revealed before. No Elite-a-like has ever been scriptable so this aspect can be considered to have been just hidden, not unavailable.
3. Allow new equipment.plist entires in OXPs
OXPs can add to the equipment dictionary.
We may need more entries in the OXP equiment.plist file, I'm not sure. How much damage can any given piece of equipment take, for example? Or do we need to define dependencies on other equipment already being installed? Perhaps this can be handled by a set of conditions, which would allow mission variables and other game state to be taken into account when deciding if a piece of equipment should be available.
Anyway, if you combine these entries with the scriptable keystrokes you should end up with a new type of equipment, defined entirely within an OXP. Then it becomes a matter of exposing enough of the engine to the scripting environment to make worthwhile widgets possible.