z33kz33k / gladiunits Goto Github PK

Traits from 'Traits' .xml files shall be parsed.

Unit/Weapons/Actions etc names displayed in-game are different than the ones used in World/Units/. The actual mapping of ones to the others can be parsed from Core/Languages/English/Units.xml

This resource holds also in-game descriptions and flavors

Weapons from "Weapons" .xml files shall be parsed

Actions are a bit involved part of "Units" .xml files

Upgrades shall be parsed from 'Upgrades' dir's .xml files

• make dereferencing gradual (first upgrades, then traits, then weapons and units at the end)
• use dereferenced data from earlier step in a later step (i.e. use dereferenced upgrades as context injected to initializer when parsing traits and so on)
• use such constructed data to infer properties like tier, prerequisites or has_melee_weapon on units

Remember that any Data object is also an Origin one, so there's no use using Union[Data, Origin] anywhere in type hints.

This makes #10 trivial as upgrade required for unit production is specified with the unit in question in Building's produceUnit action.

It will also enable adding a Building object to Unit object as its attribute, albeit this will probably entail a new Unit class (a BuiltWeapon?) in the same vein as there are CountedWeapons in Units with some added attributes and regular Weapons anywhere else.

In case of nomenclature it would probably be best to:

• Weapon ==> BaseWeapon, CountedWeapon ==> Weapon
• Unit ==> BaseUnit, the new unit with data from Buildings named as Unit

Units from "Units" .xml files need to be parsed

Based on a corresponding Upgrade.

There's a little bug of using asdict() leading to some problems.

Update

This (as usual) proved to be a completely non-trivial task that involved parsing another type of data (Buildings, #11 ) and looking for unit-producing actions in other units to grok the tier of the produced one.

This one is tricky, because:

• it demands another parsing abstraction layer beyond simple category parsers like UpgradeParser etc.
• it demands that some of the parsing must involve mutating from referenced state into dereferenced state, therefore implying it must be a least two-step operation
• it therefore demands that some of the frozen data structures (i.e. Parameter) be constructed and then re-constructed
• it therefore demands a mutable version of Effect and constructing an immutable effect only after dereferencing all parameters it contains - this is bullshit, for one param's refs are not the only ones, for second you cannot arbitrarily make one element of frozen datastructure mutable and call it a day (either all of them are mutable or immutable)
• it demands that the parsing steps be conducted independently of each other and the second step be repeated iteratively as there's no guarantee there are no circular references in the input
• it demands that parsing logic knows how to traverse in the second step the data it parsed in the first step to dereference it

Sub-tasks:

• make each frozen data object aware if it's dereferenced or not
• devise a way to mutate a frozen dataclass
• devise a macro-parser that would conduct parsing and dereferencing
• the dereferencing would involve using some static context to replace references with already parsed objects without parsing them multiple times (and to know when the whole process is finished)

To summarize:

• all data structures that apply (pretty much all of them) should assume two states: referenced/dereferenced
• parsing and dereferencing should be totally seperate processes
• parsing would just construct data in the first state and dereferencing would take it and reconstruct replacing references with actual objects

Devising a way to mutate a frozen dataclass was harder than expected. I (almost) caved in. But, there is a way and I was almost at it. One can easily manipulate each Python object by accessing its __dict__ property, frozen dataclass or not. I reached this point but stumbled trying to mutate the whole Parsed object top-down, when in reality I can just mutate Parameter objects' __dict___'s at the bottom and reference attributes at the top.

Update

It's not possible to dereference every category path contained in XMLs, because of circular refs contained therein.
The dereferencing loop stops improving and becomes infinite at 900+ still not resolved objects when trying to dereference everything.
Giving up on reference property, cuts this number to 49.

Update

Skipped circular refs, thus solving the problem.

• Units
• Weapons

Rok's link: https://steamcommunity.com/app/489630/discussions/0/3825284575377782229/#c3827536762637353185

• turn the info dumps saved in TraitParser's class space into functions that return them
• turn _ReferenceParser into function that returns a reference Origin object