Project:Data Dictionary/Proposals

Mod Testing

• Form:SystemSpecs
  • Template:SystemSpecs
    • cpuspeed | CPUSpeed [Number]
    • cpucore | CPUCore [Number(list)]
    • gpumodel | GPUModel [String[list)]
    • gpuvram | GPUVram [String(list)]
    • multigpu | MultiGPU [Number(list)]
    • ssd | SSD [Boolean]
    • arch | OSArchitecture [Number(list)]
    • dlc | DLC [String(list-multi select)]

• Form:ModTest
  • Template:ModTest
    • newGame | NewGame [Boolean]
    • loadSave | CanLoadSave [Boolean]
    • loadSaveName | LoadSaveName [String(list)]
    • uninstall | CleanUninstall [Boolean]
    • errors | HasErrors [Boolean]
    • ctd | HasCTD [Boolean]
    • bloat | SaveGameBloat [Boolean]

• Form:Performance
  • Template:Performance
    • fps | FPSImpact [Number]
    • vram | VRAMImpact [Number]

ModAttributes: Some of the attributes for this template should be associated with the Mod page itself.

Propose that we add to Template:ModTest:

• RunningDawnguard (Boolean) - Indicates that the test box is running Dawnguard
• RunningHearthfire (Boolean) - Indicates that the test box is running Hearthfire
• RunningDragonborn (Boolean) - Indicates that the test box is running Dragonborn

RE Template:ModAttributes:

• @s4n, should the internal objects of the Documentation property be converted to property "string" values of that property? Could you re-create that one as you see fit?
• Should we add the QualityImpact property to the end of this?

We should rename Template:PerformanceImpact to Template:PerformanceData and use the previous name to hold the performance result (i.e., "impact")

RE Template:SystemSpecs & Template PerformanceData:

• How can we set these to evaluate to the SystemType and PerformanceImpact Properties, respectively? These can either evaluate directly in a 1:1 or in aggregate as a query result of the "average" of these respective templates ...

~z929669Talk 21:00, November 27, 2012 (UTC)

* Yes to the Documentation properties. There should only be three (the ones currently designated as sub properties) all of type boolean.

* Per the talk last night, SystemSpecs will be queried for the user entering PerformanceData and subsequently stored on the report page for that PerformanceData. Beyond this, we'll need a query that can pull results from the PerformanceData entered and process accordingly. Still not sure on how we're going to do that.

Stoppingby4now (talk) 23:42, November 27, 2012 (UTC)

*Agree with adding the Running DLC properties, also, I didn't add QualityImpact to either list as I wasn't sure if we were going to move it at the time. As I said on the forums, where the QualityImpact goes depends on whether we want to empirically collect that info per-tester or if we just want to leave that as one of the attribute items to be fleshed out in discussion.

*What's the difference between PerformanceImpact and PerformanceData, or am I not understanding what you said? Doesn't all that info belong together?

*It seems Semantic Result Forms provides quite a few ways of presenting data usefully, especially the charts and data visualizations sections.

*In response to Stopping's forum post: don't we want PerformanceData and ModTest on the same report, thus the same form?

~FarloTalk 06:08, November 28, 2012 (UTC)

* Re: Performance data. No, that should be a separate form. The main ModTest form will be tied to a single page(ticket) that represents the mod being tested. There should then be a link to the form for adding performance data. If you included it in the same form, management could become far too much to manage effectively depending on how often performance data is submitted.

* Added list at the top as a starting point. Collapsed some things, expanded others. Discuss.

* In the list above, collapsed the DLC's to a single property. No need to keep adding these when we can make it multi-select and not have to worry about updating the form/template every time a new DLC comes out.

Stoppingby4now (talk) 06:17, November 28, 2012 (UTC)