ACCEPTED STEP Patches

EssArrBee · January 5, 2015

I think doing a separate page and then linking to it in step 2.A would be the best way to do this. I made a page with all the stuff, but damn if the requirements aren't long for STEP Extended. https://wiki.step-project.com/STEP_Patches_Requirements

Someone with a penchant for style can put some color or something on that page since it's pretty dull.

z929669 · January 5, 2015

If you were so kind as to add the necessary info, I'll mess with it .. and create your flags (you can query using the Booleans or the strings the same way, so I guess I would rather use one property to hold the 'requirement' info). I'll give s4n a chance to respond first though, as he may have ideas about all of this.

stoppingby4now · January 5, 2015

It seems to me that this kind of information would be useful to all packs. This information is not Mod specific, but rather Pack specific (which is inherited via the Patch). In this case, a Pack consumes Mods and Patches, but Patches also consume Mods.

To that end, it would be better to have a Patch page (similar to Mod page) that allows one to identify all of the mods required for it. An alternative would be to create mod pages for the patches and allow for identifying it is a patch, and then required mods could be linked. I would prefer the former, as there are a lot of attributes on the Mod page that aren't relevant for Patches.

By having a separate Patch page, specific instructions can also be added which, I hope is obvious, are specific to the Patch and not the Mods.

z929669 · January 5, 2015

Well, it is arguably a Pack-specific Mod attribute that naturally fits at the mod level with respect to its applications like IsCore and Merged. More importantly, these attributes relate to STEP, so there is relevance in creating these as mod attributes.

The alternative would be to include mod flags using a mod list name query that would also need to be manually maintained using some other attribute or by explicitly defining the mod list at the Patch/Pack level. I can see the performance/logic rationale for using the relatively small Patch/Pack 'table' to store this info than the much larger Mod 'table'.

It just seems more intuitive and simple to implement this as a mod attribute, else we can just move all three of those properties to the upcoming Pack/(Plugin?) revised template(s). A fast solution is to just use the current structure ... your call though if you want to develop that real quick ;)

Main question is how to store the info at the mod level ... two binary or one text property(s)?

stoppingby4now · January 5, 2015

Well, it is arguably a Pack-specific Mod attribute that naturally fits at the mod level with respect to its applications like IsCore and Merged. More importantly, these attributes relate to STEP, so there is relevance in creating these as mod attributes.

Correct, which means it is a Pack detail, not a Mod detail. You don't store information about consumers in low level data objects. The Merged attribute would go away with implementing Patch pages, and IsCore is a Mod unique attribute within the system since all Packs build upon STEP:Core. Recommendations are the only other information that should be decoupled from STEP and be unique to the Mod. The STEP Guide would then contain the specific instructions for Mods like Packs will.

To drill down a bit deeper, we are also now introducing Patches. If I were writing a software program from scratch to manage all of this, I would naturally end up with the following objects:

Mod - Entity that implements a Mod (and should ONLY describe a Mod)

Patch - Container that implements a collection of Mods (and should ONLY describe a Patch)

Pack - Container that implements a collection of Patches and Mods

A Mod object should only contain information that is unique to the Mod. A Patch would be a container that manages a list of Mods and has information that is unique to the Patch. A Pack would be a container that manages a list of Patches and Mods. In other words, Packs rely on Patches and Mods, and Patches rely on Mods. Not the other way around.

I would not store Patch or Pack specific information in the Mod, because it breaks the purpose of the Mod object as being a singular collection of information that specifically describes the Mod. If the Mod disappears (extreme example), all information about the Patch or Pack it stores is lost. That's not good. The more likely scenario is a Patch or Pack disappears. If done correctly, it's simply a matter of destroying the right object (or page in this case), and everything is good. Store top level data in low level objects, then you wind up with additional tasks to clean up the data. That makes no sense.

Since Packs consume Patches and Mods, and Patches consume Mods, reversing the dependency at any level makes it much harder to maintain and control data. It's why I'm against storing Pack specific instructions on Mod pages, they just don't belong there. They are Pack details, not Mod details.

The alternative would be to include mod flags using a mod list name query that would also need to be manually maintained using some other attribute or by explicitly defining the mod list at the Patch/Pack level. I can see the performance/logic rationale for using the relatively small Patch/Pack 'table' to store this info than the much larger Mod 'table'.

You would do the same thing we do for STEP now in regards to it being a Pack that contains a list of Mods. You can now have a Patch that contains a list of Mods. In turn, you would then have a Pack that would contain a list of Patches and Mods.

It just seems more intuitive and simple to implement this as a mod attribute, else we can just move all three of those properties to the upcoming Pack/(Plugin?) revised template(s). A fast solution is to just use the current structure ... your call though if you want to develop that real quick ;)

It would be faster to implement as a Mod attribute, but that doesn't make it right.

I very much disagree that it is more intuitive. It breaks dependencies by causing data that does not uniquely describe a Mod to remain should a dependent object be deleted (Patch or Pack), and disassociates information further from the object that it does uniquely represent.

It may seem simple at first, but it's an illusion shrouded in speed of implementation. You're still breaking dependencies, causing data leakage by separating said data farthest from the object that it naturally describes, and also creates unnecessary editing tasks. Why would I want to individually edit 10 Mods to indicate that they are required for a Patch, when I can edit one Patch and indicate that it requires 10 Mods?

If it doesn't uniquely describe a Mod that ALL consumers will universally use, then it's not a Mod attribute. Author, Name, URL are all unique to the Mod. "Must be installed if using Patch A" and "Must be installed if using Patch B" are not unique to the Mod. They are unique to the respective "Patches".

Main question is how to store the info at the mod level ... two binary or one text property(s)?

Main answer is, neither, because the information doesn't belong there. :P

EDIT: I can work getting a Patch implementation setup.

Muladhara86 · January 7, 2015

I've been using the STEP: Core patch out-of-the-box, and I noticed that TES5Edit is showing errors in the .esp

[00:00] WPNSwingBlunt1Hand [sNDR:00105D43]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNLeftHandSheathe [sNDR:00101F43]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNLeftHandDraw [sNDR:00101F42]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNImpactBladeVsFleshDraugr [sNDR:000F600E]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNBlunt2HandSheathe [sNDR:000E4F11]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlunt2HandDraw [sNDR:000E4F10]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNImpactBlunt2HandVsFlesh [sNDR:000E4CAD]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNSwing2Hand [sNDR:000E4CAC]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNSwingUnarmed [sNDR:000C06D1]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNUnarmedDraw [sNDR:000C06CF]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNImpactBlade2HandVsFleshSD [sNDR:000949D3]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNAxe2HandDrawSD [sNDR:0006036A]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNSwingBladeAxeSD [sNDR:0003F209]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] AMBWaterfallLargeDungeonLPSD [sNDR:0003E48D]

[00:00] SNDR \ GNAM - Category -> [0B065871] < Error: Could not be resolved >

[00:00] WPNStaffHandSheatheSD [sNDR:0003DE2D]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNStaffHandDrawSD [sNDR:0003DE2C]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNMace1HandDrawSD [sNDR:0003DE2A]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] AMBWaterfallMediumDungeonLPSD [sNDR:0003DE1F]

[00:00] SNDR \ ONAM - Output Model -> Found a ARMA reference, expected: NULL,SOPM

[00:00] SNDR \ GNAM - Category -> [0B065871] < Error: Could not be resolved >

[00:00] WPNAxe1HandDrawSD [sNDR:0003DDB7]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBowSheatheSD [sNDR:0003D882]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBowDrawSD [sNDR:0003D78C]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlade1HandSmallSheatheSD [sNDR:0003CEDB]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlade1HandSmallDrawSD [sNDR:0003CED9]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] AMBWaterfallLargeDistantLPSD [sNDR:0003C8EE]

[00:00] SNDR \ GNAM - Category -> [0B065871] < Error: Could not be resolved >

[00:00] WPNBlade2HandSheatheSD [sNDR:0003C8AA]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlade2HandDrawSD [sNDR:0003C8A9]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNImpactAxeVsFleshSD [sNDR:0003C835]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNImpactBluntVsFleshSD [sNDR:0003C824]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNImpactBladeVsFleshSD [sNDR:0003C74D]

[00:00] SNDR \ ONAM - Output Model -> [0B033B60] < Error: Could not be resolved >

[00:00] WPNSwingBladeMediumSD [sNDR:0003C730]

[00:00] SNDR \ ONAM - Output Model -> [0B04893B] < Error: Could not be resolved >

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlade1HandSheatheSD [sNDR:0003C72F]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] WPNBlade1HandDrawSD [sNDR:0003C72E]

[00:00] SNDR \ GNAM - Category -> [08001829] < Error: Could not be resolved >

[00:00] [REFR:0007C69C] (places [09030B1B] < Error: Could not be resolved > in GRUP Cell Temporary Children of [CELL:0000B285] (in Tamriel "Skyrim" [WRLD:0000003C] at 37,25))

[00:00] REFR \ NAME - Base -> [09030B1B] < Error: Could not be resolved >

[00:00] [REFR:000FE8C0] (places [0903261B] < Error: Could not be resolved > in GRUP Cell Temporary Children of [CELL:000038B8] (in Tamriel "Skyrim" [WRLD:0000003C] at 28,38))

[00:00] REFR \ NAME - Base -> [0903261B] < Error: Could not be resolved >

[00:00] [CELL:00009830] (in Tamriel "Skyrim" [WRLD:0000003C] at 29,-21)

[00:00] CELL \ XCWT - Water -> [09002DAE] < Error: Could not be resolved >

[00:00] [CELL:00009811] (in Tamriel "Skyrim" [WRLD:0000003C] at 29,-20)

[00:00] CELL \ XCWT - Water -> [09002DAE] < Error: Could not be resolved >

[00:00] HalfMoonMillExterior02 [CELL:00009B7B] (in Tamriel "Skyrim" [WRLD:0000003C] at -11,-14)

[00:00] CELL \ XCWT - Water -> [09002DAE] < Error: Could not be resolved >

[00:00] WeatherKarthspireRedoubt [REGN:00106631]

[00:00] REGN \ Region Data Entries \ Region Data Entry \ RDSA - Sounds \ Sound \ Sound -> [0B068385] < Error: Could not be resolved >

[00:00] WeatherKarthspireRedoubt [REGN:00106631]

[00:00] REGN \ Region Data Entries \ Region Data Entry \ RDSA - Sounds \ Sound \ Sound -> [0B06530C] < Error: Could not be resolved >

[00:00] WeatherKarthspireRedoubt [REGN:00106631]

[00:00] REGN \ Region Data Entries \ Region Data Entry \ RDSA - Sounds \ Sound \ Sound -> [0B053027] < Error: Could not be resolved >

[00:00] WeatherKarthspireRedoubt [REGN:00106631]

[00:00] REGN \ Region Data Entries \ Region Data Entry \ RDSA - Sounds \ Sound \ Sound -> [0B046E4D] < Error: Could not be resolved >

[00:00] DLC1BoltDwarvenExplodingShock "Exploding Dwarven Bolt of Shock" [AMMO:0300F1B9]

[00:00] AMMO \ Model \ MODS - Alternate Textures \ Alternate Texture \ New Texture -> [0A005739] < Error: Could not be resolved >