[Relz] OBSE Plugin - MenuQue : IV - Oblivion

» Tue May 03, 2011 8:51 am

And something else, probably just for TheNiceOne though, I can make a version of GetActiveMenuSelection that'll work with keyboard navigation. Although I am a bit reluctant to add it since it would be the exact same function, with just 2 lines added at the top. So if someone wants it really really bad then say the word.....

Well, it would make EE's new feature work with keyboard navigation, so I would of course like it

The fix will hopefully be added to OBSE, but there's no big problems with similar functions, I think.

» Tue May 03, 2011 10:38 am

It is certainly an interesting idea and in theory it should work. But I'm afraid it'll be next to impossible to do it from script. Why? Well mainly because you'd have to add these invisible elements to each menu that is open (or rather, to the menu that is at the very top), and without a way to delete it again it would quickly pile up (well there won't be duplicates but as soon as it's used in multiple menus the exact same element has to be copied too).

One way to get rid of newly inserted stuff is simply reloading the Menu. The Reload-http://cs.elderscrolls.com/constwiki/index.php/Category:Console_Functions at least worked without problems for the HudMainMenu.
According to the Wiki-Page, the command isn't reliable for all menus, though.

Apart from that, I suppose I could see if it is even possible, there is a small chance the whole 'mouseover' stuff doesn't work in the same frame the element gets added. But lets assume that it does, then I think it is better to start off with relatively large elements and then slowly make them smaller. As in, first use squares of 100x100 pixels, check which of the ~15 squares is selected and then further divide it into squares of 10x10, etc. Dividing the entire screen into 1x1 elements would be very, very bad for Oblivion's memory. Not to mention the fps. On average that would be nearly 1 million elements (1024x800 = 819200, and alot of people play higher resolutions)!

Well, my last though were stripes, which would result in sth. about 1280+1024 = 2304, but first using 100 Pixel-Stripes and then decrease the width should reduce the number required even more (should be sth. about 50 if this really works).
If this doesn't work I think you got to create the raster directly at the start and live with the 2000-3000 elements.

I think you have to use "\#test\_test", similar to how PrintTileInfo needs "\" for dumping top-level content. If that doesn't work let me know and I'll look into it. Oh and ofcourse I should add it to the documentation, which will probably be later today with an update too. :blush:

-kyoma

OK, this worked. Thanks.

Next Request:
What about Including strings instead of an already existing file?
It's already possible using Pluggys StringToTxtFile & DelFile (directly before & after mqInsertXML), but still requires another OBSE-Plugin-dependency.
Mainly useful for small files (e.g. change a single trait-calculation), but still ...
If you're not convinced yet, just see it as an testing-function to use from the console without the need to always leave Oblivion for a single change.

Edit:
Wait, seem like DelFile doesn't work if it's called in the same frame as StringToTxtFile (to create the file).

Edit2:
Meh, DelFile refuses to work in the Data-Folder.

But since it doesn't change anything if you delete the file per hand this shouldn't change anything.

Oh, btw. does mqInsertXML have a nth-argument (for the where-to-insert part), too?

Greetings (and sorry for that many questions),
Low Post

PS:
Are new elements always inserted at the end of the file, or just at some place (i.e. is is possible that the index of an already existing element changes (if that element also only was inserted in that frame))?

» Tue May 03, 2011 1:50 am

Uploaded version 3
* Added two new functions: mqGetMenuGlobalStringValue and mqSetMenuGlobalStringValue, both operate on the traits in the vanilla "strings.xml" file.
* Changed mqInsertXML to work with non-file strings directly too.
* Added an optional nthChild parameter to mqInsertXML to allow insertion in specific child-elements.
* Added optional parameter to all MenuChild functions to reverse the direction in which the list of child-elements is processed.

One way to get rid of newly inserted stuff is simply reloading the Menu. The Reload-http://cs.elderscrolls.com/constwiki/index.php/Category:Console_Functions at least worked without problems for the HudMainMenu.
According to the Wiki-Page, the command isn't reliable for all menus, though.

Well, my last though were stripes, which would result in sth. about 1280+1024 = 2304, but first using 100 Pixel-Stripes and then decrease the width should reduce the number required even more (should be sth. about 50 if this really works).
If this doesn't work I think you got to create the raster directly at the start and live with the 2000-3000 elements.

I wouldn't rely on the reload command, I know for a fact it messes up menus that are always opened/loaded because all of the (normally) code-handled traits revert to their actual (dummy/temp) value as defined in the xml. It stays that way until the game changes it to a different value. Not to mention the possibly large delay when reloading something like the main hud.

Anyways, it's not really relavent seince it is indeed best to implement in the plugin directly. I think I'll make a quick test to see how the game reacts to creating/reading/deleting such dummy elements all within the same frame. If the principle works then I can start further developement. I have to admit though, I suspect the hit on the fps may be noticable, since the function would most likely be called at very short intervals (if not every frame).

Next Request:
What about Including strings instead of an already existing file?
It's already possible using Pluggys StringToTxtFile & DelFile (directly before & after mqInsertXML), but still requires another OBSE-Plugin-dependency.
Mainly useful for small files (e.g. change a single trait-calculation), but still ...
If you're not convinced yet, just see it as an testing-function to use from the console without the need to always leave Oblivion for a single change.

As seen above, you can now.

Oh, btw. does mqInsertXML have a nth-argument (for the where-to-insert part), too?

This too has been added.

Are new elements always inserted at the end of the file, or just at some place (i.e. is is possible that the index of an already existing element changes (if that element also only was inserted in that frame))?

They are always inserted at the end, where the begin would be the first element at the top of the xml and the end would be the last. Reason for mentioning it this way is because the current functions (PrintTileInfo and GetTileChildren) both work in bottom-to-top order (compared to the raw structure of the xml). Most likely because each new element isn't added at the end of the list but inserted at the very beginning. Initially I figured it made more sense to keep my MenuChild functions in line with the raw xml but I decided to allow modders to reverse the iteration order so it matches the PrintTileInfo and GetTileChildren.

-kyoma

» Tue May 03, 2011 4:51 am

Uploaded version 3
* Added two new functions: mqGetMenuGlobalStringValue and mqSetMenuGlobalStringValue, both operate on the traits in the vanilla "strings.xml" file.
* Changed mqInsertXML to work with non-file strings directly too.
* Added an optional nthChild parameter to mqInsertXML to allow insertion in specific child-elements.
* Added optional parameter to all MenuChild functions to reverse the direction in which the list of child-elements is processed.

:woot:

I wouldn't rely on the reload command, I know for a fact it messes up menus that are always opened/loaded because all of the (normally) code-handled traits revert to their actual (dummy/temp) value as defined in the xml. It stays that way until the game changes it to a different value. Not to mention the possibly large delay when reloading something like the main hud.

Anyways, it's not really relavent seince it is indeed best to implement in the plugin directly. I think I'll make a quick test to see how the game reacts to creating/reading/deleting such dummy elements all within the same frame. If the principle works then I can start further developement. I have to admit though, I suspect the hit on the fps may be noticable, since the function would most likely be called at very short intervals (if not every frame).

Made some first checks, but it didn't work at all, since the mouseover-part of the rect-elements never turned &true;
I think this is simply because of my lack of experience with Oblivion-xml-files. Don't know, will make some more tests if I get bored.

They are always inserted at the end, where the begin would be the first element at the top of the xml and the end would be the last. Reason for mentioning it this way is because the current functions (PrintTileInfo and GetTileChildren) both work in bottom-to-top order (compared to the raw structure of the xml). Most likely because each new element isn't added at the end of the list but inserted at the very beginning. Initially I figured it made more sense to keep my MenuChild functions in line with the raw xml but I decided to allow modders to reverse the iteration order so it matches the PrintTileInfo and GetTileChildren.

-kyoma

OK, thanks.

» Tue May 03, 2011 12:25 am

Made some first checks, but it didn't work at all, since the mouseover-part of the rect-elements never turned &true;
I think this is simply because of my lack of experience with Oblivion-xml-files. Don't know, will make some more tests if I get bored.

Um yes, you're definitely doing something wrong as I got it working.

Still need to see how exact it is and how to do it all in 1 frame. But I have hope.

[edit]
Ok this is unfortunate but it seems the game doesn't handle/update the whole mouseover business until the next frame. Which is what I feared considering I had the same problem with changing a trait where any derived trait would not be updated until the next frame. So unless I find a way to bypass or fix this behaviour I'm afraid I've hit a dead end.

[/edit]

-kyoma

» Mon May 02, 2011 6:15 pm

Um yes, you're definitely doing something wrong as I got it working.

Hey, I understand how this xml-stuff works for only about 5 days. I have the right to make stupid mistakes. :wacko:

Still need to see how exact it is and how to do it all in 1 frame. But I have hope.

[edit]
Ok this is unfortunate but it seems the game doesn't handle/update the whole mouseover business until the next frame. Which is what I feared considering I had the same problem with changing a trait where any derived trait would not be updated until the next frame. So unless I find a way to bypass or fix this behaviour I'm afraid I've hit a dead end.

[/edit]

-kyoma

:(

» Tue May 03, 2011 12:26 am

Sorry to bother you again, but I have some problems with Oblivion behaving oddly:

	 &false; 	<_clicked>					 1 			<!---->			 2 				 1

This is somewhere in the HudMainMenu (tested at toplevel & in a second-level rect-element (using ).
Why does uncommenting the first onlyif-http://cs.elderscrolls.com/constwiki/index.php/Operator_Element (or a similar onlyif-operator comparing a copied value) cause the complete HudMainMenu not to be displayed, while the second onlyif-operator doesn't cause any problems?

mqInsertXML doesn't work if this appears to be in the inserted file.
Not the worst behavior if you ask me.

» Tue May 03, 2011 8:00 am

[edit-while-typing]
Doh, nevermind everything I said below. You just forgot a =.

I'll leave the stuff below for references as it might give you a better idea of future problems.

[/edit-while-typing]

Sorry to bother you again, but I have some problems with Oblivion behaving oddly:
.....
This is somewhere in the HudMainMenu (tested at toplevel & in a second-level rect-element (using ).
Why does uncommenting the first onlyif-http://cs.elderscrolls.com/constwiki/index.php/Operator_Element (or a similar onlyif-operator comparing a copied value) cause the complete HudMainMenu not to be displayed, while the second onlyif-operator doesn't cause any problems?

Hmm, very strange. Although I'm not suprised, I ran into a couple of strange problems myself in the past. Things that should have worked but for some reason Oblivion messed up while reading or parsing it.

I take it you are trying to determine/intercept when a button has been clicked? If so then I doubt it will work, the trait will probably just be overridden by the game code regardless of what and how it is defined in the XML.

mqInsertXML doesn't work if this appears to be in the inserted file.
Not the worst behavior if you ask me.

Meaning it returns 0? If so then for whatever reason the game doesn't like what the XML/string contains and aborts the parsing. This also explains why the whole menu disappears, if it is part of the original XML the result of an error can cause the whole menu to not get parsed or completely constructed.

-kyoma

» Mon May 02, 2011 9:42 pm

[edit-while-typing]
Doh, nevermind everything I said below. You just forgot a =.

I'll leave the stuff below for references as it might give you a better idea of future problems.

[/edit-while-typing]

Hmm, very strange. Although I'm not suprised, I ran into a couple of strange problems myself in the past. Things that should have worked but for some reason Oblivion messed up while reading or parsing it.

Only a = ...

:banghead:

Thanks, at least it doesn't hide the menu now.

I take it you are trying to determine/intercept when a button has been clicked? If so then I doubt it will work, the trait will probably just be overridden by the game code regardless of what and how it is defined in the XML.

Well, I count on that. Otherwise the _clicked-trait will always be true and I don't want to run my script every frame just to read out the original clicked-trait directly.
Anyway, I think I need to change my code a bit because clicked only is 0 or 1. :shrug:

Meaning it returns 0? If so then for whatever reason the game doesn't like what the XML/string contains and aborts the parsing. This also explains why the whole menu disappears, if it is part of the original XML the result of an error can cause the whole menu to not get parsed or completely constructed.

-kyoma

Um, don't know what's returned. At least there's nothing inserted (according to GetMenuHasTrait & mqGetMenuChildCount).

Thanks for your help.

Low Post

» Tue May 03, 2011 8:36 am

Well, I count on that. Otherwise the _clicked-trait will always be true and I don't want to run my script every frame just to read out the original clicked-trait directly.
Anyway, I think I need to change my code a bit because clicked only is 0 or 1. :shrug:

Curious as to how it will work out, I assume it won't work cause the clicked trait is one of those 'special' traits. On the other hand, I hope it does work cause then you'll have solved a problem I couldn't. Not to mention you'll be making alot of people very happy with such functionality.

P.S. http://www.gamesas.com/index.php?/topic/1097191-relz-oblivion-script-extender-obse-0018/page__view__findpost__p__16093310?

-kyoma

» Tue May 03, 2011 4:45 am

Didn't work.
But I can think of an easy workaround, but this would require an active *.esp:
Use the *.esp to check for mouse button presses & set some trait in the menu. There shouldn't be a problem checking that trait.

Then you simply have to combine that with the mouseover-trait and you should be done.

@GetDescription:
Never came in a situation so far I had to test it.

LP

» Tue May 03, 2011 8:33 am

@GetDescription:
Never came in a situation so far I had to test it.

Oh ok, um, could you try?

» Tue May 03, 2011 12:44 am

http://www.gamesas.com/index.php?/topic/1097191-relz-oblivion-script-extender-obse-0018/page__view__findpost__p__16094419

» Tue May 03, 2011 3:41 am

Thought I'd mention it. If you've got wiki articles or some other online documentation setup for your commands, you can use CSE's interop messaging system to pass a string map of command names and their respective URLs to get them to be displayed in the editor's context menu. Look into ConScribe's source to see how it's implemented.

PS : You can remove that 6MB overhead on the download archive by getting rid of the NCB file.

» Mon May 02, 2011 10:08 pm

Any updates?

» Tue May 03, 2011 6:29 am

Thought I'd mention it. If you've got wiki articles or some other online documentation setup for your commands, you can use CSE's interop messaging system to pass a string map of command names and their respective URLs to get them to be displayed in the editor's context menu. Look into ConScribe's source to see how it's implemented.

I've been meaning to make wiki pages but I keep postponing it.

PS : You can remove that 6MB overhead on the download archive by getting rid of the NCB file.

Oh thanks, I wasn't sure if the NCB file was needed or not to open the source code.

Any updates?

Well I would say yes, given the fact I got a new function pretty much done. It'll be ShowMenu which can forcefully display/open/enable certain menus. Currently it is only for the SkillPerk and MagicPopup menus (the latter will probably be of interest to TheNiceOne) but if someone knows of another they'd like to see I can try and add it too.

Atm the function just takes a MenuMode as a parameter but I'm thinking of adding the option to specify which file should be used as opposed to hardcoding the menumodes with the xml files. Benefits would be the ability to open menus such as the SkillPerk (which is actually &generic; menumode) with custom files, thus allowing the creation of custom menus that can be opened at any given time. I'll need to check this ofcourse but it appears to be doable.

======================================

Other than that, um well, my PC broke. Or my monitor, still need to confirm the source of the problems. :brokencomputer: A few days ago I started noticing that my screen (or computer) would freeze, restarting only resulted in a black monitor with an orange light (as if the pc was off). Only when I took the power off completely (both pc and monitor) would the damn thing start again. At first I thought it was just a fluke but then it happened again and again, although the power-cut still 'fixed' it. Until finally it no longer worked.

The first thing I'm gonna do is try out another monitor, if that doesn't work either I can remove my GPU and just use my onboard videocard. At the very least it will tell me which component I'll need to buy. <_<

-kyoma

» Tue May 03, 2011 9:29 am

More news! My PC is fixed (or rather, my new PC has arrived) so work continues. I've already implemented a ShowGenericMenu function that you can use to open a specific menu (albeit a somewhat simple menu) and am working on a ShowMagicPopupMenu function. Just enabling the menu isn't enough as the game will hide/disable it right away if the selected item/spell/etc isn't supposed to have a popup.

The good news is that in my pursuit on the MagicPopupMenu I came across the code that checks if an ingredient should be known or not. After some tinkering I was able to replace the standard check (with the iSkillXXXLevel gamesettings) with a custom one. Thus allowing for a function to override the default behaviour. But wait! It gets better, I noticed that the same system can be used for potions. But wait more! It gets even more better, I can probably add functions to do it on a per-item basis, allowing you to specify which effects from an ingredient and/or potion are considered known.

Two notes. First is that I still need to find the relative location for this ingredient mechanism in the AlchemyMenu. Second is that the whole 'known/unknown' stuff is more or less just a UI thing (with the exception of the first note ofcourse).

-kyoma

» Mon May 02, 2011 8:09 pm

This is ridiculously awesome! Thanks for this, kyoma!

Could mqGetIncompleteQuest be an alias for mqGetUncompleteQuest? I ask because "Uncomplete" is not a word...

» Mon May 02, 2011 9:15 pm

This is ridiculously awesome! Thanks for this, kyoma!

It is, isn't it.

Could mqGetIncompleteQuest be an alias for mqGetUncompleteQuest? I ask because "Uncomplete" is not a word...

It isn't? Well I can't say I'm not suprised, I thought it sounded 'off'. But Incomplete doesn't really match Complete either because it is 'to complete' the quest. And 'to incomplete' the quest sounds just as bad in my ears. But it doesn't really matter to me either way.

» Tue May 03, 2011 1:50 am

Sounds great kyoma.

I'm holding off the next update to Display Stats in order to see how I can use the new functionality first

» Tue May 03, 2011 7:17 am

Sounds great kyoma.

I'm holding off the next update to Display Stats in order to see how I can use the new functionality first

You're gonna love this then, we finally have a working ShowMagicPopupMenu function (with sliding in and out like normal)!

It can be called when no item is selected, and still showing the popup, it can be shown when a non-default item is selected, it can even be hidden/slided back for default items.

The next step would be to try and take over the entire popup business, thus allowing to add popups for entire groups of items. But that is of much later concern.

» Tue May 03, 2011 2:41 am

You're gonna love this then, we finally have a working ShowMagicPopupMenu function (with sliding in and out like normal)!

It can be called when no item is selected, and still showing the popup, it can be shown when a non-default item is selected, it can even be hidden/slided back for default items.

The next step would be to try and take over the entire popup business, thus allowing to add popups for entire groups of items. But that is of much later concern.

Does that mean a spell list with magic schools in separate windows may be in the future?

» Tue May 03, 2011 2:05 am

Does that mean a spell list with magic schools in separate windows may be in the future?

I suppose...although it wouldn't really involve the MagicPopup menu, just the Magic menu. :shrug:

» Mon May 02, 2011 6:34 pm

I suppose...although it wouldn't really involve the MagicPopup menu, just the Magic menu. :shrug:

True enough

» Tue May 03, 2011 10:50 am

Time for some news on the next version, I guess.....

A ShowMagicPopupMenu, can show or hide the magic popup with all of its normal behaviour.
A ShowGenericMenu, can be used to open a generic menu from a custom file.
A ShowTrainingMenu, it takes a skill, the level limit and optionally the cost and puts it all together.
Added a fix for the 'next-faction-rank-DUMMY' bug, now it will simply display "None" instead of DUMMY.
An OverrideXML function that can be used to redirect which exact file is used when the specified menu is created.

With the arrival of OBSE v19beta and its SetEventHandler function I had an idea that might be possible to implement. A way for scripts to listen and run the moment a button or element is clicked, before the actual action is performed. Currently if a modder wants to do something just before a button is clicked then he'd have to check if the mouse was pressed each frame, and even then it wouldn't work when scripts click a button or if the keyboard was used. It would be something like SetButtonHandler, it seems possible (but complicated I think) but so far I only found the info for one menu (looks like I'd have to hook things on a per-menu basis, which is.....bothersome....).

-kyoma