Project talk:Data Dictionary

Archive

---

• /Archive 1

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. ~FarloTalk 19:56, July 15, 2013 (MDT)

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

Mod Attributes

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

• 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) - 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

• DocDescription (Boolean) - Indicates that the mod includes a description of what the mod does.
• DocInstall (Boolean) - Indicates that the mod includes installation instructions.
• DocUninstall (Boolean) - Indicates that the mod includes un-installation instructions.
• HasScript (Boolean) - Indicates that the mod uses scripts.
  
• CompatibleBAIN (Boolean) - Indicates that the mod package has BAIN support.
• CompatibleFOMOD (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.
• IsCore (Boolean) - Indicates if a mod is CORE to the STEP experience. (Not Confirmed) - I think that this is still a useful property, particularly in Semantic queries (unless we can use a new 'Core Mod' category for filtering purposes) ~z929669 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: (Confirmed)
  • QualityValue (string) - Available graphical tiers or options available (2048, 1024, High, Low, etc.). (Confirmed)
  • AffectsFPS (string) - Indicates any noticeable FPS impact (positive, negative, none).
  • AffectsVRAM (string) - Indicates any noticeable VRAM impact (positive, negative, none).

Recommendations

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

Mods - Description

Proposed adding Short Mod Description (1 sentence, possibly from the Nexus API); currently this isn't in either the mod page or the STEP guide. It would be hard to include this in a STEP guide (core or pack) since it doesn't fit well in a multi-column format like those used in the guide.

Agreed, at the very least it'll help fill out the mod pages. ~FarloTalk 18:20, July 16, 2013 (MDT)

Mods - Category

Proposed change to broad categorization of the mod (NOT the STEP section, similar idea to the Nexus categories but hopefully with categories more relevant to STEP) ~FarloTalk 18:20, July 16, 2013 (MDT)

Mods - IsOptimized

The flag is somewhat problematic since it applies only to textures and can be hard to verify especially for non-core mods. Moreover, we may still want to separately optimize/reoptimize the normal maps even if the color map textures are adequately optimized. ~Kelmych Talk 12:26, July 16, 2013

I think that this is a good flag for things that really should not be run through DDSopt for whatever reason. We can change the property and tag names easily enough if necessary. ~z929669 Talk 15:21, July 16, 2013 (MDT)

What should we do if the color map textures are optimized but the normal maps are too large. Should there be tgwo flags, or just ignore the normal map issues? Kelmych (talk) 21:11, July 16, 2013 (MDT)

I'd say keep only one flag. Textures that are already optimized won't be affected anyway. We can add exceptions to the INI where there are specific use cases that might get borked. ~z929669 Talk 00:50, July 18, 2013 (MDT)

IMO we should just track the file's optimization, they can be whatever resolution the author wants, unless I'm missing something about them being "too large" (is that a thing?). Unless everything is optimized it shouldn't be tagged as such. ~FarloTalk 23:44, July 16, 2013 (MDT)

Kelmych (talk) 17:12, November 16, 2013 (EST) Based on comments about the STEP Mod Texture table and experience using this table in developing and testing a batch file for bulk optimization, I feel that the interpretation of the flag that Z recommends is the correct one; it should be one flag that means it should not be run through DDSopt without a very good reason. The revised STEP Mod Texture table in the DDSopt guide has this flag (column 2). So far the mods I've evaluated and that have this flag as Yes don't need normal map resolution changes.

Mods - Optimization-related Data

Kelmych (talk) 17:39, November 16, 2013 (EST) A few months ago I changed the information included in the STEP Mod Texture table in the DDSopt guide based on comments from some users who said it the entries needed to be easier to interpret while making decisions about optimization parameters and choices. I feel that the fields for mod-specific data about optimization should actually be in the Mod Data Dictionary and the data itself entered in a set of parameters on a Mod page, perhaps in an Optimization tab. There would also need be a new template so the data could be assembled to create a new version of the STEP Mod Texture table in the DDSopt guide. The new flags and data element I suggest are shown below. The values for these are independent of the pack or packs that include the mod. The equivalent of the IsOptimized flag is already in the STEP Mod Texture table so it is not included below. Note that values for all these parameters are available for the STEP mods in the STEP Mod Texture table in the DDSopt guide.

Kelmych (talk) 20:20, November 17, 2013 (EST) We don't test individual mods and decide whether optimization helped. There isn't enough of a change from optimizing a single mod to get useful indications on how to optimize. Recommendations on optimization are based on testing with many mods optimized simultaneously and extracting results based on different optimization choices for classes of textures used. I created the flag recommendations based on the texture classes that we've found through testing are important in determining how to optimize a mod. Results of testing have affected the choice of properties, but not the value (e.g., True or False) for these properties. The property values are characteristics of the mod itself.

Kelmych (talk) 20:20, November 17, 2013 (EST) The flags and texture resolution string help a user determine how to optimize a mod (settings, filters,...), and to understand how much effort and time it will take to optimize the mod. This information is not typically available in the Nexus mod description and some isn't even available when looking at the Windows explorer window for individual textures. Much of the information I use to determine the flag values for an individual mod is taken from logs created by DDSopt. Flag value differences between different versions of a mod versions or with mod updates are rare.

Kelmych (talk) 17:57, November 16, 2013 (EST) recommended mod optimization-related parameter additions (flags might use shorter names)

The following are binary flags

HasTextures

Kelmych (talk) 20:20, November 17, 2013 (EST) This is just an indicator flag; if it is not true for a mod then the other properties are not relevant

HasExteriorTextures

Kelmych (talk) 20:20, November 17, 2013 (EST) Exterior textures are important since they seem to be a primary cause of high VRAM use. When optimizing textures most users are now reducing the resolution of exterior textures to half the resolution of the other textures. In my system, as an example, I got a roughly 15% decrease in VRAM use by doing this. This flag is present so a user knows that when optimizing this mod an extra step is needed with different optimization parameters for the exterior textures.

HasUncompressedTextures

Kelmych (talk) 20:20, November 17, 2013 (EST) Mods with uncompressed textures need an extra processing step during optimization with different processing parameters to properly optimize the uncompressed textures. Often it isn't apparent that a mod has some uncompressed textures, and this flag would let users know that they need to identify the uncompressed textures and optimize them with different optimization parameters.

HasAllUncompressedTextures

Kelmych (talk) 20:20, November 17, 2013 (EST) For mods whose textures are all uncompressed, the optimization processing parameters are different than the usual parameters used to optimize a mod. If all the textures are uncompressed, then the optimization can be done in a single step. This flag might not be needed since a mod with the HasCompressedTextures as True and MultiStepOptimizationRecommended as False is probably equivalent to this flag.

HasCollapsableTextures

Kelmych (talk) 20:20, November 17, 2013 (EST) Collapsable textures are nxn color maps with the same color in every cell. DDSopt will collapse these into a single cell with the same color. Most graphics cards handle these properly but a few don't. When users have texture problems one of the first causes they suspect is that DDSopt collapsed some of the textures. This usually does not prove to be the actual problem, but this flag lets users know which mods actually have such textures so they can more efficiently determine the cause of texture problems.

MultiStepOptimizationRecommended

Kelmych (talk) 20:20, November 17, 2013 (EST) This flag indicates whether a mod has any exterior textures, uncompressed textures, or normal maps that should be reduced in resolution. If any of these conditions exist then optimization of a mod's textures should be done in multiple steps each with a different subset of the textures and different optimization parameters. If the flag is false the user knows that ordinary optimization will be fine with this mod and no special processing is needed.

The following are strings

MaxTextureResolutionByModVersion

Kelmych (talk) 20:20, November 17, 2013 (EST) This string will contain the max texture resolution for each version of the mod that contains textures with different resolutions. This is particularly useful in setting an appropriate value for the Resolution Limit parameter in DDSopt optimization, and for users to determine which mods need to have textures reduced in size during optimization.

Mods - LoreFriendly

Proposed removal: not a whole lot of meaning for most mods and isn't well defined. Also mostly useless for our purposes. ~FarloTalk 18:20, July 16, 2013 (MDT)

it is often difficult to assign/verify this flag ~Kelmych Talk 12:26, July 16, 2013

Mods - IsClean/HasPlugin

Proposed: Fully specify if mod has plugins and that they are clean. Also, disambiguate clean plugins from clean uninstall (or eliminate clean uninstall altogether)

Mods - IsCore

Proposed: Remove, core mods -- will be in STEP:Core, this attribute isn't tied to the mod itself.

Agreed ~FarloTalk 18:20, July 16, 2013 (MDT)

Mods - FPS and VRAM

Proposed: should have way to indicate whether effect is positive or negative ~Kelmych Talk 12:26, July 16, 2013

Only Vano89's mod positively impacts performance, so this really denotes a negative impact. ~z929669 Talk 15:25, July 16, 2013 (MDT)

But that might not be true for much longer, what if someone made a "craptastic computer pack", it might be nice to know that a mod has a positive effect. I think a choice of positive/none/negative would be well suited. ~FarloTalk 18:20, July 16, 2013 (MDT)

I was thinking about relative improvements compared to some STEP baseline, in which case a mod that reduces quality a small amount but improves FPS a lot might get a positive check here. Skyrim Performance Plus would certainly get a plus here also. Kelmych (talk) 21:11, July 16, 2013 (MDT)

When Z, Stopping, and I were talking we kind of came to the conclusion that baseline wouldn't be a universal aspect since packs can target differing computer ranges. The AffectsFPS and AffectsVRAM tags would then be compared to Vanilla; for example an HD mod would obviously negatively impact FPS and VRAM whereas some gameplay mod wouldn't affect either. ~FarloTalk 23:44, July 16, 2013 (MDT)

Mods - Recommendations/Notes

Proposed: Attach mod-specific notes to mod pages. Packs will also need recommendations relating to specific mods. Template:Recommendations could be used at the Pack level as it currently stands.

Proposed: s4n suggested adding capability to set flags (plus mod IDs) to note conflicts.

Mods - Conflicts

how about a list of important conflicts using the STEP mod index in the list Kelmych (talk) 21:11, July 16, 2013 (MDT)

We thought about this, but it'd be a huge pain in the ass to keep every mod updated with the mods it conflicts with. Not really sure how to go about this one. ~FarloTalk 23:44, July 16, 2013 (MDT)

Pack Attributes

Pack Info

• 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

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

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 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 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 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)

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 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 Talk 11:56, December 16, 2014 (EST) )
• Manual Installation (Mod-specific; This just part of the standard Mod notes I think ~z929669 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 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 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 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 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 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 Talk 11:56, December 16, 2014 (EST) )
• MCM menu options (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 Talk 11:56, December 16, 2014 (EST) )
• INI edits (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~z929669 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 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 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 Talk 11:56, December 16, 2014 (EST) )
• Merge ESPs - a guide to merge the plugins together within the mod (Pack-specific; TMI, IMO ~z929669 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 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 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 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 Talk 11:56, December 16, 2014 (EST) )
• XEdit cleaning (Mod-specific; could be covered similar to FOMOD instructions on Mod pages ~z929669 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 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 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

Issues with Current Implementation

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

• 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

Changes to Mod Pages

• 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

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) ~FarloTalk 20:32, July 16, 2013 (MDT)

Guide Attributes

Guide Info

• Guide intent, description and background
• Guide-specific procedures
• Guide-specific INI settings
• Summary
• Credits

New STEP Categories

{{{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 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)