TorqueScript limitation - is perception reality?

[Tiel]

I've come across an issue working with script files

When creating a material or object via script, and just script (ala transient), having numbers in the generated object's name seems to make things screwy.

IE, if I had a loop to create several materials like so

 

for(%i = 0; %i < 4; %i++)
{
%newmat = new Material(%i@"_testmaterial");
}

 

output is

0_testmaterial

1_testmaterial

2_testmaterial

3_testmaterial

However, if you go ahead and try to call any of these by script you'll get a parse error.

 

eval("0_testmaterial.getID();");

 

output is

parse error.

note: They'll RETURN the name you gave them if called, but basically it seems to be even though you create a material with a given name, it doesn't link up to it in a way you'd expect, because of the numbers. I can create materials just fine via script as long as their names are either pure int or pure string, there just isn't an in between.

I haven't done more extensive testing but this appears to go for more than just materials. Why is this limitation in place?

PS: Have looked through the cpp's but unfortunately the declarations I'm looking at are all 'String', which to my understanding is about as loose as you can get with a variable type in C++.

[Duion]

My materials are all numbered material_01, material_02 etc, works fine.

[Tiel]

Are you generating them on the fly, though?

I find reading objects etc from file (ie materials.cs) with alphanumeric names works just fine. But trying to create them with mixed names at execution causes them to fail to bind.

I'll clarify. Like, if I were to make a function to create a material or object

 

function generateobj(%newname)
{
//create new object
%newobj=new object(%newname);
return %newobj;
}

 

and let's say the %newname param in this example happens to be 'material'

this will work just fine

if %newname in this example is set to be '45617_666'

it will work, you can use the generated object just fine

however, if %newname is set to any combination thereof, like 'material_01', or '111_valkryieskin'

the object will generate, but you can't access it by name. so basically even if it were generated as '111_valkyrieskin' successfully and does exist, any code trying to reference '111_valkyrieskin' will result in a parse error. Note that using the getName method against the ID of the alphanumeric object will return the correct name; it just seems to fail to bind to the ID in the system for some reason.

Which is really odd, because you can create objects at runtime and have them work successfully, and you can have alphanumeric objects loaded from file work just fine (as you point out, I think), but for some reason trying to make an object at runtime with a name containing both numbers and letters just doesn't work the way it should.

Now that I've had my morning coffee I think what I could do is just set up an array for my generated objects (seeing as reference via ID seems to work alright), but just the same I'm still curious how this came to be.

[newaged]

output is

0_testmaterial

1_testmaterial

2_testmaterial

3_testmaterial

 

Names and vars can't start with numbers. Switch the names to testmaterial_[%i] and things will start going much smoother.

[Tiel]

but whyyy dad

like I'd wanted to use the skinning system with such materials, but those have to be a prefix, no?

[newaged]

The numbers thing is just how the language works. You can still easily generate prefixes with that limitation, just stick a random char or short string in front of the number

 "string" @ %i @ "_material"

[Tiel]

good god you are completely and utterly right, feeling pretty dumb. Thank you for taking the time to enlighten this ignorant fool.

Though, gotta say, wish this were annotated somewhere.

[MangoFusion]

TS grammar is similar to C, so you cant prefix variable names or references to object names with numbers.

In addition you wont be able to locate the object by name since Sim::findObject assumes names which begin with numbers are id strings.

I would advise just postfixing numbers instead of prefixing them.

[Tiel]

Is that true? Man, I'm actually half decent in C#, guess I've just never had a reason to prefix numbers in variables before until torque's skin tutorial.

Whelp, you live to learn.

[rlranft]

Heh - saw this and thought "but, why would you start a variable name with a number?" I've actually never tried this in my life. AppleSoft BASIC also didn't allow it - in fact, IIRC you couldn't use numbers in variable names at all (in addition to the two character name length limitation - names could be longer than two characters, but only the first two characters mattered) and you had to be careful that the parser didn't decide the variable SCORE was actually SC or E.