Project talk:Data Dictionary

From Step Mods | Change The Game

This is our WIP discussion of our WIP Mod/Pack/Guide wiki Semantics. Feel free to contribute to the discussion!

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

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 Ixian Insignia.png Talk 14:33, February 12, 2014 (EST)

Pack-specific mod notes would clutter mod pages and it creates more work for pack authors having to switch between pages. They should be able to edit with the header and do it with a template. The template can call any mod page info needed such as Author, Nexus Link,and anything else, but not the STEP guide specific notes. Page creation is still an issue, but if we adapt the Nexus API for mod metadata to the form, it could be as easy as entering the link. EssArrBee SoloandChewy.jpg (talk) 17:49, December 19, 2014 (EST)
You misunderstand ... 1) Pack-specific installation notes add no clutter to mod pages if placed in tabbed format at bottom of mod page with STEP notes as default top tab (see comments below for more about this) .. 2) Pack authors would add/edit Pack notes on the Pack form ... the notes would be transcluded onto mod tabs, so navigation is not really an issue for authors (it would be for users though, but that is not an issue, as it is what we do now in STEP). ~z929669 Ixian Insignia.png Talk 03:56, December 23, 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)
I have the same viewpoint as Kelmych ... mod notes spread across the wiki = bad ... consolidated notes available by Pack under tabs on mod pages = nice neat consolidation and context for those interested in a given mod. ~z929669 Ixian Insignia.png Talk 03:56, December 23, 2014 (EST)
The only issues with having pack notes on the mod pages are 1) confusing users or users accidentally following the wrong notes and potentially breaking something and 2) clutter. If pack notes are added to the mod pages then 13 different packs all with 13 different notes (this is possible now, say with Soul Gems Differ) could add their own set of notes. Things could get messy. TechAngel85 (talk) 18:27, December 23, 2014 (EST)
I have no problem with keeping them in DD if they show on the Pack pages only. The problem is that we want to make it easier and more accessible and it is harder to put stuff on separate pages. Works are a guide that sticks to vanilla, but not for guides that go into more complex mods. You need the info in one place with a bit more hand holding. If we can query stuff from the DD, then that is alright, but sometimes instructions need to be specific to the other mods you install, such as patches. EssArrBee SoloandChewy.jpg (talk) 15:39, December 24, 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)

UPDATE: Rather than comment on all below that apply, any Mod-Pack-specific attributes could be stored under "Pack" tabs on mod pages, and all tabbed content would be transcluded from the Pack form and also maintained via the Pack form (if that is possible .. s4n??) ~z929669 Ixian Insignia.png Talk 03:56, December 23, 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) )
    Unless we have some wizard build a way to get the file version from the nexus page, mod version will have to remain a manual operation and not be tied to the DD. The Pack/Guide version should stay on the page of the pack, I do not see why it would be in the DD unless the actual pack has data that can be queried by other packs to list compatibility with a certain version. EssArrBee SoloandChewy.jpg (talk) 17:49, December 19, 2014 (EST)
    The idea here was for the mod table/form to have an option to input the version used by the pack author. That would make it easier for the author and the user to properly associate the instructions given by the author with the version of the mod being used. This was not intended, at least by myself, to be a pull from some database somewhere, but simply a declaration of the version of the mod being used at time of compilation, and indeed most Pack Authors are mentioning this already in their packs. For it to be in the DD, no, but in the form to create the table, why not? It would be convenient. DoubleYou (talk) 16:30, December 20, 2014 (EST)
    Thinking more on this, it is doable in the context of mod pages with tabs corresponding to Packs. If the Pack author wishes to instruct a user to install one of many possible versions of a mod, then that info would be under the Pack tab of a mod page ... this info is in fact Mod/Pack specific, so it makes sense, IMO. Maintenance is not an issue this way, as the Pack authors will need to maintain it, not us :P ~z929669 Ixian Insignia.png Talk 03:56, December 23, 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 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
    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 SoloandChewy.jpg (talk) 17:49, December 19, 2014 (EST)
    The idea of this option came from a desire to eventually have the ability to use a MO plugin to pull information from our wiki database for a semi-automatic installation of a pack in the future. Definitely a hard task that we are not close to doing yet. DoubleYou (talk) 16:30, December 20, 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. For the form it could be a check box that opens up to fields that you can enter, but I don't know what level of work that is. I like the direction we are already going with the FOMOD installer template, so making it part of a form would be awesome. EssArrBee SoloandChewy.jpg (talk) 17:49, December 19, 2014 (EST)
    It is impossible to make our current fomod template a part of the form as it stands, unless I'm mistaken (quite possible). It definitely would be desirable if so. DoubleYou (talk) 16:30, December 20, 2014 (EST)
    I can see a way that it could be done via a form; however, it might be complex enough that a separate form would probably need to be developed before it being integrated into the current form (if integration is even possible).TechAngel85 (talk) 00:00, December 31, 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) )
    This category has less and less use, but if we ever had Oblivion fully supported, then it would be essential. IFF. EssArrBee SoloandChewy.jpg (talk) 17:49, December 19, 2014 (EST)
    Would agree with SRB on this one. This is of very little use to STEP and STEP-based Packs. The only users to get use out of this are users makes Guides for other games...not Pack Authors. I've for getting rid of the BCFs off the mod pages for a while now since they just seem to confuse users since the switch to MO.TechAngel85 (talk) 00:09, December 31, 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) )
    No reason for this, should not have a DD flag. EssArrBee SoloandChewy.jpg (talk) 14:02, December 20, 2014 (EST)
    I think you misunderstand what I was meaning on this note. This would indicate a mod that required you to push the "Manual" button and play with the files in Mod Organizer to install correctly. But perhaps you would just indicate this generally. DoubleYou (talk) 16:30, December 20, 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) )
    This is Pack/Load Order Specific, but not always mod specific. Should probably not be in the DD unless it is necessary to flag it on a mod page, but I just don't see why. A template that can be copy-pasta to the instructions is a better solution. Also, I can contribute rules to the masterlist if need be. EssArrBee SoloandChewy.jpg (talk) 14:02, December 20, 2014 (EST)
    Technically we should not need this, and should simply instruct authors to contribute to the LOOT masterlist. But I doubt that will happen, so we'll probably need this. And this would be mod specific in most cases. LOOT rules that are not mod specific should, of course, be left out. DoubleYou (talk) 16:30, December 20, 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) )
    I see this as a positive, but it may require to much maintenance. We already have an SKSE flag, but it could got that the SKSE flag is dependent on this flag. Then there would be something like text field to enter other mods. That is where it becomes a burden. I like the idea of just having a Requirements field in the mod table or form that we end up with. EssArrBee SoloandChewy.jpg (talk) 14:02, December 20, 2014 (EST)
    We probably cannot have this mod-specific, because many mods have options that vary widely in required mods (e.g. STEP Patches) DoubleYou (talk) 16:30, December 20, 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, but not as a flag in the DD, better to enter manually. EssArrBee SoloandChewy.jpg (talk) 17:49, December 19, 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) )
      Would be in a section marking the mod for xEdit instructions. EssArrBee SoloandChewy.jpg (talk) 14:02, December 20, 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) )
    Would be nice for the STEP guide to see on Mod Pages and as a template for recommended settings in packs. For the STEP guide it would actually be best to list the MCM settings all at once so people can do it once in game from one page instead of changing mod pages. Make it something that can be queried from the DD, but not show it on the mod pages. EssArrBee SoloandChewy.jpg (talk) 14:54, December 20, 2014 (EST)
    I agree with SRB and users have voiced the same opinion. Taking this information off the mod pages and providing it at the end of the STEP Guide would be far more efficient and easier for our users. As for Packs, they can do the same as the STEP Guide and put the info at the bottom of their pack guides by entering the information in an open text field via the Pack form.TechAngel85 (talk) 00:30, December 31, 2014 (EST)
    I understand your reasoning, but I'm pretty sure that we could make it a property that would be stored on the mod pages and then queried from the list at the end to automatically add those to an ending section. That would make maintenance on this a little more doable I think. DoubleYou (talk) 16:40, December 31, 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) )
    Very seldom used, so don't waste the effort creating this unless there is somehow lots of additional time. EssArrBee SoloandChewy.jpg (talk) 14:54, December 20, 2014 (EST)
    Agree, it's not anything that needs to be tracked. Just provide an open text box for users to add an INI section to their packs, have it format to a template, and that is all that's needed.TechAngel85 (talk) 00:35, December 31, 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) )
    Not sure this would be needed in the DD. Why flag this at all. Maybe a template for the instructions to add it so we can standardize it across all of STEP. EssArrBee SoloandChewy.jpg (talk) 14:54, December 20, 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) )
    Should be something like Post-Install Patcher for Skyproc, Bashed Patch, and FNIS. Not really necessary though. EssArrBee SoloandChewy.jpg (talk) 14:54, December 20, 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) )
    Individual optimization of a mod is not really a good idea for the DD. Better to be full guide/pack instructions and don't see the need for any DD implementation. EssArrBee SoloandChewy.jpg (talk) 14:54, December 20, 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. I think my instructions on Fear and Loathing are pretty universal and if we can create a form or template then I'd assist in any way. Here's an example merging some guns and TES5Edit instructions are the same, but it should be said that hand holding is absolutely necessary. The instructions are not mod specific though, it is pack/guide specific, so this would not really be part of the mod page DD, but used only for packs/guides. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 2014 (EST)
    Are we not talking about the Pack mod table on this now? So this would be pack-specific.DoubleYou (talk) 16:30, December 20, 2014 (EST)
    I still think that maybe adding some kind of template to the WYSIWYG that users could chose to add to their text field might be best. A form for this would not be used often and may be overkill. EssArrBee SoloandChewy.jpg (talk) 20:59, December 20, 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) )
    This is all due to circumstance, so pack/guide specific. Mods come with all kinds patches that would/wouldn't be uses, so not DD flag is really needed. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 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) )
    This is another pack/guide specific instruction. A mod's BSA may ticked in one guide/pack and unticked in another. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 2014 (EST)
    Are we not talking about the Pack mod table on this now? So this would be pack-specific.DoubleYou (talk) 16:30, December 20, 2014 (EST)
  • Hide files - for specific instructions on hiding files (Pack-specific; could be covered similar to FOMOD instructions but on Mod pages ~z929669 Ixian Insignia.png Talk 11:56, December 16, 2014 (EST) )
    Again guide/pack specific stuff should not be mod pages. Better to have it as part of a template/form for the packs. I could see this as a flag for mods, but it would be used on mod pages only for the STEP guide. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 2014 (EST)
    Are we not talking about the Pack mod table on this now? So this would be pack-specific.DoubleYou (talk) 16:30, December 20, 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) )
    Let the top to bottom order of mods take care of that. Way to specific for any DD flag. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 2014 (EST)
    This could also vary between pack authors, so probably not very useful. DoubleYou (talk) 16:30, December 20, 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) )
    I like the idea of this for the mod pages, it would be nice to incorporate a nice template for cleaning mods in the mod pages for the STEP guide, but also be able to call on the info for packs/guides. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 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) )
    Should be a separate template that we can use that looks somewhat like the xEdit cleaning, but shouldn't be in the Mod pages. May be a useful part of the DD though if there was enough mods that actually had the problem. As of right now there are only a couple. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 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) )
    I see the benefit to this on a mod page, but it would also have to something that can be called on from the pack/guide as well. Should be attached to SkyProc and xEdit instructions. EssArrBee SoloandChewy.jpg (talk) 14:21, December 20, 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)

Making all of these toggleable is key. In this way, Packs become modular and that is what we need. Very few sections in a Pack should be mandatory. This keeps things versatile for our users and allows the creation of more unique packs. TechAngel85 (talk) 00:47, December 31, 2014 (EST)

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.
    I don't see this a big issue, but it is a good idea for pack authors to state up front what to remove from STEP Core or even Extended. Might be less of an issue with Extended being a pack. EssArrBee SoloandChewy.jpg (talk) 15:05, December 20, 2014 (EST)
    The point here is that STEP:Core is suppose to be the base of all Packs. Meaning users shouldn't have to state to remove any mods from Core. They should only have to post Core as an installation prerequisite and that be the end of it. This does not apply to Extended, since it will be a Pack itself. Pack Authors will have to tell users to remove any mods from Extended they don't want installed with their Packs, if it is listed as an installation prerequisite. TechAngel85 (talk) 00:58, December 31, 2014 (EST)

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

  • 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.
    Specific instructions do not belong on mod pages, they belong with the packs. -- Stoppingby4now (talk) 19:16, December 19, 2014 (EST)
    I agree, it would clutter mod pages and instructions may be different for different packs. EssArrBee SoloandChewy.jpg (talk) 15:03, December 20, 2014 (EST)
    I used to feel the same way, but I am now leaning to placing Pack-soecific mod instructions on the mod page ... why? Because such instructions are also mod-specific, and this allows mod pages to contain notes for installation in a number of contexts. Since we are placing recommendations for STEP:Core AND STEP:Extended (a Pack in 2.3.0) on mod pages, then it defies reason that we don't elect to do the same for Packs. Otherwise, we should offload all mod installation notes and recommendations from mod pages ;). Imagine a mod page just as it exists today, with several tabs at the bottom, each named according to the Pack they apply to. The main tab (first tab) would contain the STEP instructions (that is why the page will stay looking essentially the same), while the other tabs will contain Pack instructions. This is not cluttered at all and treats all mod installation notes consistently. ~z929669 Ixian Insignia.png Talk 03:37, December 23, 2014 (EST)
    This goes against the reasons you stated for not using HeaderTabs on Guides. It becomes cluttered when there are a lot of tabs. The limit that you stated was somewhere around 5 for Guides. So what happens when we have 20 packs all using the same mod? You're going to have 20 tabs! I'm against this and agree that all this information should be on the Packs and not on the mod pages. The fact that some of this info exists on mod pages for STEP should also be addressed. If we're moving towards a Pack-based future for STEP, then we need to offload the instructions for Extended mods when we create the Extended Pack into that pack. For Core mods, the information can stay on the mod pages since Core is suppose to be the foundation for all packs. TechAngel85 (talk) 01:12, December 31, 2014 (EST)
    @Z: Pack specific instructions do not belong on Mod pages in any shape or form, via header tabs or sub pages, etc. Think of this in terms of objects. There are a collection of Mod objects, and Pack objects. Pack objects consume Mod objects. This means that Mod objects should only have information specific to the mod that is usable by every consumer. If a Pack object needs to declare additional information beyond what the base Mod object represents, it must implement those details, not the Mod object. The basis for the STEP information being on mod pages was due to the entire development being geared only for STEP. We can still continue down that path, but if any change is to be made, then it is in fact that the STEP Guide needs to be the owner of special instructions, and not the Mod page. -- Stoppingby4now (talk) 02:26, December 31, 2014 (EST)
    AND... if we can't even now get pack authors to make pack pages, how in the world are we gonna get them all to put their instructions on the mod pages! DoubleYou (talk) 18:13, December 31, 2014 (EST)
  • Retain current mod-table implementation for those that want to use it - port mod notes (By 'retain' I just mean'loosely' ... not that we needed to keep the same format/layout; however, we need to consider what will happen to existing Packs if we don't at least leave the current method implemented (i.e., conversion)).
    Disagree about retaining mod-table implementation. Aside from pack specific instructions being entered via normal wiki text, there should be a consistent layout. -- Stoppingby4now (talk) 19:16, December 19, 2014 (EST)
    The form may work like a table, but the actual look of the wiki page should look more like SRLE because of the install instructions being needed on the pack page. Complex mods like Requiem or SkyRe require a bit more hand holding than something like USKP, which is the type of mod the STEP guide uses, but not really what the packs are about. EssArrBee SoloandChewy.jpg (talk) 15:03, December 20, 2014 (EST)
    That makes sense after re-reading. -- Stoppingby4now (talk) 22:24, December 21, 2014 (EST)
    Not sure what s4n's last comment is addressing, but to previous comments: Disagree that we need to keep mod installation notes on the Pack mod tables. This adds a lot to page length, and breaking up content is nice for load times and maintenance (fe., edits). Pack install notes could be on the mod page just like STEP notes. Otherwise, let's maybe discuss a new implementation for all STEP that is consistent. ~z929669 Ixian Insignia.png Talk 03:37, December 23, 2014 (EST)
    First, I don't think we should be too worried about conversion since most Pack Authors aren't using the mod-table implementation anyway. Do away with it and implement something easier for the users. I do agree with SRB that the information needs to be vertical rather than horizontal for mods. We discussed as much on Mumble and this is the common theme in the Packs we have now. It's what the users want and it works well. TechAngel85 (talk) 01:20, December 31, 2014 (EST)
    @Z: Refer to my comment for the item above. Pack install notes only belong on the Pack page. The only additional information that would be a good fit to store on a Mod page would be information related to it's relationship to other Mod's. Such as ModA is incompatible with ModB unless you do THESE_STEPS. In other words, only information that is specific to a Mod and it's interaction with other Mods, and is thus relevant to all consumers. -- Stoppingby4now (talk) 02:26, December 31, 2014 (EST)
  • 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
  • There is a mechanism for having pages created if they don't exist (if they are referenced), but all I know of is the global setting which isn't very ideal. Will see if I can find anything that allows more control over what gets created. This could provide a little more incentive for folks to update mod pages on the wiki. -- Stoppingby4now (talk) 19:16, December 19, 2014 (EST)
  • What about having a section at the very top that references mods used in a pack? No meta information, just the mod names, and linked to the heading for the mod within the page. This can provide a couple benefits: 1) allows for easily identifying mod pages that have not been created so anyone can choose to update them (if third point above is not possible), 2) allows quick scanning of all mods that are used in a pack up-front, which can be beneficial to both users and authors. -- Stoppingby4now (talk) 19:15, December 19, 2014 (EST)
    So something like a TOC, but instead of all the headings, it just lists the mods? That might work. We don't use TOCs on the packs that use mod tables AFAIK, so it would be a nice stripped down TOC. EssArrBee SoloandChewy.jpg (talk) 15:06, December 20, 2014 (EST)
    Not really a TOC, just a representation of Mod's that are used. Project:Data_Dictionary#Form:DataDictionary is a small example, where the templates used by the Form are listed in a table. Not advocating the exact format used on that page, just the concept. Could either categorize all compactly at the top, or per section. -- Stoppingby4now (talk) 22:24, December 21, 2014 (EST)
    Could be nice, but it could also be messy and largely redundant ... what about packs with 50+ mods? ~z929669 Ixian Insignia.png Talk 03:37, December 23, 2014 (EST)
    Good point. -- Stoppingby4now (talk) 18:26, January 3, 2015 (EST)

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) ~FarloUser Farlo Sig.pngTalk 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

Something like this...

A - Configuration
ENBoost
Simple Borderless Window

B - Script Extenders

Skyrim Script Extender

C - Fixes
D - Interface
E - Conflicting Graphics
F - Landscape & Environment
G - Characters & Creatures
H - Clothing & Equipment
I - Effects
J - Clutter & Miscellaneous
K - Sound
L - Gameplay
M - Animations

XPMS
Realistic Ragdolls and Force
FNIS
No Spinning Death Animation

N - Patches

Bashed Patch
STEP Patches

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

Without messing up catagories...

STEP 1:

C - Utilties

This would be the current 2.B

STEP 2:
A - Ignore section or leave it for text
B - Ignore section or leave it for text
C - Script Extenders

Skyrim Script Extender
ENBoost
Simple Borderless Window

D - Fixes
E - Interface
F - Conflicting Graphics
G - Landscape & Environment
H - Characters & Creatures
I - Clothing & Equipment
J - Animations & Effects
K - Clutter & Miscellaneous
L - Sound
M - Gameplay
N - Patches

Dual Sheath Redux
XPMS
FNIS
Bashed Patch
STEP Patches

→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=164922"