Talk:Adding an Options Menu


Revision as of 15:27, 26 December 2008 by Quetzilla (Talk | contribs) (Headings)

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)

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
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)
Hopefully these are much easier to understand
-- Cipscis 10:36, 26 December 2008 (UTC)


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)
Personal tools