Morrowind Scripts

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Morrowind Scripts

Post by lgromanowski »

Zini wrote: With the current roadmap the development focus is rather narrow, i.e. it is not always easy for multiple developers to find tasks they can work on in parallel. Since we seem to have started picking up tasks outside the roadmap anyway, I thought I could pick up the implementation of a Morrowind script compiler and interpreter. Through my work on the Redemption project I have intimate knowledge of the MW scripting language.

The idea would be to create a configurable and extendible pair of compiler/interpreter components, that have no dependency on any Morrowind feature.

The compiler could be used in the engine as well as in the editor. I happen to have some bits and pieces of code lying around (from a completely different project), that could easily be pressed into service.

The interpreter would be a simple stack machine. I don't think there is any point in recreating a interpreter for the original compiled Morrowind scripts. I can't find any information on it, but from my experience with Redemption the format is way too limited to be useful.
We would ignore the compiled code in the esm/esp files and use the compiler in a JIT-fashion. For maximum performance it might be useful to run the compiler in a separate thread, but we can take care of that later.
Much later, when we have an editor of our own, we could re-add the usage of precompiled scripts.

Please note, that this approach will give us a substantial benefit even without a new editor. The compiler in the CS is often generating broken code when encountering constructs it can't handle (without producing an error message or a warning). With the proposed approach we could bypass the original broken compiler and extend the power of the scripting language substantially.

Since the Morrowind scripting language is completely outside of the current development focus, I would develop the components in a separate topic branch, that could be periodically merged into master.

Opinions?
nicolay wrote: The roadmap isn't really canonical, it's just a suggestion (and a list of what I will be working on if no-one beats me to it, unless it's things that I can't do.) If you want to do this now, then you certainly have my blessing.

To be honest the script interpreter is one of the parts I've dreaded starting on myself, but if you already have workable parser and compiler code [i:mjuk6bov]and[/i:mjuk6bov] intimate knowledge of the language at hand, then that's a very very good starting point.

I completely agree with you about ditching the compiled code. As long as all the scripts also come with source (which they do, as far as I seen), then the precompiled bytecode is useless. I've also heard rumors about the buggy CS compiler, so we'd likely save ourselves a huge mess by totally ignoring it.

BTW by compiling I assume you still mean we compile to some sort of byte code? If so, what are your suggestions for a VM?
nicolay wrote: BTW, I've added the task to the "Unplaced tasks" list on the roadmap. I've also started linking a few of the tasks to the specific forum threads that discuss them, so it's easier for people to keep up with what's going on.
nicolay wrote: And speaking of optimizations (while we're on a posting roll): we could cache compiled bytecode even without an editor, just store it in a separate cache. We could eg. index byte codes by the md5 hash of the script source (very quick to compute), so if a script has changed then it is automatically recompiled. That is if this is even necessary. It could be that the compiler is so fast (it's a simple language after all) that you wouldn't even notice if it ran every time the script loaded.
Zini wrote:
I completely agree with you about ditching the compiled code. As long as all the scripts also come with source (which they do, as far as I seen)
Yes, they do. I think there are even cases where the CS stores the script but no compiled code in the esm.
BTW by compiling I assume you still mean we compile to some sort of byte code?
Correct. Compiling it to assembly or machine code would be too complicated and too risky. And I don't know x86 assembly anyway (only ARM assembly).
If so, what are your suggestions for a VM?
A custom one, specially made to make maximum use of our knowledge about the special structure of Morrowind scripts. As I said, basically a simple stack machine, probably with fixed size opcodes.
And speaking of optimizations (while we're on a posting roll): we could cache compiled bytecode even without an editor, just store it in a separate cache. We could eg. index byte codes by the md5 hash of the script source (very quick to compute), so if a script has changed then it is automatically recompiled. That is if this is even necessary. It could be that the compiler is so fast (it's a simple language after all) that you wouldn't even notice if it ran every time the script loaded.
Sounds a bit like overkill to me. But only profiling will tell for sure.
(it's a simple language after all)
You wish!
athile wrote: Have you given any thought to possibly transcoding the Morrowind script to another scripting language rather than generating bytecode? I.e. translate Morrowind script to Lua, Javascript, etc. or some other more standard scripting language. This would avoid a lot of low-level work on generating an efficient Morrowind-specific VM and instead would leverage existing work others have already done.

This also has the nice side-effect that new scripts could be written natively in Lua/Javascript/etc. (which would be very nice if OpenMW does develop into a generic game engine and/or ease work for modders as a standard language was being used). It also means that if we wanted to using a scripting language for any OpenMW internals (e.g. the gui, the music system, the weather system, etc.) we could leverage that existing framework.

Regarding the efficiency of this approach...

The transcoding would only have to happen once at start-up. OpenMW could keep a cache on disk of transcoded files - and basically just need to do a timestamp / checksum comparison (just as you were mentioning about the compiled caches) to determine if it needed to re-translate the Morrowind script or not.

I don't mean to disagree, but what is your motivationfor a custom Morrowind VM? Would that be done for performance reasons or design reasons? Lua is pretty darned efficient as far as I know. I doubt it would be a bottleneck as long as the initial transcoding wasn't doing anything silly.

(Also, in terms of problem complexity transcoding from Morrowind script to Lua should be no harder than compiling to bytecode: they are both effectively just translations.)


Personally, I really like the idea of transcoding to Lua. I like using standards (i.e. a lot of developers know Lua), I like using something already well documented and supported (i.e. Lua is mature and has a large user community), I like the idea of reusing other people's existing work (i.e. get OpenMW completed faster!), and I like the flexibility that generic scripting language affords for other areas of OpenMW.

Feel free to disagree, it's just a thought :)
Zini wrote: The primary reason for having a custom format is, that we can exploit our the knowledge about the specific structure of Morrowind scripts and the underlying world model to gain a higher efficiency.

The secondary reason is, that translating to Lua sounds like more work than a custom interpreter (for which I might have reusable bits and pieces of code lying around from another project too).
The original Morrowind scripting language has so much bizarreness, that a straight forward translation would be pretty much impossible. Also, I am not really sure if a move to Lua as primary scripting language is a good idea. Yes, the Morrowind scripting language has its odd sides, but it is what everybody is using when it comes to Morrowind scripting and it actually isn't that much worse than other scripting languages (from an end-user's point of view), if you ignore how buggy it is. I would rather extend it, than offering a different language.

And the tertiary reason finally is, that I don't know much about Lua and I am only weakly motivated to change that. While I am aware that Lua is rather popular, so far I have failed to see the attractiveness of this language.
athile wrote: Apologies, but give me one more chance to try to convince you...

Obviously without real numbers it is impossible to say, but my initial reaction is that using a custom bytecode format for performance reasons would be an over optimization. A specialized solution (to any problem) almost inevitably has the potential to be faster, but I'm not sure the potential performance gain justifies the additional effort and maintenance of a custom VM.

You do have a valid point about a custom interpreter being easier if you have existing code lying around already. However, that aside, in the general case I have to disagree about a straightforward translation being "pretty much impossible". You could always register custom Lua functions (in C++) like "weirdMorrowindFeatureXYZ(...)" and then translate from Morrowind script to a Lua call to that C++ function. The problem complexity of transcoding versus interpreting really should be equivalent.

So I understand the problem better, can you give me a example chunk of Morrowind script that would be difficult to transcode? Skimming at the Morrowind Scripting for Dummies book, it looks there aren't any strange variable types (short, long, float) or strange control structures. The rest just seem like function calls that could be implemented in C++ and registered as Lua functions.

Lastly, If you don't know much about Lua, I'd suggest at least spending some time reading about it. It's simple, fast, extensible, and really easy to integrate with C/C++. It's worth understanding even if you only use that added knowledge simply to choose not to use it.


That was my attempt to get you to give the transcoding idea another thought. Since you're the one offering to do the work however, I graciously defer to your opinion to choose against it :)
Zini wrote: I haven't given much thought to the situation. I wrote my post mostly on recollection from my work on the more arcane parts of Redemption, which are admittedly a big vague. But things that might cause problems are:

- very odd function argument syntax, that does among others not require a comma to separate arguments (though that would probably have some negative effect on my proposed course of action too)

- different binary storage data format of local and global variables. Again not 100% sure how that would affect translation, but it is at least a point to consider.

- names can contain spaces. I don't think Lua will like this.

- some global variables need special treatment (various parts of the engine will probably require adjusting when their value changes; again not so sure about the details). So unless we want to scan all these globals after every script execution (which sounds horrible inefficient to me), they would need a special treatment too.


Anyway, that is actually a bit besides the point. The point is how we want to continue after 1.0. Are we offering a separate scripting language (e.g. Lua) or are we extending the Morrowind scripting language. In the first case your proposal is clearly the way to go. In the second case, it doesn't matter that much (both proposals could yield good results).

Edit: Just a note. Scripting for Dummies contains only a very small fraction of the perversities, that you can encounter when working with Morrowind scripts. That mostly affects bugs and limitations, but I guess it is true for some features and syntactical quirks too (been a while since I read this file).
Zini wrote: Argument against offering Lua as second language (instead of extending the Morrowind scripting language):

Wouldn't the 2-layer system (Morrowind->Lua, Lua->Lua-Bytecode) force us to implement error checking twice?

The Morrowind compiler can identify various non-syntactical errors (e.g. using a global variable, that doesn't exist). This feature is crucial for working with the CS and dearly missed in placed, where it doesn't work (e.g. dialogue scripts). If we have an editor of our own and offer two scripting languages, the compiler would need to offer this kind of error checking regardlessly what language is used.
Zini wrote: I thought a bit more about the topic. To sum up my position:

Your arguments don't convince me. From what I see, both solutions might be performing about equally well regarding to speed as well as to development time. What we have done in this thread so far is mostly blind guessing. The only way to find out for sure would be to try out both. But it is really not worth it.

Since I know exactly what to do for implementing my solution, while implementing your solution would require a lot of research and quite a bit more of thinking, I consider my solution preferable.

The only argument, that I buy, is about using Lua as a replacement language. If we are going to do that, than your solution is clearly the way to go (would be wasteful to have two script VMs).

So the question really is, what is our target audience? Are we primarily focussing on the Morrowind/TES community, who knows the Morrowind scripting language, but maybe not Lua? Or are we focussing on a larger audience, who may know Lua to some percentage, but are unlikely to have knowledge about the Morrowind scripting language?
Zini wrote: btw.: Nico, what is up with the SCPT record? I see, that this one is disabled and had a comment indicating special treatment is needed. I reactivated it and indeed it does not load properly (I only get one script record). Any idea, what is happening here?

Edit: oh, wait! I got it. The ID is handled differently. Got it working now.
Greendogo wrote: I would hope the target audience would be primarily the Morrowind community. Doing otherwise would make script compatibility between existing mods and the new engine rough and uncertain, would it not?
Zini wrote: Not really. The old scripting language would still be available. it just wouldn't provide any new/improved features.

The more I think about it the less I like the idea. I guess I will simply go ahead with my original plan.
nicolay wrote: I think as we're all working on a voluntary basis, it's largely the one who does the job who gets the biggest say in how it's done. I can see both approaches working actually, but the important thing in the end is that we get some way to run the scripts that works.
Zini wrote: Well, we are getting there. My code can now successfully transform a script into a token stream. I pushed to the mwscript branch in my repository, in case anybody wants to take a look. All still a bit rough, but working as far as I can tell.

I am running my code as a standalone tool for now. Integration into MW will come later. Currently the compiler looks for a file named test.mwscript, but I will add a command line option for choosing different files soon.

The roadmap for the scripting implementation looks like this:

- compiler for MW-independent features (loops, expressions, variables)
- interpreter for MW-independent features
- integration of compiler and interpreter into OpenMW

MW-specific features will be implemented once OpenMW actually supports them.

btw. it would be nice to have an in-game console, once I start to work on the integration. Could we set the focus for 0.09 on the GUI implementation?
athile wrote: Go for the custom VM. I simply wanted to share the idea for discussion :)
Zini wrote: I removed the dummy parser from the previous commits (which was simply logging all tokens to cout) and started working on the real thing. Basic structure is in place, as well as parsing of local variable declarations.

For example this test script parses correctly now:
Begin Test ; totally meaningless test script

short var1 ; some random variables
long var2
float var3

End
Greendogo wrote: I love reading coding updates! Fascinating.
Zini wrote: Added a standalone interpreter.

The following script now compiles and executes correctly:
Begin Test ; totally meaningless test script

short var1 ; some random variables
long var2
float var3

Set var1 to 10 ; we can only handle non-negative integers for now
Set var2 to 20
Set var3 to 30

End
Zini wrote: Basic arithmetic and the first function are working. I will have to work more on the parser though to cover all the odd cases of MW's arcane function call syntax.

The following script now compiles and executes correctly:
Begin Test ; totally meaningless test script

short var1 ; some random variables
long var2
float Var3

Set var1 to -10 * (2 - 3) * 3
Set Var2 to GetSquareRoot 4
Set var3 to -30.5

End
Zini wrote: Added MessageBox (no formating, no buttons) and Return statement. And we can use if-elseif-else-endif constructs now.

The following script now compiles and executes correctly:
Begin Test ; totally meaningless test script

short var1 ; some random variables
long var2
float Var3

Set var1 to -10 * (2 - 3) * 3
Set Var2 to (GetSquareRoot, 4) + 1.5
Set var3 to var2

Set var2 to 0

if (var2)
MessageBox "test"
else
MessageBox "test2"
Endif

Return
Set var3 to 10

End
pvdk wrote: Nice work Zini!

-- Edit --

Had to type "git checkout mwscript." "git branch" somehow does not show all the branches if they are not created locally.

Haha!

Code: Select all

ERROR: square root of negative number (we aren't that imaginary)
Really like what you've done so far! Keep up the good work 8-)
Zini wrote:
Had to type "git checkout mwscript." "git branch" somehow does not show all the branches if they are not created locally.
I think that is intentional. But don't ask me. I have no idea, what is happening in the minds of the git developers. They are a brilliant, but sometime a bit odd too.

I went through the list of remaining tasks again. It has become pretty small:

- while loops
- make comma optional as argument separator
- add comparison operators (==, ...)
- add . and -> operators -> possibly later
- global variables -> later
- message box text formatting
- message box buttons -> later
- add interfaces for custom compiler extensions -> possibly later
- integrate compiler and interpreter into OpenMW (local world scripts)
- add support for global scripts, targeted scripts, local inventory scripts, dialogue scripts and console scripts -> later (depends on other parts of OpenMW being implemented first)
- optimisation -> later or never (depending on how well it performs)

And that's it basically. We still have to add all the MW-specific commands and functions, but we can do that alongside while we implement the respective feature.

I hope to finish the first stage of the scripting implementation (excluding the points marked as 'later') sometimes next week. At this point I will probably merge it back into master and send a pull request.
Zini wrote: Everything not marked as later except for OpenMW integration is done. MessageBox formatting is still very basic though.


The following script now compiles and executes correctly:
Begin Test ; totally meaningless test script

short var1 ; some random variables
long var2
float Var3

Set var1 to -10 * (2 - 3) * 3
Set Var2 to (GetSquareRoot, 4) + 1.5
Set var3 to var2

Set var2 to 0

if (var2)
MessageBox "test"
else
MessageBox "test2"
Endif

Set var2 to 5

While (var2 >= 1)
Set var2 to ( var2 - 1 )
MessageBox "loop %g %f %S", var2, 1.111, "foo"
Endwhile

Return
Set var3 to 10

End
Zini wrote: Merged the mwscript branch into my master branch. Pull request sent.

I decided to postpone the integration into OpenMW until at least some kind of usable console is available.

Happy merging!

btw. somehow we got bad line endings again (in CMakeLists.txt). Please try to be more careful next time, because it is bloody annoying.
nicolay wrote: Very nice work! I've merged it in. You actually had a couple of line ending snafus in your commit yourself :) (but its fixed now)
Zini wrote: Oops! I re-used some of my code from before my move to Linux. That's the only source I can think of.
Zini wrote: btw. I deleted the mwscript branch. Since development now will happen in small incremental steps again, I am using master instead.
athile wrote: Quick, minor note Zini:

In your code, the forward declaration of a class or struct should be use same keyword as the actual declaration. In other words, if it's a declared as a "struct" try to make sure the forward declaration is also a struct. If it's declared as a "class" make sure the forward declaration is also "class". Mixing and matching the two is causing warnings on Windows.
Zini wrote: I am not sure, if that would be even legal C++. But unless something went wrong with the old code I imported, I doubt I have any of these.

Oh, wait. TokenLoc. I completely forgot about it. Will fix.
athile wrote: They're fixed in my fork.

But it looks like Windows changed the line endings on everything I merged. Ugh!!!

(http://github.com/athile/openmw/commit/ ... b50f235774)
Zini wrote: That looks bad. Did you read this page: http://help.github.com/dealing-with-lineendings/ ?
Zini wrote: I am currently implementing local script handling.

The engine tries now to compile all local scripts in active cells. Next step is obviously to implement script execution.

btw. the default cell has three scripts. One of these compiles correctly. The other two don't, because of lacking vocabulary (the Morrowind specific script instructions aren't implemented yet).
Those two scripts mostly fail because of script instructions related to sound. Once these are implemented, the cell will make a nice test setup for the 0.08 sound features.
Zini wrote: Okay. Done. Script execution is working.

We also have a new command line option: --script-verbose
Zini wrote: While working on the scripting, I had to do some major refactoring in the apps/openmw directory. Was becoming a bit chaotic, so I had to clean up. I hope no one else is working at it at the same time.

The code in my master branch is still WIP, but pulling might be a good idea anyway so we can get these structural changes out of the way.
Zini wrote: All the scripts in the default start cell compile and execute correctly now.

Edit: The following features are not implemented yet.
- the -> and . syntax
- global variables
- ID verification (check if a name mentioned in a script has a corresponding record)
- dialogue scripts, console scripts, global scripts, targeted scripts

And obviously we still have tons of functions and instructions to add. But that's all. I guess we can claim that the script implementation is almost finished. At least I am very close to the point, where I can't continue without other parts of OpenMW having made more progress first.
Zini wrote: Global scripts and global variables are implemented. The main script itself compiles and executes properly now. A couple of scripts, that are started from the main script, need some more work though.

I also added a new command line option:

--new-game

This will kick the start scene/the character generation process into action (once the respective script functionality is implemented). If you remember how this works, you will probably have noticen, that it would interfere with regular engine testing. Therefore I made it optional.
nicolay wrote: What can I say .. fantastic work Marc, I've merged it all in now.
Zini wrote: I made a list on the wiki with all script instructions and their current implementation status. http://openmw.org/wiki/index.php?title= ... g_(status)
Zini wrote: Added a couple more script instructions and functions. In the start cell (Prisonship) all but two scripts are working now.
Sslaxx wrote:
Zini wrote:Global scripts and global variables are implemented. The main script itself compiles and executes properly now. A couple of scripts, that are started from the main script, need some more work though.

I also added a new command line option:

--new-game

This will kick the start scene/the character generation process into action (once the respective script functionality is implemented). If you remember how this works, you will probably have noticen, that it would interfere with regular engine testing. Therefore I made it optional.
Well, this was interesting. Not sure if it's all been merged into the main branch, but running got me this:
./openmw --new-game wrote:Hello, fellow traveler!
Your data directory for today is: /media/Stuarts.AMD/Games/TES/3/Data Files
Initializing OGRE
Adding /media/Stuarts.AMD/Games/TES/3/Data Files/Morrowind.bsa
Adding /media/Stuarts.AMD/Games/TES/3/Data Files/Bloodmoon.bsa
Adding /media/Stuarts.AMD/Games/TES/3/Data Files/Tribunal.bsa
Loading ESM /media/Stuarts.AMD/Games/TES/3/Data Files/Morrowind.esm

39 record types:
CREA: 260
REPA: 6
APPA: 22
GLOB: 73
PROB: 6
NPCC: 0
CREC: 0
MISC: 536
CNTC: 0
LEVC: 116
RACE: 10
SNDG: 168
ALCH: 258
ENCH: 708
LIGH: 574
ACTI: 697
LEVI: 227
LOCK: 6
BOOK: 574
DIAL: 2358
SPEL: 990
CELL: 2538
REGN: 9
BSGN: 13
SOUN: 430
ARMO: 280
WEAP: 485
SSCR: 0
INGR: 95
DOOR: 140
CLAS: 77
STAT: 2788
FACT: 22
CONT: 890
CLOT: 510
SCPT: 632
GMST: 1449
BODY: 1125
NPC_: 2675

Not implemented yet: INFO LAND LTEX MGEF PGRD SKIL
loading cell 'Beshara'
Statics in cell: 140

Setting up cell rendering
Setting up input system
Starting command server on port 27917

Start! Press Q/ESC or close window to exit.
sound effect: playing sound cave drip from Unnamed_3 at volume 1, at pitch 1
sound effect: playing sound cave drip from Unnamed_4 at volume 1, at pitch 1
sound effect: playing sound cave drip from Unnamed_5 at volume 1, at pitch 1
sound effect: playing sound cave wind from Unnamed_6 at volume 1, at pitch 1
sound effect: playing sound cave wind from Unnamed_7 at volume 1, at pitch 1
error line 1, column 0 (<newline>)
Unexpected special token
error line 7, column 21 (Centurion_Spider_TGA1)
Unexpected name
error line 26, column 13 (player)
Unexpected name
Zini wrote: That is one of the scripts, that doesn't work yet. Two reasons:

- the -> syntax used in this script isn't supported yet

- currently only the active cells are searched for IDs. This does not cover the cell, where the unique reference to the ID Centurion_Spider_TGA1 is located. We will have to do some more work on the way cell data is stored, before we can address this issue.
Zini wrote: The very first of these error messages is a bug though. Fix has been pushed to my fork. Thanks for reporting it.
Zini wrote: The -> operator is fully implemented now.
nicolay wrote: Great, I'll pull in soon as I'm able to. Github seems to be having problems right now.

EDIT: done
Zini wrote: Implemented the coc instruction. You can now switch to a different cell by typeing

Code: Select all

coc cellname
in the console. But don't try this on exterior cells!

btw. I think we should give exterior cell implementation a rather high priority. I know this is nasty stuff, but we already have so many FIXME and TODO notes regarding exterior implementation. It will be a pain to fix them all and it is only going to be worse when new features are implemented.
nicolay wrote: I agree. How about making terrain the focus for the next release? I would rather do terrain and collision in separate releases, and terrain makes for better screenshots I guess :)
Zini wrote: I fully agree!
raevol wrote:
nicolay wrote:How about making terrain the focus for the next release?
*SQUEEE*

Sorry. Really excited.
fallenwizard wrote: I have tested the console commands (great job by the way) and I found a bug:

If I set an attribute to "31" it looks ok. If I set it lower than 30 the scripting engine sets it to 2147483647.
Zini wrote: Confirmed and fixed. Thanks for reporting this bug.
Zini wrote: We have a container system now. Container-related script functionality is implemented. Also, you can go around and pick up items.
fallenwizard wrote:
Zini wrote:We have a container system now. Container-related script functionality is implemented. Also, you can go around and pick up items.
Wow! Your speed of development is impressive. If this continues, I am sure OpenMW will be playable in a few months.
Zini wrote: Just added a new command line switch (--script-all), that makes OpenMW compile all scripts at startup (excluding dialogue scripts) and print some statistics.

Currently 23% of all scripts in Morrowind.esm can be compiled correctly. Not bad.

Edit: For Redemption the value is only 17% though. Oh well, we knew Redemption is a bit more demanding.
Zini wrote: I added the journal related script instructions (they don't do anything yet). The rate of correctly compiled scripts in Morrowind.esm is now at 29%.
Zini wrote: And 2% more just by added the instruction GetPCCell. ;)
Star-Demon wrote: Zini, I was thinking - when I do some inputs into the console window, I notice they don't immediately take effect until I close the window.

The behavior in MW was that they immediately processed and resolved.

As well, can we get some sort of output in the console showing that a command went through correctly? Color change to blue or something? Or maybe a -verbose sort of argument?
Zini wrote:
Zini, I was thinking - when I do some inputs into the console window, I notice they don't immediately take effect until I close the window.
I don't know what you mean. Can you give an example of such a command with delayed effects?
As well, can we get some sort of output in the console showing that a command went through correctly? Color change to blue or something? Or maybe a -verbose sort of argument?
Well, you get an error message, if the command did not work. While it is the inverse of what you are asking, it served the same purpose.
Star-Demon wrote:
Zini wrote:I don't know what you mean. Can you give an example of such a command with delayed effects?

Well, you get an error message, if the command did not work. While it is the inverse of what you are asking, it served the same purpose.
I noticed it when using togglecollision, but I'm sure TCL (which should do the same) actually is supposed to be that way. Probably a bad example.\

Let me go back and test just to be sure. I know some commands immediately worked.


The error messages are fine, though. Some messages I would prefer some verbose args just to make sure it performed the action I wanted it to.

IE: things like TCL, TGM, etc would output "God Mode - ON"
Zini wrote: Opps. Completely forgot about TCL. Will add it as an alias for ToggleCollision.

I agree about TGM. This instruction has no immediate effect and any way to test it is most likely fatal. Therefore it should give feedback.
Ace (SWE) wrote: I think that what Star-Demon means is this:
Image

Some commands did give output when you ran them.
(Also, disregard the small error. MGE didn't like ZScreen)
Sslaxx wrote:
Zini wrote:Opps. Completely forgot about TCL. Will add it as an alias for ToggleCollision.

I agree about TGM. This instruction has no immediate effect and any way to test it is most likely fatal. Therefore it should give feedback.
As pointed out by the screenshot, tgm does give feedback - on the console. You mean some other (another?) way to show god mode being enabled, maybe?
Zini wrote: Nope. That is exactly what I meant. The screenshot above is from MW, not from OpenMW.
Sslaxx wrote:
Zini wrote:Nope. That is exactly what I meant. The screenshot above is from MW, not from OpenMW.
I know. Some kind of out-of-console notification that god mode is enabled would be nice though.
Star-Demon wrote: That's what we both were saying. :)
Zini wrote: More verbose toggles are implemented in my script branch.

If the toggle instruction has been issued from the console, you get a report similar to what MW is doing.

This new report channel currently redirects to the MessageBox channel when not issuing instructions from the console (e.g. from a regular script). This is probably not exactly what Morrowind is doing, but I hope people have no objection about this slight divergence from the original behaviour.
Star-Demon wrote: Shouldn't be much of a problem - Morrowind isn't very diku-mud-ish in the way information is presented to the player. The GUI held only three of these messages, though. Not sure how many ours should, though they DO take up room on the screen for whatever amount of time they are up.

Also - Think we could implement the quick commands to get data on objects in the game? ORI, and so on. Very useful command for troubleshooting.

I would *love* a command that takes a selected game object as input and then outputs all reference changes by load order. That'd be tremendously useful. (if not slow)
Zini wrote: We will look into improved debugging, when we have reached 1.0. But my current position on this is, that we should not spend too much time with implementing these kind of features in OpenMW. Since we have firm plans for an Editor now, it would make debugging plugins much easier, if we establish an IPC connection between OpenMW and the Editor and use the Editor as a debugger-frontend.
Zini wrote: Oops! Big time. By a major blunder during the script manager implementation, a new instance of the virtual machine was created whenever a local or global script was executed; not only once per frame, but once per frame per script. Since this is a rather CPU-intense procedure, the impact on the overall performance is notable.
By creating only one instance for all local/global scripts I got a performance increase of about 25% around Vivec (other areas with less scripts are probably less affected). Also, I am feeling a bit silly now for making such a stupid mistake in the first place.

@gus: Sorry! You were right about the scripts being too slow. Script execution is naturally rather expensive, but not that expensive.
sir_herrbatka wrote: @zini
congratulations! :-)
Hircine wrote:
Zini wrote:Oops! Big time. By a major blunder during the script manager implementation, a new instance of the virtual machine was created whenever a local or global script was executed; not only once per frame, but once per frame per script. Since this is a rather CPU-intense procedure, the impact on the overall performance is notable.
By creating only one instance for all local/global scripts I got a performance increase of about 25% around Vivec (other areas with less scripts are probably less affected). Also, I am feeling a bit silly now for making such a stupid mistake in the first place.

@gus: Sorry! You were right about the scripts being too slow. Script execution is naturally rather expensive, but not that expensive.
I Lol'd.

Good that its found and fixed. :)
Greendogo wrote: Good job Zini! Get that FPS up! :lol:
gus wrote: Zini: that's OK ;) BTW, couldn't we exexute scripts in a thread? or is it too hard to make everything thread-safe?
Zini wrote: I thought about that too. But there are too many problems. Primarily:

- scripts can interact with pretty much any part of OpenMW, which means we would need tocks everywhere. Sounds like a guarantee for a substantial slowdown.

- scripts require a defined sequence of execution (you can't just execute all scripts in random order)
Locked