Difference between revisions of "Talk:Options Menu"

From the CreationKit Wiki
Jump to navigation Jump to search
imported>Cdcooley
imported>JustinOther
Line 1: Line 1:
== 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==
==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. {{unsigned|13 April 2012|Fg109}}
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. {{unsigned|13 April 2012|Fg109}}

Revision as of 08:56, 5 July 2012

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 (talkcontribs) 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)