Game Development Community

AddField() and arrays

by Edward F. Maurina III · in Torque Game Engine · 06/20/2003 (11:07 pm) · 19 replies

I'm puzzling over some unexpected behavior and am hoping someone on the staff or a more experienced member can give me some insight.

Context:
I was goofing around with Sky object and poking at the cloudHeightPer field. I soon noticed that changes only affected the 0th cloud layer. Thinking this was strange, I took a look at the engine. and saw this:

addField("cloudHeightPer", TypeF32, Offset(mCloudHeight,Sky),MAX_NUM_LAYERS);

I though, "Gee. This is an array, with a mCloudHeight for each layer. I should be able to specify three values here." So I tried and got nothing. More specifically, not matter what I tried, syntatically, I could only get one value into the field. My real issue is the Inspector. I can set the array values from script as follows:

cloudHeightPer[0] = "0.349971";
cloudHeightPer[1] = "0.3";
cloudHeightPer[2] = "0.199973";

It seems as if this is a bug with the Inspector, but before I go there I'd like to see if I'm missing something.

Question:
In this specific case, mCloudHeight is a 3 element array of type F32. I'm tyring to figure out if there is a short way to populate all three elements using the current addField() specification. i.e. How do I get a value into element 1 and 2 using the Inspector?

OR,

How can I change the addField() above to allow me to intialize all three elements from the Inspector.

Footwork I've Done:
0. I've looked at the code in consoleObject.cc and simBase.cc, where the elements are manipulated.
1. Discovererd that the elementCount parameter for addField() is used for streams, but not much else. It is used to make sure the right amount of data is streamed.
2. Seen alternate methods of the form:
addField("cloudHeightPer0",          TypeF32,       Offset(&mCloudHeight[0],Sky));
addField("cloudHeightPer1",          TypeF32,       Offset(&mCloudHeight[1],Sky));
addField("cloudHeightPer2",          TypeF32,       Offset(&mCloudHeight[2],Sky));

I would like to avoid this solution if at all possible, because it is not backwards compatible and would not qualify for a patch.

Definition of addField() to save lookup:
void ConsoleObject::addField(const char*  in_pFieldname,
                       const U32 in_fieldType,
                       const dsize_t in_fieldOffset,
                       const U32 in_elementCount,
                       EnumTable *in_table)
{
   AbstractClassRep::Field f;
   f.pFieldname   = StringTable->insert(in_pFieldname);
   f.pGroupname   = NULL;				// MM: Reset new Group Field.
   f.type         = in_fieldType;
   f.offset       = in_fieldOffset;
   f.elementCount = in_elementCount;
   f.table        = in_table;
   f.validator    = NULL;

   sg_tempFieldList.push_back(f);
}

#1
06/20/2003 (11:30 pm)
Ed - I have been working closely with this code; I can give you an answer Monday or Tuesday when my brain comes back to me.
#2
06/21/2003 (2:56 am)
I screwed around with this for a while last weekend. Best answer I came up with was to list each element with addField. Course someone should really just fix the inspector.
#3
06/21/2003 (10:28 am)
@Ben - Thanks. I can wait till you recall. I'll just defer this bit of work till then.

@J. Donavan - Yeah, thats the alternate method I was discussing above. If this doesn't work, and there isn't a bug already, I'll file one. I'll wait for Ben's answer though.

Thanks again,

Ed
#4
06/21/2003 (12:44 pm)
I don't understand what the problem is.
Doing this works fine for me:


// in header
MaxNumbers = 5;
F32 times[MaxNumbers];


// in class constructor
for(U32 i = 0; i < MaxNumbers; i++)
   times[i] = 0.0;


// in initPersistFields
addField("times", TypeF32, Offset(times, SomeClassData), MaxNumbers);


// in other functions
for(U32 i = 0; i < MaxNumbers; i++)
   times[i] = someRandNumber();

So maybe I'm not understanding what the problem is?
#5
06/21/2003 (1:02 pm)
@Robert. - What I'm trying to to is modify all elements of the array from the Inspector Tool. I can modify these values from script, but the Inspector only gives access to the first element of the array.

For example, from your sample code above, in script you would be able to modify all values of times as follows:
times[0] = 0.1;
times[1] = 0.2;
...
times[4] = 0.5;

However, in the Inspector you would get a single field named times that would only 'attach' to times[0]

I hope this clears up my (minor) dilema. Thanks for answering and taking an interest in the post.

-Ed
#6
06/21/2003 (1:49 pm)
Excellent summation of the problem.

Still tracking this, just have other stuff to do first :)
#7
06/21/2003 (1:56 pm)
Thanks. I should have summarized the first time, but I tend to be wordy in my first posts... My attempts at clarity sometimes cause befuddlement instead. :)
#8
06/21/2003 (3:59 pm)
Ahh, ok now I understand :)
Interesting. I'll have to look into it myself :)
#9
06/21/2003 (4:12 pm)
Uggg I wound all the way down into the AbstractClassRep code to figure out WHY the guiInspector only shows one item. When we for a for loop adding each element of our array as a field we create one field per entry. But if we use the easy, one line addField passing in our array size it adds ONE field to the AbstractClassRep with the elementCount set to the size of the array.

When the guiInspector iterates over the fields in the object it's inspecting it doesn't pay any attention to the elementCount property of the field and just picks a control to use based on the type of field it is.
#10
06/21/2003 (4:34 pm)
Ok, I fixed it.
Once I clean up the mess I'll post the fix in this forum and submit a patch to GG.

Give me a few minutes.
#11
06/21/2003 (4:38 pm)
Oops, double post.

Going to be a little longer then a few minutes.
I have it showing all the fields now, just need
to get it to edit all the fields ;)

No longer then an hour.
#12
06/21/2003 (4:50 pm)
Most excellent! Thanks a lot for your help. I'll be watching for that patch.

-Ed
#13
06/21/2003 (5:27 pm)
Most excellent! Thanks a lot for your help. I'll be watching for that patch.

-Ed
#14
06/21/2003 (6:43 pm)
Phew, Ok done.
That was a tricky bastard, mostly because I've never fully explored that area of code, except for the console functions, so I sort of knew what I was doing :)

Trying to think of the best way of getting this to you guys.
I'll probably just do a diff of torque head and then give you guys the .patch file. Does that sound okay?
#15
06/21/2003 (7:32 pm)
Okay. Here is the .patch for this.
Let me know if you have any problems.
I'm going to submit this to Tim Gift later today.

The fix
#16
06/21/2003 (9:52 pm)
Good deal. Thanks a lot for your effot!
#17
06/22/2003 (9:59 am)
Bump for those who missed it. Fix is above. I would appreciate any feedback about the fix or if you've run into an issue with it.
#18
06/22/2003 (12:21 pm)
You are a stud. It works like a charm. The patch applied no problem and, viola, it works the way it should.

Thanks again.
#19
12/29/2005 (8:21 am)
Is it me or is this still not working ? The link to the patch above doesnt work anymore either..