Difference between revisions of "Talk:Object instance format"

From VCMI Project Wiki
Jump to: navigation, search
(Possible enchancements)
(Fields renames/tweaks)
Line 14: Line 14:
  
 
* Stack instance: "creCount" -> "amount" - readability
 
* Stack instance: "creCount" -> "amount" - readability
 +
*:{{done}}
 +
 
* Stack instance: "creID" -> "type" - readability
 
* Stack instance: "creID" -> "type" - readability
 +
*:{{done}} Hate this one: "type" is a keyword in pascal (but can be used as identifier in form &type).
 +
 
* Garrison: "garrison" -> "army" - for consistency with hero, town, etc.
 
* Garrison: "garrison" -> "army" - for consistency with hero, town, etc.
 +
*: {{done}}
 +
 
* Hero: "sex" (string) -> "female" (bool) - to match engine & modding format
 
* Hero: "sex" (string) -> "female" (bool) - to match engine & modding format
 +
*: This need 3 values: female, male, and "defined by config"
 
* Hero: "id" - I don't like this word. Type? Base Hero?  
 
* Hero: "id" - I don't like this word. Type? Base Hero?  
 +
*:{{done}} set to type, see above :)
 
* Check for case inconsistencies - I see "spellID" and "spellId" in some fields. Same applies to other types of id's
 
* Check for case inconsistencies - I see "spellID" and "spellId" in some fields. Same applies to other types of id's
 
* Or just remove "id" part from all fields. "spell" : "slow". Looks fine for me.
 
* Or just remove "id" part from all fields. "spell" : "slow". Looks fine for me.
 +
*:{{wip}}
  
 
== Notes ==
 
== Notes ==

Revision as of 05:19, 5 July 2015

Possible enchancements

  • Mine : "army" - already supported by engine, but can't be configured in map
    Should we prepare army/guards option for _all_ objects?
  • Random dwelling : instead of using "linked" field just don't save unused field. So if dwelling is linked "sameAsTown" is present, while "allowedFactions" is not and vice versa.
  • Random dwelling : Perhaps we can find better way to store references to other object without specifying coordinates? By some unique ID for example? (same applies to quests and what else uses such scheme)
    We can introduce instance ID for all objects as incremented counter (vector position will not work for map editor) (and may be reuse it in engine too as separate std::map<si32, CGObjectInstance>).
  • Scholar : save only active reward? Scholar with skill will have "skill" : "wisdom", scholar with spell will have "spell" : "magicArrow" field
    Ok [Done], may we need to unify rewards with other objects?
  • Monster : remove "randomCount" - if "count" is not defined, assume that count is random
    [Done]

Fields renames/tweaks

  • Stack instance: "creCount" -> "amount" - readability
    [Done]
  • Stack instance: "creID" -> "type" - readability
    [Done] Hate this one: "type" is a keyword in pascal (but can be used as identifier in form &type).
  • Garrison: "garrison" -> "army" - for consistency with hero, town, etc.
    [Done]
  • Hero: "sex" (string) -> "female" (bool) - to match engine & modding format
    This need 3 values: female, male, and "defined by config"
  • Hero: "id" - I don't like this word. Type? Base Hero?
    [Done] set to type, see above :)
  • Check for case inconsistencies - I see "spellID" and "spellId" in some fields. Same applies to other types of id's
  • Or just remove "id" part from all fields. "spell" : "slow". Looks fine for me.
    [WiP]

Notes

  • IIRC there is difference between "empty" garrison in town and "undefined" garrison. Game spawns 1-2 stack in town for undefined garrisons. For format that means that entry with 0 items is not identical to lack of entry.
  • Any reason to have any actual default values? What "mana" : -1 means for hero? If default value should be used then just don't write this entry in map. (or write null entry: "mana" : null).