Jump to content

Search the Community

Showing results for tags 'xml'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Welcome
    • Announcements / News
    • Introductions & Off-Topic Discussion
    • Help & Feedback
  • 0 A.D.
    • General Discussion
    • Gameplay Discussion
    • Game Development & Technical Discussion
    • Art Development
    • Game Modification
    • Project Governance
    • Testing

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







First Name

Last Name

Skype ID

Found 4 results

  1. \gui\session\ sprites.xml session.xml \gui\session\minimap\ MiniMap.xml \art\textures\ui\session\
  2. Can we make it possible to dictate where techs can go in the UI? It would be very helpful (and logical) to be able to place techs beneath the units that they primarily affect. For instance, Rank Promotion techs and "Tradition" techs ("Archery Tradition", "Hoplite Tradition" etc.) can go directly beneath the unit. Example: It could go in the building's template in the productionqueue/technologies component, perhaps productionque/technologies/row. <ProductionQueue> <BatchTimeModifier>0.8</BatchTimeModifier> <Entities datatype="tokens"> units/{civ}/infantry_javelineer_b units/{civ}/infantry_slinger_b units/{civ}/infantry_archer_b units/{civ}/infantry_crossbowman_b </Entities> <Technologies> <Row2 datatype="tokens"> upgrade_rank_advanced_infantry_jav upgrade_rank_elite_infantry_jav upgrade_rank_advanced_infantry_slinger upgrade_rank_elite_infantry_slinger upgrade_rank_advanced_infantry_archer upgrade_rank_elite_infantry_archer </Row2> <Row3 datatype="tokens"> <br/> <br/> special_archery_tradition </Row3> <Row4 datatype="tokens"> training_levy_infantry_ranged </Row4> </Technologies> </ProductionQueue>
  3. I know this may be controversial, but I think the current SpecificName scheme adds a minor amount of confusion, or at least a better scheme may add some more clarity where currently there is little. So, for example: <GenericName>Gallic Champion</GenericName> <SpecificName>Soliduros</SpecificName> This is actually a Swordsman, along with whatever that means to the game, but you don't know that from the name of the unit. What I would suggest is something like this: <GenericName>Champion Swordsman</GenericName> <SpecificName>Gallic Champion</SpecificName> <EthnicName>Soliduros</EthnicName> In the UI, it would show: Gallic Champion (Champion Swordsman) Likewise: Spartiate Hoplite (Champion Spearman) This now gives you a much better idea what "kind" of unit it is. The <EthnicName> "Spartiátēs" and "Soldurios" would show up elsewhere, likely in the Information viewer. Extended, we could give the player the option of what they want to see in the UI and tooltips.
  4. Currently, unit template files have a translatable field called Tooltip. This field, as far as I’ve seen, may contain the following information: • Unit classes (recently prefixed by ‘Classes:’). • Units that this unit counters (prefixed by ‘Counters:’). • Units that counter this unit (prefixed by ‘Countered by:’). • Unit description. In the XML, these are differenciated by line breaks. What would you think about providing separated fields for each one of these? • DisplayClasses (as opposed to the class names used in the game logic) • Counters • CounteredBy • Description Pros would be: • Easier to keep consistency between tooltips. • Ability to use a different font or text style on different elements. • Ability to reorder the elements in the interface easily, without changing all XML files, nor affecting translations. • Ability to show a different combination of these bits of information in different contexts. • Easier for translator, as they would only need to translate the "Prefix: <data>" strings once, and the rest of the strings will have a decreased size. And I honestly cannot think of cons here. Also, if you agree, should I let you do this yourselves in master, or should I do this myself in my i18n branch? Or should I maybe write a patch against master only for this?
  • Create New...