Project talk:Data Dictionary

From Step Mods | Change The Game
Revision as of 21:06, December 19, 2014 by Z929669 (talk | contribs) (→‎Mod Flags)

Template:TOC right Following is a work-in-progress list of current and proposed attributes that can be associated with mod pages. Feel free to add anything you might think is useful. Let's try to keep it organized, so group similar or related properties as best you can. Note that Baseline has been removed from this list on purpose, that should be a Pack attribute based on the Pack's guidelines. ~FarloUser Farlo Sig.pngTalk 19:56, July 15, 2013 (MDT)

Discussion Forum PM admin if you can't access and want to help!)

Mod Attributes[edit source]

Color key:

  • Not changed - Represents at most minor changes being made to the property.
  • Addition - Proposed additional/replacement property.
  • Removal - Property proposed to be removed/replaced.
Mod Info[edit source]
  • Author (string) - The author(s) of the mod.
  • FullName (string) - Full name of the mod according to source.
  • Description (string) - Brief mod description. (Confirmed)
  • SourceName (string) - Supported mod source. Specifies a URL created from "Steam" or "Nexus" mod ID. "Other" prompts for user input of a full URL string.
    • SourceID (string) - "Steam" or "Nexus" mod SourceID if either is specified in SourceName.
    • SourceURL (URL) - Full URL if SourceName is specified as "Other".
  • Section (string) - STEP installation "blocks" specified using "allows value" declarations. (Confirmed)
  • Category (category) - Broad category/"class" of the mod, similar (if not identical) to the Nexus categories. (Confirmed)
  • Baseline (string) - Specifies the recommended mod option when more than one are available. (Confirmed)
  • ForumTID (string) - Specifies a URL created using the thread ID of the mod on the STEP forums.
  • External URL (object) - Multiple-instance template containing:
    • ExternalURL (URL) - URL string specifying a page associated with the mod; other hosts, Facebook, etc. (URL)
    • ExternalLabel (string) - A human-meaningful label associated with ExternalURL (string)
  • HasResource (string; see next property) - Indicates how a mod's resources files are packaged. (BSA, Loose, None).
  • ResourceType (string; previously, 'HasResource', which is a misnomer indicating Boolean) - Indicates how a mod's resources files are packaged. (BSA, Loose, None).
  • DLCRequired (string) - Indicates which DLC's are required by the mod.
  • DLCSupported (string) - Indicates which DLC's are supported by the mod via an addon.
Mod Flags[edit source]
  • DocDescription (Boolean) - Indicates that the mod includes a description of what the mod does. (not useful ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • DocInstall (Boolean) - Indicates that the mod includes installation instructions. (not useful ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • DocUninstall (Boolean) - Indicates that the mod includes un-installation instructions. (not useful ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • HasScript (Boolean) - Indicates that the mod uses scripts.
  • CompatibleBAIN (Boolean) - Indicates that the mod package has BAIN support. (bad property name, move to following property ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • HasBAIN (Boolean) - Indicates that the mod package has BAIN support.
  • CompatibleFOMOD (Boolean) - Indicates that the mod package has FOMOD support. (bad property name, move to following property ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • HasFOMOD (Boolean) - Indicates that the mod package has FOMOD support.
  • IsOptimized (Boolean) - Applies to texture mods only. Indicates that the mod textures are correctly formatted (but not that they are necessarily size/constraint optimized).
  • HasSKSE (Boolean) - Indicates that the mod depends on SKSE.
  • HasMCM (Boolean) - Indicates that the mod has MCM functionality and depends on SkyUI.
  • HasSkyProc (Boolean) - Indicates that the mod contains a SkyProc patcher.
  • LoreFriendly (Boolean) - Indicates that the mod is considered lore friendly. (Confirmed)
  • IsClean (Boolean) - Indicates that the mod's EPS/M files are free of ITM/UDR errors. (Confirmed)
  • HasPlugin (Boolean) - Indicates that the mod has a plugin file (ESP, ESM, None). (Confirmed)
    • CleanPlugin (Boolean) - Indicates that the mod's plugin is clean. Dependent on HasPlugin. (Confirmed)
  • CleanUninstall (Boolean) - Indicates that mod can be deactivated without corrupting save games. (Most mods have no save game issues, so unchecked will almost never be default. beter to use the following property. ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • UninstallIssue (Boolean) - Indicates that mod can corrupt save games after removing corrupting save games. (This is uncommon, so unchecked by default is better than previous property ~z929669 Ixian Insignia.png Talk 16:05, December 19, 2014 (EST))
  • IsCore (Boolean) - Indicates if a mod is CORE to the STEP experience. (Not Confirmed) (his is still a useful property that applies to all mods ~z929669 Ixian Insignia.png Talk 10:49, December 16, 2014 (EST))
  • AffectsFPS (Boolean) - Indicates if a mod has a noticeable FPS impact. (Confirmed)
  • AffectsVRAM (Boolean) - Indicates if a mod has a noticeable VRAM impact. (Confirmed)
  • PerformanceAvailable (Boolean) - Indicates if a mod has a performance version available. (Confirmed)
  • QualityAvailable (Boolean) - Indicates if a mod has a quality version available. (Confirmed)
  • QualityItems (object) - Multiple-instance template containing:
    • QualityValue (string) - Available graphical tiers or options available (2048, 1024, High, Low, etc.).
    • AffectsFPS (string) - Indicates any noticeable FPS impact (positive, negative, none).
    • AffectsVRAM (string) - Indicates any noticeable VRAM impact (positive, negative, none).
  • ResourceHog (Boolean) -Indicates that the mod tends to have a relatively high performance cost in relation to other mods.
Recommendations[edit source]
  • Recommendations (Text) - Contains either the short note, or a link to the Mod page if detailed instructions are available. This property is specified by Template:Recommendations.
  • Notes (string) - Mod-specific information or special notes.
  • Conflicts (?) - Figure out some method to denote salient conflicts of particular interest.

Pack Attributes[edit source]

Pack Info[edit source]
  • Author (string) - The author(s) of the pack.
  • FullName (string) - Pack name.
  • Description (string) - Brief pack description.
  • ForumTID (string) - Specifies a URL created using the thread ID of the mod on the STEP forums.
  • Version (string) - Current version of the Pack.
  • DLCRequired (string) - (Optional) Indicates which DLC's are required by the Pack.
  • RequiredPack (string) - (Optional, multiple allowed) Pack(s) which are required for the pack to work. STEP:Core is an underlying requirement for all Packs and is thus excluded from this list.
  • CompatiblePack (string) - (Optional, multiple allowed) Pack(s) which are known to be compatible with this Pack, either inherently or through some kind of compatibility instruction/patch.
  • ModList Table - List of mods in the pack and specific installation instructions; similar to the current STEP guide's mod tables.

The following won't be stored semantically but are text boxes for the various text associated with the pack's description, installation, etc.

  • Description (none/plaintext) - Introduction, long description, purpose and goals, author notes, etc.
  • Pre-Installation Setup (none/plaintext) - Explanation of any pre-requisite steps that need to be taken before installing the pack's mods.
  • Post-Installation Config (none/plaintext) - Configuration instructions and anything else that should be done after installing the mods. Also outro and special credits.
ModList[edit source]

The mod list for the pack will define a number of the following:

  • ModListObject (object) - Multiple-instance template containing:
    • Order (number) - Order of the mod in the pack's list.
    • ModName (string) - Name of the mod.
    • Notes (string) - Pack-specific notes regarding the mod's installation.
Pack-Specific Mod-Level Install Notes[edit source]

Need to devise some way of allowing Pack-specific mod notes that are tied to mod pages. Maybe a Pack-Mod Form could be invoked from the Pack ModList Form to allow the notes and the resulting page could be Pack:Pack1-Mod1 (corresponding to Mod1 mod page) and the link(s) could be housed within a Pack section of the Mod1 mod page. This alleviates the issue of having to reproduce all of the mod-specific metadata and only point to the Pack-specific mod notes for that mod from the mod pages. This does not require that mods be tied to specific Packs but provides a way for mods to be associated with none or many packs, each with their own notes. ~z929669 Ixian Insignia.png Talk 14:33, February 12, 2014 (EST)

I feel the pack-based notes should be accessible as different recommendations sections/tabs on the mod page. That way someone using the mod could see all the basic information about a mod as well as different ways it could be configured to achieve different purposes, and see any conflicts in how the mods are used. A good example is XP32 maximum Skeleton which is configured in a different and incompatible way for STEP 2.2.8 as it is for Skyrim Revisited (including SR:LE). A few of the current fields (e.g., baseline) in the mod page would be moved to the recommendations portion of the form if this suggestion is followed. I think it's reasonable that pack pages should be able to show the information that is specific to their pack, but I feel that it adds too much complexity to have information about an individual mod spread out in different places on the wiki vs. being displayed multiple places (and formats) but saved and maintained in a single place. Kelmych (talk) 22:42, February 12, 2014 (EST)

Subpages include nav links to parent, and adding subpage links to mod main page is simple ([[/subpage]]), so we could use the subpage method I described above to achieve this behavior. Furthermore, the "subpage search" issue (subpages tend to ambiguate search results by attributing their unique content to the parent page) is a non-issue with respect to mod subpages, because these Pack notes are also attributable to the mod and are desirable associations in search. ~z929669 Ixian Insignia.png Talk 11:07, December 16, 2014 (EST)

This deserves some expansion. I'm wanting these options, but they need to be able to provide instructions, not just flags or categories:

  • Version - version-specific instructions (Mod/Pack/Guide-specific; problematic in terms of maintenance, because these notes change with updates to the Mod and the Pack AND any implicit changes due to versioning in other Mods/Packs ... Version number for Packs is fine, but not tying together Pack/Mod/Guide versions and associated instructions/recommendations ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Files - with crc (optional) and filesize (optional) listed in install order (Mod-specific; This is another maintenance nightmare without an API to some application [e.g., MO] that could spit out mod-specific file lists ~z929669
This would be better as a text box. Nexus has three or four different ways to list files (Main, Optional, Updates...) and it's easiest to just type out the files to get. CRC and file size might be overkill. Essarrbee (talk) 22:58, December 18, 2014 (EST)

Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )

  • FOMOD - change current one to be an actual template for installation options (Mod-specific; this is doable for Mods and desirable I think ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
Would love for this to be part of the Form, but if that is asking to much, then a nice template will suffice. I like the direction we are already going with the FOMOD installer template, so making it part of a form would be awesome. Essarrbee (talk) 22:58, December 18, 2014 (EST)
  • BAIN - change current one to be an actual template for installation options (Mod-specific; this is doable for Mods and may be desirable ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Manual Installation (Mod-specific; This just part of the standard Mod notes I think ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • LOOT Rules (Pack-specific; This is doable and desirable I think ... which alludes to moving the current mod-specific LOOT rules out of Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Required Mods (Pack/Guide-specific; undesirable IMO, as it is implicit in the Pack Guide itself ... no need to track this as a mod-specific attribute ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Incompatible mods (Mod/Pack specific; ... way too much maintenance and makes inferences about potential and n/a user-specific builds ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
Again, better as a text box and the author can add these in. Maybe do an Incompatible STEP Mods section. Essarrbee (talk) 22:58, December 18, 2014 (EST)
    • Patchable - with or without instructions (Pack specific; unnecessary information that should be covered in the pack instructions ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
    • Unpatchable - not possible to fix incompatibility (Pack specific; redundant with previous; unnecessary information that should be covered in the pack instructions ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
    • Redundant - mods that conflict that are completely redundant (Pack-specific?; Tn/aMI - too much n/a info ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • MCM menu options (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • INI edits (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Applications to add to Mod Organizer (Guide-specific; configuring a template for this would set the precedent to convert all aspects of any Guide to a template [i.e., modularizes Guide instructions, which is overly complicated, IMO] ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Skyproc - with instructions for usage (Pack-specific; could be covered similar to FOMOD instructions but on on Pack pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Optimize - actual instructions to optimize with DDSopt, etc (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Merge ESPs - a guide to merge the plugins together within the mod (Pack-specific; TMI, IMO ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
Not sure if this could be made into a nice template, but that would be useful for people around the plugin limit. 22:56, December 18, 2014 (EST)
  • Optional ESPs - any esps to move to Optional ESPs (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • BSA ticking - sic for BSAs to tick in archives to activate without plugin (Mod-specific; could be covered similar to FOMOD instructions on Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Hide files - for specific instructions on hiding files (Pack-specific; could be covered similar to FOMOD instructions but on Pod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Priorities - to tell which mods should be above or below in priority for "conflicting" mods (Pack-specific; redundant with Pack mod list ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • XEdit cleaning (Mod-specific; could be covered similar to FOMOD instructions on Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • ESP Errors - with actual instructions to fix the error (Mod-specific; possibly redundant with previous; could be covered similar to FOMOD instructions on Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
  • Overwrite - for mods that place files in Overwrite, instructions to deal with them (Mod-specific; could be covered similar to FOMOD instructions on Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )

These instructions would be toggleable within packs/etc. Some of these on this list are probably redundant, but the point is these would be for specific changing instructions on the mod level rather than a tickable attribute with no instructions for resolution. None of these would be forced, although encouraged where applicable. DoubleYou (talk) 19:07, September 2, 2014 (EDT)

Pack Implementation[edit source]

Issues with Current Implementation[edit source]

We Mumbled on Dec, 18, 2014 and discussed revisions to our current pack implementation. Following are problems with the current implementation:

  • Overly Form-constrained - When creating a Pack page, user needs to supply all of the existing pack properties, instructions, and mod list using Form fields. It would be better if there was less constraint by using forms only to capture Pack Property info (e.g., Name, Author, RequiredDLC, etc.)
  • Mod Tables - Too constrained in terms of layout mostly. Pack authors should be able to extract from mod pages any info needed without the layout of the mod list being constrained to [ Mod Name | Wiki Link | Mod Note ] horizontal layout.
  • Mods - Mod pages contain a lot of useful information, but much of it relates explicitly to STEP (e.g., Baseline, IsCore, Recommendations/Notes, etc.), so linking to the Mod page can be confusing to those following the Pack Guide. As a result, many pack guides currently ignore mod-page info and reproduce the desired info manually (less the undesired info) instead of linking directly to the mod page ... this adds redundancies and disconnects pack authors from communal mod content (and hence their incentive to help us maintain existing mod pages and add new mod pages).
  • STEP:Core - Right now, STEP:Core contains mods that may conflict or be rendered redundant with mods used in Packs. This belies that mod pages currently contain information in a STEP-Guide context, where they should only contain mod-specific information. A little of this is OK, but some of it is just wasteful (e.g., Main Font Replacement, Lockpicking Interface, etc.). Moving such mods to STEP:Extended resolves this.

New Implementation[edit source]

  • Layout Freedom - Pack authors should be able to define the presentation of the guide elements outside of some basic pack info (i.e., the info header of all packs should contain standard info that is consistently presented ... fe, Author, Name, version, and prerequisites).
  • Automated Content Import - Packs should allow import of applicable and select mod info from existing mod pages. This means that mod pages should only contain information that is universally applicable ... mod subpages or 'tabs' on the mod page could contain mod/pack-specific info.
  • Template Tool-Kit - Guide elements should be available via Templates that pack authors can elect to use. Ease of use could be facilitated by wrapping the template in a Semantic Form. A good example is FOMOD instructions and conflict resolution among many others. These tools would be optional, and authors could elect to use them or define (and maintain) their own methods.

Proposed New Implementation[edit source]

  • Semantic Form/Template to add pack page 'header' with basic pack properties (much like what currently exists, but augmented with all finalized properties).
  • Remainder of pack page allows raw wiki markup with optional tools available for using Forms/Templates presented as either Boolean options within the Pack Form to "turn on" these features or in-line buttons within the page after saving with the Form.
  • Move STEP/Pack-specific mod properties and attributes into mod tabs (via HeaderTabs), with each tab representing the pack to which it applies with default (top/first tab) representing STEP:Core if applicable. Tabs could be created when Packs add specialized info pertaining to a given mod within the pack's context (using a check box to indicate "special instructions" from the pack Form. This way, pack authors have the option of using [[Mod Name]] in their mod list, trusting that the mod page will contain mod info relevant to context of their guide.
  • Retain current mod-table implementation for those that want to use it - port mod notes
  • Enable the ability to 'pull' mod attributes from mod pages using template call or even optional form. The following assumes page [[Mod Name]] already exists, and that the mod page contains no info relating to the pack in question:
{{Mod Name|Author}} <-- This info is already in the mod page and will 'import' into the pack at this position
{{Mod Name|Description}} <-- This info is already in the mod page and will 'import' into the pack at this position
{{Mod Name|URL}} <-- This info is already in the mod page and will 'import' into the pack at this position
{{Mod Name|Version|1.0}} <-- This info is not on the mod page, but will be 'exported' to a new tab on the mod page once this edit is saved
{{Mod Name|Instructions: Stand up, sit down, run naked into your local supermarket.}} <-- This info is not on the mod page, but will be 'exported' to a new tab on the mod page once this edit is saved

Packs - ForumTID[edit source]

We're just giving each pack it's own thread right? Some of the bigger ones could be given a subforum (STEP, SR, etc.) but we can deal with that on a case-by-case basis) ~FarloUser Farlo Sig.pngTalk 20:32, July 16, 2013 (MDT)

Guide Attributes[edit source]

Guide Info[edit source]
  • Guide intent, description and background
  • Guide-specific procedures
  • Guide-specific INI settings
  • Summary
  • Credits

New STEP Categories[edit source]

{{{title}}}

{{{text}}}

←I propose that we split Section J - Animations and Effects into two different categories. Section J should include only mods that add/modify in-game effects, like Burn Freeze Shock Effects. We would then add a new section near the end of the guide specifically for mods that affect Animations. This would include mods that edit the skeleton, like XPMS, and raw animations, like No Spinning Death Animation. We should also create a new category at the end for the STEP Patches. Maybe this section should include the Bashed Patch creation as well? --DoubleYou (talk) 01:30, February 12, 2014 (EST)

I like the idea of a separate section for complex animations like XPMS and FNIS, but the main issue with that is 2.2.9 is the only version they would even get used. Starting with 2.3.0 all the Extended mods would get moved to a pack page and this would eliminate the need for a split section. Moving them all up is still the best way forward with the new focus on streamlining the guide. Section M should be the Patches section. The current section B should be a mod table in Step 1, everything else gets moved up one letter in Step 2, and the new section will be M - Patches. For 2.2.9 we can do the complex mods that require post install patchers at the end of section M or N. --Essarrbee (talk) 23:22, February 12, 2014 (EST)

I concur. --DoubleYou (talk) 00:35, February 13, 2014 (EST)

{{{title}}}

{{{text}}}

→This may be the only way forward if we move the mod table for utilities up to Step 1. This is also a mock up for 2.2.9, but will work for 2.3.0, but the last section will be tiny, just bashed patch and STEP Patches. The current format with Section A for the Patches confuses to many people and we get people asking about it daily. This is also the only way to keep the current categories and move stuff around that I can think of. I'd like to see what else others might come up with. --Essarrbee (talk) 13:42, February 13, 2014 (EST)

This is why we never added the tables for secs A/B, since utilities need to be configured first. I think that we can just go with 2.2.9 mockup for next time and see where it goes. ~z929669 Ixian Insignia.png Talk 21:22, February 13, 2014 (EST)
The way I have it mocked up on the right is pretty much the way that DY put it together. The difference is that section B is used for the 1.C and section A is the 2.N. He pretty much put it together without creating anything new, and it will work just fine for 2.2.9. This will also give us a better idea of what we can do with extended for 2.3.0 if we move some of those mods with post install patchers to the last two sections. --Essarrbee (talk) 22:13, February 13, 2014 (EST)
Retrieved from "https://stepmodifications.org/wiki/index.php?title=Project_talk:Data_Dictionary&oldid=53023"