var d1 = new Array();
...
d1.Push(Vector2(someX, someY));
...
if (d1[i].x > xMax)
DoSomething();
Now it’s telling me that “x” and “y” are not members of “Object”. So now how do I define and build an array with an unknown number of elements? This method appears to still be supported according to the scripting reference.
You’re saying arrays are no longer supported? Bummer! I can convert to lists, but that’s pretty much every project I have, which will involve a significant amount of work to be able to do anything with any of them in 3.4.
If arrays are not supported in JS, I’d suggest updating the documentation to reflect that change. Maybe it will prevent others from making the same mistake I did.
No, that’s not what I’m saying. Switch to web/PC/Mac publishing (as opposed to iOS/Android) and JS Array class works as usual. With #pragma strict (which is enforced with iOS/Android publishing), you have to cast the results of Array to the correct type manually. But I would strongly recommend using List over Array, and it would actually probably be simpler to convert to List than do all the typecasting necessary to use Array with #pragma strict, not to mention it’s significantly faster.
In updating my code, I see that GetPixels returns an array. Since lists are significantly faster and since GetPixels is very slow, I was just wondering if there is any way to use a list with GetPixels. Seems like if I just typecast the result to a list, that would make it even slower.
GetPixels returns Color[ ], which doesn’t have anything to do with the Array class at all. It’s much much faster. Built-in arrays like that are the fastest possible array type. However, Unity 3.4 has GetPixels32, which returns Color32[ ], which is faster than Color[ ] and uses 4X less RAM.
That sounds great. Unfortunately it looks like SetPixels32 is not interchangeable with SetPixels. It does not let you set the pixels in only a region of the texture.
That sounds great! Unfortunately it looks like SetPixels32 is not totally interchangeable with SetPixels. It does not let you set the pixels in only a region of the texture.
So far in my Unity development, I’ve only used JavaScript arrays. Now that I’m on Unity 3.4, it complains about the 2d javascript arrays I’m using.
Here’s an example of some of my existing code. In the second line below I assign a value from a 1d array to a spot in a 2d array.
levelSectionNames[levelSectionNamesIndex] = new Array(5);
levelSectionNames[levelSectionNamesIndex][0] = levelSectionNameWords[0];
Under 3.4, the second line of that now gives me the error: Type ‘Object’ does not support slicing. What’s the correct way to access a 2d array with the new JS compiler?
If I move everything over to Lists, does “Should be using List instead” mean ArrayLists or System.Collections.Generic.List? My Google-fu doesn’t seem to be good enough to find a good reference for how to properly use Lists as a 2d array. Does anyone know of a good reference for 2d lists?
Thanks a ton Eric. That works great for an all-String array. Is there a way with the new compiler to have an array with a string as the first column and an int as the second?
I have a 2d array with GameCenter friend’s names (as strings) and their high scores (as ints). I could use strings for everything with a cast, but I’d rather just define the array how I want to use it - if possible.
Here’s an example of what the array assignments currently look like:
var friendArray = new Array();
for (i=0;i<=totalFriends;i++) { //totalFriends is the number of friends from GameCenter
friendArray[i] = new Array();
}
//placeholder names scores...
friendArray[0,0] = "1337Racer";
friendArray[0,1] = 145;
friendArray[1,0] = "evil friend";
friendArray[1,1] = 1128;
friendArray[2,0] = "JScott";
friendArray[2,1] = 2034;
//...and this goes on
If I define the array this way, I have to make the scores strings:
var friendArray = new String[9,2];
//placeholder names scores...
friendArray[0,0] = "1337Racer";
friendArray[0,1] = "145";
friendArray[1,0] = "evil friend";
friendArray[1,1] = "1128";
friendArray[2,0] = "JScott";
friendArray[2,1] = "2034";
//...and this goes on
Yup, you’re right. That’d be a good way to do it. It scares me how much code I’m going to have to change to make that happen though. My entire level structure is defined in arrays like this too. This is not going to be fun.
I just converted my arrays to lists in an app in preparation for porting to iPad. This is a physics simulation that does a HUGE amount of number crunching with HUGE arrays. Using lists has dramatically decreased the time it takes to complete these calculations. Went from over 5 minutes to just over 2 minutes! And the necessary code changes were minimal. Thanks again for the advice about using lists.
I’m getting the same kind of errors with a hashtable that I was getting with arrays. Compiles fine and works correctly for web player, but does not compile for iPad (I’ve commented the line with the error).
Could it have something to do with the Hashtable not having a type? If so, I can’t find a way to define a hashtable with a type. Is it possible to define the values in the hashtable as integers?
var rowCount: int;
function CreateHashTable () {
var i: int;
longLookup = new Hashtable(); // columns
for (i = 1; i < longitudes.Count; i++)
longLookup.Add(longitudes[i], i);
latLookup = new Hashtable(); // rows
for (i = 1; i <= rowCount; i++)
latLookup.Add(latitudes[i], i);
}
// ----------------------------------------
function GetTemperature (theLat: int, theLong: int, theLevel: int): float {
var tLa: int;
var tLo: int;
tLa = latLookup[theLat] + (theLevel * rowCount); // Operator '+' cannot be used with a left hand side of type 'Object' and a right hand side of type 'int'.
tLo = longLookup[theLong];
return tempData[tLa][tLo];
}
If I assign latLookup[theLat] to a temporary int variable, and use that in the equation, it works. But it seems like there should be a better way of doing it.
Thanks. Once again, a significant difference. Using dictionaries instead of hash tables knocked another 30 seconds off the calculation time. So using lists and dictionaries instead of arrays and hash tables, the calculation time went from over 300 to 100 seconds!
It would be great if some of this info were included in the script reference. Especially about arrays versus lists in the section on JS arrays.