openmw.org

cc9cii wrote: ↑18 Jun 2020, 22:44 I'm a little confused about the scripting work - will you be generating a bunch of empty methods that needs to be implemented? Like, all these and more from OBSE, etc?

Yes, basically. Let me elaborate;

I split the implementation into multiple steps:

At stage 1 it, it will be an acceptor:

Given an input string x decide whether x is part of the Oblivion scripting formal language or not. x can be any finite string. If x is a accepted by the compiler, x is a valid script, otherwise it's not, which is guaranteed to be decidable for Oblivion's scripting language (other than for C++ due to Templates being turing complete).
The compiler is based on Flex and Bison, Flex takes a bunch of Regular Expressions (Which have to be ordered such that the maximum munch rule is enforced) and produces a DFA in c. Bison want the actual formal grammar description to generate the parser which calls the tokens from the Flex generated lexer to verify that the script is a derivable sentence of the Scripting Language. Just very basic so far and yes - it would not actually do anything yet.

At stage 2, it will be a partial interpreter:

If the script submitted is valid, bytecode is generated and scheduled for execution, with the opcodes referring to either logical arithmetical primitives or game functions. That's the tricky part because I intend to use some fun additions I added in other Virtual Machines like branch prediction and caching to improve performance.
The Opcodes corresponding to game function have to be implemented of course. I can't test that without being able to load basic Oblivion assets. Alongside that, for many functions the game logic also has to be implemented first or adapted whereever it differs from what we thankfully already have in OpenMW.
https://en.uesp.net/wiki/Tes4Mod:Script_Functions
Some functions refer to game systems not present in Morrowind like for example GetPersuasionNumber, so that game logic would have to be implemented first, such that the VM is able to call the function once the opcode it hit. I call this partial interpreter as long as not every opcode it implemented

At stage 3, the full interpreter with extensions:

OBSE can be integrated over time for sure, with a priority on the subset of opcodes used by the most important plugins.
As a long term goal, I would also integrating some convenience functions for quick mathematics parsing like for example evaluate("3*5 + sin(2)") with a minimal benchmarked high performance parser (Good reference https://github.com/ArashPartow/math-par ... rk-project ) + an SAT solver (for example good old MiniSAT) and a implementation for SLD resolution to let NPC interfere logical conclusions from a set of known facts (for example events that occurred in the game world like a village being attacked by dragons) about the gameworld. Make it more of a true fun sandbox with hopefully non linear, chaotic events and utilize more CPU power.

So I can either do this in your fork, or I can wait for you to merge your commits into the current master.

Much of that sounds independent of what I'm doing other than testing new functionality as you say. Why not do that on the current master rather than my fork? Better for the community (unless you're doing experimental stuff in which case your pull request will sit in the queue for months... then you're better of using my fork)

I agree, for OpenOB to be a thing, then we'll need this anyway.

I suggest you fork from OpenMW master and add a new directory in apps: apps/openob
From there, you can base it lightly on apps/openmw

This way you can do work and it doesn't effect OpenMW that much since your work would be in that directory only and not touch openmw itself (for now).

We can later see about any refactor work as I think mwscript is similar enough to obscript that we can eventually make that generic 'script' that covers both and any differences in behaviour between two of the same commands depending on context (flag) from where they are called (out of openmw or out of openob).

So for now, it's fine that you develop openob independently in apps/openob, we can later refactor. That way it doesn't effect OpenMW as a whole.

I'm still not decided if we role out two binaries: openmw and openob
or that openmw eventually supports running Oblivion.

I thought the plan was to implement OpenMW-Lua, try and implement a MWScript-to-OpenMW-Lua transpiler, ditch the MWScript interpreter, and then implement later games' scripting languages as transpilers, too.

AnyOldName3 wrote: ↑19 Jun 2020, 12:44 I thought the plan was to implement OpenMW-Lua, try and implement a MWScript-to-OpenMW-Lua transpiler, ditch the MWScript interpreter, and then implement later games' scripting languages as transpilers, too.

That is the goal yes; but I'm not going to block someone else's progress just yet. Unless of course 1Zero or someone else wants to jump right in and create a transpiler now that is stubbed on the Lua side. This doesn't get us far until we have a Lua subsystem (in components?) to begin with.

Having a working solution now that we can then use as a target for transpilation is fine for me, as it would sit 'loose' from openmw for now. It was why I suggested this route then we can refactor later. So just take mwscript as is and then run with it for obscript?

One question though... would the transpiler itself be C++ based subsystem or Lua based?

It makes more sense to me for C++ to generate Lua than Lua to generate Lua. It feels more dangerous for Lua to do it, as there's more opportunity for it to interfere with itself, whether or not it's deliberate. Also, C++ should be faster, and we don't want unnecessary latency when loading.

Adding to my document then.

Not to pull the discussion too far off course but the original plan from Zini was oldscript+. Without active newscript (Lua) development that seems to be the current trajectory and it shouldn't be discouraged. Newscript will just come when it comes...

Everyone agreed that was a dumb plan and MWScript should be treated like the dumpster fire it is and abandoned with extreme prejudice. Newscript has been the official plan for a long time now.

Hello,
for legal reasons, I am unfortunately required to withdraw my Involvement in the development of an open source Oblivion immediately.
I wish the project the best of luck and progress going forward!

Best regards,

1Zero