Difference between revisions of "Talk:Object Format"

Revision as of 21:29, 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 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. --Warmonger (talk) 21:36, 1 February 2013 (CET)

Creature banks (at least one added by mods) should have their configuration defined in objectData. As for monoliths - good point. Such objects can have one property (in this case - group they're linked with) that usually will be same as subID. Ivan (talk) 22:29, 1 February 2013 (CET)

So how do you want scripts to influence objects? How would they refer to an object type? --Tow dragon (talk) 21:45, 1 February 2013 (CET)

Modifying behavior of existing objects - by string ID's (no changes here). Implementing new objects - "object" field should refer to class implemented in script. Another option (to avoid OOP in mods) is to use same mechanism as for existing objects. In this case object and objectData fields will be unused Ivan (talk) 22:29, 1 February 2013 (CET)