Game Development Community

Prevent fields from being written out to .gui's and .mis ?

by Orion Elenzil · in Torque Game Engine · 02/25/2006 (1:21 pm) · 3 replies

Is there an easy way to prevent a field from being written out to the .gui file by the GUI editor ?

i've got some fields which want script access, so they're in InitPersistFields, ... oh.
but isn't that how they get script access ?

A: yes, but an easy alternative is to NOT put them in InitPersistFields and instead just provide setters and getters.


okay, but what about not storing fields when their value is the default value ?

is there a mechanism for that ?

tia,
orion

#1
03/03/2006 (9:11 am)
Well, theres nothing there by default to do that, but you could always check the save function which saves the fields out to a file. Although, theres no real reason to hide the fields. If they need to be hidden from the user for 'security' purposes, I suggest just having set and get functions.
#2
03/03/2006 (10:10 am)
Are those fields created in script? If so, I have a way of storing dynamic variables and keeping them from being saved: globals! Read...

In traditional way, you'd do this:

function myButton::setMyValue(%this, %value)
{
   %this.myValue = %value;
}

But myValue will be saved when the myButton object is saved. To prevent that, store the value in a global variable, using torquescripts "arrays" with the object's ID to indentify it. Example:

function myButton::setMyValue(%this, %value)
{
   $fields[%this, myValue] = %value;
}

To access the value, just use the object ID:

function myButton::getMyValue(%this, %something)
{
   return $fields[%this, myValue];
}

If you're already using getters and setters, it's easy to change the implementation. Storing dynamic values in GUIs was the cause for a major bug in one of our projects: we had an inventory GUI, and stored the ID of a simGroup used to store the inventory items. That ID eventually got saved with the GUI file, and when the inventory clear() method was called, something else that happened to have the same ID as the one stored was deleted instead.

It took us a good while to find out why some objects were being deleted seemingly at random... afterwards I changed all GUI and mission object dynamic field storage to ID-tagged globals.
#3
03/08/2006 (11:46 am)
Manoel,
again thanks.

this seems to be just the ticket.

i'm a bit worried about performance hits to recommend it as a general technique,
but in certain spots it's just the thing.


PS
i created a pair of functions like this:
function gSetField(%object, %name, %value)
{
   $gGlobalFields[%object, %name] = %value;
}

function gGetField(%object, %name)
{
   return $gGlobalFields[%object, %name];
}