Scripting - Once Again

[jvoisin]

Congratulations!

[sirherrbatka]

this is a good moment to post this:
https://www.youtube.com/watch?v=Y9QxaJLt7EA

[scrawl]

I'm trying to understand why the Spriggan script isn't working properly. I ended up with this minimal test case, which isn't working either:

Code: Select all

begin placeItemTest

float xpos
short doOnce

if ( doOnce == 0 )

set xpos to 500

messagebox, "position %G", xpos
player->setpos x xpos
endif

set doOnce to 1

end placeItemTest

This script (e.g. when started as a global script) should print a messagebox with the text "500", then call "player->setpos x 500".
Instead, it prints the messagebox correctly, but calls "player->setpos x 0".

Furthermore, if we comment out the if (doOnce == 0) part, we get an even more curious result:
First frame: setpos x 0
All frames after: setpos x 500

.esp for testing attached.

What the hell is going on here?

[lef42]

hey scrawl sorry to bother but i cant continue testing blood moon till this is fixed. I built off your github fork and i got closer to the good beast but he still died a bit too soon. Almost could reach him though. Not sure if vanilla you're suppose to use a speed boost or something to reach him. Is there a way i can mark him invulnerable in the terminal so i can just move on in the quest? Thanks

[scrawl]

off-topic, responded in PM.

[Zini]

I manually disassembled the code generated for this script and it does not look like what I expected. In fact it seems the setpos instruction is cut into two parts with the set to and message box instruction in the middle. Seems the compiler is broken.

This must be a recent problem. I suspect that we broke it with one of the script argument workarounds. I will see if I can find the time to bisect it tomorrow.

[Zini]

Fix is in the openmw-32 branch. I will call for another round of RC and some testing just to make sure. This was both subtle and nasty.

[dragondeathlord]

Morrowind would just ignore that unnecessary argument, but OpenMW does read them and says something is wrong with this script. If any of you has an idea what these extra arguments mean, why don’t you join the discussion on this topic?

as I remember (this years baaack so do not even ask for link.) they wear for stuff that never worked and got scrapped from the scripting. But instead rewriting all the scripts to just tweaked the engine to ignore it.It was shadows or some such they realized they had better ways of doing..

[scrawl]

Thread necro time again...

I assume this works only reliably for unique IDs (i.e. IDs that are referenced only once).

Confirmed. I was able to start separate scripts on two references of the same ID, but after saving and reloading the game, only the first reference still had a script running.

I just checked how the targeted scripts are stored in MW savegames. There is an RNAM integer stored with the script record, which is the RefNum of the targeted reference.
So the earlier statement was wrong, having references with clashing RefIDs does not cause problems.
(The reason that my test back then wasn't successful, is because targeted scripts on manually placed references are broken. Such references do not have a RefNum value, so after saving and reloading the game the target gets lost)

I guess we should fix our implementation to match. Finding a reference from a given RefNum shouldn't be too hard. Even better if we can somehow come up with a fix for the manual references problem.

[Zini]

Nasty. Not going to get around to that immediately. Still busy with tinkering around with the ref move implementation in OpenCS.