Larian Banner
Previous Thread
Next Thread
Print Thread
Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
If you generate Stat Objects outside of the editor, the editor will not recognize the name fields of stat entries, but will display everything else. You end up with rows of skills that have no skill names, and will not be recognized by scripts.

Example
Code
    <stat_object index="33" is_substat="true">
      <fields>
        <field name="Name" type="NameStatObjectFieldDefinition" value="GENERATED_ASC_Ricochet" />
        <field name="Using" type="BaseClassStatObjectFieldDefinition" value="Ricochet" />
        <field name="Damage Multiplier" type="IntegerStatObjectFieldDefinition" value="100" />
      </fields>
    </stat_object>


It correctly reads when there are duplicates, so it's still validating these fields, it's just not pulling them in correctly. It will also correctly delete entries if you delete them in the skill editor. Literally everything works except recognizing it's name.

Is this intended behavior? An external generation tool as about the only option I have left to expand item progression beyond what's currently possible, as I don't want to edit/create all these permutations by hand.

Last edited by Sinistralis; 02/11/17 02:21 AM.
Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
I think it has something to do with the Skill Type that it prefixes skills with. Attempting to add new abilities after the bugged one causes them to be prefixed with '_' instead of 'Projectile_' for example in the generated .txt files.

Last edited by Sinistralis; 02/11/17 02:38 AM.
Joined: Jan 2010
Location: USA
F
enthusiast
Offline
enthusiast
F
Joined: Jan 2010
Location: USA
I... don't have this issue. I do see your example is a substat. Are you outputting the parent stat object?

Why aren't you filtering out duplicates in your program? I'm just doing something simple like:

Code
    exists = []
    for obj in new_stat_objects:
        value = obj.find('fields/field[@name="Name"]').get('value')

        if value not in exists:
            exists.append(value)
        else:
            # find duplicate fields, then remove the stat_object parent with the least number of fields
            # the assumption is that more fields = the most up-to-date stat_object, so we keep that one
            dupes = new_stat_objects.findall('stat_object/fields/field[@name="Name"][@value={}]'.format('"' + value + '"'))
            if len(dupes) > 1:
                field_counts = []
                for dupe in dupes:
                    parent_obj = dupe.getparent()
                    field_counts.append(len(parent_obj))
                i, v = min(enumerate(field_counts), key=operator.itemgetter(1))
                new_stat_objects.remove(dupes[i].getparent().getparent())


Also, are you reindexing the stat objects? (My script processes multiple .stat files and merges same-name .stat files together, so I have to reindex.)

Code
def reindex_output(file_path):
    try:
        e = etree.parse(os.path.abspath(file_path), XML_PARSER)
    except etree.XMLSyntaxError:
        raise etree.XMLSyntaxError

    root = e.getroot()

    i = 0
    for stat_object in root.iterfind('stat_objects/stat_object'):
        stat_object.set('index', str(i))
        i += 1

    with open(os.path.abspath(file_path), 'w', encoding='utf-8') as f:
        f.write(etree.tostring(root, encoding='unicode', pretty_print=True))

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
I'm not worried about duplicates right now, I was just testing duplication out to try to narrow down the issue.

I don't need to re-index, I am keying mine in a very explicit manner, and all of those keyed values are removed before building the xml and are indexed accordingly.

So I must has misunderstood the meaning of is_substat. I was under the impression this means it had a Using value and I thought I tested this, but it doesn't seem to be the case. Setting it to false fixed the issue.

What is the point of this value?


Last edited by Sinistralis; 02/11/17 03:46 AM.
Joined: Jan 2010
Location: USA
F
enthusiast
Offline
enthusiast
F
Joined: Jan 2010
Location: USA
is_substat isn't used in Stats.*, but it is used in TreasureTable.*, ItemProgression.*, etc. For example, ST_StaffNormal in TreasureTable has three substats.

Also, in case you had not figured this out, I forgot to mention you have to edit the .stats file in the Stats Editor, save, revert your change, and save again in order to generate the corresponding .txt file. "Save All," unfortunately, does not rebuild all .txt files. It should, but it doesn't. frown

By the way, I'm working on a CLI enhancement for the ConverterApp that can be plugged into scripts, and I think Norbyte is working on a STATS-to-TXT converter. Together, these will allow us to generate data mods by script without requiring the editor for anything except publishing to Steam.

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Yea, I caught onto the TXT generation issues. I'll likely end up generating those too since I already have all the data needed to do so. Although if Norbyte is working on that, I'll put that at the end of my priority list.

If you are making a CLI for the ConverterApp I am VERY interested in that. I was just about to figure out how to basically recreate his LSFWriter in Node as I don't want importing gamescripts to be a step people have to do with the file I generate. Having a CLI for that would make needing to do that unnessecary so I can focus more on creating the permutation support.

Last edited by Sinistralis; 02/11/17 05:29 AM.

Moderated by  Larian_KVN 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5