Talk:Settings

Active discussion

Default values

I've just been directed to one of the various settings pages from a thread on the official GECK forum, and it looks like a few of the default values aren't correct. When I went to check the correct default values, I noticed that Fallout3.esm changes that values of many GMSTs.

Should the default values listed here be the actual default values of the setting, or the values assigned to the setting when Fallout3.esm is loaded? The latter seems to be the case at the moment, but (at least to me) the former seems to make more sense, as Fallout3.esm is essentially just an official modder's resource.
-- Cipscis 00:24, 17 March 2009 (UTC)

Which page was it? Default values from Fallout3.esm should be used and not the ones in the base GECK with nothing loaded.

--SnakeChomp 01:12, 17 March 2009 (UTC)

I just checked the thread and page again and it looks like the OP misread the page here - they had confused iLevelUpSkillPointsBase with iLevelUpSkillCount. The page is Derived_Skill_Settings, but now that I realise that the OP had confused the two GMSTs I see that the default values listed on that page are those set in Fallout3.esm.
-- Cipscis 00:03, 18 March 2009 (UTC)

"Default" should be the value when Fallout3.esm is loaded. The base entries are essentially meaningless. Knowing where Bethesda put those numbers is far more useful.

DragoonWraith · talk · 00:12, 18 March 2009 (UTC)

Archived discussion

Consolidation

I've consolidated some settings into setting group pages, redirecting when there were already individual pages. I highly recommend that we avoid individual pages for settings wherever possible, as it creates clutter and makes information hard to correlate.
For example, there were previously 3 pages for some movement settings, but that information is next to useless if one doesn't understand how the movement settings interrelate. I've consolidated them on Movement Settings, and I think we can all agree that this is a much better situation.
Obviously there will be a few settings just won't relate to others, but other than those I think it's in the best interests of users and editors to group related settings.
If people want to set up individual redirects for such pages, I have no objection to that, but I don't think it's worth the effort. Consider setting up a Firefox Quick Search for the geck, it will save you a lot of time (and if you don't have Firefox... ???)
--Quetzilla 21:07, 20 December 2008 (UTC)

magic settings

I'm guessing that the "Magic" game settings here were carried forward from Oblivion but are not actually used? Should they even be listed here? --SnakeChomp 03:40, 14 December 2008 (UTC)

I'm assuming that modders (scripters in particular) are going to be using the magic effects all the time. I say keep, for now. Hpfreak26 04:04, 14 December 2008 (UTC)

redirects necessary?

I'm wondering what the point of setting up redirects for grouped settings is. Won't the search engine just point them to the group page since the name of the setting is in the text of the page? Seems like extra work.
--Quetzilla 01:59, 16 December 2008 (UTC)

For links and for anyone who types the URL directly into the address bar (personally I do that fairly often...), I think it's worth while.

If Bethesda OKs my Wiki bot, I could automate it, too.

DragoonWraith · talk · 18:35, 16 December 2008 (UTC)

Section Organization

I think we should promote the combat section to the same level as the actor section instead of having it as a subsection, since they aren't strictly related to actor settings in such a fashion. Especially the mine settings and VATS, those don't really change actors in any way. --SnakeChomp 04:23, 20 December 2008 (UTC)

Feel free to reorganize it as you like; I'm willing to defer to you on this, since you're definitely putting more work into this. I only added the new headings because I felt there did need to be more; I'm not particularly attached to any particular organization, I just think there should be organization.

Also, you should put related settings in one page and use {{Template:SettingGroup}} for all of them.

DragoonWraith · talk · 05:51, 20 December 2008 (UTC)

Formatting observations

I hope you're in a reading mood. =)

I'm still not happy with the way the organization of the settings page and the pages it links to has ended up. We have pages like Movement Settings which "abuse" the Template:SettingGroup template to document a group of related settings. (This page needs to expand into a formula so we know how movement speed is calculated so it will be changed eventually.) We have pages like Gun Spread Formula which document a group of settings by providing a formula describing their use and sprinkling the setting default values in with the formula explanation. We have pages correctly using the settings group template like fWeaponConditionReloadJamXX to document settings that have 10 slightly different names. We have pages left over from Bethsoft that document settings using individual pages as well as one master page that duplicates all of the documentation for the individual settings onto one page, like the Sandbox Package page and its related settings (such as iSandboxDinnerMax). Basically, what we have ended up with is a big inconsistent mess.

I don't like the current setting group template style. I much prefer the table style as used by the CS wiki, like this page: http://cs.elderscrolls.com/constwiki/index.php/Movement_Game_Settings. Also of interest is that this page contains the formulas in which the settings are used. It can be compared/contrasted to the style of our formula pages, like the Weapon Damage Formula page, because they contain the same information (setting names, default values, formula). Additionally, I don't think we should be using the settings group template as the page body for pages that aren't simply there to document a setting that has 10 different names. See Derived Skill Settings for another example that I don't works very well. The settings group template mangles the page name, and the presentation of the information lacks something... it doesn't really flow as normal pages using section headers do. I still believe we should document settings like these on the same page because they relate to each other so closely, but I would prefer to see conventional markup used for these pages and not this template.

I also don't believe we should be creating section headers that are links on the Settings page, as they are for the Derived Skill Settings section and the Movement Settings section. It breaks away from the conventional wiki page formatting and looks a bit odd, what with the links being different sizes and all. Losing the red color also takes away from the organization that section headers provide as there is nothing immediate that jumps out at you to say "a new section is starting" when all the text uses the same black underlined style.

As to addressing these concerns... I think for the settings group template, I would rather see the template change into a simple table with a header row that applies what ever formatting we deem suitable instead of being used for the entire body of the page. This way we can still use conventional wiki syntax and formatting to describe the settings generally before providing the table of the settings, their default values, and any specifics about a particular setting. The template can then also be used for pages like Derived Skill Settings without mangling the page name but keeping some of the formatting consistent. For pages like fWeaponConditionReloadJamXX that need the page name mangling, we can just rip out the syntax needed to accomplish this from the template itself and put it directly on the page. Doing that is not really a big deal and it allows the template to be used in more situations.

As for section headers as links, there would need to be a sentence of lead in text in which to place the link to the section. I'm not sure its worth coming up with sentences in which the section name fits in a grammatically correct fashion. It could be as simple as saying "These settings are documented on the Movement Settings page." This technique can also be applied to the weapons section that have the settings with 10 values documented on fFooXX pages.

As for individual settings pages vs pages documenting a group of settings with a single page... I wonder whether there is any value in having individual settings pages at all. All the well documented settings listed on the settings page are categorized. Perhaps it would be better to simply document all settings within the category on a single page? They are grouped into categories like this on the settings page because it is often necessary to understand what all of the settings do in order to understand the impacts of changing a single setting, so instead of having to go back and forth between a ton of individual settings pages it would be nice to see all the settings on a single page. To this end, perhaps the existing Template:Setting template could be modified so that the template could be repeated several times on the page documenting the category of settings, once for each setting? Or alternatively the Template:SettingGroup template can be modified to be used for the purpose. Either way, it should be possible to have more than one of each of these templates on the same page in order to be able to separate the page into sub sections if it aids in grouping the settings in a more logical way.
--SnakeChomp 20:49, 25 December 2008 (UTC)

Not a single point I disagree with. The templates don't have to be used on every single settings page. Enforcing a standard is good, but if it deducts from the readability we need an alternative.

As a direct solution for your last point I think it's sufficient to remove the Back to: links from the templates and add them to pages manually.

The different groupings of settings are a bit more difficult to solve, because none of them is essentially better than the others.

• I like the formula grouping, because that's how the settings will be used. However, not all settings are part of a formula (we'll be using), and if some are part of multiple formulas it would decentralize the information of a setting.
• The name dependent grouping (SettingNameXX) only groups the settings that are obviously closely related, but offers no good way to add formulas to the page, or explain other relations.
• Category grouping you talk about (Sandbox example) is similar to the formula grouping, but more extensive. It doesn't only group settings that are part of one formula, but all settings that relate to each other closely. I think this could result in very long pages which are hard to follow. It does put all information about a setting on one page, as well as the related settings.

It's important to discuss this before continuing to document the settings. I thought a (group)settings template would cover it all, as it's a vast improvement over the situation we have at the CS Wiki, but there's obviously more. The templates still serve a purpose, but don't have to form the main item on a page.

I'd like to add that I think you're doing a great job at shaping the Settings section and documenting the settings!

--Qazaaq 22:37, 25 December 2008 (UTC)

Changing SettingGroup to include name/default/description on one line is possible. I was going for maximum consistency with the Setting template, but I had expected a discussion like this to come up, so I could get feedback.

I don't think SettingGroup must be used on "named groups" as Qazaaq calls it, however. I don't consider the "movement settings" page an abuse (at all) - though the template needs to be fixed to not lower-case the first letter in such circumstances. But I think it's good to use the template as much as possible.

I do agree that Setting could, and should, be used multiple times in a page - the only serious change necessary would be to remove the Bc tag, but that can easily be added to the pages themselves.

I very much agree that individual pages are unnecessary and undesirable - in fact, I almost requested that you convert certain groups of settings to a single page using SettingGroup, but since you're running the Setting show here (and doing an excellent job, I might add), I figured it best to let you do your thing.

Anything I can do to help with any of the changes you propose, let me know, because I think you're right on all of it.

DragoonWraith · talk · 03:14, 26 December 2008 (UTC)

I added a new template to document setting groups in a way that appeals to me and I am using it on the Mine Settings page as a demonstration. It uses three distinct templates: one Template:SettingGroupHeader to give the name of the group, any number of Template:SettingGroupSetting to document each setting in the group, and one Template:SettingGroupFooter to end the group.

For Example:

{{SettingGroupHeader
|Name = Foo Settings
}}

{{SettingGroupSetting
|Name        = fFoo1
|Default     = 0
|Description = foo
}}

{{SettingGroupSetting
|Name        = fFoo2
|Default     = 0.2
|Description = foo
}}

{{SettingGroupFooter}}

Foo Settings
Setting	Default	Description
fFoo1	0	foo
fFoo2	0.2	foo

I like doing it this way because it is simpler to implement the templates (they are all very small), it is trivial to reorder the settings within the group as you don't have to change a lot of numbers (Setting1Default -> Setting9Default) and it is easy to move settings into and out of the group as all you need to change is the name of the template being used (use the Setting template instead of SettingGroupSetting).

I'm not married to the formatting of the table that is in use right now, namely the colors being used on the heading row (Setting, Default, Description). It also seems a bit weird that the master table header that has the group name is smaller than the heading that names the columns.

I actually have a question about templates, is it possible for the Template:Setting template to be conditionalized so that it results in different html when it is used within a {{SettingGroupHeader}} ... {{SettingGroupFooter}} section? That way it is simple to move setting documentation into and back out of the group as you don't have to rename the template being used. Its not a big deal, but it would be awesome if we can do that.

I plan on changing the pages that currently use Template:SettingGroup to use the new template, that is assuming that people don't hate the new design behind the template (the fact that it is now 3 separate templates instead of one big monster template). We can refine the look and feel of the new template as we go. I already notice quirks in the example I used here; the width of the "Default" column should be constrained.

--SnakeChomp 05:15, 27 December 2008 (UTC)

I happened to discover by chance that stringing several of the (fixed) Template:Setting templates one after another happens to create what looks to be one continuous table very similar to the Template:SettingGroup template. Compare this example with the example of the new setting group template I made shown above.

{{Setting
|Name = fAutoAimMaxDegrees
|Description = Desc 1
|Default = Def 1
}}
{{Setting
|Name = fAutoAimMaxDegrees3rdPerson
|Description = Desc 2
|Default = Def 2
}}
{{Setting
|Name = fAutoAimMaxDegreesMelee
|Description = Desc 3
|Default = Def 3
}}

fAutoAimMaxDegrees
Default value	Def 1
Description	Desc 1

fAutoAimMaxDegrees3rdPerson
Default value	Def 2
Description	Desc 2

fAutoAimMaxDegreesMelee
Default value	Def 3
Description	Desc 3

I think thats really spiffy. Perhaps we don't even need templates for group settings if we can just do something like this?

--SnakeChomp 07:32, 27 December 2008 (UTC)

Individual page benefits (and I mean for every setting):

• Good for settings that fit into multiple categories. In Oblivion, the obvious example was fMagicDurMagBaseCostMult which affected everything magicka including potion strength, spell strength, enchantments, vendor prices, etc.
• Easier and clearer to edit - an edit will only be about that setting instead of a group of settings. The talk page will only be about that setting.
• Allows us to implement the page information elsewhere, and on several other pages.
• Very clear when a setting's effect is unknown.

Negatives:

• Annoying to open and navigate multiple pages
• Quite a few settings don't mean anything alone (i.e., Base/Mult combos)
• Have to make/upkeep 100s of pages

To me, those negatives far outweigh the positives. So, where do we put them - formulas, group pages... well, actually, we already have a Page :P Like the CS List of Functions page, we can place all of the settings here in several tables, such as

=== Auto Aim Settings ===

Auto Aim Settings are used to configure the auto-aim feature.

fAutoAimMaxDistance
Default value	1800.000000
Description	Configures the working distance of Auto Aim in 1st person mode. A red cursor while targeting a hostile character indicates that auto aim will guide your shots towards the targeted body part.

fAutoAimMaxDegrees
Default value	bar
Description	foo

This will make this page a better list - the settings will have enough information to explain what they are without the need to go to another page. Also, this will allow us to be more flexible with the pages we use - a formula, group, or both, and any other relevant page can be linked in a short paragraph, much as we're doing now. Finally, the specific pages will no longer have to fill the role of explaining each setting - they have already been explained over here.

And now, if you'll excuse me - I'm not sure how I'm still awake (but hopefully I am).

--Haama 08:44, 28 December 2008 (UTC)

I think it's easier if the settings are categorized in a few (or more) groups. Most settings don't have a lot to do with others, putting them all on one page wouldn't be very helpful. I don't think we have to list all settings on the settings page even. Listing the group names should be sufficient.
--Qazaaq 18:15, 29 December 2008 (UTC)

Item Settings category?

The following settings are listed as "Unused" and I think it'd be good to see them fit into the wiki under something a bit more helpful, perhaps "Item Settings"?

fDamageToArmorPercentage, fDamageToWeaponEnergyMult, fDamageToWeaponGunMult, fDamageToWeaponLauncherMult and fDamageToWeaponMeleeMult.

These all affect the durability of items and how fast items take durability 'damage' until they break. A lower than default value will make items last longer, whereas a value higher than default will cause them to break sooner. A value of 0.000000 is accepted, and causes items to never break.

The settings listed under "Unused" are actually unused by the game. These are listed as "Uncategorized", because no one has categorized them yet.

There are a lot of settings that could fit the category "Item Settings". I'd make "Durability Settings" subheader, or something else more specific. Feel free to move these settings under their own heading. And all other settings you wish to categorize, all help here is appreciated.

--Qazaaq 14:11, 17 April 2010 (UTC)