Validate Error when no file is given in plugin section

[erri120]

`

Uses vanilla ragdolls

          <image path="fomod\1.jpg"/>
          <typeDescriptor>
            <type name="Optional"/>
          </typeDescriptor>
        </plugin>`

This is invalid because after the description, it expects either a sequence with 'files'+'conditionFlags' or a sequence with 'conditionFlags'+ 'files'. I don't even know if you're still active but if you see this let me know and maybe post an idea. My work around: creating a new tree and inserting the files section with no content.

[GandaG]

College is keeping me quite busy for the moment, in a few more weeks I'll be back to working on this! meanwhile, I was quite sure I had that issue addressed (it was one of my headaches when initially writing the designer), do you mind checking that the schema in the pyfomod folder is correct?

On Tue, 3 Jul 2018, 17:47 Florian, notifications@github.com wrote:

Uses vanilla ragdolls

This is invalid because after the description, it expects either a sequence with 'files'+'conditionFlags' or a sequence with 'conditionFlags'+ 'files'. I don't even know if you're still active but if you see this let me know and maybe post an idea. My work around: creating a new tree and inserting the files section with no content.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GandaG/pyfomod/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2QzwMy8ibwAKyh3qxggDMCp52dzRk_ks5uC6AdgaJpZM4VBS1i .

[erri120]

<xs:complexType name="plugin">
        <xs:sequence>
            <xs:element name="description" type="xs:string">
                <xs:annotation>
                    <xs:documentation>
                        A description of the plugin.
                    </xs:documentation>
                </xs:annotation>
            </xs:element>
            <xs:element name="image" type="image" minOccurs="0">
                <xs:annotation>
                    <xs:documentation>
                        The image associated with the plugin.
                    </xs:documentation>
                </xs:annotation>
            </xs:element>
            <xs:choice>
                <xs:sequence>
                    <xs:element name="files" type="fileList">
                        <xs:annotation>
                            <xs:documentation>
                                The list of files and folders that need
                                to be installed if the plugin is selected.
                            </xs:documentation>
                        </xs:annotation>
                    </xs:element>
                    <xs:element name="conditionFlags" type="conditionFlagList" minOccurs="0">
                        <xs:annotation>
                            <xs:documentation>
                                The list of flags to set if the plugin is selected.
                            </xs:documentation>
                        </xs:annotation>
                    </xs:element>
                </xs:sequence>
                <xs:sequence>
                    <xs:element name="conditionFlags" type="conditionFlagList">
                        <xs:annotation>
                            <xs:documentation>
                                The list of flags to set if the plugin is selected.
                            </xs:documentation>
                        </xs:annotation>
                    </xs:element>
                    <xs:element name="files" type="fileList" minOccurs="0">
                        <xs:annotation>
                            <xs:documentation>
                                The list of files and folders that need
                                to be installed if the plugin is selected.
                            </xs:documentation>
                        </xs:annotation>
                    </xs:element>
                </xs:sequence>
            </xs:choice>
            <xs:element name="typeDescriptor" type="pluginTypeDescriptor">
                <xs:annotation>
                    <xs:documentation>
                        Describes the type of the plugin.
                    </xs:documentation>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
        <xs:attribute name="name" type="xs:string" use="required">
            <xs:annotation>
                <xs:documentation>
                    The name of the plugin.
                </xs:documentation>
            </xs:annotation>
        </xs:attribute>
    </xs:complexType>

This is the section for the plugin. I tried to implement the xs:all element because it allows the elements "files" and "conditionFlags" to be in any order and not even necessary, but the parent of xs:all can't be xs:choice. Tried to put a xs:group befor xs;all but got errors from lxml.etree. Do you think that xs:all could help?

[GandaG]

The schema appears to be correct, so it's an error in the code.

And now that I'm rereading the issue, it may be that I've misunderstood what you were saying. Did you create that initial tree with pyfomod? Or are you trying to validate an external tree?

On Tue, 3 Jul 2018, 18:46 Florian, notifications@github.com wrote:

A description of the plugin. The image associated with the plugin. The list of files and folders that need to be installed if the plugin is selected. The list of flags to set if the plugin is selected. The list of flags to set if the plugin is selected. The list of files and folders that need to be installed if the plugin is selected. Describes the type of the plugin. The name of the plugin. This is the section for the plugin. I tried to implement the xs:all element because it allows the elements "files" and "conditionFlags" to be in any order and not even necessary, but the parent of xs:all can't be xs:choice. Tried to put a xs:group befor xs;all but got errors from lxml.etree. Do you think that xs:all could help? — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

[erri120]

The tree was created by pyfomod in it's directory in site-packages of Python 3.5.

[GandaG]

I was talking about this:

Uses vanilla ragdolls

If this was made with pyfomod then there is an issue because a files element should have been created automatically. If this was something written manually then I don't see the issue, it is invalid.

On Tue, 3 Jul 2018, 18:54 Florian, notifications@github.com wrote:

The tree was created by pyfomod in it's directory in site-packages of Python 3.5.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GandaG/pyfomod/issues/3#issuecomment-402241929, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2Qz_9fkC4YhZZpT_seQjBxN-e3293Kks5uC6_SgaJpZM4VBS1i .

[erri120]

That was an excerpt of a ModuleConfig.xml I tried to read using a program I currently develop. The file is from the mod 'Realistic Ragdolls and Force' (Skyrim SE mod). NMM (Nexus Mod Manager) read it correctly and it's one of the most downloaded mod for SSE. I now realize how bad I started this comment. To clarify: I want to validate info.xml and ModuleConfig.xml of any mod and the your pyfomod.validate tells me that it shouldn't have found typeDescriptor but rather some files.

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://qconsulting.ca/fo3/ModConfig5.0.xsd">
  <moduleName>Realistic Ragdolls and Force</moduleName>
  <installSteps order="Explicit">
    <installStep name="Custom">
      <optionalFileGroups order="Explicit">
        <group name="Force" type="SelectExactlyOne">
          <plugins order="Explicit">
            <plugin name="Realistic">
              <description>
               Ragdolls will crumble to the ground when killed. Represents realistic body weight and force of attacks.
              </description>
              <image path="fomod\1.jpg"/>
              <files>
                <file source="plugins\dD - Realistic Ragdoll Force - Realistic.esp" destination="dD - Realistic Ragdoll Force - Realistic.esp"/>
              </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
            <plugin name="Reduced">
              <description>
               Ragdolls will have increased reactions when killed. More feedback from final hits.
              </description>
              <image path="fomod\1.jpg"/>
              <files>
                <file source="plugins\dD - Realistic Ragdoll Force - Reduced.esp" destination="dD - Realistic Ragdoll Force - Reduced.esp"/>
              </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
            <plugin name="Medium">
              <description>
               Ragdolls will react more greatly to melee and range kills. Closer to vanilla, but ranged weapons and magic will not have the force of a cannon.
              </description>
              <image path="fomod\1.jpg"/>
              <files>
                <file source="plugins\dD - Realistic Ragdoll Force - Medium.esp" destination="dD - Realistic Ragdoll Force - Medium.esp"/>
              </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
            <plugin name="High">
              <description>
               Very high force for melee and range attacks. Action movies.
              </description>
              <image path="fomod\1.jpg"/>
              <files>
                <file source="plugins\dD - Realistic Ragdoll Force - High.esp" destination="dD - Realistic Ragdoll Force - High.esp"/>
              </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
        </plugins>
      </group>
        <group name="Ragdolls" type="SelectExactlyOne">
          <plugins order="Explicit">
            <plugin name="All">
              <description>
                Replaces all ragdolls
              </description>
              <image path="fomod\1.jpg"/>
                            <files>
                                <folder source="ragdolls\Others" destination="meshes"/>
                                <folder source="ragdolls\Players" destination="meshes"/>
                            </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
            <plugin name="Cretures Only">
              <description>
                Replace creatures and animals only. Use this to avoid conflict with mods that also replace the playable race skeletons. If you using any compatibility skeleton patch use this option.
              </description>
              <image path="fomod\1.jpg"/>
                            <files>
                                <folder source="ragdolls\Others" destination="meshes"/>
                            </files>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
            <plugin name="None">
              <description>
                Uses vanilla ragdolls
              </description>
              <image path="fomod\1.jpg"/>
              <typeDescriptor>
                <type name="Optional"/>
              </typeDescriptor>
            </plugin>
        </plugins>
        </group>
     </optionalFileGroups>
    </installStep>
  </installSteps>
</config>

(in case you want to see how the whole ModuleConfig.xml)

[GandaG]

Ahhh that explains it. The folks of NMM have the unfortunate habit of eschewing parts of the schema that may be trickier to implement. And while I mostly agree it would help if they let people know about it, like say, with a repository or versioning or anything really.

Ah but I'm ranting. There is no real solution here tbh, I knew that eventually this would become a problem because there is no unified schema for all mod managers and maintaining one for each is an obvious problem. All my tools follow the original (even the 5.1 version I wrote is merely a "redesign" rather that something new) which is the most restrictive but most compatible.

I'll only be free to work on this in a few weeks, but if you'd like, you could check NMM, MO and maybe Vortex if it has been released already for what schema they use so later a unified schema could be made (if at all possible).

On Tue, 3 Jul 2018, 19:20 Florian, notifications@github.com wrote:

That was an excerpt of a ModuleConfig.xml I tried to read using a program I currently develop. The file is from the mod 'Realistic Ragdolls and Force' (Skyrim SE mod). NMM (Nexus Mod Manager) read it correctly and it's one of the most downloaded mod for SSE. I now realize how bad I started this comment. To clarify: I want to validate info.xml and ModuleConfig.xml of any mod and the your pyfomod.validate tells me that it shouldn't have found typeDescriptor but rather some files.

Realistic Ragdolls and Force Ragdolls will crumble to the ground when killed. Represents realistic body weight and force of attacks. Ragdolls will have increased reactions when killed. More feedback from final hits. Ragdolls will react more greatly to melee and range kills. Closer to vanilla, but ranged weapons and magic will not have the force of a cannon. Very high force for melee and range attacks. Action movies. Replaces all ragdolls Replace creatures and animals only. Use this to avoid conflict with mods that also replace the playable race skeletons. If you using any compatibility skeleton patch use this option. Uses vanilla ragdolls

(in case you want to see how the whole ModuleConfig.xml)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GandaG/pyfomod/issues/3#issuecomment-402249396, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2Qzyc1GTQDu4Jc4j8wZfhZ2IHWL8SGks5uC7YFgaJpZM4VBS1i .

[GandaG]

As of 7ca2955 pyfomod should ignore this "error" and still be able to parse the installer, although when the user validates it will still complain this is not a good practice.