Project talk:Data Dictionary: Difference between revisions
No edit summary |
No edit summary |
||
Line 111: | Line 111: | ||
:::: IMO we should just track the file's optimization, they can be whatever resolution the author wants, unless I'm missing something about them being "too large" (is that a thing?). Unless everything is optimized it shouldn't be tagged as such. ~[[User:Farlo|Farlo]][[File:User Farlo Sig.png|19px|link=User:Farlo]]<small>[[User talk:Farlo|Talk]]</small> 23:44, July 16, 2013 (MDT) | :::: IMO we should just track the file's optimization, they can be whatever resolution the author wants, unless I'm missing something about them being "too large" (is that a thing?). Unless everything is optimized it shouldn't be tagged as such. ~[[User:Farlo|Farlo]][[File:User Farlo Sig.png|19px|link=User:Farlo]]<small>[[User talk:Farlo|Talk]]</small> 23:44, July 16, 2013 (MDT) | ||
:::: [[User:Kelmych|Kelmych]] ([[User talk:Kelmych|talk]]) 17:12, November 16, 2013 (EST) Based on comments about the STEP Mod Texture table and experience using this table in developing and testing a batch file for bulk optimization, I feel that the interpretation of the flag that Z recommends is the correct one; it should be one flag that means it should not be run through DDSopt without a very good reason. The revised STEP Mod Texture table in the DDSopt guide has this flag (column 2). So far the mods I've evaluated and that have this flag as Yes don't need normal map resolution changes. | :::: [[User:Kelmych|Kelmych]] ([[User talk:Kelmych|talk]]) 17:12, November 16, 2013 (EST) Based on comments about the STEP Mod Texture table and experience using this table in developing and testing a batch file for bulk optimization, I feel that the interpretation of the flag that Z recommends is the correct one; it should be one flag that means it should not be run through DDSopt without a very good reason. The revised STEP Mod Texture table in the DDSopt guide has this flag (column 2). So far the mods I've evaluated and that have this flag as Yes don't need normal map resolution changes. | ||
=== Mods - Optimization-related Data === | |||
[[User:Kelmych|Kelmych]] ([[User talk:Kelmych|talk]]) 17:39, November 16, 2013 (EST) A few months ago I changed the information included in the STEP Mod Texture table in the DDSopt guide based on comments from some users who said it the entries needed to be easier to interpret while making decisions about optimization parameters and choices. I feel that the fields for mod-specific data about optimization should actually be in the Mod Data Dictionary and the data itself entered in a set of parameters on a Mod page, perhaps in an Optimization tab. There would also need be a new template so the data could be assembled to create a new version of the STEP Mod Texture table in the DDSopt guide. The new flags and data element I suggest are shown below. | |||
=== Mods - LoreFriendly === | === Mods - LoreFriendly === |
Revision as of 22:39, November 16, 2013
New Properties for STEP Guides - WIP (Discussion Page)
Following is a work-in-progress list of current and proposed attributes that can be associated with mod pages. Feel free to add anything you might think is useful. Let's try to keep it organized, so group similar or related properties as best you can. Note that Baseline has been removed from this list on purpose, that should be a Pack attribute based on the Pack's guidelines. ~FarloTalk 19:56, July 15, 2013 (MDT)
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.
Discussion
Mods - Description
Proposed adding Short Mod Description (1 sentence, possibly from the Nexus API); currently this isn't in either the mod page or the STEP guide. It would be hard to include this in a STEP guide (core or pack) since it doesn't fit well in a multi-column format like those used in the guide.
Mods - Category
Proposed change to broad categorization of the mod (NOT the STEP section, similar idea to the Nexus categories but hopefully with categories more relevant to STEP) ~FarloTalk 18:20, July 16, 2013 (MDT)
Mods - IsOptimized
The flag is somewhat problematic since it applies only to textures and can be hard to verify especially for non-core mods. Moreover, we may still want to separately optimize/reoptimize the normal maps even if the color map textures are adequately optimized. ~Kelmych Talk 12:26, July 16, 2013
- I think that this is a good flag for things that really should not be run through DDSopt for whatever reason. We can change the property and tag names easily enough if necessary. ~z929669 Talk 15:21, July 16, 2013 (MDT)
- What should we do if the color map textures are optimized but the normal maps are too large. Should there be tgwo flags, or just ignore the normal map issues? Kelmych (talk) 21:11, July 16, 2013 (MDT)
- I'd say keep only one flag. Textures that are already optimized won't be affected anyway. We can add exceptions to the INI where there are specific use cases that might get borked. ~z929669 Talk 00:50, July 18, 2013 (MDT)
- IMO we should just track the file's optimization, they can be whatever resolution the author wants, unless I'm missing something about them being "too large" (is that a thing?). Unless everything is optimized it shouldn't be tagged as such. ~FarloTalk 23:44, July 16, 2013 (MDT)
- Kelmych (talk) 17:12, November 16, 2013 (EST) Based on comments about the STEP Mod Texture table and experience using this table in developing and testing a batch file for bulk optimization, I feel that the interpretation of the flag that Z recommends is the correct one; it should be one flag that means it should not be run through DDSopt without a very good reason. The revised STEP Mod Texture table in the DDSopt guide has this flag (column 2). So far the mods I've evaluated and that have this flag as Yes don't need normal map resolution changes.
- I'd say keep only one flag. Textures that are already optimized won't be affected anyway. We can add exceptions to the INI where there are specific use cases that might get borked. ~z929669 Talk 00:50, July 18, 2013 (MDT)
- What should we do if the color map textures are optimized but the normal maps are too large. Should there be tgwo flags, or just ignore the normal map issues? Kelmych (talk) 21:11, July 16, 2013 (MDT)
Kelmych (talk) 17:39, November 16, 2013 (EST) A few months ago I changed the information included in the STEP Mod Texture table in the DDSopt guide based on comments from some users who said it the entries needed to be easier to interpret while making decisions about optimization parameters and choices. I feel that the fields for mod-specific data about optimization should actually be in the Mod Data Dictionary and the data itself entered in a set of parameters on a Mod page, perhaps in an Optimization tab. There would also need be a new template so the data could be assembled to create a new version of the STEP Mod Texture table in the DDSopt guide. The new flags and data element I suggest are shown below.
Mods - LoreFriendly
Proposed removal: not a whole lot of meaning for most mods and isn't well defined. Also mostly useless for our purposes. ~FarloTalk 18:20, July 16, 2013 (MDT)
Mods - IsClean/HasPlugin
Proposed: Fully specify if mod has plugins and that they are clean. Also, disambiguate clean plugins from clean uninstall (or eliminate clean uninstall altogether)
Mods - IsCore
Proposed: Remove, core mods -- will be in STEP:Core, this attribute isn't tied to the mod itself.
Mods - FPS and VRAM
Proposed: should have way to indicate whether effect is positive or negative ~Kelmych Talk 12:26, July 16, 2013
- Only Vano89's mod positively impacts performance, so this really denotes a negative impact. ~z929669 Talk 15:25, July 16, 2013 (MDT)
- But that might not be true for much longer, what if someone made a "craptastic computer pack", it might be nice to know that a mod has a positive effect. I think a choice of positive/none/negative would be well suited. ~FarloTalk 18:20, July 16, 2013 (MDT)
- I was thinking about relative improvements compared to some STEP baseline, in which case a mod that reduces quality a small amount but improves FPS a lot might get a positive check here. Skyrim Performance Plus would certainly get a plus here also. Kelmych (talk) 21:11, July 16, 2013 (MDT)
- When Z, Stopping, and I were talking we kind of came to the conclusion that baseline wouldn't be a universal aspect since packs can target differing computer ranges. The AffectsFPS and AffectsVRAM tags would then be compared to Vanilla; for example an HD mod would obviously negatively impact FPS and VRAM whereas some gameplay mod wouldn't affect either. ~FarloTalk 23:44, July 16, 2013 (MDT)
- I was thinking about relative improvements compared to some STEP baseline, in which case a mod that reduces quality a small amount but improves FPS a lot might get a positive check here. Skyrim Performance Plus would certainly get a plus here also. Kelmych (talk) 21:11, July 16, 2013 (MDT)
- But that might not be true for much longer, what if someone made a "craptastic computer pack", it might be nice to know that a mod has a positive effect. I think a choice of positive/none/negative would be well suited. ~FarloTalk 18:20, July 16, 2013 (MDT)
Mods - Recommendations/Notes
Proposed: Attach mod-specific notes to mod pages. Packs will also need recommendations relating to specific mods. Template:Recommendations could be used at the Pack level as it currently stands.
Proposed: s4n suggested adding capability to set flags (plus mod IDs) to note conflicts.
Mods - Conflicts
how about a list of important conflicts using the STEP mod index in the list Kelmych (talk) 21:11, July 16, 2013 (MDT)
- We thought about this, but it'd be a huge pain in the ass to keep every mod updated with the mods it conflicts with. Not really sure how to go about this one. ~FarloTalk 23:44, July 16, 2013 (MDT)
Packs - ForumTID
We're just giving each pack it's own thread right? Some of the bigger ones could be given a subforum (STEP, SR, etc.) but we can deal with that on a case-by-case basis) ~FarloTalk 20:32, July 16, 2013 (MDT)