Extra Scripting Functions

Feedback on past, current, and future development.
User avatar
sjek
Posts: 441
Joined: 22 Nov 2014, 10:51

Re: Extra Scripting Functions

Post by sjek » 04 May 2015, 17:26

The Morrowind scripting language is convoluted, quirky, buggy, poorly documented and, as a result of all these, difficult to master and to debug.
not sure what you mean with convoluted but all those are basically becos of poorly made engine, not becos of poor scripting language. if you take only commands and how they should works without restrictions and workarounds it's kinda powerfull i think

ie. change the health, make it variable, get the position, aim and shoot.

it's basicality is also a strength becos without limitations it's easy to understand traight from the street and work with by almost anyone then you learn the syntax.

it might certainly on some point that more sophisticated functions are needed to keep the command list down and shortening scripts but otherwise direct calling functions might be better to code directly to the engine.
Arrays. Potentially linked lists, hash tables or other goodies, but some form of arrays or lists is fundamental.
Hooks. Overrides. Ability to react to game events as they happen, rather than polling for them constantly every frame from every object. Ability to override fundamental game formulas and calculations.
Dynamic, convenient in-game object accessing (referring to items, characters, containers, activators etc).
The full set of elementary programming tools: the conventional looping constructs, operators and built-in functions. Flexible, powerful syntax supporting complex expressions everywhere, with no arbitrary limitations.
Debugging and error-checking.
Object Oriented Programming.
https://wiki.openmw.org/index.php?title ... #Scripting

some are basically already possible. item referring, hooks (script from script (bugged, open for report))
overriding game mechanics after they have been converted to openmwscript

no background frame by frame calling definitely for optimization..... it has limitations but not after it's coded and engine specific design surely has it advantages :?

edit: ^^
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

Golken
Posts: 27
Joined: 04 May 2015, 05:03

Re: Extra Scripting Functions

Post by Golken » 05 May 2015, 14:01

I realized that providing compatibility for MWSE functions may not be quite as easy as I thought (though it still might be easy, I don't know). I was thinking of MWScript as an interpreted language when I considered that, which it is not. It depends on how MWEdit works (how MWSE functions are compiled), which I don't really know. The rest of the scripting extenders would be on a lesser priority to support because they're used less often.
sjek wrote: not sure what you mean with convoluted but all those are basically becos of poorly made engine, not becos of poor scripting language. if you take only commands and how they should works without restrictions and workarounds it's kinda powerfull i think
Convoluted is the twisty or roundabout way it often forces you to do things, and the longer code that results. You're right however that OpenMW would not have the arbitrary and quirky limitations that Morrowind has in compiling and running MWScripts (in Morrowind, scripts could refuse to compile or even break randomly with no warning if you did "wrong" things with the syntax or tried advanced uses of it and as such), which would make things a little easier, but the language still wouldn't be even nearly as powerful as JavaScript.
Perhaps with a ton of additions (not "normal" scripting functions like say MWSE adds or people have already added to OpenMW) it might get close, but it's kind of a silly thought at this point, why would you add workarounds in an open-source project...? That completely defeats the whole point of making a rewrite. A rewrite is done to make things right from the roots, and if it still ends up has the same major problems the original had, it's... not good.
Another pitfall is that current modders are already used to the random quirks and shortfalls of MWScript that if you actually give them a new and improved MWScript, they might stick to their previous habits and misconceptions and be wary of doing different things, unless extensive documentation of every change is provided and they read it.
sjek wrote:ie. change the health, make it variable, get the position, aim and shoot.
In Morrowind, say you wanted to do a simple thing like add a spell that provides a new kind of elemental damage (arcane, holy, unholy, whatever). Or an even simpler one, like a spell that teleports whatever it hits to somewhere else, maybe a 100 meters above their current position.
That's completely impossible in vanilla Morrowind unless the spell is only to be used on the player, or you add a script to every NPC and creature (which is of course completely impractical) to allow them to be affected by the spell.
It is much more practical, and possible, to do using MWSE, but that requires a polling implementation by looping through all loaded NPCs and creatures all the time, to constantly check if the spell hit them. Which eats resources and is a ridiculous implementation (objectively speaking).
sjek wrote:it's basicality is also a strength becos without limitations it's easy to understand traight from the street and work with by almost anyone then you learn the syntax.
Allegedly, LUA and Python are also easy to learn. Of course, what you said is kind of a global truth; an experienced programmer (or just someone with a talent for it) can work with any language once he learns the syntax (though not necessarily be proficient with it).
Python creates "beautiful" and clean code due to whitespace indentation which is easier to intuitively grasp, in contrast, LUA and MWScript need to include end keywords everywhere. With whitespace indentation there is also the big advantage that the programmer and the compiler read the code in the same manner (using indentation).
sjek wrote:it might certainly on some point that more sophisticated functions are needed to keep the command list down and shortening scripts but otherwise direct calling functions might be better to code directly to the engine.
Yep. Many things would be needed to be worked into the engine itself, some are in any case inevitable (like event handling), some because MWScript has no concept of them at all, like function calling, delays in functions (e.g. a sleep() or wait() function), arrays and whatnot.
I don't know whether zini has plans to add that kind of things to MWScript at all, though. When you do such a thing, it might already be partially like creating a new language, and at the same time hacking in new bits into an existing language and engine. Kind of feels like more of an approach that MCP would be forced to take, when you think about it.
MWScript would need more additions than what it currently has. Even with MWSE many things are impossible to do and many game properties and inaccessible. But you'll most likely need to add more functions whether you're using a new scripting language or not. You'd need to do design work and also decide what new syntaxes to add to MWScript, and as such. All that is already done and working if you use an existing complete language, of course.
sjek wrote: https://wiki.openmw.org/index.php?title ... #Scripting

some are basically already possible. item referring, hooks (script from script (bugged, open for report))
overriding game mechanics after they have been converted to openmwscript
Well, as far as I can see, you've linked to just a wishlist, a brainstorming page. But most of the items them (except the last) aren't even particularly relevant to the language features quoted. Note that about a third of them are actually already possible in vanilla Morrowind+MWSE (which, as discussed, still limited).
The thing is, most of the language features desired (quoted) are almost irreconcilable with MWScript. Or, more accurately, what I mean to say: let's say you work extremely hard and do your best to add them all to MWScript. When you're done... it will not quite be MWScript anymore. The new MWScript v2.0 code would look different and have new styles, as it would have some form of the following: logical operators (or keywords or functions, at any case if statements will look different), new syntaxes, functions, some kind of function overriding, etc. In any case, it would be less familiar to users of current MWScript, which I guess kinda defeats the point of even using it rather than another language.
sjek wrote:no background frame by frame calling definitely for optimization..... it has limitations but not after it's coded and engine specific design surely has it advantages :?^
I've heard that before. To me, that just sounds like a default, automatic-like sentence to throw out... though it could be that I'm missing things.
It might be me, but I don't see any advantage to it at all. The only thing I might understand that MWScript has going for it is that it's already familiar to MW community. I definitely see no inherent advantages in polling or in all scripts forced to run every frame, only disadvantages. Even Bethedsa's own scripts need to work around those issues and are typically disadvantaged by them, just like every script.
The engine-specific design might have only come from Oblivion onward, when they added script-launching spell effects and other things which I'm not familiar with.
jirka642 wrote:If you don't know, there was actually thread about that, and it even produced some basic python and lua functionality.
Yeah, I saw those. They are good beginnings. I just think it's kind of a waste of time to pretend that MWScript is a good alternative for the purposes of the main release, and I thought replacing it would be one of the main aims of an open-source Morrowind engine project. We would also end up in an annoying situation if we would have mods released for multiple forks of OpenMW, each with a different scripting language.

Post Reply