Difference between revisions of "Talk:Object Format"

From VCMI Project Wiki
Jump to: navigation, search
m
m (ID's, subID's and strings)
Line 39: Line 39:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
I think object mechanics 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.
+
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.
 
--[[User:Tow dragon|Tow dragon]] ([[User talk:Tow dragon|talk]]) 18:52, 1 February 2013 (CET)
 
--[[User:Tow dragon|Tow dragon]] ([[User talk:Tow dragon|talk]]) 18:52, 1 February 2013 (CET)

Revision as of 17:52, 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"
}

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)