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

[DarkDominion]

 

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

 

All the documentation and information and FOMOD creator mods on the Nexus and GitHub, all point to that one single PDF I showed you.

Both that PDF and the Bible agree on the same thing: when is a line of code optional, and when is it required.

 

 

 

 

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

 

That's absolutely understandable and not something I ask for.

I humbly suggest to contact the MO2 devs and kindly ask them to use the same generic .xml library as Vortex does.

Because I think that will stop the use of invalid .xml files.

 

 

If MO devs improve their fomod installer this script will stop working.

 

Exactly, someone with knowledge of Vortex and MO might get them to understand the issue.

 

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? ...

 

It's scripted so one would think from top to bottom ? Or to be save: use the priority flag.

Higher priority numbers are unpacked after lower priority numbers...

( I haven't seen any mention of this It's said to be "relative priority" ? )

Give the "conditionalFileInstalls" a priority too ?

 

 

But non of all this has to be Vortex's concern, that's for the mod author to worry about.

If they can't find a solution they will search on Google, or even use the FOMOD creator mod on the Fallout 4 page.

As long as all terms are met with the generic .xml library the FOMOD will work, and the mod author can fix it.

Now they don't fix it...

 

I would personally ask the MO2 devs to consider this, but I think you pack more punch than I :D

 

This will be the last reply from me, I've bothered you enough with this.

I look forward to you answer on my last post and I appreciate the thorough answers you have given me so far.

Cheers

-=DD=-

 

[EDIT : Typo]

[Tannin42]

All the documentation and information and FOMOD creator mods on the Nexus and GitHub, all point to that one single PDF I showed you.

Except that Bible also says:

FOMOD Bible

Please take note this isn’t a fully comprehensive document (at least so far).

But as I said: Even between the Bible and the schema there are things left undefined that are open to interpretation by the tool developer.

 

Also: That Bible was written 2016, well after NMM and MO were developed. It's a (very commendable) effort to reverse engineer what the existing mod managers do, it's

not a standard that those managers could have been based on.

 

Both that PDF and the Bible agree on the same thing: when is a line of code optional, and when is it required.

I pointed out an example of where the PDF doesn't specify it. And yes, the Bible says that the typeDescriptor is required, yet you blamed Vortex and NMM for requiring it...

 

t's absolutely understandable and not something I ask for.

I humbly suggest to contact the MO2 devs and kindly ask them to use the same generic .xml library as Vortex does.

Because I think that will stop the use of invalid .xml files.

They can't use the _same_ xml library because the library FOMM, NMM and Vortex use is C#, MO is written in C++, Wrye Bash for example is written Python.

You can use C or C++ libraries in C# or python but not the other way around. (That's a bit simplified but effectively that's the reality)

They could still use a library that verifies schemata though, not sure why you need me to be the messenger for that though.

 

Exactly, someone with knowledge of Vortex and MO might get them to understand the issue.

They will understand it, they are quite competent.

 

It's scripted so one would think from top to bottom ?

Higher priority numbers are unpacked after lower priority numbers...

You might think that but no, NMM (which Vortex tries to mimick) sorts them alphabetically (and folders after files, so if a plugin installs the folder "foo_aaa -> foo" and foo_aaa contains a file "bar.esp"

but then also installs the file foo_zzz\bar.esp -> foo\bar.esp then the one from foo_aaa is used).

Find the documentation that explains that (outside the Vortex repository ;) )

 

Or to be save: use the priority flag.

...

Give the "conditionalFileInstalls" a priority too ?

You're kind of missing the point here. I'm trying to explain to you the difficulties a tool developer has to deal with. We, as the Vortex devs, can not "use the priority flag", we have to write

code that deals with the situation that a mod author didn't use a priority flag, because that is optional.

 

( I haven't seen any mention of this It's said to be "relative priority" ? )

It's in the xml schema, which is used by fomm to verify files so I'm treating it as (the only) official documentation.

 

But non of all this has to be Vortex's concern, that's for the mod author to worry about.

 

This very thread proofs that to be wrong.

You yourself blamed Vortex and NMM for not supporting an invalid installer. We get attacked for this so it is very much Vortex's concern.

 

If they can't find a solution they will search on Google, or even use the FOMOD creator mod on the Fallout 4 page.

No they don't! Have you already forgotten how this thread started? "They" test the installer with a single mod manager and if it works as expected there they assume it's correct and then "they" and other "theys" complain about other mod managers where it doesn't work. Like, you know, the OP of this thread... :P

 

As long as all terms are met with the generic .xml library the FOMOD will work, and the mod author can fix it.

Now they don't fix it...

Again: There are things that are open to interpretation in fomod. Different Mod Managers treat them differently and there is no standard that would proof one or the other is right. Unless everyone developing a mod manager or fomod creator would agree to defer to one reference implementation and agree to change their own tool to follow that reference, there will always be installers that work in one tool but not the other. And even then, what would happen is that all the mods that currently "only install with MO" or "only install with NMM" would stop working and so people would be giving brilliant advice like "just install the old version where it still worked".

And no, using "the generic .xml library" or applying the schema or reading the "Bible" is not enough because again, none of them, not even combined, fully define a standard.

 

I would personally ask the MO2 devs to consider this, but I think you pack more punch than I :D

It shouldn't matter _who_ contacts them, I'm pretty sure having worked on MO for a while they understand the problem and how hopeless it is.

Just - trust me on this: fomod is an unredeemable mess (we haven't even talked about c# installers...).

Anew fomod version (or just a completely new format) could be defined that fixes all that, one that can only be implemented in one way. But that wouldn't fix the existing installers and it would require cooperation from so many parties, some of which I haven't experienced as being particularly cooperative I wouldn't hold my breath.

[DarkDominion]

Lol, thanks!

btw, I never attacked or blamed anyone, I just asked why there was a difference, because I didn’t know what I know now. Every time I came up with something you came up with information I didn’t know before, which is good eventually, I learned a lot these couple of days, thanks !

 

also : if I get MO2 to use a library to verify schemata, then mod authors will use Google or use a FOMOD creator is what I meant, because non of the mod managers will accept the FOMOD so they’ll have to find a solution.

 

again, much thanks for all the info, I’ll try to get in touch with the MO devs.

 

Cheers

-=DD=-