Give TS a real array, or allow passing of arrays.

#1 There are some resources posted to add support for real arrays and even STL. Try a search and see what you can find.

#2 @Jason, If you read the thread I referenced, I'm completely aware of my options, but TS needs a "real" native array in my opinion , binary only users would appreciate that data type, and at a minimum what is there today should be able to be copied, and passed around like other data types.

#3 This would be my vote:

1. enhance SimSet to provide more array like features,
2. add a new type: SimDictionary (hashtable)

1. could be done in script though by adding members to the SimSet:: namespace.

#4 Its still my opinion that for many "utility" functions, building up simsets, etc are just overkill. I use simSets myself for most of my stuctures personally. But honestly go build a simset of 10K members for a point map... You'll see what I mean, the performance just isn't there for building things like pathfinding. I'm just starting the discussion, I could build mine in c++ or use STL , but I'm thinking about the value to the Binary only users. And yeah, they should just buy the source... my real original point was , if your going to call something an array, that array should be passable to functions..

#5 I like the suggestions by Alex. [Now that you mention it, SimDictionary would be an invaluable addition to the TGB toolset.]

Unfortunately, asking for radical changes to the engine when the GG team is rushing to declare GM status probably makes them groan in frustration. Adding the array resource to the engine, however, would be simply done and would benefit the poor blokes who will purchase the engine-without-source; only to discover that something as elementary as a real array is not included.

#6 I dont want or need it immediately, its just a suggestion :-)

#7 A ScriptObject works great to act as an array... such as

new ScriptObject(array);

array.contents[0] = "blah1";
array.contents[1] = "blah2";
array.contents[2] = "blah3";
array.contents[3] = "blah4";
array.contents[4] = "blah5";

than you can pass that object and each array reference is just a value attached to that script object.

#8 @Matt, thats exactly what I currently use, but i'm having performance issues scaling past 10K or so entries. I'm not trying to be a bad apple, my suggestion was only that a native array would be faster and less overkill for doing things like AI and pathfinding in native TS... I'm building mine in c++ anyway, it was just a suggestion.

Rod :-)

#9 I mean why they (GG) can't add this simple cc file, it has been in my code base since 1.0.2
an still is working in my current release, and I can't imagine do some things without it... and almost every new torqueScript programmer ask the same question always...
Lazines? ;). its just 5 minutes to add this cc file to the current release...
and forget foreever and ever...

#10 When you add something to your code base, you support it and only need it to work for you...

If we add something to our codebase then it needs be fully supported by us, completely tested by us, proven by us, and work for everyone's solution. All of that takes time, even if it is a stable fix and just requires testing.

We can never forget any file we add :)

Edit: honestly I find the laziness comment a bit offending, especially since most of us work 10-16 hour days (and right now in crunch time we work all weekend long, sometimes outside of crunch time as well), to make TGB as good as possible. Just because you don't understand the reasons behind something doesn't mean there aren't reasons behind it. Its polite to simply ask before you assume.

#11 Sorry for starting this post guys... I just thought it was odd you couldn't pass a quasi array to functions...

I mean no disrespect and Matt and team I hope you realize that.

#12 Rodney your request was phrased respectuflly and I definately understand your concern. Right now TGB is in feature lockdown to ensure we polish and bug test what we already have. We can consider including it, though most likely would be a later addition.

#13 Thanks thats all I expect is for it to be taken into some consideration.. Now get back to work! :-)

#14

Quote:Lazines? ;).

It was a bad joke man... Sorry about that. I mean the evil smile was saying that... :)
I know you work hard and I KNOW is not in your hands Mattew, that for sure
Also you can always add this addon to the binary and say is unsupported, no code is going to break
(except mine maybe) if you call it array that it is.
And whoever want to use it must be aware of this.

#15 Sorry, didn't realize it as a joke... part of the problem of communication over a forum lol.

Unfortunately leaving something that is completely unsupported isn't much of an option for us, since whether we say it's unsupported or not people will still expect us to support it. Also this may make sense to us, now... but to the end binary user, if they hit a problem they will wonder why we have code in our engine we don't support.