• Cfgfile.em suggestions

Posted: **Mon Jan 29, 2007 4:10 pm**

Not sure if these have been suggested already, and to be honest, I'm moving to another server platform anyway, but I had always found these lacking in POL before so thought I would suggest them for it's improvement.

A way to get all the properties in a given cfg element without necessarily knowing the names of those properties.

Ie, a : GetConfigPropertyNames(cfgelemref) which returns an array of the names of all the elements for that element reference.

A way to get the type of the config element.

Ie, a : GetConfigElemType(cfgElemRef) which returns a string, which is the type of the config element.

These are useful for when you want to do generic rebuildings of config files, which is something you might want to do for various reasons, though the one that comes to mind is when you are shifting art/items from one ID to another, and want to run a script which scans through various config files, and writes out new versions of them by changing the ID's for those items that are getting moved. Since you don't know the type(you could be reading a variety of cfg files with different types), and since there is no way to get the elem type via script that I know of, the GetConfigElemType would be useful in reconstructing the cfg file. Also, since you don't know what the property names are, GetConfigPropertyNames allows you to get all the property names for that given element, and then you can use those names to ask for the values and from there rebuild that element with the new IDs.

If there are ways to do this already, I would love to hear how. But if not, it might be useful to add in some future version of POL at some date.

Posted: **Tue Jan 30, 2007 2:00 pm**

neizarr wrote:...

GetConfigPropertyNames(cfgelemref) which returns an array of the names of all the elements for that element reference.

...

GetConfigElemType(cfgElemRef) which returns a string, which is the type of the config element.

...

I thought it rather interesting that the first of those functions didn't exist already (as well as slightly disappointed) when I was scripting an in-game config-file navigator. I wanted to be able to display a config file as it appears in notepad, but had to settle. I definitely think that is a good idea.

The second one, however, I don't see as particularly useful. To my knowledge, the only text-files that care about datatypes in POL are datafiles. Config files don't use the datatype prefix unless you're dealing with CProps.

For example:

itemdesc entry

Code: Select all

    CProp   my_integer    i52

would set a CProp named my_integer with an integer value of 52 on the item upon creation.

Assuming that the need for knowledge of datatypes was absolutely imperative, however, I would take a look at basic.em's TypeOf().

TypeOf dictates that all available datatypes are:

"Dictionary", "AccountRef", "ConfigFileRef", "ConfigElemRef", "DataFileRef", "DataElemRef", "ScriptExRef", "GuildRef", "BoundingBox", "DebugContext", "Package", "MenuRef", "MobileRef", "OfflineMobileRef", "ItemRef", "BoatRef", "MultiRef", "Unknown", "Uninit", "String", "Integer", "Double", "Array", "ApplicPtr", "ApplicObj", "Error", "Struct", "Packet"

Since it's a config file, you can immediately narrow that down to:

"String","Integer","Double"

Considering that, testing for a datatype could be done as:

Code: Select all

use cfgfile;
use basic;

function GetConfigElemType( byref cfgElem )
    /*
     *  Use a string array, because you don't know how many 
     *  values there are going to be for this entry. 
     */
    var elem_value = GetConfigStringArray(elem_value);

    /*
     * If the value has more than one entry, it can either be 
     * an array or a dictionary.  For demonstration purpose, we'll
     * ignore the idea of a dictionary.  They're just specialized 
     * arrays anyways.
     */
    if( len(elem_value) > 1 )
        return "Array";
    endif

    /*
     * If the value cannot be converted to an integer, it must be
     * a string.
     */
    if( !CInt(elem_value) )
        return "String";
    endif

    /*
     * If the value is not an array, and it is not a string, it must be
     * either an integer, or a double.  Since doubles have decimals, and
     * integers do not, test it for a decimal point.
     */
    if( elem_value["."] )
        return "Double";
    endif

    /*
     * If the value is not an array, string or double, then it must be an
     * integer.
     */
    return "Integer";
endfunction

I hope that's even slightly helpful.

Posted: **Sun Feb 04, 2007 12:04 am**

The Type I speak of is of the config file element Type...such as Weapon, Armor, Item, etc.

It is useful in that it allows you to know what sort of Type the config element is. Bear in mind, in this case I am not speaking of the "TypeOf" type, but rather the config elem Type.

As in :

Weapon 0xF020
{
...
}

Reading the 0xf020 element you can get all the individual properties of that element via cfgfile.em functions, but you can't determine what the Type of the element is, which, in the above case it is Weapon.

If you are trying to find out what that specific Type is for a element, you have absolutely no means of doing so. This hurts when you might want to write a script to start converting ID's from one ID to another. Say your script converts itemdesc.cfg file items based on a table created in an include file that you created to help the process. When you try to make a new itemdesc.cfg file off of the current one, you will be able to read all the keys in the file, and with my suggested function for finding out all the properties of the element you can do that too, but without my suggested function for determining the Type, you can't determine that it is of Type Weapon, and so can't write the new file properly.

Hopefully I'm being clear, the config elem Type has nothing whatsoever to do with the various types found in POL escript. And I would use another term if it wasn't the term given for what it is called in the POL documentation. It would probably be better off called something else, like Header or something.

Thanks for the suggestion though, but it doesn't really work for this particular case.

Posted: **Sun Feb 04, 2007 4:46 pm**

That isn't completely impossible; it's just not a reliable fix across all scriptbases. What I would suggest is finding a configuration value that's unique to one object class, and use that to differentiate the type. For example:

Code: Select all

function ItemType( byref cfg_elem )
    if ( cfg_elem.SpellType )
        return "Spellbook";
    elseif ( cfg_elem.Gump )
        return "Container";
    elseif ( cfg_elem.XMod )
        return "Door";
    elseif ( cfg_elem.MultiID )
        if( /* Do check for boat */ )
            return "Boat";
        else
            return "House";
        endif
    elseif ( cfg_elem.Editable )
        return "Map";
    elseif ( cfg_elem.Damage )
        return "Weapon";
    elseif ( cfg_elem.AR )
        return "Armor";
    endif
    return "Item";
endfunction

(Based on pol096 Documentation)

Posted: **Sun Feb 11, 2007 1:46 am**

I think we are missing something in translation. Cfgelem.Weapon would return whether there was a Weapon property inside the Cfgelem. What I want is the Type for that Element, not an element named Weapon.

Ie :

Weapon 0x5352
{
...
Weapon 1
...
}

Armor 0x5352
{
...
Weapon 1
...
}

If you have an element named cfgElem and you say if cfgElem.Weapon, you will get the value 1 for both cases, when what I want is what is in italics in each case, the string value for the Type.

All I am saying is I want a function that when passed a cfgElem gives me back, in string form, what is in italics above for that given element in the config file. There is no current way to get that whatsoever.

Cfgfile.em suggestions

Cfgfile.em suggestions

Re: Cfgfile.em suggestions