OpenMW-CS Plugins

[psi29a]

It has been mentioned a few times, but I wanted to know if any real thought has been given to how plugins would work in the OpenMW-CS?

I have a canidate, TESAnnwyn that I'm working on. I've refactored the code to have two parts, a standalone CLI (like everyone knows) and the library itself used by the CLI. I plan on adding Python bindings so it can be used to import and export TES3 heightmaps for WorldEngine.

So I guess the question is... how will this work? What kind of API and hooks? Python, C, more?

[Zini]

We don't have any real plans for plugin support yet. But here are my thoughts so far.

We should use Python for plugins. Its a good language and well suited for the task. I mentioned the sandboxing issue before when we discussed using Python as scripting language for OpenMW. But I don't think that is relevant here. We can't sandbox our OpenMW-CS plugins or else we cut down too much on their usefulness.

There should be two ways to run python scripts with OpenMW-CS.

1. Command line mode (yet to be implemented): Run OpenMW-CS without a GUI; load content file(s) and process/modify them from a Python-script.

2. Editor-extensions: Allow plugins to add UI elements that can trigger python scripts. Examples would be adding a new lighting mode, a new scene editing mode or a complete new tool.

For both cases would would have to expose read-only access to the records and the ability to issue commands (to modify the records). For #2 we would also need to expose some of the GUI functionality (adding buttons, menu items, add new subview types) and the 3D scene functionality (camera controls, lighting and lots more).

[psi29a]

Are you/we going to have pre-defined GUI layout (via Qt) options?

Or can the plugin make use of, say, PyQt for it's own GUI management, for example that the plugin has its own GUI?

In addition to this, is tesannwyn a candidate for a plugin or is its usefulness better served in openmw-cs itself? I don't mind either way, I just want to know how useful it would be. If it is built into OpenMW-CS, I can develop it further there. As an apart plugin, it can be developed at a different pace.

[Zini]

I don't have a good answer to either question yet. Sorry. So far working out the concept for plugin support has been very much at the bottom of my to do list.

[psi29a]

At least this thread exists and you answered it.

I'll get back to librarifying tesannwyn. I'm hoping that when it is finished, lightwave will commit support for tes4 and tes5 heightmaps.

Another question before you go, heightmaps in OpenMW aren't capped are they?

[Zini]

Not per se (other then through the limitation of the float type). However the height difference between two neighbouring points is limited by the range of a signed 8 bit integer value multiplied by a factor of 8. I think it is slightly more complicated than that (very complex format), but I would have to look that up in the source. scrawl should have the details (if they are needed).

[psi29a]

The gradient can only be between +127 or -128 (8-bit), otherwise it under or overflows and has to be corrected in tesannwyn, but I meant in terms of height as Morrowind clips at a certain point. The Morrowind game engine has a 16-bit height range limit, ironically the original CS didn't.

This isn't a problem for OpenMW right?

[Zini]

I am 99% sure that this isn't the case. @scrawl Can you confirm?

[scrawl]

The gradient can only be between +127 or -128 (8-bit), otherwise it under or overflows and has to be corrected in tesannwyn, but I meant in terms of height as Morrowind clips at a certain point. The Morrowind game engine has a 16-bit height range limit, ironically the original CS didn't.

This isn't a problem for OpenMW right?

Not that I know of.

[psi29a]

Lucius of DaggerXL/XLEngine has been wrestling with the LUA/Angelscript/Python problem and decided to make his own XLC, a JIT C99 based "scripting" language that is sandboxed.

I asked if he would be willing to make a library of it, perhaps this is something we can support?

http://xlengine.com/forums/viewtopic.ph ... 74&p=10445

XLC stands for XL Engine “C”, which uses JIT compiled “C99″ as the basis for the scripting system. In order to improve the scripting experience, the environment is sandboxed (only engine provided functions and services are available) and the API is written in a way that avoids or hides the use of pointers and avoids user memory management. The language is not hobbled, however, and advanced users can use the full power of C. The compiler is built into the engine and compiles code, as needed, directly into memory. This means that the engine can call script functions with very little overhead, memory and data can be shared between scripts and the engine and scripts can call into the engine with the same cost as calling any C or C++ function using a pointer.