Project talk:Data Dictionary: Difference between revisions

From Step Mods | Change The Game
m (Text replacement - "fc|#e6b69e" to "Fc|salmon")
 
(194 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{TOC right}}
{{ArchiveBox|
* [[/Archive 1]]
* [[/Archive 2]]}}
{{TOC}}


= LATEST STUFF =
''This is our WIP discussion of our WIP Mod/Pack/Guide wiki Semantics. Feel free to contribute to the discussion!''
== Updates ==
:[https://stepmodifications.org/forum/topic/843-data-dictionary-talk/ {{fs|1.2em|Discussion Forum}}] {{fc|#ddd|PM admin if you can't access and want to help!}})
(most recent first)


=== DDSopt Properties ===
==Mod Attributes==  
Applies only to texture mods. Propose that we include Section as a Mod Attribute to indicate the STEP Section to which a mod will belong if added. Only Section G will apply to the DDSopt Property set.
Color key:
* '''IsOptimized''' - The textures are ''already optimized'' to the appropriate compression format or are necessarily uncompressed.
* {{Fc|salmon|'''''Not changed'''''}} - Represents at most minor changes being made to the property.
<br />
* {{fc|#9eb6e6|'''''Addition'''''}} - Proposed additional/replacement property.
If IsOptimized is ''not true'', then the following could also apply:
* {{fc|#ff6060|''Removal''}} - Property proposed to be removed/replaced.
* '''OptSettings''' - This might hold the main variable settings suggested for ideal optimization. We could use several separate Properties or  group as SubProperties (or possibly as a Record type). I am not sure what the variable settings should be, because that will depend on the definition of the standard settings and this Property could hold only the non-standard settings.
* '''OptExceptions''' - This could hold something similar to the previous, but it might also hold the specific texture paths that should be included in the DDSopt INI and how they should be treated there.
* '''ByteDiff''' - This would hold the byte diff from the log output.
* '''VramDiff''' - This would contain the resulting VRAM change of the pre/post optimized versions.
~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 02:44, December 17, 2012 (UTC)


: ''Section'' is already declared as a property under Template:Mod. The distinction between Mod and ModAttributes is that Mod is for basic info such as the mod's name, section, NexusID, etc. while ModAttributes is based around the ticket/performance data results and will be the kind of stuff that needs some amount of discussion/consensus before declaring.
===== Mod Info =====
: All of those sub-properties will be great to have. The problematic one will be ''VramDiff'' since it will likely be different depending on the rig.
* {{Fc|salmon|'''''Author'''''}} (string) - The author(s) of the mod.
: ~[[User:Farlo|Farlo]][[File:User Farlo Sig.png|19px|link=User:Farlo]]<small>[[User talk:Farlo|Talk]]</small> 04:22, December 17, 2012 (UTC)
* {{Fc|salmon|'''''FullName'''''}} (string) - Full name of the mod according to source.
* {{fc|#9eb6e6|'''''Description'''''}} (string) - Brief mod description. {{fc|#ddd|(Confirmed)}}
* {{Fc|salmon|'''''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.
** {{Fc|salmon|'''''SourceID'''''}} (string) - "Steam" or "Nexus" mod SourceID if either is specified in SourceName.
** {{Fc|salmon|'''''SourceURL'''''}} (URL) - Full URL if SourceName is specified as "Other".
* {{fc|#ff6060|''Section''}} (string) - STEP installation "blocks" specified using "allows value" declarations. {{fc|#ddd|(Confirmed)}}
* {{fc|#9eb6e6|'''''Category'''''}} (category) - Broad category/"class" of the mod, similar (if not identical) to the Nexus categories. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''Baseline''}} (string) - Specifies the recommended mod option when more than one are available. {{fc|#ddd|(Confirmed)}}
* {{Fc|salmon|'''''ForumTID'''''}} (string) - Specifies a URL created using the thread ID of the mod on the STEP forums.<br>
* {{Fc|salmon|'''''External URL'''''}} (object) - Multiple-instance template containing:
** {{Fc|salmon|'''''ExternalURL'''''}} (URL)  - URL string specifying a page associated with the mod; other hosts, Facebook, etc. (URL)
** {{Fc|salmon|'''''ExternalLabel'''''}} (string)  - A human-meaningful label associated with ExternalURL (string)<br>
* {{fc|#ff6060|'''''HasResource'''''}} (string; see next property) - Indicates how a mod's resources files are packaged. (BSA, Loose, None).
* {{fc|#9eb6e6|'''''ResourceType'''''}} (string; previously, 'HasResource', which is a misnomer indicating Boolean) -  Indicates how a mod's resources files are packaged. (BSA, Loose, None).
* {{Fc|salmon|'''''DLCRequired'''''}} (string) - Indicates which DLC's are required by the mod.
* {{Fc|salmon|'''''DLCSupported'''''}} (string) - Indicates which DLC's are supported by the mod via an addon.


:: * Can you provide examples of data that is needed to store for a DDSOpt ini file. Since I haven't messed with one, I don't know what all is available or needed. Shouldn't be a need for records or subobjects though.
===== Mod Flags =====
:: * What does ByteDiff provide you that makes it necessary?
* {{fc|#ff6060|''DocDescription''}} (Boolean) - Indicates that the mod includes a description of what the mod does. (not useful ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
:: * I don't see VramDiff as being needed either.
* {{fc|#ff6060|''DocInstall''}} (Boolean) - Indicates that the mod includes installation instructions. (not useful ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
:: [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 08:37, December 17, 2012 (UTC)
* {{fc|#ff6060|''DocUninstall''}} (Boolean) - Indicates that the mod includes un-installation instructions. (not useful ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
----
* {{Fc|salmon|'''''HasScript'''''}} (Boolean) - Indicates that the mod uses scripts.<br>
* {{fc|#ff6060|''CompatibleBAIN''}} (Boolean) - Indicates that the mod package has BAIN support. (bad property name, move to following property ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
* {{fc|#9eb6e6|'''''HasBAIN'''''}} (Boolean) - Indicates that the mod package has BAIN support.
* {{fc|#ff6060|''CompatibleFOMOD''}} (Boolean) - Indicates that the mod package has FOMOD support. (bad property name, move to following property ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
* {{fc|#9eb6e6|'''''HasFOMOD'''''}} (Boolean) - Indicates that the mod package has FOMOD support.
* {{Fc|salmon|'''''IsOptimized'''''}} (Boolean) - Applies to texture mods only. Indicates that the mod textures are correctly formatted (but not that they are necessarily size/constraint optimized).
* {{Fc|salmon|'''''HasSKSE'''''}} (Boolean) - Indicates that the mod depends on SKSE.
* {{Fc|salmon|'''''HasMCM'''''}} (Boolean) - Indicates that the mod has MCM functionality and depends on SkyUI.
* {{Fc|salmon|'''''HasSkyProc'''''}} (Boolean) - Indicates that the mod contains a SkyProc patcher.
* {{fc|#ff6060|''LoreFriendly''}} (Boolean) - Indicates that the mod is considered lore friendly. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''IsClean''}} (Boolean) - Indicates that the mod's EPS/M files are free of ITM/UDR errors. {{fc|#ddd|(Confirmed)}}
* {{fc|#9eb6e6|'''''HasPlugin'''''}} (Boolean) - Indicates that the mod has a plugin file (ESP, ESM, None). {{fc|#ddd|(Confirmed)}}
** {{fc|#9eb6e6|'''''CleanPlugin'''''}} (Boolean) - Indicates that the mod's plugin is clean. Dependent on ''HasPlugin''. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff80ff|''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. ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
* {{fc|#9eb6e6|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 16:05, December 19, 2014 (EST))
* {{Fc|salmon|'''''IsCore'''''}} (Boolean) - Indicates if a mod is CORE to the STEP experience. {{fc|#ddd|(Not Confirmed)}} (his is still a useful property that applies to all mods ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 10:49, December 16, 2014 (EST))
* {{fc|#ff6060|''AffectsFPS''}} (Boolean) - Indicates if a mod has a noticeable FPS impact. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''AffectsVRAM''}} (Boolean) - Indicates if a mod has a noticeable VRAM impact. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''PerformanceAvailable''}} (Boolean) - Indicates if a mod has a performance version available. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''QualityAvailable''}} (Boolean) - Indicates if a mod has a quality version available. {{fc|#ddd|(Confirmed)}}
* {{fc|#ff6060|''QualityItems''}} (object) - Multiple-instance template containing:
** {{fc|#ff6060|''QualityValue''}} (string) - Available graphical tiers or options available (2048, 1024, High, Low, etc.).
** {{fc|#ff6060|''AffectsFPS''}} (string) - Indicates any noticeable FPS impact (positive, negative, none).
** {{fc|#ff6060|''AffectsVRAM''}} (string) - Indicates any noticeable VRAM impact (positive, negative, none).
* {{fc|#9eb6e6|'''''ResourceHog'''''}} (Boolean) -Indicates that the mod tends to have a relatively high performance cost in relation to other mods.


Added reference to new [[Form:Mod Version]] and [[Template:Mod Version]]<br>
===== Recommendations =====
[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:51, October 16, 2012 (UTC)
* {{fc|#ff6060|''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]].
* {{fc|#9eb6e6|'''''Notes'''''}} (string) - Mod-specific information or special notes.
* {{fc|#9eb6e6|'''''Conflicts'''''}} (?) - Figure out some method to denote salient conflicts of ''particular'' interest.


: - Looks like Farlo created some more tables to hold our ideas about Form:ModTest, including the properties I set up as well as a couple of 'tentative' templates (thanks)
==Pack Attributes==
: - Broke out elements of Template:ModTest into Template:PerformanceImpact. Reason being that this is an important multi-faceted variable to track in and of itself. I see this being the info that basically qualifes the Property, 'AffectsPerformance' (sub-properties using 'AffectsPerformance via Internal Objects). Still thinking about designing a simple way to roll up testing results (including performance data) with SystemSpecs into a single form if possible.
===== Pack Info =====
:~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 07:56, November 5, 2012 (UTC)
* {{fc|#9eb6e6|'''''Author'''''}} (string) - The author(s) of the pack.
:: Associating SystemSpecs with the performance data shouldn't be too difficult.  The form will grab the user's name and simply apply their SystemSpecs declarations to the report itself. Basically: "TestReport#34/CPUProperty" = "User:Farlo/CPUProperty".  Thus we end up with the reports having a full set of specs themselves which means we don't have to include anything about the users while querying them and they will remain static even if the user updates their specs. ~[[User:Farlo|Farlo]][[File:User Farlo Sig.png|19px|link=User:Farlo]]<small>[[User talk:Farlo|Talk]]</small> 08:18, December 17, 2012 (UTC)
* {{fc|#9eb6e6|'''''FullName'''''}} (string) - Pack name.
* {{fc|#9eb6e6|'''''Description'''''}} (string) - Brief pack description.
* {{fc|#9eb6e6|'''''ForumTID'''''}} (string) - Specifies a URL created using the thread ID of the mod on the STEP forums.
* {{fc|#9eb6e6|'''''Version'''''}} (string) - Current version of the Pack.
* {{fc|#9eb6e6|'''''DLCRequired'''''}} (string) - (Optional) Indicates which DLC's are required by the Pack.
* {{fc|#9eb6e6|'''''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.
* {{fc|#9eb6e6|'''''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.
* {{fc|#9eb6e6|'''''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.
: {{fc|pink|{{fs|1.2em|Need to not turn headings into wiki text, as this breaks "right-click to edit" functionality!}} }}
* {{fc|#9eb6e6|'''''Description'''''}} (none/plaintext) - Introduction, long description, purpose and goals, author notes, etc.
:~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 06:23, November 21, 2012 (UTC)
* {{fc|#9eb6e6|'''''Pre-Installation Setup'''''}} (none/plaintext) - Explanation of any pre-requisite steps that need to be taken before installing the pack's mods.
:: Editing the Data Dictionary page is pointless as it is all form based and uses queries to pull everything together. So right-click to edit really doesn't do you any good in this scenario.
* {{fc|#9eb6e6|'''''Post-Installation Config'''''}} (none/plaintext) - Configuration instructions and anything else that should be done after installing the mods.  Also outro and special credits.
::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 08:28, December 17, 2012 (UTC)


= old stuff =
===== ModList =====
== Mod Properties ==
The mod list for the pack will define a number of the following:
* '''Unique ID''' - Not needed, as the Wiki page is the Unique ID.
* {{fc|#9eb6e6|'''''ModListObject'''''}} (object) - Multiple-instance template containing:
* '''Status''' - Not needed on the Wiki unless we wanted to implement bug tracking on the Wiki itself. Interesting to note that I have come across a really good example of using Semantic data and forms to do such a thing.
** {{fc|#9eb6e6|'''''Order'''''}} (number) - Order of the mod in the pack's list.
* '''Reason Rejected''' - Directly tied to use of '''Status''' above.
** {{fc|#9eb6e6|'''''ModName'''''}} (string) - Name of the mod.
* '''Active''' - Not needed, as setting a section to "blank" effectively marks the mod as not active.
** {{fc|#9eb6e6|'''''Notes'''''}} (string) - Pack-specific notes regarding the mod's installation.
* '''Short Mod Name''' - Not needed, as the Wiki page name is the short mod name.
* '''Section ID''' - Already being used (''current name is '''Section''' '')
* '''Section Name''' - Already being used (''current name is '''SectionDescription''' '')
* '''Core''' - Already being used.
* '''Baseline''' - Already being used.
* '''Impact''' - Already being used.
* '''Notes''' - Need to add this, but we need to decide if we only need the notes for the current release, or if we want to retain notes for all releases. I vote for current release only so it can be implemented in the Mod Form (''should be marked to be editable by administrators only'').
* '''Nexus ID''' - Already being used, but needs to change (''[http://forum.step-project.com/showthread.php?tid=929&pid=13731#pid13731 reference]'')
* '''Forum Thread ID''' - Already being used.
* '''Install Order''' - Implementation in the works.
* '''Conflicts''' - Now implemented in a bare-bones form, but not using the property yet. The property should name should be changed to '''Overwrites''' (''needs to be finished'')
* '''STEP''' - No idea what this is intended for.
* '''Mod Attributes''' - No idea what this is intended for.
* '''Nexus Link''' - Not needed, already determined by '''Nexus ID''' (''implementation will change to account for multiple external sources'').
* '''STEP Forum Link''' - Not needed, already determined by '''Forum Thread ID'''.
* '''Mod Name''' - Needs to be added, but should be changed to '''Full Mod Name'''.
* '''Mod Site Name''' - This or similar to identify the name of the primary site for downloading the Mod (''primarily used for labels and/or link text'').
* '''Mod Site ID''' - The ID of the Mod on the '''Mod Site Name'''.
:[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 22:20, 8 October 2012 (UTC)


:- RE: '''Status''' - Is "section" in reference to mod or PDF section? I assume the former, so it should be ModSection"" in that case
=====Pack-Specific Mod-Level Install Notes=====
:- RE: '''Section Name''' - That sounds like a great idea. I vote to track status in a "Semanticized" manner and teach our mod testers how to update ;) ... however, I see this datum as labels like "Accepted" "Denied", etc
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.  ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 14:33, February 12, 2014 (EST)
:- RE: '''Notes''' - Agree
: 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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 17:49, December 19, 2014 (EST)
:- RE: '''Conflicts''' - I definitely see use for a property, <nowiki>[[Member of conflict group::X]]</nowiki> Conflict groups are mod groups that share overlapping/associated conflicts and who "wins"
:: 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). ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 03:56, December 23, 2014 (EST)
:- RE: '''STEP''' - This would be STEP Section number ;)  
::: 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. [[User:Kelmych|Kelmych]] ([[User talk:Kelmych|talk]]) 22:42, February 12, 2014 (EST)
:- RE: '''Mod Attributes''' - This is mod type and anything else mod specific ... we have this covered already
:::: 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. ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 03:56, December 23, 2014 (EST)
:~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 03:19, 9 October 2012 (UTC)
::::: 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. [[User:TechAngel85|TechAngel85]] ([[User talk: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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 15:39, December 24, 2014 (EST)


::- In relation to "Section", mod section and PDF section are the same thing as a direct relation based on mod. This serves as a mapping specifically to section 2.X as it stands today. So as an example, Section=A is a direct mapping between the PDF (Section 2.A), and the Wiki (Category:Section_A). Semantically, it's the only section we care about, but it could be changed to ModSection to increase it's descriptiveness.
Subpages include nav links to parent, and adding subpage links to mod main page is simple (<code><nowiki>[[/subpage]]</nowiki></code>), 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. ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:07, December 16, 2014 (EST)
::- Conflicts aren't a group. Each individual Mod will have a list of mods that they conflict with, to mean that they overwrite some portion of that Mod. In fact, this should be changed to '''Overwrites'''. You can then query to answer questions like: What mods does ModA Overwrite? What mods overwrite ModA? ''([http://wiki.step-project.com/TestList example])''
::- As for over-arching STEP, I still don't see a use for storing this semantically.
::- Mod Type appears to be a label, not a Property. It should be removed from the list.
::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 09:05, 10 October 2012 (UTC)


:::- RE '''Section/STEP''' - STEP Guide "Chapters" correspond to STEP 1, STEP 2, ... STEP ''n''. Under each, we have Section #.A, Section #.B, ... Section #.''X''. Then we have Sub-Sections like #.X.#, etc. Given all of this, I do see value in semantic annotations for all, as I think that we still need to convey and encourage users to follow each step of the guide sequentially, and it will make interrelating portions of the guide more intuitive by adding those semantics ... this is where it seems intuitive to make use of subobjects (but I admit that this is pure intuition, as I do not yet realize the potential of subobject classification or even the other annotations for that matter!)
{{fc|#ddd|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??)}} ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 03:56, December 23, 2014 (EST)
:::- RE '''Conflicts/Overwrites''' - respectfully disagree. Specifically "resource conflicts" imply overwrites, while "data conflicts" imply ''overrides''. This is why it is helpful to provide info on install order ''and'' plugin order, hence "conflict groups". This allows the user to make educated decisions regarding customization --both in terms of installation and implementation.
This deserves some expansion. I'm wanting these options, but they need to be able to provide instructions, not just flags or categories:
:::- Do you (or anyone else) mind helping me flesh out the page according to these notes? We also need to be mindful of Thunderbolt data assets (@Fri .... hint, hint).
* {{fc|#ff6060|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
:::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 05:24, 11 October 2012 (UTC)
*: 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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk: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  ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 03:56, December 23, 2014 (EST)
* {{fc|#ff6060|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''FOMOD'''''}} - change current one to be an actual template for installation options (Mod-specific; this is doable for Mods and desirable I think ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk: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. 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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk: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).[[User:TechAngel85|TechAngel85]] ([[User talk:TechAngel85|talk]]) 00:00, December 31, 2014 (EST)
* {{fc|#9eb6e6|'''''BAIN'''''}} - change current one to be an actual template for installation options (Mod-specific; this is doable for Mods and ''may be'' desirable ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:TechAngel85|TechAngel85]] ([[User talk:TechAngel85|talk]]) 00:09, December 31, 2014 (EST)
* {{fc|#ff6060|'''''Manual Installation'''''}} (Mod-specific; This just part of the standard Mod notes I think ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
*: No reason for this, should not have a DD flag. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#ff6060|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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) [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#ff6060|'''''Incompatible mods'''''}}  (Mod/Pack specific; ... way too much maintenance and makes inferences about ''potential'' and n/a user-specific builds ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk: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, but not as a flag in the DD, better to enter manually. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 17:49, December 19, 2014 (EST)
** {{fc|#ff6060|'''''Patchable'''''}} - with or without instructions (Pack specific; unnecessary information that should be covered in the pack instructions ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
**: Would be in a section marking the mod for xEdit instructions. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:02, December 20, 2014 (EST)
** {{fc|#ff6060|'''''Unpatchable'''''}} - not possible to fix incompatibility (Pack specific; redundant with previous; unnecessary information that should be covered in the pack instructions ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
** {{fc|#ff6060|'''''Redundant'''''}} - mods that conflict that are completely redundant (Pack-specific?; Tn/aMI - too much n/a info ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
* {{fc|#9eb6e6|'''''MCM menu options'''''}} (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:TechAngel85|TechAngel85]] ([[User talk: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. [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:40, December 31, 2014 (EST)
* {{fc|#9eb6e6|'''''INI edits'''''}} (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:TechAngel85|TechAngel85]] ([[User talk:TechAngel85|talk]]) 00:35, December 31, 2014 (EST)
* {{fc|#ff6060|'''''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] ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:54, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''Skyproc'''''}} - with instructions for usage (Pack-specific; could be covered similar to FOMOD instructions but on on Pack pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 11:56, December 16, 2014 (EST) )
*: Should be something like '''Post-Install Patcher''' for Skyproc, Bashed Patch, and FNIS. Not really necessary though. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:54, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''Optimize'''''}} - actual instructions to optimize with DDSopt, etc (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:54, December 20, 2014 (EST)
* {{fc|#ff6060|'''''Merge ESPs'''''}} - a guide to merge the plugins together within the mod (Pack-specific; TMI, IMO ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk: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. 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. [[User:EssArrBee/FalloutNewVegas_MilleniasAdditionalWeapons#Merging_Millenias_Weapons|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:DoubleYou|DoubleYou]] ([[User talk: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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 20:59, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''Optional ESPs'''''}} - any esps to move to Optional ESPs (Mod-specific; could be covered similar to FOMOD instructions on mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:21, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''Hide files'''''}} - for specific instructions on hiding files (Pack-specific; could be covered similar to FOMOD instructions but on Mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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.[[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#ff6060|'''''Priorities'''''}} - to tell which mods should be above or below in priority for "conflicting" mods (Pack-specific; redundant with Pack mod list ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:21, December 20, 2014 (EST)
*:: This could also vary between pack authors, so probably not very useful. [[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 16:30, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''XEdit cleaning'''''}} (Mod-specific; could be covered similar to FOMOD instructions on Mod pages ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:21, December 20, 2014 (EST)
* {{fc|#ff6060|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 14:21, December 20, 2014 (EST)
* {{fc|#9eb6e6|'''''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 ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:DoubleYou|DoubleYou]] ([[User talk: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. [[User:TechAngel85|TechAngel85]] ([[User talk:TechAngel85|talk]]) 00:47, December 31, 2014 (EST)


::::- RE '''Sections''' - I have no problem with having the over-arching STEP's in the PDF. My point is that there is no benefit to having Sections available in the PDF as semantic data. The links in the guide will point to specific pages on the Wiki which can use Categories or sub-pages. There is nothing that needs access to this data that can't be accomplished via standard MW methods. In other words, you are talking about blobs of text, not records of data (with the Mod section being the exception).  
===Pack Implementation===
::::- RE '''Conflicts''' - I respectfully disagree back :P So first off, you are talking about adding a new set of data here. In terms of '''Overwrites''', it is definitely not a group. This is information stored on each specific Mod page containing the list of mods that it overwrites. '''Overwrites''' is also the only piece of data we need to aid in determining Mod Install Order. For '''Overrides''', I don't see the point of storing this information. Plugin order is already handled by BOSS, and quite frankly would consume far too much of our time to maintain.
====Issues with Current Implementation====
::::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 05:28, 11 October 2012 (UTC)
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 ''un''desired 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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. [[User:TechAngel85|TechAngel85]] ([[User talk:TechAngel85|talk]]) 00:58, December 31, 2014 (EST)


:::::- Good points all. I have been working on a thought exercise after having read some info on SemanticForms. Take a look at the new Page.
====New Implementation====
:::::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 06:09, 11 October 2012 (UTC)
* 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.


::::::- Like the new layout and org notes. I just wonder why we are not using the conventional/recommended property nomenclature (e.g., "Mod created by" rather than "Author"). As I understand, this is done to remind users of the context of query results. My feeling is that the SMW gurus that recommend this methodology have insights that we do not, and I am inclined to trust them.
====Proposed New Implementation====
::::::- What about Changelogs and recent changes? Since these are also mod properties, handling them as Record-Type Properties just makes sense to me.
* '''Semantic Form/Template to add pack page 'header' with basic pack properties''' (much like what currently exists, but augmented with all finalized properties).
::::::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 16:06, 11 October 2012 (UTC)
* '''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 <nowiki>[[Mod Name]]</nowiki> 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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:16, December 19, 2014 (EST)
*:: I agree, it would clutter mod pages and instructions may be different for different packs. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:TechAngel85|TechAngel85]] ([[User talk: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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk: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! [[User:DoubleYou|DoubleYou]] ([[User talk: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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk: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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|talk]]) 15:03, December 20, 2014 (EST)
*::: That makes sense after re-reading. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk: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.  ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|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. [[User:TechAngel85|TechAngel85]] ([[User talk: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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk: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 <nowiki>[[Mod Name]]</nowiki> already exists, and that the mod page contains no info relating to the pack in question:
<pre>
{{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
</pre>


:::::::-For starters, their recommendation to name Properties to fit a natural query language is primarily with respect to article management where a wider user base will be maintaining those articles. That can be fine to use them in that case, but they also introduce problems requiring many variables to answer questions. As a small example, for Author, you would most likely have a "Has Author" Property to contain the name, and a "Is Author" Property of type boolean. Wiki authors would need to remember to set both on the appropriate pages concerning an Author. Secondly, we don't fit into the article management mold. We are using these to maintain records of data that are handled by forms, so the naming honestly doesn't matter from a user base perspective. For every example I find out there that uses a natural language naming style (though they often mix styles), I find one that uses a program variable naming style. Their use is typically in relation to what the data is being used for (article management or records of data to generate pages). There is no hard and fast rule. We can have a group discussion on this if you like, but for our purposes, I'm not a fan.
* 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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:16, December 19, 2014 (EST)
:::::::-To expand on the above, I prefer to have template field names as concise as possible. As an example, we could keep the semantic Property ModFullName, but for the template we don't need to qualify it as modFullName (I'm using first letter lower case to distinguish between template and Semantic Properties btw), as it's already given that it's the Full Name of a Mod based on it's association with Template:Mod.
* 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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:15, December 19, 2014 (EST)
:::::::-Changelogs/recent changes are already handled by the Updates structure as subpages. A query already exists to pull this information into the page, as well as provide a link to get the entire list. I had forgot to add the template that is being used to the list, but just added it. [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:38, 11 October 2012 (UTC)
*: 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. [[User:EssArrBee|EssArrBee]] [[File:SoloandChewy.jpg|20px|link=User:EssArrBee]] ([[User_talk:EssArrBee|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. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk: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? ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk:z929669|Talk]] 03:37, December 23, 2014 (EST)
*:::: Good point. -- [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 18:26, January 3, 2015 (EST)


::::::::- I really think that we ought to prefix all or none of the "Mod Properties" with "Mod". It is currently inconsistent and irrelevant whether or not an attribute will be used elsewhere.  
=== Packs - ForumTID ===
::::::::- Need to change "Notes" to "ModRecommendations"
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) ~[[User:Farlo|Farlo]][[File:User Farlo Sig.png|19px|link=User:Farlo]]<small>[[User talk:Farlo|Talk]]</small> 20:32, July 16, 2013 (MDT)
::::::::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 14:56, October 16, 2012 (UTC)


:::::::::- If you want consistency, then I have to say that "Mod" should be dropped. Some of those properties can be used for more than Mod information, and it makes no sense to duplicate Property names that would contain the same relevant information, just for different products. You also lose the very useful ability to autocomplete based on already entered information.
==Guide Attributes==
:::::::::- Same as above in terms of prefixing with "Mod". As for the name, "Notes" is more generic and can cover use in other "products", but changing is still fine. Just without "Mod".
===== Guide Info =====
:::::::::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 19:21, October 16, 2012 (UTC)
* Guide intent, description and background
* Guide-specific procedures
* Guide-specific INI settings
* Summary
* Credits


::::::::::- OK, I then favor dropping the "Mod" prefix on all, as that adds specificity where generalities may be more useful (it also shortens things up a bit). As long as redundancies in your autocomplete fieds aren't an issue. This is just as good a solution, because the current inconsistency was just bugging me :P
==New STEP Categories==
::::::::::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 20:25, October 16, 2012 (UTC)
{{Sidebox|float=left|width=30|title=Something like this...|text=
A - Configuration
:ENBoost
:Simple Borderless Window
B - Script Extenders
:Skyrim Script Extender
C - Fixes<br />
D - Interface<br />
E - Conflicting Graphics<br />
F - Landscape & Environment<br />
G - Characters & Creatures<br />
H - Clothing & Equipment<br />
I - Effects<br />
J - Clutter & Miscellaneous<br />
K - Sound<br />
L - Gameplay<br />
M - Animations<br />
:[https://stepmodifications.org/wiki/XP32_Maximum_Skeleton XPMS]
:Realistic Ragdolls and Force
:FNIS
:[https://stepmodifications.org/wiki/No_Spinning_Death_Animation No Spinning Death Animation]
N - Patches
:Bashed Patch
:STEP Patches}}


:::::::::::- I'll update the main page, Property names, and templates in a few. Already changed "Note" to "Recommendations" on the main page, but I still need to change the Property and template.
<big><big><big>'''←'''</big></big></big>I propose that we split [https://stepmodifications.org/wiki/Category:ModSection_J Section J - Animations and Effects] into two different categories. Section J should include only mods that add/modify in-game effects, like [https://stepmodifications.org/wiki/Burn_and_Freeze_Shock_Effects 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 [https://stepmodifications.org/wiki/XP32_Maximum_Skeleton XPMS], and raw animations, like [https://stepmodifications.org/wiki/No_Spinning_Death_Animation 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? --[[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 01:30, February 12, 2014 (EST)
:::::::::::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 20:34, October 16, 2012 (UTC)


== STEP Guide Properties ==
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. --[[User:Essarrbee|Essarrbee]] ([[User talk:Essarrbee|talk]]) 23:22, February 12, 2014 (EST)


* GuideReleaseMajor - Agree, not needed.
:I concur. --[[User:DoubleYou|DoubleYou]] ([[User talk:DoubleYou|talk]]) 00:35, February 13, 2014 (EST)
* GuideReleaseMinor - [Is minor release] Type=String (''the name of the property dictates it as Type Boolean. I don't see how this gains us anything, can you give an example of what you expect to use it for.'')
{{Sidebox|float=right|width=30|title=Without messing up catagories...|text=
* GuideSection - Based on my previous comments, I don't see this as necessary. The blobs of text that are going to be placed in the Wiki can be identified by Category.
STEP 1:<br />
* GuideChangeLog - Prefer to manage this as sub-pages. Refer to Updates for individual Mods as a perfect example.
C - Utilties
* GuideRecentChanges - How does this differ from a Change Log?
:This would be the current 2.B
* GuideImage - Can you expand on what this is to be used for?
STEP 2:<br />
A - Ignore section or leave it for text<br />
B - Ignore section or leave it for text<br />
C - Script Extenders
:Skyrim Script Extender
:ENBoost
:Simple Borderless Window
D - Fixes<br />
E - Interface<br />
F - Conflicting Graphics<br />
G - Landscape & Environment<br />
H - Characters & Creatures<br />
I - Clothing & Equipment<br />
J - Animations & Effects<br />
K - Clutter & Miscellaneous<br />
L - Sound<br />
M - Gameplay<br />
N - Patches
:[[Dual Sheath Redux]]
:[https://stepmodifications.org/wiki/XP32_Maximum_Skeleton XPMS]
:FNIS
:Bashed Patch
:STEP Patches}}


I think in some cases you are trying to force data into Semantic Properties when there is no need to. Particularly when you start trying to associate large amounts of data, Semantic Properties are just not efficient enough. There is a lot we can still accomplish with typical Wiki structure. Mod Updates is a perfect example of tying information together without needing to use Symantic Properties on a grand scale (Update date is being used, but only for the purpose of determining the latest update). In other words, don't think of this exercise as creating an application (I was stuck in that mindset in the beginning myself), as the application is already written (MediaWiki). We are just extending it in order to store data in a different way where it makes sense.
<big><big><big>'''→'''</big></big></big>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. --[[User:Essarrbee|Essarrbee]] ([[User talk:Essarrbee|talk]]) 13:42, February 13, 2014 (EST)
[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 21:13, 11 October 2012 (UTC)
: 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. ~[[User:z929669|z929669]] [[File:Ixian_Insignia.png|20px|link=User:z929669]] [[User talk: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. --[[User:Essarrbee|Essarrbee]] ([[User talk:Essarrbee|talk]]) 22:13, February 13, 2014 (EST)
:OK, we can table these ideas unless/untill it makes sense to revisit down the road. At least we have a data dictionary for reference and to build out if/when things do get more complex. Since we are adding Semantic associations here, it may be worth creating a table of categories we are using and plan to use as well as their purpose. This will be both instructive and constraining (in a good way).
:~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 23:11, 11 October 2012 (UTC)
 
::-I agree to keep the current items on the page for reference. A few of those I just questioned their use as I'm not sure what you intended them for, but that doesn't mean they may not be useful. As for documenting Categories, I used the main header for Form:Mod to list what is being used, but then it is much simpler than what the PDF structure will be. Do we want to break information out into sub pages? [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 23:49, 11 October 2012 (UTC)
::-I just thought of something that is a good example for Property use even when it's not needed. Technically we don't need ModSection as a Property, as a query constraint can be placed on the Section Category itself. But, it does provide something very useful in that the Property contains "Allows value" declarations which gives us the ability to have a dropdown that can only contain those values. Unfortunately the form still requires an update for the hints to the right of the input, but at least logic is kept to minimum, and forgetting to update the hints list won't prevent successful use of the form. [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 00:10, 12 October 2012 (UTC)
 
:::- You should know that many of my ideas are founded in intuition and instinct. I throw them out there into the blogoshere hoping that they will land somewhere useful or grow into something useful. Surprisingly, this works more than one might think :P
:::-Allows value is a case in point I suppose, as I can see how this feature would help in the field constraints department. [http://semantic-mediawiki.org/wiki/Help:Inferencing SMW Inferencing] has some interesting implications, and I am beginning to wonder if Properties are not almost always better ''substitutes'' for Categories, as the former has fewer restrictions. My question is ultimately "when to use a category in a SMW?"
:::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 04:10, 12 October 2012 (UTC)
 
::::- I hear you on intuition. I've learned to follow those gut feelings, and agree that while they don't always lead to the right way, it can cause those A-Ha moments (as I call them) that lead to potential solutions.
::::- I had read that page early on, and they make some good points. But the points are specific to a very large Wiki (Wikipedia) where Categories have become too lax, and the depth of information is so large that it just doesn't fit well into a tiered Category structure, thus losing useful association. I don't see Properties offering any greater control as long as the Categories have meaning and focus (which is the only time SMW provides any value). I highly doubt we'll ever have the problem that Wikipedia faces today. When to use Categories over Properties? When they share the same meaning, such as the proposed Guide Section Property. Consequently, Categories also have an edge on Properties in that you can navigate the Wiki via Categories. You can't via Properties. The only thing I've found that probably allows getting to data based on Properties is Semantic Drilldown, but it's also a whole different way of getting to the data you want. Some will like it, some won't. Cases can be made either way, I just feel that SMW shouldn't be treated as the holy grail. I'm basing my questions and doubts on proposed Properties, because I ask myself if MW can already handle the intended use. If it can, why not use what is already there instead of adding to the overhead? This extends to the better alternative for Overwrites over using subobjects. It has been stated that they suffer a performance cost, and in general you don't want more than 4 associated properties in an object. I have no idea what the extra overhead is like when you start having multiples of the same object on a page. I just play it safe by asking that key question. The closer you can implement a solution to core MW the better, I say. [[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 07:20, 12 October 2012 (UTC)
 
:::::- I can buy all of those arguments. Good practice: MW when it works and SMW when MW doesn't cut it. I also think that we should continue to make use of cats and subcats.
:::::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 20:59, 12 October 2012 (UTC)
 
::::::- Totally agree. We need to figure out what Categories make sense for Sections as far as naming. Would be nice to have the sections for Mod's fit in seamlessly.
::::::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 23:22, 12 October 2012 (UTC)
 
== Semantic Data Mappings (intro) ==
 
- Please define "sub-headings" as you reference them in the intro.
<br />
- Also confused about contexts of "new data structure" and "second-level heading".  
 
Would you care to clarify or elaborate?
<br />
~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 04:41, October 17, 2012 (UTC)
 
:- Talk about weird. I was gong over the entire main page making updates, and actually just got done updating the intro to clarify things as I too felt it was lacking (made sense to me when I wrote it late at night haha). Then I come into the talk page and read this. :P Great minds think alike. If anything needs to be added or worded differently (have it), or something still isn't clear (let me know).
:[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 10:28, October 17, 2012 (UTC)
 
::- Thanks for cleaning out the confusing elements and adding the org directions for future build-out. This is really a great reference now for getting a grasp of the Semantic relationships and key data elements involved in this process ... I just love good documentation :D
::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 15:54, October 17, 2012 (UTC)
 
:::- @s4n ... could you define "multiple-instance template" and the relationship of property, sub-properties and internal objects defined by Template:ModOrder?
:::~[[User:z929669|z929669]][[File:Ixian_Insignia.png|30px|link=User:z929669]][[User talk:z929669|Talk]] 03:45, October 23, 2012 (UTC)
 
::::A "multiple-instance template" just means that a template is intended to be callable multiple times within a page. This can be anything from applying formatting to text that would be too tedious to type out for each occurrence, or for maybe producing a list item on each call. In relation to Semantic Forms, a multiple-instance template allows for the mechanism of adding new entries in the Form (such as adding a new Gallery item in Form:Mod). In order to make the form aware of a multiple-instance template, the parameter "multiple" must be added to the form declaration for the given template. Example:
<nowiki>{{{for template:ModList|multiple}}}</nowiki>
::::This tells the form that the template '''ModList''' can exist multiple times in the page, and will add a button for creating another template call in the resulting page.
::::You can also use a multiple-instance template to feed multiple pieces of data that it returns to another template, which is what I'm doing in all of the Forms that exist currently. If you were to do this manually, it would look something like the following:
<nowiki>
{{ParentTemplate
|parentfield={{ChildTemplate
|childfield1=some data}}{{ChildTemplate
|childfield1=some other data}}
}}</nowiki>
::::This is how Form:STEP Version is setup. The field '''mods''' in ModOrder is defined to hold a template. The form declaration for ModList is then specified as "multiple" and told that its contents should be placed inside the field ModOrder[mod], which then produces a result similar to the example above when the form is saved.
::::As for the Internal Object, the first parameter needs to be a Property of type Page which points the object to the page. I labeled the other properties as sub properties as they are set in relation to the Internal Object. This allows querying on the object itself, and then asking for the properties that are associated with it. In terms of ModOrder, this is the only way to be able to query the object that contains say ModName=Skyrim_HD and be able to ask what the Version is, without that property being set on the Skyrim_HD page itself.
::::[[User:Stoppingby4now|Stoppingby4now]] ([[User talk:Stoppingby4now|talk]]) 07:15, October 23, 2012 (UTC)
 
== Mod Testing Walkthrough ==
Assuming that mod testers will have a detailed guide as to how to set up their base system to prepare for mod testing (SIS should be specifically employed so that testers can save their current profiles and set up two additional profiles from scratch as we define then. This should be a strict protocol and prerequisite to begin official testing for STEP.
# Load up the wiki SystemSpecs Form and system specs (including Skyrim DLC info).
# Navigate to the mod source
# Read through the documentation and skim through the associated forum until acquainted with the mod's current status from the perspectives of author and users.
# Load up a new wiki Form instance in a new browser tab.
# Enter the mod name and source information.
# Download the mod and check any additional documentation within the package if any.
# Check the documentation properties off as they apply (if the documentation property has internal-object sub-properties, can it be set to "auto tick" based upon whether or not all of the sub-property Booleans are ticked or not?)
# Check the package structure and tick off whether or not it is BAIN compatible (testers will need to understand these criteria ... link to WBG section?), and repack if necessary and '''create a BCF'''.
# Tick off whether or not the mod has scripts.
# Tick off whether or not the mod has loose files (as opposed to BSA?).
#
#Install mod into defined game base using Wrye bash
# TBC ...
 
<headertabs/>

Latest revision as of 18:05, September 17, 2021

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

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[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.
    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[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.
    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[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]

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"