Scripting - Once Again

Everything about development and the OpenMW source code.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Scripting - Once Again

Post by scrawl » 21 Jul 2014, 11:26

I find no references to it. Go ahead.

Code: Select all

./esmtool --plain dump /home/scrawl/mwdata/Bloodmoon.esm  | grep -i -C 2 MockChangeScript

Record: SCPT ''
  Name: MockChangeScript
  Num Shorts: 4
  Num Longs: 0
--
  Script:
START--------------------------------------
Begin MockChangeScript

;THIS SCRIPT WILL CHECK THE TIME OF DAY FOR WEREWOLF PLAYERS, CHANGE THEM INTO WOLF FORM, AND CHANGE THEM BACK
--


End MockChangeScript

END----------------------------------------

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Scripting - Once Again

Post by Zini » 23 Jul 2014, 10:01

Another ugly topic: Stray arguments.

The original compiler did not check for additional arguments. For example the addSpell instruction takes a single ID as argument, but in some scripts you can find things like:

player -> addSpell "fire_bite", 645

Vanilla MW would just ignore the 645.

Now our compiler does check for extra arguments. It wasn't build for letting crap through without producing error messages. Changing that would be a large amount of work and we would lose a lot of the scripting advantages we already have in 0.31. Frankly, I don't wanna do it.

The workaround we have applied so far is adding optional ignored arguments to the argument lists of instructions and functions where this kind of stray arguments typically show up.

We have:
* x A single string or name
* X A numerical expression.
* z Either a string or name or a single numerical value.

For example we have:

Code: Select all

extensions.registerInstruction("face", "llX", opcodeFace, opcodeFaceExplicit);
That means the face instruction takes two integer values as arguments, but can take an additional numeric expression that then will be thrown away.

Now we need to figure out to which functions and instructions we need to add those optional arguments. I presume there is some kind of pattern. People have not added stray arguments randomly to their scripts. These are probably the result of some mental lapse or a misunderstanding how a function/instruction works.

To find these patterns we need to look at a large selection of content files, which means we need the help of our community.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Scripting - Once Again

Post by Zini » 25 Jul 2014, 10:50

Anyone any input on the script ColonySeler?

It contains the line

Code: Select all

PositionCell "Rabenfels, Taverne" 4480.000 3968.000 15820.000 0
which is obviously wrong. The cell should be placed at the end of the argument list, not at the start.

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Scripting - Once Again

Post by scrawl » 25 Jul 2014, 16:01

ConolySeler is used by NPC Seler Favelnim. This PositionCell call appears to be equivalent to positioncell 4480.000 3968.000 15820.000 0 (the cell name at the start is ignored).

User avatar
MiroslavR
Posts: 156
Joined: 12 Feb 2014, 17:45

Re: Scripting - Once Again

Post by MiroslavR » 25 Jul 2014, 16:41

scrawl wrote:ConolySeler is used by NPC Seler Favelnim. This PositionCell call appears to be equivalent to positioncell 4480.000 3968.000 15820.000 0 (the cell name at the start is ignored).
Are you sure? I've executed "player->PositionCell "Raven Rock, Bar" 4480.000 3968.000 15820.000 0" and ended up on the mainland, southeast of Caldera, at pos x=0, y=4480.000, z=522.000. This seems to have no effect on Seler for some reason, although there have been reports of him missing on the UESP article. On a side note, even if the order of arguments was correct, he would be positioned way off the bar.

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Scripting - Once Again

Post by scrawl » 25 Jul 2014, 17:07

Let's see.. positionCell with an incorrect order of arguments is a no-op for NPCs, but works for the player. Where does this madness end?
at pos x=0, y=4480.000, z=522.000
So the arguments are messed up too. Not really an issue, because with a defunct cellName argument the actor will not end up where he was supposed to go in either case.

So what can we do? If the first argument is a string, emit a warning and do nothing, but do not throw an exception. That should make the quest work.

User avatar
MiroslavR
Posts: 156
Joined: 12 Feb 2014, 17:45

Re: Scripting - Once Again

Post by MiroslavR » 25 Jul 2014, 17:32

To me it seems all arguments have a default value, in case something strange happens to be in their place.

Code: Select all

player->positioncell "a", "b", "c", "d", 0
results in x=0, y=0, z=906.00 (presumably adjusted so you end up standing on terrain), zrot=0, and the last argument seems to teleport you to the mainland, if invalid.


Edit: The instruction seems to be no-op for NPCs only if the last argument is not a valid cell id.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Scripting - Once Again

Post by Zini » 27 Jul 2014, 10:58

Okay, there is no way we can replicate the vanilla behaviour. Our compiler just can't do it (that is without a large scale rewrite). I implemented a workaround. PositionCell instructions with incorrect arguments are ignored completely now (still produce a warning message). I hope that is good enough, because if it isn't I am out of ideas.

That being said, I think we are mostly done here. There is still the issue with some instructions and functions that have occasional stray arguments. And there are still some instructions missing complete (not planning to do them myself). If there are more script issues, now would be the right time to bring them to my attention. Because otherwise I will wrap this up and return to work on OpenCS.


User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Scripting - Once Again

Post by Zini » 27 Jul 2014, 12:20

I see. Multiple problems reported in a single issue. Not that great. Anyway, we have the means to fix the stray argument problem. Regarding the other one I guess I have to get into a bit of testing here, but if anyone has anything that can narrow down the situation that would be most helpful.

Post Reply