LE FOMod Documentation?

[KunoMochi]

@TechAngel:

Nice, thank you for taking your time to make an online guide, though! I find it a lot more convenient to have an online database of things than a local document sometimes. I'll have it bookmarked for future references.

 

One thing I would probably suggest for further clarity is to highlight tag names in green, properties in red, and values/strings in blue, if it can be done. Possibly setting the code segments to XML style is possible? (I'm not quite familiar with writing Wiki pages.)

Edited June 19, 2016 by KunoMochi

[TechAngel85]

@TechAngel:

Nice, thank you for taking your time to make an online guide, though! I find it a lot more convenient to have an online database of things than a local document sometimes. I'll have it bookmarked for future references.

 

One thing I would probably suggest for further clarity is to highlight tag names in green, properties in red, and values/strings in blue, if it can be done. Possibly setting the code segments to XML style is possible? (I'm not quite familiar with writing Wiki pages.)

Syntax Highlighting is coming with the wiki update. That is one of the reasons I've been waiting on the update to finish out that guide.

[Deleted133263User]

I asked in the following topic back in 2012 what the score was with NMM documentation ..

 

https://forums.nexusmods.com/index.php?/topic/850224-suggestion-nmm-scripting-documentation-for-mod-creators/

 

.. I think its still pending coming out of beta before they do the documentation.

 

But the best reference I found was the one already linked on New Vegas Nexus - Guide to FOMOD scripting by nyrb

 

@CDCooley - One nice thing about doing a multi-installer friendly file for NMM and Wrye Bash .. MO will also be catered for, by default it will use FOMod scripting aswell ( it is supposed to be able to handle Wrye Bash wizards too, but if it comes across a file with both, the FOMod scripting is used )

 

See also my files Alt Navetsea UNP Seamless, or Kill The Orchestra in my sig' .. Both are multi installer friendly :)

[yatz]

First and foremost, the full documentation for what is available will almost always be in the header of the XML file for something like this. NMM and MO have to understand how to interpret the XML, so they have to use something as a base API (in this case, an XML schema). For example, there used to be plugins that you would install for MO and NMM, allowing for the interpretation of the XML code, which is now generally just part of the latest versions of NMM and MO. So, where is that master reference?

 

Find a newer FOMOD installer (from a well known author) and extract it. You will find a "fomod" subfolder with a ModuleConfig.xml file. Open that up in whatever text editor you want (or just view it in IE/Chrome) and look at the top line:

 

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://qconsulting.ca/fo3/ModConfig5.0.xsd">

 

If you then navigate to http://qconsulting.ca/fo3, you can open up the various XSD files and see the progression of the XML schema.

 

@cdcooley, ModConfig5.0.xsd is the current master reference you are looking for. If you don't find an option defined in this document, then you can not do it using an XML FOMOD installer - you must use a C# installer or possibly Wyre Bash. So, I would recommend you start here for your "reference". You seem to be much like me in that you code most everything directly. However, I would still recommend you use a tool like Wenderer's FOMOD Creation Tool mentioned above. As of the last conversation I had with him, I believe he has finally incorporated about 99% of what's possible into the tool. So, you can use the tool, then compare against the XML to see what is going on behind the scenes. Great way to learn, even for us "hand coders".

 

@TechAngel85, thank you for the work on the wiki that you're doing - looks nice. If I may make a suggestion, I would recommend adding a brief section on the history of the current FOMOD installer (and, yes, that is the correct term for the latest Beth games when talking about the XML installer). For example, noting FOMM (the precursor to the FOMOD installer), the old plugins for NMM and MO, the relationship of NCC to NMM and how it affected these types of installers, etc. Alt3rn1ty also has a good point surrounding Wyre Bash that you would want to mention. Please note, I am not suggesting you provide "instructions" for FOMOD C# or Wyre Bash installers - I just recommend mentioning them and how all these items relate. This way, when people come to your document from all the varied links and forum discussions, they know how all these terms relate and which terms & technologies have been superseded.

 

I am currently testing and providing feedback on a couple of new FOMOD installer tools in development. I can't say more than that, but I think they will make some nice additions to things like Wenderer's tool. But, probably 3 to 6 months out before those get released (although I lost contact with one creator - so, hopefully they get released).

 

EDIT: By the way, if you would like some initial information on FOMOD C# scripting, try here: http://miere.ru/posts/nmm-installer-scripting.

[cdcooley]

The point of my original question was that useful documentation of the FOMod format for someone actually wanting to create a configuration file is hard to find. And evidence is mounting that reasonably complete user-level documentation is non-existent. Those who have a technical understanding of how the format is used in practice seem to be either unwilling or unable to share that knowledge in a useful format other than creation of yet more helper utility programs.

 

Using some configuration builder along with a trial-and-error experimental approach to learning the format isn't acceptable in my view. The entire point of a markup language is that it can be used by both humans and machines. XML is viewed by many as a savior from the bad old days of custom formats where you often needed a program to intercede for you. But frankly too often I see XML that's still only accessible to the machine and requires intermediary programs because the inherent structure and meaning isn't fully documented except in arcane technical detail with the "big picture" design missing. There's nothing wrong with "installer tools" and "configuration builders" but the fact the people keep pointing to them in place of documentation shows that XML is not solving the problem it was meant to solve.

 

I'm perfectly capable of reading arcane technical detail and had already looked at the schema at qconsulting.ca. And while the FOMod format described in qconsulting.ca/gemm/ModConfig5.0.xsd with the included documentation annotations is better than many it certainly isn't complete as a source of documentation. At its core the schema is still simply an annotated grammar describing what is technically allowed with isolated definitions for the components and it only provides semantic information by implication in many cases. Knowing how the options are used (and even if they are used) by a particular program is not documented as part of the schema (nor would I expect it to be).

 

It's a matter of documentation for users vs. documentation for developers vs. documentation for machines. An XML schema works well for machines, can be extended with annotations to cover some of the information needed by application developers, but for actual content creators (AKA users) it's completely inadequate. As someone who has been around since before XML existed and remembers the old days of configuration files that could actually be read and written by ordinary humans I find the current state of things extremely disappointing.

[yatz]

It is what it is. Obviously we are no help to you (or at least that's how your post is coming across). I deal with modding across multiple platforms in my personal gaming "life" and nothing is the same or "easy". Additionally, even at work, I open premier support tickets with Microsoft and major vendors all the time only to have them refunded because I figured out the answer and bug before they did (because even their own in-house documentation is poor these days). It's the state of affairs. I agree it's not a great state of affairs, but unless you'd like to make some documentation yourself for all the different games and how their modded... it is what it is. Sorry.

[cdcooley]

It is what it is. Obviously we are no help to you (or at least that's how your post is coming across). I deal with modding across multiple platforms in my personal gaming "life" and nothing is the same or "easy". Additionally, even at work, I open premier support tickets with Microsoft and major vendors all the time only to have them refunded because I figured out the answer and bug before they did (because even their own in-house documentation is poor these days). It's the state of affairs. I agree it's not a great state of affairs, but unless you'd like to make some documentation yourself for all the different games and how their modded... it is what it is. Sorry.

Sorry, I think it's probably because I've been dealing with Microsoft's "documentation" lately that your description of the schema as documentation got to me. And actually many of the things in this thread were very helpful and interesting even if they didn't actually answer my question directly.

[yatz]

I do understand. I personally know 3 different engineers from Microsoft that quit because of the way things are going there. They laid off a significant portion of their QA team and are using their users to do all the QA form them for Windows 10 and the upcoming Server 2016, hidden under the guise of making the users think they are part of the process when they are just being used for cheap labor, basically (whether Microsoft is doing that intentionally or accidentally, I'll keep my comments to myself). Funny, they actually told one of my friends to not worry about whether the code fully worked - just implement the feature and they'll work it out after release. He then "gracefully retired".

 

Not that it's just Microsoft either. So, yeah, I do feel your pain to some degree at least.

 

By the way, if the "documentation" from Microsoft you're dealing with has to do with Windows 10 or Server 2016, don't trust it. Much of the documentation published as recent as May is already incorrect and superseded by the new upgrade system and v1511.2 onward, and they aren't doing much to get good info out there. I've spent hours researching to find the "correct" information and then made a link repository for my co-workers so they had valid info.

 

All we can do is just slog through the muck as best we can :)

 

Take care.