Difference between revisions of "Talk:Object Format"

Revision as of 17:57, 1 February 2013

ID's, subID's and strings

I am not sure if stringID's from the rest of engine (creature.xxx, artifact.xxx) are applicable here. This ID should be a property of an object and may not have same ID (e.g. external dwellings).

Maybe something like this:

// either some new stringID or id from current Obj enum
// in first case corresponding numeric ID will be autoassigned by engine
"id" : "dwelling"

// same as ID
"subID"

// Class responsible for handing of this object.
// Can be one of our C++ classes or something from scripting system
"object" : "CGDwelling",

// Data passed to object during construction
"objectData" :
{
    "creature" : "pikeman"
}

I wan to see code example how to handle this in engine (not in scripts). Assume you have typeID found by classname, what next?--AVS (talk) 18:57, 1 February 2013 (CET)

This will also allow us some more flexibility for some objects like star axis:

"id" : "id of axis",
"subID" : "subID of star axis",

"object" : "COncePerHeroObject", //or whatever its name is...

"objectData" :
{
    "skill" :
   {
        "spellpower" : 1
    }
}

I think object mechanics (objectData) should not be configured here -- at least not to this degree. Maybe a path to script handling mechanics would be OK but what you suggest seems to be of little benefit. BTW string IDs are one of additions I would like to see. What's the problem with external dwellings? They are randomized, but so what? This operation just changes their stringID. Encoding of randomization rules is an interesting topic for another discussion. --Tow dragon (talk) 18:52, 1 February 2013 (CET)