Strange "Call Compile Loadfile" Bug

[ColonelSandersLite 0]

I attempted to pass file names through script arguments (an array of strings) that would let the end user pass multiple files to read from.

Here's some sample code of what it may look like:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_files = _this select 0; // an array of strings containing file names

_i = 0;

_fileCount = count _files;

_fileContents = [];

while {_i < _fileCount} do

{

_files = _this select 0;

_fileContents = _fileContents + [call compile loadFile (_files select _i);];

};

player sideChat format ["%1", _fileContents];

Now, baring any typos, that's perfectly legitimate code there. However, it appears that loadfile writes it's data in both directions. In otherwords, after the first run through that loop, _files is loaded with the contents of the first loadfile command.

To work around it you have to do this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_files = _this select 0; // an array of strings containing file names

_i = 0;

_fileCount = count _files;

_fileContents = [];

while {_i < _fileCount} do

{

_files = _this select 0;

_fileContents = _fileContents + [call compile loadFile (_files select _i);];

};

player sideChat format ["%1", _fileContents];

In other words, reset _files every time you use it.

[UNN 0]

I think the problem might be down to array pointers and _This. I noticed something similar when trying to determine the number of parameters passed to a script.

Basicly _This resides in the parent scope of the calling script. So when you execute the call command within that script, _This is reassigned. I can only assume from what you said. That the call compile bit, when used without parameters, defaults to the content of the function.

If thats the case then using the copy command, should fix it:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_files = +(_this select 0);

Assuming your not updating the location pointed to by (_this select 0) at the same time your running your loop.

If you are then perhaps this would work:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while {_i < _patrolContentsCount} do

{

private ["_this"];

_fileContents = _fileContents + [call compile loadFile (_patrolContents select _i);]

};

Or something similar, used in the scripts you load via Loadfile.

P.S

I guess _patrolContentsCount and _patrolContents are typos, seen as you don't define then. And should be _fileCount and _files?

[ColonelSandersLite 0]

I think the problem might be down to array pointers and _This. I noticed something similar when trying to determine the number of parameters passed to a script.

Basicly _This resides in the parent scope of the calling script. So when you execute the call command within that script, _This is reassigned. I can only assume from what you said. That the call compile bit, when used without parameters, defaults to the content of the function.

I would provisionally agree, except for the fact that _this isn't being modified at all, but _files is. It's also not just overwriting the specific passed element of _files, but the whole thing, otherwise, there's a chance I would have never even noticed it at all. IMHO, that makes it even stranger. In any case, what you said bears some testing. I'll look into that later since it's very late for me right now.

P.S

I guess _patrolContentsCount and _patrolContents are typos, seen as you don't define then. And should be _fileCount and _files?

Yeah, my bad. I intended to make it completely cleaned up and generic just to illustrate the point. It's fixed up now.

[UNN 0]

Quote[/b] ]I would provisionally agree, except for the fact that _this isn't being modified at all, but _files is.  It's also not just overwriting the specific passed element of _files, but the whole thing, otherwise, there's a chance I would have never even noticed it at all.

Yeah, I wasn't 100% sure and thinking about it. It does not following the same route as the problems I mentioned, form previous experience of calling _this half way through a long script. But it does sound like a problem with array pointers or a functions scope.  

Does any of the functions your calling also contain a variable call _files, that might have been omitted from the functions list of private variables? Data could be leaking from the scope of one function into another.

For array pointers, if you add the + command, you can be sure your referencing a new copy of the array which can't be corrupted elsewhere by other scripts. Won't fix the problem if that is the case, but it can help narrow down the search.

[Taurus 20]

Interesting.

I've had a similar issue with an trigger list sent to a script.

For some reason it changed even tho' I didn't modify it in any way.

example, trigger on Act: nil = [thisList] execVM "bopp.sqf"

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_triggerList = _this;

{

//do stuff which read _triggerList

}forEach _triggerList;

I was confused when I realized that _triggerList got modified by something, as it became smaller, but I didn't understand why as I didn't remove any elements from it within my script.

So I did a copy of the list sent in, not in a clever way which Unn described but it worked.

Then I realized that "_triggerList = _this" just made a reference to the "thisList" which I've sent in, not a "new" one as I wanted.