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. --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)

RMG and AI traits

To allow effective usage of new objects, the properties listed below should be assigned to their classes (types). For performance reasons it would be nice if object properties were retrieved once at RMG / AI launch and not polled for every new object.

Yeah, properties like this should be stored globally. RMG needs access to them without creating object instance.

BTW - sign below your post with 4 tildas (~) to add signature

Ivan (talk) 23:57, 4 January 2014 (CET)

RMG traits

Partially overlaping with map editor:

• Allowed terrain
• Tags

Tags do not only help to manage objects in map editor. I fact, all viistable objects in RMG are (probably) assigned to three groups - we can see these groups in RMG templates. Each zone has defined density of objects of some kind. it is important to deduce these groups and force objects to be assigned to some category. Alternative is to separate editor tags and editor category.

• Object value - determines if the object will appear in poor or rich zones on a map and strength of its guardians
• Object rarity - how often does the object spawn on the map. Preferably I'd make this parameter float to allow fine-tuningand making some objects very rare. There is also need for algorithm who can draw objects based on their rarity.

• Visual propeties. These may help to group objects on a map in a visually pleasing way. A list of tags should be extensive, but closed to ensure consitency. Visual properties can work as boolean tags or be fractional to allow fine-tuning. Some examples are:
  • Foliage
  • Rock
  • Mountain
  • Structure
  • Fauna
  • Magical
  • Modern
  • Ancient

For instance one can imagine that Dwarven Treasury has "Mountain" and "Structure" tags, so it appears near mountains and other built structures and not in a middle of forest.

* Tags - I think that RMG tags and editor tags should be separate. Idea behind editor tags was to add easy-to-use filters so for example typing "inferno dwelling" will show objects with these two tags, namely - all inferno dwellings. Editor would need some way to help searching through huge lists of objects

Ivan (talk) 00:03, 5 January 2014 (CET)

AI Traits

These traits help AI understand the object and use it in an effective way. For example, AI may need to know which objects could be a source of resources or army. Creature banks cna provide such functionality with their config, but custom objects also do (for example Windmill-like objects). It would be nice if an object type could return complete list of goods it can provide, so AI could plan its actions based on that knowledge:

• creatures
• resources
• artifacts
• stats
• spells
• uncover area?

Additionally, object value shared with RMG could serve as a simple factoring. This way AI could try to visit objects of highest value and not all of them, as it does now.