Great. I'm looking forward to it


...which I will use for Display Stats, to have an option to show additional stats for all types of items.


Sounds really great. The standard menu is more than a bit lacking, and I have often wished to be able to open up some better-looking menus.

What is the difference between this and the ShowGenericMenu? Is it a function to call once, and then Oblivion will open your menu instead of, say, the Haggle Menu (thinking of EE here).

Now, this is something I have lots of uses for, as both Map Marker Overhaul and Enhanced Economy listen for mouseclicks on certain buttons. I will not change such a core element if it means that menuque becomes required for the entire mod though, so here's another vote for adding this stuff to OBSE

1. Which is mainly the reason I started looking into such a function in the first place.

2-3. Perhaps I should have explained it further, by opening a 'generic menu' I literally mean a menu/file with class = &GenericMenu;. There are certain limitations that come with it, like inability to give elements any IDs (if doing so the menu will close when they are clicked, regardless of the actual ID used). The real 'strength' of a generic menu is that with this function you'd be able to open it from any menu or gamemode and have full control over which file is used. Apart from the class, almost anything can be added in the menu.

At first simply had a function that would open up any menu with any filepath but as I started testing it I quickly ran into crashes. Most menus need additional background info due to other processed that might run while it is open. So after some fiddling I dropped the 'one-function-to-open-them-all' approach and started working on functions designed specifically for that menu. If a custom haggle menu is useful to you I can probably add it. (although you can probably use OverrideXML to redirect to some custom file directly)

How OverrideXML works is by changing the filepath the game uses when a menu is opened. Currently it will remain that way for the remainder of the session, in time I hope to also allow one-time-use. It is mainly useful for when you have a mod that, depending on the cirumstances, changes how alchemy works (and for example, change the xml file to reflect it). Normally if you want to change the layout of a menu the best way is to change the actual file. But this means it is either yes or no, nothing in between. Now a modder can change this on-the-fly.

To be honest I just started to second-guess the usefulness of this function myself. I made it after remembering a couple of comments in the OBSE thread about being able to change which file was used for a menu. Personally I don't have any use for it but I can imagine someone might. I don't expect it to be a heavily used function and I'll probably leave it with a beta tag for the initial release.

4. Yea, definitely useful. I really hope I can find the info I need to make it work. Even if its just for a few menus.

-kyoma

If a mod uses this then does the mod require this?(like everyone who downloads has to have it)

Doesn't have to be, you can add code like this to prevent MenuQue functions from executing when the user does not have it

if IsPluginInstalled "OBSE_Kyoma_MenuQue"     ;your codeendif-or-if GetPluginVersion "OBSE_Kyoma_MenuQue" >= YOUR_REQUIRED_VERSION     ;your codeendif

With that you can easily use MenuQue's functions (or any other OBSE plugin's functions for that matter) without making your entire mod dependent upon it.

Could this be used when I want to open a menu for the player to choose some options? I don't mind if the menu automatically closes when a button is clicked (as that's how the normal generic menu works anyway), but would like to have the ability of aligning things differently, have images in it, etc. What I do need, is to be able to read which button was clicked (just like the normal menubox).

One use that came to mind, was Enhanced Economy's Auto Haggle feature. It opens a generic Barter display menu instead of the standard Haggle Menu, but EE also includes an invisible version of the Haggle menu to be used when EE needs to open and immediately close the Haggle Menu. This works fine, but confuses players a bit since EE's Haggle Menu conflicts with DarnUI's etc.

So if EE could just redirect the xml file that gets opened as the Haggle menu to my invisible menu instead, I would avoid having to include a standard haggle menu xml file. The question is whether this alternative file would be understood as the haggle menu and work as intended though.


What kyoma said. As an example, my Enhanced Economy mod has two features that requires Pluggy (read price files, write item removal log) and one feature that requires MenuQue (show Real Values - not rounded values - in Bartrer Menu when you hover over an item). But Enhanced Economy only requires those plugins if you enable those features. If you enable a feature without having the needed plugin, the feature will be disabled.

My Useful Houses mod however, requires MenuQue to work at all.

For the generic menu you can add pretty much anything you'd like. I planned to include a small demo esp/xml to show what kind of things are possible. Tracking which button might have been pressed will be difficult. I might be able to implement SetButtonHandler just for the generic menu but I'm not too confident about it.

Ofcourse making a custom message_menu file together with (temporarily using) OverrideXML you could make a menu with full button control AND any custom element you might want to put in it.

That is very possible. As far as my testing showed the game does not care which file is used by a menu. Only that certain elements are in it (depending on the exact menu), they don't even have to be visible. Unlike the other ShowXXXMenu functions, which construct the menu by hand, OverrideXML does not interfere with the game's code. It literally goes like this:

Game: Hmmm, it seems I need to open up a menu. I'll just use this file.
MenuQue: Hey, wait, you shouldn't use that ol' little file. That's sooooo outdated, here, use this one instead.
Game: Oh ok, whatever, I just wanna make-a-menu!

You could name the file "negotiate_menu_hidden.xml" and then use

mqOverrideXML "data\menus\negotiate_menu_hidden.xml" 1025

[edit]
Ok, just tested (a bit quick) the possible hooking of button clicks and it seems to work perfectly. Ofcourse now I need to find it for menus other than dialogue. I'll probably try to get it for the generic menu and leave it at that for now. Actually making a SetButtonHandler will require spending some more time with the OBSE source....
[/edit]

-kyoma

I haven't fully looked into the beta's source, but I'm fairly certain that the user function manager hasn't been exposed to plugins yet.

Yes! GetGenericButtonPressed is done. :celebrate: Now all that remains is cleaning up the code (alot) and finalize the testing. Will probably take a year or so, but if you take out 'finalize' then I expect a week at most. :whistling:

Thanks for the headsup, will need to keep it in mind.

I don't know much about Oblivion's menu XML, but I've been wondering for awhile whether it's possible to create completely new custom menus, independent of all the game's predefined menus, and it sounds like this might be the way to do it.

I'd like to build a better UI for RefScope than the MessageBox menus that I use now, but I don't want to hijack any predefined menus or require the user to install modified versions of existing XML files, because that'd create conflicts with things like DarnUI. If MenuQue can display custom menus from arbitrary new XML files, and can pass user input (e.g. button clicks, mouse wheel) back to scripts, I'd be interested in using that feature. (Of course, it'd probably require another major rewrite and lead to RefScope 3.0...)

Well next version will not only have a ShowGenericMenu but also a GetGenericButtonPressed which will work similar to how GetButtonPressed works with messageboxes. Although not mouse wheel, atleast not directly within the context of the menu (e.g. scroll bars).

But it is very possible to make a totally new kind of 'messagebox' with no button limit or with all kinds of extra elements.

[edit]
Also, once I can call user functions from within the plugin I'll be able to finish the SetButtonHandler and possibly the SetMenuHandler functions. They will work in a similar fashion as SetEventHandler only then for button clicks and menus getting opened/closed respectively. The former can even be used to prevent the button click if I decide to implement that possibility. It'll give an almost total control over anything the UI does!
[/edit]

-kyoma

http://cs.elderscrolls.com/constwiki/index.php/Category:MenuQue :celebration:

I decided to ditch the very smart (too smart) way I got a hud wheel icon in my new Enhanced Hotkeys mod, and instead try out MenuQue's mqInsertXML function - and it was so easy to use that I hardly believed it. Everything worked on the first try!

So many thanks for this simple, yet extremely powerful function :foodndrink:

I want to update my HUD Improved, so it will use MenuQue.

But there is a problem:
I've made many changes to the "Hud_main_menu.xml" file.

Example:

Original code:	

HUDI code:						  		  												 70 			

MenuQue is able to realize this?

Ah yes, I read your post in your thread but forgot to anwser it there. To put it simple: yes, MenuQue can do that.

Anything that is inserted with InsertXML is parsed as a whole and then gets integrated into the existing menu(component). The real reason as to why you'll be able to do the above is that any existing trait (at the same level) will be overwritten by its 'to-be-inserted trait'. Not just the raw value but also any expressions or conditions associated with the trait. The real 'obstacle' is that you'll still need to know the original, raw text for that trait.

Atleast, it should be possible. I recall testing it but I can't remember what the outcome was.

More on that tomorrow, first, sleeping. :snoring:

-kyoma

Different mod issue, nm this.

Uploaded version 5
Critical update for possible plugin conflict, users whom downloaded version 4 MUST upgrade to this version.

...but HUD Status Bars 2.0, which was compiled with MenuQue 4 will not work correctly with MenuQue 5, so if you're using HSB 2.0, wait until I get an update (2.0.1) later this evening (day if you live in America).

Yes ofcourse, sorry. :blush:

...but HSB 2.0.1 is out now, so no worry

Any other than HUD status bars?

Hehe, I haven't really made a list yet. I do know that Enhanced Economy will use it when present, which is something alot of mods have nowadays (optional support). In the (not so far) future my MiniMap will also require this.

Don't know about other mods, but in addition to http://www.tesnexus.com/downloads/file.php?id=32365, MenuQue is required by http://www.tesnexus.com/downloads/file.php?id=32365, and gets used (but is not required) by http://www.tesnexus.com/downloads/file.php?id=25078 and http://www.tesnexus.com/downloads/file.php?id=34735.

Mods like Oblivion XP would benefit greatly from using MenuQue too, instead of having different versions for different UI mods, and being incompatible with others.

http://www.tesnexus.com/downloads/file.php?id=26196 requires MenuQue as well. See, we've done your work for you, so get your butt in gear and update the list that uses MenuQue

And, yes, yes, yes, I will be looking at adding Oblivion XP to the list :sigh: Now I'm getting nagged from people who don't even use Ob XP Clearly TheNiceOne is getting tired of being nagged by Oblivion XP users on how to configure his mods to work with Ob XP :wink_smile:

Thank you all, that will definitely shorten the amount of time needed to compile a list. And as such, I'll have more time to work on other stuff.

Which brings me to the reason for this post, what would you all say if I now have a GetMousePos function that (reliably) returns the X/Y position of the mouse in menumode (and even with just the console)....

http://www.tesnexus.com/downloads/file.php?id=35343 also lists MenuQue as one of the requirements, btw.