and Robert, I have made great progress working on a python scripting integration using boost::python to generate bindings.
I just want to make sure I understand how the Scripting examples work so that I can figure out the best way to distribute my own plugin when the time comes.
ScriptGeneratorPlugin is a UHT plugin. When UHT is configured to load ScriptGeneratorPlugin, a bunch of files are generated containing the glue that is the headers for the actual classes + the actual bindings.
ScriptPlugin is what actually includes the “GeneratedScriptHeaders.inc” or whatever, and also contains the pieces that expose the bindings to the engine, in ScriptEditorPlugin
So, the easy way to get started on this is to add a new language to these existing plugins, but that makes distribution and ownership complicated, as you are modifying a included plugin.
Ideally, I’d like to move my code into “MyScriptGeneratorPlugin” and “MyScriptPlugin”, but I have a few questions about this.
- Do ScriptGenerator plugins HAVE to be part of the entire Source/Engine structure in order for UHT to load them?
- How exactly does UHT find ScriptGeneratorPlugin?
- If I want to rapidly interate in terms of generating the bindings repeatedly, how can I run UHT without triggering an engine build+link? Right now I am deleting the headers generated and then doing it again but it still takes a long time and links the EXE’s at the end as if i changed a core engine file.
The goal is for me to have a completely seperate directory structure and repo for just my python bindings, so I can easily have ownership of the code, distribute it, and keep it in a public repo without breaking any licenses