MenuQue
Bringing you the functions of Tomorrow, Today
Version 8.0

Download at http://www.tesnexus.com/downloads/file.php?id=32200
Requires http://obse.silverlock.org/ v20


What's it all about:

This plugin for the Oblivion Script Extender is the result of me looking into how both OBSE works and how the game works. It began as a small plugin with only a handful of UI and quest functions. But it quickly grew far larger than I could have ever imagined.

It also has a couple of features that do not directly involve any functions.

The ability to load an additional 25 extra fonts, giving a much larger variaty. http://cs.elderscrolls.com/constwiki/index.php/Extra_Fonts_%28MenuQue%29.
The ability to load additional strings.xml files, which the game uses as a source for string localization (e.g. language and translation). http://cs.elderscrolls.com/constwiki/index.php/Extra_Fonts_%28MenuQue%29.



See the readme for more details on installing and/or uninstalling the mod.

See the command documentation for a list of all the new functions and examples on how to use them.

Special thanks to:

• The OBSE team for making OBSE and scruggsy in particular for decoding all font-related stuff.
  
• shadeMe for continuously reminding me I should keep modding for Oblivion. And ofcourse alot of help with solving problems and finding the new things I needed.
  
• TheNiceOne for help with a few C++ problems and general ideas and suggestions.
  
• andalaybay for making sure I stayed efficient and general support.
  
• Me for finally deciding to start digging in the internal works of OBSE.
  
• * All the others I may have forgotten, please don't be mad...!

Plans for future release

• Selective spam blockers, choose what type of message spam you wish to block based on the source and object of the message. Like only stopping AddItem/RemoveItem messages during gamemode or only stop them for non-gold items.
  
• Addition of X-Skills, a way for modders to create a fake skill which then gets integrated into the UI. This is purely visual and the modders still need to give meaning to their fake skill through scripting. But from a user's point of view it will be just like any other normal skill.
  
• Better and more direct tile manipulation, an induvidual menu component is called a tile. Most likely in a style similar to OBSE's string_var and array_var, although somewhat simpeler.

List of mods that either require or use MenuQue:
....todo......

Curse you - now I can forget getting EE 4.2 out this week :hehe:

It looks relly great though. :celebration:

I can really see good use for some of those, and it even give me ideas for new mods (like a mod where you have another quest tab for paused quests - quests that you have recieved but no intention of doing for the time being, and therefore want them out of the running quest tab).

I was trying to understand exactly how the mqGet/SetMenuChild... functions worked, and was afraid from this post that they fell a bit short of my needs, but then I looked up the documentation in the dowloaded package and found that they were even more powerful and versatile than I had imagined! So cudos to you. They seem to be all I can dream of when it comes to xml handling functions (almost, see below).

One note, if I understand it correctly, you have one error in the document examples. The first MenuChild example is mqGetMenuChildName "background\##" 1001 4, but isn't mqGetMenuChildName "background\_test_rect\##" 1001 4 the correct path - and similar for the others?


As for the mqCreateMenuStringValue function. I guess

let include_string := ""mqCreateMenuStringValue "|%z" include_string 1004

...(in order to add a completely new hud element, defined in new_xml_file.xml) is too advanced for its use?


Anyway, I am really impressed by your work. :foodndrink:

[quote]
like a mod where you have another quest tab for paused quests - quests that you have recieved but no intention of doing for the time being, and therefore want them out of the running quest tab).
[/end quote]

Outstanding! Congrats Kyoma, and I hope you can pull off the paused quest menu TheNiceOne - I'm pretty sure I posted asking if this was possible several years ago, only to be told it was impossible...yet another occasion where the impossible proves to be possible...

Btw, what is the plugin name to use with OBSE's IsPluginInstalled function? Is it "MenuQue" ?

Ohhh, that would be very interesting to see. I'm always struggeling between avoiding to start a quest vs finishing a small quest as soon as possible, both have the same reason which is to avoid my questlog from cluttering. :facepalm:

The original implementation was alot more limited, it didn't allow the use of filtering the child elements by their name. Which made them terribly inefficient when dealing with large lists. I didn't include the examples in the second post cause that would make it rather large and possibly confusing. I figured it'd be nice to have a brief function list before downloading the plugin.

Hmmm, I admit that the last bit of documentation was mostly copy-paste so I'm not suprised to see a small error in it. I'll go over it again and re-check everything, I know from experience how confusing erronous documentation can be.

Yes, unfortunately that would be a bit out of the function's league. Mainly because include is only used during parsing of the XML files, after it has been loaded into memory all traits and elements are stored (and linked) not as a simple string but as an actual data structure. Giving some trait a string value that would, from a pre-parsing point of view, effectively create a new trait/element won't work (see below).

	<_str> Hello 

SetMenuStringValue "_str|%r<_newtrait> 99 %r<_str> Hello"

If you just look at the string and what will be replaced then the result is this

	<_str> 	<_newtrait> 99 	<_str> Hello 

Which would appear as if a new trait (which could have been an entire new insert-line) has been inserted or created, but in reality the "_str" data structure that is already loaded into memory will simply have a (string) value of

<_newtrait> 99 <_str> Hello

In theory I might be able to parse the inserted-file by hand and construct the new element by hand (besides creating new traits I can also create new elements from inside the plugin). The biggest problem or limitation is is that it would need to be done by hand (the converting of a string to whatever data structure it represents), each operator (copy, add, mul, etc) and each link or reference to an element (src="http://forums.bethsoft.com/index.php?/topic/1097119-relz-obse-plugin-menuque/...", trait="...", etc.). But there might still be an easier way, assuming I can get that to work properly (it would use some existing code to parse and insert the element into the menu structure), I managed to get it working (as in, the element did appear) but only to be followed by Oblivion freezing. <_<

Nope, although I'm not so sure why anymore. Anyways, it's OBSE_Kyoma_MenuQue (yeah, I looked at Pluggy for guidence ). Not case sensitive ofcourse, that's just for my sanity.

-kyoma

:clap:

Might be due the game getting stuck in a loop while parsing the new elements. Chuck a PM my way and we'll talk.

If I recall correctly, IsPluginInstalled is case-sensitive.

hey cool, i can use this to make the anti-fast travel mod ive wanted for a while now (eg, cycles through all map markers you have and sets them untravable to, but still act as guides to where stuff is),

thanks! :celebration: and amazing work

You are aware of Map Marker Overhaul's anti-fast travel functionality, right? - Disable Fast Travel alltogether, allow fast travel only for shorter distances, or only for a max total distance per time unit...

So, I assume just as I asked in the OBSE thread that adding more values and such to menus like the statistics menu is not possible (yet)?

Not without directly editing the xml files. In my Display Stats mod I add many new values to the popup you get when hovering over items, but I do that by directly changing a xml file, and must therefore have variants for all UI mods I support - and it is incompatible with any other mod changing the same xml file (which are noe, except the standard UI mods).

Interesting. It'd be cool to see a mod to at least add some things in there anyway.

It used to be; the current version is not, but it may be wise to treat it as if it is in case one of your user's has an old version of OBSE.

@kyoma: Yay, looking good. Congrats on release. Some of the quest-related cmds (GetCurrent/CompletedQuests, Get/SetActiveQuest) have already been implemented for 0019, which I guess was bound to happen. If you have plans for further commands give me a heads-up so I can avoid duplicating your work.

In that case I'll probably update it cause I think the internal name was all lowercase....

Yea I noticed it when you posted the preliminairy functions for v19. It's no big deal, the functions were easy to make and served as a good learning curve. As for future commands, the only thing I'm still looking into is a InsertInXML-ish function, right now I kinda got it half working so it's definitely something I'm gonna continue working on. Other than that I can't think of any more functions, I'd love to add a GetQuestTargets but I cannot find the info for each quest target that controls if it is currently active or not.

P.S. Feel free to look at the source and add/use anything you want to OBSE, that's why I made it.

-kyoma

Hi kyoma,

I think I stumbled into one problem which may prevent me from use your new functions with the new EE feature I'm working on (but I will still find other use for many of the functions). If I change the string trait of the currently active cont_item_cost element, I must be able to continue to update the strings. But except for the currently highlighted item on the list, I don't have any link between the list item and the real item, so I have no way to find the correct value. To get it to work I guess I would need a function that could give me the base ref that an item list element belongs to. E.g. something that is a cross between OBSE's GetActiveMenuSelection and your mqGetMenuChildFloatValue, that only works for the lists that GetActiveMenuSelection works for, and returns a reference to the base object.

If I had this, I could use mqGetMenuChildCount and this new function to traverse the list, and for each get the base object, find its adjusted value and set it using mqSetMenuChildStringValue. But until then I don't see how I can find the right price to set for each list element...

nvm

Can we edit soul gems by adding a value in its stats to show what the captured soul was?

After a good (well, a bit short, sat up modding) night's sleep I thought of a way to get around the issue above, and will therefore be able to do as intended with your xml functions anyway

The problem was to find the real value to set for each xml item, and it can easily be solved by always setting barter sell/buy settings to 100%. That way, the prices the engine puts into the user2 property will be the full value of an item. I can then use your new functions to traverse the entire list, read the user2 property of each element, multiply it by the real sell/buy percentage and write the corrected value back.

So I'm back on track with your new functions now (or will be, I got distracted by my Quest Log idea). :foodndrink:

You can edit the name traits for each soulgem entry but they will still stack together as if they are all the same (soullevel-wise). :shrug:

It's getting a bit confusing for me so let me make sure I understand what it is you are trying to do.

Whenever you are highlighting an item you want to change the user2 trait to display the exact cost. And when the highlighting is removed/changed you want to restore the previous value, right?

If that is the case then I have a suggestion, you won't have to keep updating the user2 trait forever once you change it. You'd only need to change it back after the item is no longer highlighted. If, for whatever reason, the prices or barter gold change the engine will refresh all the user2 traits. Atleast, it did for me.

So the only problem would be that you don't know which child element (if there are more than one with the same name) to restore its user2 trait, right? I was thinking of making a GetMenuActiveChildIndex that would return the child index/position of the active element (either by identicle names or the overall index). Which can then be used with the various MenuChild-functions. And as I mention above, it looks like you'd only need to do this once after the highlighting is changed.

But maybe I'm not thinking of the same thing as you are and all of the above is irrelevant.

I'm not sure this will work as intended, I mean changing the user2 traits to display what each item should cost won't affect what the merchant thinks. So you could try to sell something that you think the merchant can afford but because the actual price is higher he'll complain about how he can't do that, right? :unsure:

-kyoma

That is the second best solution, but the best is, as soon as the barter menu is opened, to change the user2 trait for all items to display the "real value"

Ah, that makes it much simpler. I thought I would have to manually keep the user2 traits correct after my first change.

If I change all user2 traits I will not need this, but if I only change the currently highlighted I will probably need it. But child elements with the same name will be for equipment with the exact same name, and they should have the same price as well, so changing back the user2 trait for all should work well - unless there are differently priced objects with the same name.

But I can still manage without GetMenuActiveChildIndex . I can check the use2 trait of all elements of the given name, and then easily find out which one that has the value I changed to - and that is the one I need to change back. GetMenuActiveChildIndex would be easier though


Good point. But I have ways to manage this

Ok, I thought you didn't want to change all the traits, that would indeed be easier. I'll add GetMenuActiveChildIndex anyways and let you decide how to do things. I'm sure there are other uses for that function.

Wow, I got super-awesome news. I just tried messing around with an InsertXML function and this time I got it working right away. I think I know what I did wrong the last time, back then I didn't use the actual menu with ReadXML, instead I tried to register the tile to the menu afterwards (that required a few castings before the function would accept the new tile). Which then froze the game (well actually it froze the menu/UI, I could still open the console).

-before-Tile* tile =Tile::ReadXML("data\\menus\\prefabs\\insert.xml");-after-Tile* tile = menu->tile->ReadXML("data\\menus\\prefabs\\insert.xml");

Anyways, I haven't done extensive testing but it appears that my dream finally comes true. I'll add the function as a BETA cause there may be problems with certain combinations or layouts for the inserted XML. That's all for now.

[edit]
A question for those that are interested, I can probably allow you to insert a file not only at toplevel but also inside other elements. Worth doing? I'd say yes but I may be a bit biased.
[/edit]

-kyoma

I have no idea what any of that means, but I feel as if that will create even more amazing possibilities.

Can I plan for this to come soon? It would indeed simplify things a little bit, and wondering if I can assume to have it within a week or so?



Great. I think I will try to create my own hud xml file for the tiredness bar in Real Sleep Extended, and just add it to the main HUD xml using this. It'll make it simpler to not have to use kuertee's HUD elements to get it to work.

This means that anyone can pretty easily make completely new hud elements, and just insert them, instead of changing the original xml files. Great for compatibility


I'd say yes to. In Quest Log Manager I change a bit too much in the xml to make just using this function practical, but if I was allowed to insert a file inside other elements, I could do things like inserting a tiredness line in the Stats menu without having to change the stats xml.

Oh yes ofcourse, I already added it and was about to release an update. But then I discovered the whole InsertXML possibility and, although it works, I ran into a small snag, hence the delay. If I can't get it working within a day I'll just leave it out and release what's already been added. So you can expect it within a day, if I still haven't released it tomorrow just pester me about it a little. It'll probably be due to either lazyness or short-term memory-loss.

Yup, which is why I'm very happy I found a way to make the function. In fact, I'm close to even finding a way to insert files with just some traits which will override the existing ones. As in, like this:

			 500 		 500 

With a function call of

mqInsertXML "someFile.xml|background" 1001

Where someFile.xml contains just this

											
 2 
													
 2 
		

Result: exactly what it should be had the original XML contained the latter code. Safe to say if I can work out the kinks this function will be the most powerful thing Oblivion has even layed eyes on.... :toughninja:

-kyoma