Talk:Object Format

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 meaning as ID
"subID" : "guardhouse"

// 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 would need some object registering phase. Not sure if this can be automated (bad part). During this registering engine should create mapping string -> function that constructs object from objID + json objectData. Everything else can remain unchanged Ivan (talk) 19:50, 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)

Dwellings problem is need of dwellings.json config file - their subID does not matches ID of creature. So instead of writing that config file all dwelling -> available creatures information can be stored in object definitions. Same goes to huge switch(objectID) in our code. Ivan (talk) 19:50, 1 February 2013 (CET)

and how does it make string ids inapplicable? --Tow dragon (talk) 20:37, 1 February 2013 (CET)

I think that objects should not have id-dependent behavior. All such behavior should be moved somewhere else. Like objectData. This won't affect ID's - they should be handled similar to the rest of engine (dynamic in mods, static in H3 object for H3M loading) Ivan (talk) 21:17, 1 February 2013 (CET)

It should be possible to append more objects with same ID but different subIDs, both for sanity and for random map generator. Examples of such objects are creature banks which should keep base behaviour same, or monoliths - adding monoliths with new look should be possible and they should all be picked by RMG equally.