Talk:Options Menu

Page reversion

The multilevel menus had been unnecessarily compartmentalized. While some of the altered versions would have worked, there is no advantage to splitting each submenu into a different function and it can, in fact, be a disadvantage if using the menus arguments as variables while in the menu. The first example was broken as Game.GetPlayer().RemoveItem(Self) will not remove the item. Incidentally, PlayerREF as a property is about 1,000 times faster than Game.GetPlayer().

By all means, add examples, notes, and whatever else, but the examples are tried, tested, and true.

New material was, of course, retained.

aiButton < 0

In a few cases, not checking if aiButton != -1 tripped me up and the MessageBoxes were displaying when not desired. I'd been recycling aiButton with sub-sub-submenus IIRC. Anyhow, had it not been necessary I'd have never added it as initially I wasn't checking it and found I needed to in order to keep the menu fluid. Might not be necessary for all multilevel menus, but I see it as preventative maintenance as menus tend to grow. (JustinOther)

I don't think there's a need to check for when aiButton is -1. Unlike with the previous script language, Papyrus seems to pause script execution (of the rest of the event/function) until it receives input from the Show() function. —The preceding unsigned comment was added by Fg109 (talk • contribs) 13 April 2012

Yep, Show() will block the script until it returns. If the return value is -1 then it means the message failed to show for some reason. I think that would more likely happen during development if the author forgot to set a property. If it's ever seen in a released then something is fubar. Tunaisafish 05:17, 13 April 2012 (EDT)

Reading the description of the return value and doing a little testing I am certain that a MessageBox style message will never return a -1. The -1 gets returned if it's a Notification style message. And if you try to use Show on an unfilled property, you'll get a 0 return value! So make sure your first button is a reasonable choice for a default. Cdcooley 18:13, 13 June 2012 (EDT)

My changes were reverted. JustinOther you keep telling people that a check for -1 matters and I have tested it and found that it absolutely does not. I'm not going to get into an edit war on the page you created but you are wrong on this.

• A call to Show() will always return -1 when it's used on a Message that isn't a Message Box. It shows a notification in the top corner instead.

• A call to Show() on an un-filled property (with the None value) will fail and return a 0 immediately.

• A call to Show() on a Message Box message that doesn't have any buttons defined will get a default "OK" button which returns 0 when pressed.

• A call to Show() on a Message Box message that does have buttons defined will return the matching button number.

Checking for -1 to wait for a button to be pressed was part of the scripting system on previous games, but is not part of Papyrus. What makes your code work are the bool variables you use to control the while loop and the check for -1 does absolutely nothing useful. -- Cdcooley 06:32, 17 June 2012 (EDT)

During my testing on Fallout 3 with the options menu, it appears that the myVar = myMsg.Show() would return a -1, pause the script, then come back and evaluate to the end, before starting over at the top of the loop with the inputted value in myVar. None of my debug notes suggest this is true in Skyrim, when using a While loop. Having a way to break out of the loop isn't a bad idea though, just in case. But in the code listed, the if(aiButton == -1) won't break out of the loop. so if you were paranoid, adding abMenu = False would be a check. although I don't like the idea of always evaluating a bool statement at the beginning of a loop that has almost zero chance of success, i would just put Else statements within the subMenu if/else blocks with abMEnu = False. So it never gets evaluated at all unless catastrophic failure occurs somehow.