Am I going mad?

[macguba]

(You'll like this one.)


Trigger:
Activation box:  West present Once
Condition:   true (for testing purposes)
On activation:  [thislist] exec "upHill.sqs"


Script: "upHill.sqs"

_upList = _this select 0

#loop
~3
scripty stuff using _uplist
goto "loop"


The interesting part is that _uplist gets updated!    Every time the script loops the array _upList is different, which rather screws up the whole thing.    You would have thought that _uplist would be cast in stone, but no:  it is "live".

It's not the end of the world, I can probably figure out at way to deal with it now I've discovered what's happening.   (Praise the Lord for hint format.)    

The question comes in two versions:    

Formal version:   anybody know how I can crystallise the array at the moment when the script is called?

Informal version:   What the fuck is that all about?

Many thanks.

[Planck]

Maybe you could create a duplicate copy of thislist as soon as the script runs.

In response to the original question the answer is undoubtedly.......YES.


Planck

[macguba]

 ;D

I've got two possible workarounds:   run the loop multiple times (I won't bore you with the details); or delete the trigger.

Putting

_newList = _upList

somewhere and working off _newList doesn't help, it updates too.

The more I think about this the more it seems to be a handy feature rather than a game bug.    Although not in this case.

Auto-updating local variables.  What will they think of next.

[Planck]

Will it still update the copy if you make it global?


Planck

[macguba]

Yes.     upList and newList work just like _upList and _newList.

[Planck]

What I meant was make _uplist (local) and newlist (global).

Does it still update both the same?


Planck

[MachoMan]

erm, are you sure you are not excidently changing _uplist within the loop?

and yes you are insane

[Artak]

Hmm.. I might be reaching WAY too far, but I assume you could compile a new array of the elents in the 'thislist' array


...
_newuplist = []
_selector = -1
_max = count _uplist
#compile
_selector = _selector +1
_newuplist = _newuplist + [_uplist select _selector]
?!_selector == _max: goto "compile"
...

Hope it doesn't have to come to that, because adding stuff like above is baaad editing when there's an easier way to do something. (My scripts are always full of silly things like above).  ;D

*marked red the part I'm not sure on the syntax

[macguba]

@ MachoMan - uplist doesn't appear anywhere in the loop at all (except in a hint format), so it can't be that.

@ Artak - that's a very cunning idea.  It might even work.

@ Planck - I'll try that tomorrow.


I'm surprised there isn't a standard solution.   (Though I know the thread hasn't been up for very long.)     It's amazing that we are still discovering new stuff after three years.

[Artak]

I thought I remembered seeing this somewhere. Yup, the comref.

Array assignment
    Assignment used on arrays assigns only pointer to the same array to the target variable. When b is an array, after executing a = b both a and b represent the same array. When b is changed, a is changed as well. One particular situation that can lead to this behaviour is aList = list sensor_name. You can force creating a copy of array by using unary operator +Array

+ a
Operand types:
    a: Array
Type of returned value:
    Array
Description:
    unary plus: returns copy of array

Example:
    + [0, 1, 2] , result is [0, 1, 2]

[macguba]

 ;D  So I was right the first time, there IS a standard solution.

Your OBE is in the post.  :toocool:

[General Barron]

Yeah, I guess to explain what the comref says, in case it isn't clear:

When you pass an array via the "exec" ([array1, thislist, etc] exec "blah.sqs") command or the "=" command (listB = thislist), you aren't passing a copy of the array, you are passing the reference to that array. So changes in either "variable" will affect the other one.

Imagine if you passed an object to a script, like [player] exec "blah.sqs". Any 'changes' you made to the object in one script would also affect that object in another script, even if it is referenced under a different name (maybe "player" in one script, and "_man" in another). Arrays just act like objects in that regard.

Most people have used this 'feature' of arrays all along, without realizing it; for example, placing a trigger of limited size, and executing a script that waits until "thislist" reaches a certain size. I never realized it until I happened to be browsing the comref, and read the above portions. A while later it finally dawned on me what it meant  :-X

If you don't want this effect, then you need to make a copy of the array like this:

array2 = +array1

[Uldics]

You could probably make a new array in beginning of the script and pass each object from the trigger list (old array) individually to the new array.

[Wadmann]

Well this is just the topic that I was looking for but did not realize it until I read the entire topic! I have finally moved from "snippeter" to "scripter" (but I use that term loosely) but was stumped by a problem that did not exist (if that makes sense )! I was trying to end a script when the target count from an array of units reaches zero but was unfamilar with the whole _i =_i -1 routine. So I did this (just excerpts from script):

Code: [Select]

_grp = group _targ
_amt = count _grp
? _amt == 0 : goto "end"

I am not sure if this is my exact code but it was very similar and simple. Anyway, I thought that it would not end as I never removed units from the array of units that comprised the original group and that the amount of the group was static. Well for some reason it seemed to work but I thought that it was because I had put the count command into the looping routine of my script. I guess that I will save my "How do you use the _i=_i -1 routine" for another day as this topic has shed considerable light on this vexing issue.

                                                     Wadmann  

[Tyger]

this reminds me of references (&newlist for example) and pointers in C++, but I don't know how to get around it.
Any C++ gurus know any tricks? I know that C++ and OFP are very close, so somethin ought to work...

*forgot to add that a pointer points to the address of the varible, but references are the varible blah blah blah ... and update themselves in C++ too. So dats why i don't know a way around em. *