Talk:Adding an Options Menu

Variable names

Looks good Cipscis, very clear. I do have one suggestion. In your examples you use variable names that describe the type of the variable instead of it's function (the setting). I know they don't actually have a function because it's an example, but maybe you could make a note that these names aren't practical.

Maybe a naming your variables article is in order, or a general variables page, as that one doesn't even exist. Not necessarily by you, this has little to do with a settings menu.
--Qazaaq 10:53, 24 December 2008 (UTC)

Thanks Qazaaq, I've added a paragraph making it clear that I've named them in order to illustrate what type of setting they're associated with, instead of naming them for functionality.

While we're on the topic of variable names, I thought I'd mention something that I find useful. I prefix all my variable names depending on the type of variable they are, like "fTimer" or "rMySelf". This means that I will always know what type of variable they are without having to look at comments or scroll up to variable declarations.

I also prefix all variables that I intend to access from outside the scripts in which they were defined with my username and the name of the plugin they belong to, like "sCipscisAMPUTATEDeathclawHandAssociatedLimb". They can end up getting pretty long, but I'll never wonder what they do or where they come from.
-- Cipscis 11:13, 24 December 2008 (UTC)

This is a choice everyone has to make for themselves, but when a variables page is made all these have to be listed. The naming method you're using is called Systems Hungarian.

Prefixing with the data file is a bit too much for my taste, but I will consider it if I ever do a large scripting project with multiple masters. Thanks for the idea!

--Qazaaq 11:23, 24 December 2008 (UTC)

True, prefixing the variable name with the Data file is a bit extreme, I usually just do it out of habit. The only time in which I find it is actually necessary is when using sIsAffected type variables (see Checking if a Mod is affecting an Object), so that the specific data file which is affecting the Object can be determined.
-- Cipscis 01:32, 25 December 2008 (UTC)

Just giving my two cents here. Using systems hungarian notation in a typeless language such as the fallout scripts is not a bad idea. Without the type prefix there is no way for a reader to know what data the programmer intended to store in the variable. Prefixing the variable names with full mod and author names is overboard though. When I add globals I do include a standard prefix so that they appear together in the list of globals (which don't actually use systems hungarian notation), but not the full mod name. What Martigen does is a good example to follow, all their globals start with MMM.

--SnakeChomp 20:51, 26 December 2008 (UTC)

Yeah, I always start my globals with a prefix, usually QZ. I used to prefix everything when I was doing stuff in oblivion, mainly so I could just find my junk in the object window. Now however, anything I add or change I put in a master Form List. Related stuff might go in a sublist which then goes in the master form list. The exception to that is quests, which I still prefix with QZ because usually the quest is named after the mod, which I also prefix with QZ :P.

As for individual variables in a script, I never prefix anything, but rather give them names that are meaningful in the script. If I'm using a list of weapons, it'll be weaponList or something. However, I'm often using objects for purposes at odds with their original implementations, so if I'm using a list as a queue, it'll be SomeQueue rather than SomeList. I'm generally too lazy to bother prefixing anything with s/f/b/r/x etc.

--Quetzilla 21:17, 26 December 2008 (UTC)

Categorising Settings

At the moment I've categorised settings in two ways - Global/Specific and Analogue/Digital. While I know in my head what I mean by these classifications, I'm not too sure about the terminology that I've used - particularly Analogue/Digital.
I've been planning on changing Digital to Boolean, which is much more fitting, but I'm not sure what terminology to use for "Analogue" settings. If anyone has any comments about this I'd be glad to hear them.
-- Cipscis 04:11, 25 December 2008 (UTC)

For once you have actually managed to confuse me. I have no idea what you mean by analogue vs digital.

--Quetzilla 04:21, 25 December 2008 (UTC)

Probably at least in part because they're horribly named, lol. I suppose I should explain them in a little more detail then. Basically the idea is that "Digital" variables are Boolean variables - they'll only ever be 0 or 1 and basically turn features on and off. "Analogue" variables, on the other hand, tweak how features work instead of turning them on and off.
The reason why I've separated them is that they can utilise different menu structures - "Digital" settings can simply be toggled - they only need to be selected in an options menu. "Analogue" settings, on the other hand, require a sub-menu of their own so that the user can choose their value from a list.
-- Cipscis 06:05, 25 December 2008 (UTC)

Ok, I've just updated the relevant sections of the draft, and I've changed the way in which I've categorised variables into something that I hope is a lot clearer. There are now four categories:

• General Toggle Settings
  
• General Select Settings
  
• Object-Specific Toggle Settings
  
• Object-Specific Select Settings
  

Hopefully these are much easier to understand
-- Cipscis 10:36, 26 December 2008 (UTC)

Okay, Toggle vs Select is a good improvement. I was going to suggest Toggle but I hadn't thought of anything to go with it. However, the General vs Object-specific stuff is hard to grasp -- I think I understand what you're saying, but I'm not sure why you're introducing that at that point in the article. the GS vs OS and GT vs OT sections are almost identical, so any difference in meaning between the two pairs requires close comparison of the paragraphs which I imagine will throw most readers for a loop.

One suggestion here would be to think up an example mod that you would want to make a menu for, and use actual settings that you would want to change for that. The Item1OT1 stuff can be very cryptic to read. Having actual settings that the user can understand on a functional level would also help make clear what you mean by G/T/O/S.

--Quetzilla 20:26, 26 December 2008 (UTC)

I've been thinking about this section and I'm not really sure anymore whether or not I should bother with categorising settings like this. It's not that it isn't relevant, it's just that the required menu structure for each setting is pretty intuitive anyway and if I try to explain it that'll probably lead to confusion.

I'll probably end up re-writing the "Setting Up Your Plugin To Use An Options Menu" section at some point to focus more on the simple concept of using quest variables instead of local variables in scripts, and not bother so much with all that GS/OS/GT/OT confusion. I might talk about the fact that different settings may require different menu structure, but at the moment I'm going to concentrate on writing the section about actually creating the menu.

Hopefully QZ Menus won't make this obsolete, lol.
-- Cipscis 10:14, 17 January 2009 (UTC)

I've re-written the entire first section, and this time I didn't really feel the need to categorise settings. I don't think I'll end up adding that part back.
-- Cipscis 12:11, 20 January 2009 (UTC)

Headings

The "title heading" is unnecessary (there is the title bar on top), as is the "introduction" heading (the first paragraph is always the heading. General Wiki style recommends that those things be removed, and that you start without any heading. The disclaimer should probably go in a box a la {{Incomplete}} or something.
DragoonWraith · talk · 16:55, 26 December 2008 (UTC)

Perhapse we need a {{WIP}} tag?

--Quetzilla 20:27, 26 December 2008 (UTC)

The latest draft includes a mock-up of a "WIP" tag with the same styles as the Incomplete Template. I've left the top heading there because the tutorial is now split into two main sections, which is what I originally had in mind.
I've also removed the "Introduction" title, but I haven't added a general introduction to the tutorial yet. It's on my to-do list though, and if I understand you correctly it should go before the "Setting Up Your Plugin To Use An Options Menu" title?
Thanks for letting me know about these things, I'm still fairly new to Wiki style and standards so I'm keen to learn more about it.
-- Cipscis 13:14, 17 January 2009 (UTC)