[post-1.0] Scripting enhancemnts

Everything about development and the OpenMW source code.
Post Reply
User avatar
psi29a
Posts: 5361
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: [post-1.0] Scripting enhancemnts

Post by psi29a »

Python has my heart, white space is king leaving you with an enforced style which helps newbies.

Lua is like the javascript version of Python. It is lightweight and can do darn near everything.

If you do not need all the wonderful libs available for Python, then I would go with Lua.

Nice write-up here: http://lua-users.org/wiki/LuaVersusPython

That being said, getting either Lua or Python into OpenMW will require us to create a dialect or domain specific language (DSL) of them that still keep to the theme of the original Morrowind scripting system (for backward compatibility).

Another thought came to mind, leave the API exposed and let other people use whatever language they want? If people want to write python, lua, javascript, ruby or whatever... they just need an API against it. Leave it up to the modder to pick the language they feel comfortable with.
wheybags
Posts: 207
Joined: 21 Dec 2012, 19:41

Re: [post-1.0] Scripting enhancemnts

Post by wheybags »

BrotherBrick wrote:That being said, getting either Lua or Python into OpenMW will require us to create a dialect or domain specific language (DSL) of them that still keep to the theme of the original Morrowind scripting system (for backward compatibility).
I think you're missing the point. We would keep the existing tes script implementation, but allow python scripting as well.
User avatar
psi29a
Posts: 5361
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: [post-1.0] Scripting enhancemnts

Post by psi29a »

Not missing the point, I know what was said. I did not say throw away the existing system.

I'm saying that you'd still be creating a niche language who's constructs/primitives are pointed into the OpenMW direction. It happens to almost every language who is bound (be it by API or something else) to another. Take Boost-Python for example: http://www.boost.org/doc/libs/1_55_0/libs/python/doc/

We use this at work to expose python to developers against our mostly Ocaml and C++ product.

My point was... give a basic API to OpenMW and an initial supported language that binds to that API to use as an examples to modders who want to use another language.

So we make a Python interface as an example, and someone else with more time on their hands can contribute a Lua binding. I personally think this would be incredibly handy for a game engine. Pick your weapon of choice, and get to work.
wheybags
Posts: 207
Joined: 21 Dec 2012, 19:41

Re: [post-1.0] Scripting enhancemnts

Post by wheybags »

ah, ok, I misunderstood
endorph
Posts: 20
Joined: 27 Feb 2012, 22:48

Re: [post-1.0] Scripting enhancemnts

Post by endorph »

What about plugins with LLVM-bytecode, which is to be translated into native code by engine in runtime?
So modders automatically will be able to write code for all supported LLVM front-end's.
wheybags
Posts: 207
Joined: 21 Dec 2012, 19:41

Re: [post-1.0] Scripting enhancemnts

Post by wheybags »

That sounds like MASSIVE overkill :S
endorph
Posts: 20
Joined: 27 Feb 2012, 22:48

Re: [post-1.0] Scripting enhancemnts

Post by endorph »

That sounds like MASSIVE overkill :S
What exactly is overkill?
wheybags
Posts: 207
Joined: 21 Dec 2012, 19:41

Re: [post-1.0] Scripting enhancemnts

Post by wheybags »

Having llvm as a dependency :S
grigi
Posts: 2
Joined: 21 Jan 2014, 06:23

Re: [post-1.0] Scripting enhancemnts

Post by grigi »

Hi, first time poster here, so I hope I'm contributing to this discussion.

As Zini said, we should be focusing the discussion on what we need to do for omw 1.0, I'd hazard that it does include modifications to allow expansion if needed.

As I understand it, we have the following goals in this forum: (in rough order of priority)
  1. 100% Morrowind compatibility
  2. Simple/clean way of allowing future expansion to happen in potentially compatibility-breaking ways
  3. Some ways of reducing errors/mistakes in scripts by simplifying or detanglation of syntax, possibly adding new constructs
  4. performance should be considered
Points #1 is a given, as they coincide with the goals of the project.

Point #2 I think can be served very well by Zini's proposal:
flavour x
It worked so well for shell with the #! syntax.
I would propose we simplify the interface somewhat, and only use strings and not numbers (as a lookup to which dialect to use)
e.g:

Code: Select all

feature MW 
// Tries for 100% compatibility with those dialects, including insanities.
feature MW-1 
// From here on we assume "sane" variants of the language, why do we need to complicate matters by having both a sane and insane variant of the scripting language for forwards-incompatible variants of the language?
I'm not knowledgeable enough to really comment on point #3

For point #4 using a priority queue as Zini explained, and maybe processing the scripts in another thread, could go a long way towards making the game "feel" more optimised.

For future language use, I'm unsure whether going 3'rd party or continuing to roll-our-own would be best. Something like LuaJit is super-optimised, and LUA syntax is used by many people. It also could be a huge pain to get to cooperate with openmw, or interoperate with other existing scripts.
For the roll-our-own case, we could make it so that existing scripts could be fixed up by a small amount of change. We could also seriously consider more capable async methodologies, such as triggers (mentioned previously) and co-routines. But this is all definitely for post-1.0 discussion.
Also, LLVM has been shown to not be very suitable for JIT usage. Just look at the post-mortem of the unladen-swallow project.

Edit: Updated to remove MWSE faulty assumptions
Last edited by grigi on 21 Jan 2014, 12:36, edited 1 time in total.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: [post-1.0] Scripting enhancemnts

Post by sirherrbatka »

We do not aim at MWSE compatibility.
Post Reply