Trouble with initPersistFields
by John Purchase · in Torque Game Engine · 01/30/2009 (8:28 am) · 5 replies
I'm trying to extend the Path and Marker code to create a network of connected markers instead of a series of markers. To do this, obviously I need to specify the connections. The first thing I tried in the initPersistFields method was:
The thought here was that I'd use a vector of object IDs. When I fired up the engine and entered the world editor, the field was there, but it was just a field - I was hoping the UI would have some control suggesting a list - and if I put more than one value in, all but the first got dropped.
So I tried something else. I figured if I could just get a string, I could put in a space or comma separated list and parse it myself into the list. A bit fiddly, but why not. So I tried this:
The mConnectionLists variable is of type StringTableEntry, which is really just a typedef-ed const char*. This causes the world editor to crash when attempting to inspect the MyMarker. This looks like me trying to write to memory with an uninitialized pointer, so maybe I'll figure this out on my own.
But my real question is: Is this the right way to go about this? Is there not some example in the engine already of someone collecting a list of something in a field?
addField("connections", TypeS32Vector, Offset(mConnectionList, MyMarker));The thought here was that I'd use a vector of object IDs. When I fired up the engine and entered the world editor, the field was there, but it was just a field - I was hoping the UI would have some control suggesting a list - and if I put more than one value in, all but the first got dropped.
So I tried something else. I figured if I could just get a string, I could put in a space or comma separated list and parse it myself into the list. A bit fiddly, but why not. So I tried this:
addField("connections", TypeCaseString, Offset(mConnectionList, MyMarker));The mConnectionLists variable is of type StringTableEntry, which is really just a typedef-ed const char*. This causes the world editor to crash when attempting to inspect the MyMarker. This looks like me trying to write to memory with an uninitialized pointer, so maybe I'll figure this out on my own.
But my real question is: Is this the right way to go about this? Is there not some example in the engine already of someone collecting a list of something in a field?
#2
Something like
In script
Then in c++ do something like
The reason not to use the object id's is they can change from one mission load to the next.
01/30/2009 (12:59 pm)
A better way may be to use the fields to point to the markers unique name.Something like
In script
new Marker("Marker_uniqueName") {
...
}Then in c++ do something like
SimObject * obj = Sim::findObject(Marker_uniqueName);
The reason not to use the object id's is they can change from one mission load to the next.
#3
One of the reasons that I was considering object IDs was because of the data types available. I'm trying to create an arbitrary list of markers, so "TypeS32Vector" looked like a possibility, as I should be able to stuff an object ID into an S32 variable.
There doesn't seem to be a TypeStringVector, in which I could store a list of unique names. The only solution I can think of is to create a comma separated list from a single string, which I then have to parse. I can write my own parser to do this, but I'd prefer not to, particularly if someone has already built this functionality.
Has anyone built this?
02/02/2009 (2:07 pm)
Thanks for the tip on preferring unique names to object IDs. I can see how that could have got me into trouble.One of the reasons that I was considering object IDs was because of the data types available. I'm trying to create an arbitrary list of markers, so "TypeS32Vector" looked like a possibility, as I should be able to stuff an object ID into an S32 variable.
There doesn't seem to be a TypeStringVector, in which I could store a list of unique names. The only solution I can think of is to create a comma separated list from a single string, which I then have to parse. I can write my own parser to do this, but I'd prefer not to, particularly if someone has already built this functionality.
Has anyone built this?
#4
02/02/2009 (5:59 pm)
The ParticleEmitterData class actually does something similar. Look for "particleString" in particleEngine.cc. The ParticleEmitterData class takes a string which is a space-delimited list of ParticleData objects (allowing you to specify multiple particles to be emitted from the same emitter). You can probably pull that code for your own needs. 
Torque Owner John Purchase