Discerning between an integer and an object

[Vaux]

I'm currently writing a serializer but having trouble with discerning between regular integer properties and object properties due to the way objects are stored in TS.  isObject doesn't work in this case because an integer tested (E.G: 1338) could/and most likely will be an existing object even though the integer isn't meant to represent that object.  Thoughts?

[Ad Bot]

[otto-san]

is it a problem that it might represent an object? what are you actually trying to do? if you just want to make sure something is a number you might be overcomplicating things

i'm a big smelly dingus butt that doesn't understand what reading is

[Goth77]

You would have to convert the integer to a string

[Headcrab Zombie]

Is this a serializer for one specific object type for your own add-on, or a generic serializer to use as a general resource?

[Vaux]

For example, say I have a variable %foo and I set foo to %foo = new ScriptObject();.  This variable then becomes a representation of the script object created in an integer ID format (%foo = 17259;).  When my serializer comes across this variable, it will attempt to save it.  Theoretically, if this variable was able to be clearly identified as an object, the serializer would then perform additional steps on the object's properties and so-forth.  The problem currently being: every integer it comes across is treated as an integer because of this uncertainty, thus not allowing potential objects to have their properties saved as well.

A solution I currently see, however, is one where each script object ID is manually prefixed by a special character when the script object is created.  What I'm hoping for though is a more dynamic solution that doesn't require the manual prefixation of script object ids, though I currently don't see a way of that working, which is why I'm creating this thread for help.

Is this a serializer for one specific object type for your own add-on, or a generic serializer to use as a general resource?

A serializer for any potential object, but specialized for my own add-on.

[Headcrab Zombie]

You could create a "SerializerSettings" class that people use to mark how fields are serialized
That's something you'll want even if you find a solution, because there will be instances where their are fields you don't want serialized

[$trinick]

At the Torque level, an object ID and a number of the same quantitative value are exactly the same thing. If your Object's ID number is 1532, (1531+1).dump(); will dump your object.

If you are serializing your own objects, use the property names to denote the type of value they are.

oWeapon -> serialize weapon object
nWeapon -> serialize as number

[portify]

This is perhaps one of my single biggest issues with the language. Generally in more dynamic approaches I tend to suffix object IDs with "\x01" and test for that. This eliminates almost all false positives but it still allows for rogue user input to break it. Do note that LeverScript class instance references already have this suffix, and that liblever can check for it with iloveplicitObject.

[Headcrab Zombie]

Yeah if you're serializing only your own objects, the naming convention solution would be the easiest.

But as a resource for others to use, it's not as doable because you can't just change the naming of every single class in the game, so I'd go with the "SerializerSettings" class idea. Probably just an array of SerializeFieldAs[fieldName] = "ignore/value/object"

[Vaux]

I've decided to implement a cross between two of the systems suggested.  As Port mentioned, due to the peculiarity of how ScriptObject ids are interpreted when called, any integer with a special hidden character at the end is regarded as an object, and anything that doesn't have the extra character is simply regarded as a normal integer.  Also, for determining which properties should be serialized, I implemented a variation of Headcrab Zombie's idea in the form of onSave and onLoad methods in SOs for them to support serialization.  These functions return/take-in a payload of which properties should be serialized/have been serialized.  Thanks everyone for the help.

[Headcrab Zombie]

Is this going to be released as a resource?
Also, what format does it serialize to? JSON? XML? Some format you made up?
Will there also be a deserializer?

[Vaux]

Is this going to be released as a resource?
Also, what format does it serialize to? JSON? XML? Some format you made up?
Will there also be a deserializer?

I don't have any intentions of releasing it, being as it's only currently intended to be used by my own add-on, but if you want the source, feel free to ask.  It serializes and deserializes (parses) data in a format I threw together -- the format, however, is closest in syntax to JSON, instead of XML, in that values are delimited with commas and objects are enclosed in braces.