Scripting - Once Again
Re: Scripting - Once Again
Congratulations!
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Scripting - Once Again
this is a good moment to post this:
https://www.youtube.com/watch?v=Y9QxaJLt7EA
https://www.youtube.com/watch?v=Y9QxaJLt7EA
Re: Scripting - Once Again
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:
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?
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
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?
- Attachments
-
- test.esp.zip
- (1.21 KiB) Downloaded 323 times
Re: Scripting - Once Again
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
Re: Scripting - Once Again
off-topic, responded in PM.
Re: Scripting - Once Again
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.
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.
Re: Scripting - Once Again
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.
-
- Posts: 13
- Joined: 30 Sep 2014, 14:58
Re: Scripting - Once Again
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..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?
Re: Scripting - Once Again
Thread necro time again...
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.
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.scrawl wrote: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.Zini wrote:I assume this works only reliably for unique IDs (i.e. IDs that are referenced only once).
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.
Re: Scripting - Once Again
Nasty. Not going to get around to that immediately. Still busy with tinkering around with the ref move implementation in OpenCS.