Difference between revisions of "Talk:Reference Variables"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Tegid
(Follow-up on script race conditions reply.)
imported>JOG
(commented Jduvall's caveats and moved them to Discussion.)
Line 6: Line 6:
I'm not sure what you mean by "race conditions in scripts". Script processing is threaded, however, so several scripts can be processed simulataneously, if that's what you're referring to. --[[User:Kkuhlmann|Kkuhlmann]] 08:02, 25 April 2006 (EDT)
I'm not sure what you mean by "race conditions in scripts". Script processing is threaded, however, so several scripts can be processed simulataneously, if that's what you're referring to. --[[User:Kkuhlmann|Kkuhlmann]] 08:02, 25 April 2006 (EDT)


That's what I mean.  So two scripts can be running simultaneously both of them operate on the same persistent data, we can have data races.  Do you run blocks of scripts together (ie, do you split the scripts into separate threads on groups of 16 scripts (or 32))  I ask that because things work correctly, reliably with 16 new objects, but with 18 (I create two at a time) things stop working reliably (they more reliably fail to work). --[[User:Tegid|Tegid]] 09:16, 25 April 2006 (EDT)
That's what I mean.  So two scripts can be running simultaneously both of them operate on the same persistent data, we can have data races.  Do you run blocks of scripts together (ie, do you split the scripts into separate threads on groups of 16 scripts (or 32))  I ask that because things work correctly, reliably with 16 new objects, but with 18 (I create two at a time) things stop working reliably (they more reliably fail to work). --[[User:Tegid|Tegid]] 09:16, 25 April 2006
(EDT)
 
----
CAVEAT: Objects created by leveled lists do not process in low, if you set a reference variable from a leveled list, if your script tries to refer to that reference variable when that actor isn't loaded, bad things will happen. So don't ever do a "set myRefVariable to myXmarker.placeAtMe myLeveledList". Instead create an if-then section in a script which checks the player level, pick an appropriate base object for the players level, then do a "set myRefVariable to myXmarker.placeAtMe  SpecificBaseObjectID".--[[User:Jduvall|Jduvall]]
 
:This happens when you try to refer non-persistent objects or those that can be put in a container, not a specific problem with reference variables or leveled lists.--[[User:JOG|JOG]] 17:19, 24 May 2006 (EDT)
 
 
CAVEAT 2: You can not pass reference variables IN OTHER SCRIPTS as parameters to functions that take references. You must first set a local reference variable. For example: "myCharacterRef.look MyQuestScript.myReferenceVariable" will fail whereas "myCharacterRef.look myReferenceVariableDeclaredInThisScript" will work just fine. So in the local script just declare a "ref myReferenceVariableDeclaredInThisScript" and then set it to the external one "set myReferenceVariableDeclaredInThisScript to MyQuestScript.myReferenceVariable", and use the local one.--[[User:Jduvall|Jduvall]]
 
:You can't use ANY variables this way.--[[User:JOG|JOG]] 17:19, 24 May 2006 (EDT)

Revision as of 16:19, 24 May 2006

How are reference variables stored internally. I'm having issues reliably accessing my reference variables when there get to be more than 16 user created ones in a cell. I get correct behaviour sometimes but not all the time. I can provide an ESP and simple instructions to replicate the problem. It is possible it is my code however which is why I would like to try and eliminate as many issues as possible, since you certainly don't have time to be debugging my scripts.

On further testing, I see that the same code works perfectly sometimes and not others. Is it possible to hit race conditions in scripts? I assumed they would be linearly processed with no interruption. If that's not the case, then the errors I am getting virtually require that the references I have stored are variable and not fixed as I would expect. Almost nothing else describes this behavior. --Tegid 00:16, 24 April 2006 (EDT)

I'm not sure what you mean by "race conditions in scripts". Script processing is threaded, however, so several scripts can be processed simulataneously, if that's what you're referring to. --Kkuhlmann 08:02, 25 April 2006 (EDT)

That's what I mean. So two scripts can be running simultaneously both of them operate on the same persistent data, we can have data races. Do you run blocks of scripts together (ie, do you split the scripts into separate threads on groups of 16 scripts (or 32)) I ask that because things work correctly, reliably with 16 new objects, but with 18 (I create two at a time) things stop working reliably (they more reliably fail to work). --Tegid 09:16, 25 April 2006 (EDT)


CAVEAT: Objects created by leveled lists do not process in low, if you set a reference variable from a leveled list, if your script tries to refer to that reference variable when that actor isn't loaded, bad things will happen. So don't ever do a "set myRefVariable to myXmarker.placeAtMe myLeveledList". Instead create an if-then section in a script which checks the player level, pick an appropriate base object for the players level, then do a "set myRefVariable to myXmarker.placeAtMe SpecificBaseObjectID".--Jduvall

This happens when you try to refer non-persistent objects or those that can be put in a container, not a specific problem with reference variables or leveled lists.--JOG 17:19, 24 May 2006 (EDT)


CAVEAT 2: You can not pass reference variables IN OTHER SCRIPTS as parameters to functions that take references. You must first set a local reference variable. For example: "myCharacterRef.look MyQuestScript.myReferenceVariable" will fail whereas "myCharacterRef.look myReferenceVariableDeclaredInThisScript" will work just fine. So in the local script just declare a "ref myReferenceVariableDeclaredInThisScript" and then set it to the external one "set myReferenceVariableDeclaredInThisScript to MyQuestScript.myReferenceVariable", and use the local one.--Jduvall

You can't use ANY variables this way.--JOG 17:19, 24 May 2006 (EDT)