Vortex has a problem with some scripted installers, MO/MO2 does not.

[DarkDominion]

@Tannin42,

 

There were two mods in a short time that had trouble installing through Vortex ( and NMM ) due to a incompatible scripted installer.

Vortex gives off a error warning about things it expects, but can't find.

 

But the same scripted installer is working fine on MO/MO2.

 

If the scripted installer is changed as the error warning says, it will work on Vortex and NMM

You have to change/add ( see green parts ) :

 

<plugin name="Black">
<description><![CDATA[select this if you want a black Windhelm horse]]></description>
<image path="00 Images\Black.jpg"/>
<files>
<folder source="09 Brown Horse\Black" destination=""/>
</files>
<typeDescriptor>
<type name="Optional" />
</typeDescriptor>

</plugin>

 

Without the green parts this part of the scripted installer works on MO/MO2 but not on Vortex/NMM

 

It would be great if one type of scripted installer could work for all mod organizers

Can you tell me why there is such a difference ?

 

Cheers

-=DD=-

 

[Edited typo]

[Pickysaurus]

MO2 must have a tolerance for invalid XML files in FOMODs, Vortex does not. It's bad practice to allow these non-standard FOMOD XMLs to work IMO. If a standard is set it should be used properly.

[Tannin42]

Without a full example I can't test, why didn't you post a link?

 

But in general: There is no exhaustive standard for fomods but if a fomod installer works for 1 out of 3 mod managers and that one mod managers is the smallest one (in terms of user base) the problem is not the mod managers, it's the script.

As Pickysaurus said: One mod manager having tolerances that the other mod managers don't doesn't mean those managers are wrong. A valid script works correctly with all three managers.

[DarkDominion]

Thanks for responding Picky and Tannin.

 

I just wanted to know why there is a diffenrence between Vortex and MO/MO2 handeling FOMODs :)

 

Kyne's Grass https://www.nexusmods.com/skyrimspecialedition/mods/33118

Oblivion Horses SE https://www.nexusmods.com/skyrimspecialedition/mods/32335

 

Will provide some .xml files ( original xml file from Oblivion Horses SE and the one I adjusted ) when I get home.

 

Cheers

-=DD=-

[M48A5]

There has been an ongoing problem with NMM and Vortex not working with mods that were published before the advent of NMM or Vortex.

 

To expect the mod authors to update their mods to accommodate the new managers as opposed to the manager developers accommodating the published mods is a little far fetched.

 

Just my opinion.

[DarkDominion]

Two .xml files, the Original one from Oblivion Horses SE ( works on MO/MO2, not on Vortex ) and the New one I made ( tested on Vortex, it works )

 

http://www.mediafire.com/folder/oowfyu2h7mn22/Documents

[DarkDominion]

There has been an ongoing problem with NMM and Vortex not working with mods that were published before the advent of NMM or Vortex.

That is to be expected, same as Fallout 3 and Fallout: New Vegas not working on Windows 10 without some tinkering.

Can't expect Games and mods from 12 years old ( and older... Oblivion ) to work out of the box on new OS and software ( Windows 10, Vortex )

 

 

To expect the mod authors to update their mods to accommodate the new managers as opposed to the manager developers accommodating the published mods is a little far fetched.

If we are talking about the FOMOD issue I mentioned, no.

The mod authors should fix it because they use incomplete and faulty ModuleConfig.xml files.

 

The fact that MO/MO2 accepts these faulty ModuleConfig.xml files is a design flaw in their software.

 

 

[Tannin42]

The problem is that fomod isn't actually a standard. There is no document that you can follow and at the end you get a compliant software. Some functionality is completely incidental based on the platform you develop.

 

> To expect the mod authors to update their mods to accommodate the new managers as opposed to the manager developers accommodating the published mods is a little far fetched.

 

It's not the case that we expect mod authors to update their installers, if you provide us with a link to a mod that doesn't install correctly I will always look into whether we can make it compatible.

But

a) No one ever does. People complain on the comment section of individual mods and mod authors then complain on their comment section about Vortex but it's very rare anyone even contacts us to let us know of the problem to give us a chance to fix it.

b) Fixing one mod may break another. If we try to fix support for a mod that work in MO but not in NMM, that may break another mod that worked in NMM but not in MO. so it's really difficult to make these changes because we can't verify every installer that previously worked every time we make a change. It's not even clear if it's _possible_ to write a tool that supports all installers in a single tool, there may be functionality between MO and NMM that is mutually exclusive, where you always have to make a decision on which mod to support.

c) As I said: There is no document or test framework that would allow a tool developer to verify if they support all mods because fomod isn't a professionally defined standard and if we made steps to turn it into one, there would always be mods that are outside the standard no matter _how_ we define it.

 

This is not a new problem and it's not anyone's fault. It's simply because there is no single authority that clearly defined "this is the correct fomod format, everything that violates it is invalid".

If we (Nexus Mods) tried to be that authority many would hate us for it and ignore us.

[DarkDominion]

The problem is that fomod isn't actually a standard. There is no document that you can follow [...]

 

If we (Nexus Mods) tried to be that authority many would hate us for it and ignore us.[...]

@Tannin42

 

You say that FOMOD isn't a standard and there is "no document we can follow" ( both statements are actually quite debatable ), but still Vortex knows exactly when to throw an error and when not...

So there must be something inside Vortex that checks for certain lines of code that MO/MO2 doesn't or does differently.

 

Maybe it's possible to contact the people over at MO2 and check with them and maybe create a consensus about the rules of building a FOMOD.

I know the green code lines above aren't breaking anything and the mod will work, but every single information on FOMOD says these lines should be a part of the ModuleConfig.xml .

Look, Vortex does not have to be an authority, but the problem is: Vortex users ( and NMM users for that matter ) need to change the ModuleConfig.xml to make it work on Nexus' own mod manager !

 

 

To create some understanding about FOMOD:

This guide is the one that I always follow ( never had a user ( independent of any mod manager ) complain it couldn't be installed due to errors ) :

 

https://www.mediafire.com/file/xnw28cs87jo1eip/A_guide_to_FOMOD_scripts.pdf/file <--- downloadable PDF file

 

It's been around for some time...

 

More info can be found here, all the info is the same.

Wrye Bash:

https://github.com/wrye-bash/wrye-bash/wiki/%5Bdev%5D-Fomod-for-Devs

 

Daniel Nunes ( aka GandaG ) :

https://fomod-docs.readthedocs.io/en/latest/index.html

https://fomod-designer.readthedocs.io/en/stable/

 

They even have a "bible" on FOMOD ( which is the same as the one I use above )

https://fomod-designer.readthedocs.io/en/stable/advanced.html#fomod-bible

 

 

Conclusion to my ramble is :

There is a standard on creating a FOMOD, there is plenty of information on FOMOD and Vortex isn't at fault, but we need a consensus about the use of FOMOD among the dev of the mod managers ( with all due respect ).

 

Tanks for reading :smile: and stay save all !

Cheers

-=DD=-

[Tannin42]

both statements are actually quite debatable

No they aren't, they are just apparently quite easy to misunderstand.

There are requirements for something to be a standard and fomod doesn't fulfill them, that's a fact, not an opinion.

Yes, there are documents but they don't fully define a standard.

 

but still Vortex knows exactly when to throw an error and when not...

No, Vortex knows _some_ things that clearly violate the documentation (which includes the Oblivion Horses mod, see below) but that doesn't mean it knows _all_ the things that violate the documentation or that there aren't things open to interpretation.

Your logic is just flawed. "From A follows B" doesn't mean "From B follows A". Just because Vortex means a thing is wrong doesn't mean it will let you know about everything that is wrong.

 

So there must be something inside Vortex that checks for certain lines of code that MO/MO2 doesn't or does differently.

 

Yes. In this case it's not even in Vortex itself though, see below.

 

Maybe it's possible to contact the people over at MO2 and check with them and maybe create a consensus about the rules of building a FOMOD.

You still don't understand: It's probably impossible to create a "consensus of rules" that wouldn't break some existing mods.

The only thing that would be viable would be to define a fomod version 2.0 that is a proper, fully defined, standard and then treat all existing fomods as "legacy" with the current hit&miss reliability.

But that would require an amount of work that right now I don't have time for.

 

I know the green code lines above aren't breaking anything and the mod will work, but every single information on FOMOD says these lines should be a part of the ModuleConfig.xml .

Huh? The green lines above seem to be required. They don't break anything, they fix it I thought?

 

Look, Vortex does not have to be an authority, but the problem is: Vortex users ( and NMM users for that matter ) need to change the ModuleConfig.xml to make it work on Nexus' own mod manager !

 

But the reality here is: Vortex is right. The installer included in Oblivion Horses is not a valid fomod. MO is in the wrong here for being too lax.

In this specific case (this is not intended to be quoted as a general rule!) there is actually no way around the mod author fixing the script. If MO devs improve their fomod installer this script will stop working.

 

To create some understanding about FOMOD:

This guide is the one that I always follow ( never had a user ( independent of any mod manager ) complain it couldn't be installed due to errors ) :

Yes yes, there are guides, but look here: "The final part of the <plugin> is the <typeDescriptor>. ..."

It doesn't specifically state whether typeDescriptor is required or whether it can be left out. The same is true for the wiki in Wrye Bash, didn't check the others.

This is incomplete information, open to interpretation and invites making mistakes.

A standard has to be precise and unambiguous.

 

A guide aimed at mod authors, who are *users* of the format is not the same thing as a "standard" that lets you implement compliant parsers. A developer writing a mod manager needs a different type of documentation than a user - in the same way that you need different information to learn to drive a car than you need to build a car.

 

 

 

HOWEVER there is one document that is important here and that is mentioned at the very top of the guide you posted: http://qconsulting.ca/fo3/ModConfig5.0.xsd

(If you include the line at the beginning of your script, and edit it in Microsoft Visual Studio, you are given hints about what needs to/can be included at each point")

 

This file is an xml schema which specifically and unambiguously defines which fields are required in a fomod xml file and if you could read it it would tell you that "typeDescriptor" is actually a required field within plugin.

If you do what the guide suggests and open the xml file in visual studio it will generate 85 error messages where that xml file violates the schema that it claims to adhere to.

MO doesn't verify the schema and apparently it therefore also doesn't verify the typeDescriptor. That proves - in this single case - that it's MO that's wrong here. NMM and Vortex are correct to reject the file.

in fact the error message you get doesn't even come from Vortex, it comes from the generic xml library which already knows that the file is invalid before Vortex even gets to take a look.

Or to rephrase: That file isn't just an invalid fomod xml installer, it's not technically a valid xml file at all, you can send it to any xml validator and it will be reported as wrong, even if the validator doesn't know anything about mods.

 

 

 

But that's only this one case, a schema doesn't make a standard. This case could have been way more interesting.

For example: What happens if multiple plugins contain files that get copied to the same location, which one overwrites the other? The schema doesn't say. In the order they appear? or alphabetically? What if plugins from different groups have conflicting files? What about the "priority flag"? It's said to be "relative priority", relative to what? plugins in the same group or relative to all other plugins?

And how do "conditionalFileInstalls" play into this vs. plugins with priorities? ...

 

I have an entire test suite dedicated just to verifying that Vortex overwrites files in the same way NMM does but none of this is documented (outsite my test suite). I can't state that NMM and Vortex are _correct_ I can just say that they do the same.

The test suite is open source so MO and Wrye Bash can go and use the same test suite to ensure they act the same as well but that doesn't make any of it a "standard" just a "convention".