Jump to content
  • Announcements

    • AndalayBay

      Orphan Attachments   07/31/2018

      I have been doing some housekeeping lately and I've noticed that I had a lot of orphaned attachments. Attachments get orphaned when the PM or post is deleted without removing the attachment first. Deleting a PM or post does not delete the attachment and the file or image remain on the server. I'd like to ask all members to go through their attachments and delete any attachments you don't need anymore or those that have been orphaned. Where can I get a list of my attachments? Click on your display name in the upper right corner of the forums and pick "My Attachments" from the drop-down list. How can I tell an attachment is orphaned? If the PM has been deleted, you'll see a message like this in your attachment list: Unfortunately there is no message if the post has been deleted, so please check your old posts. We do purge old birthday threads every once in a while. Also some hosted projects have been shut down, so you may have orphaned attachments on one of those locations. Thanks!
AndalayBay

Northern UI Compatibility

Recommended Posts

I'm not sure they scale as the Wiki says, or maybe they do and that's the problem. The problem I had with 4K monitors is that the menus got TINY, so all the elements overlapped. My fix was to increase the spacing, even allowing for two lines in some cases. That also helps with other languages. Then I had to change the clipping, I think, so that when the elements overlap, users can still click on the plus and minus buttons to adjust their skills and attributes.

Oblivion XP's scrollbars highlight when user mouse over them so that they know that there are more skills. The first pane is for Combat skills and they need to click the scrollbar to the right to bring up the Magic skills. From the Magic pane, they can go left or right. The Stealth skills are on the last pane. It's a horrible design, but there wasn't much to work with, especially at low resolutions.

One last thing: I mentioned other languages. I put all the text that Oblivion XP uses in its own Strings file. This made it much easier to translate and indeed lots of people have some forward and translated Ob XP into many languages. That was one of the first things Kyoma did: add a feature to MenuQue to allow for custom Strings file. So you'll see the strings file references in Ob XP's menus.

Share this post


Link to post
Share on other sites

I'm not sure they scale as the Wiki says, or maybe they do and that's the problem. The problem I had with 4K monitors is that the menus got TINY, so all the elements overlapped.

Strange.

The wiki description is based on me reverse-engineering a few "normalized screen size" getters, which get used when the game sets the size of the "screen()" tile and when specific menus work with mouse coordinates (e.g. the lockpickmenu catching cursor movement). However, I didn't actually test the game with my system set to different resolutions, so there's room for error in what I wrote.

Oblivion XP's scrollbars highlight when user mouse over them so that they know that there are more skills.

Ah, right. I just have the scrollbar hide if everything already fits on-screen. ('Course, the level-up menu uses a constant height, so...)

I put all the text that Oblivion XP uses in its own Strings file. This made it much easier to translate and indeed lots of people have some forward and translated Ob XP into many languages.

Yeah, I noticed that, made sure to keep using any such strings I saw, and tried to avoid adding any hardcoded text. NorthernUI actually has its own strings file as well (different approach from the MenuQue method, though).

Share this post


Link to post
Share on other sites

Yeah, I've played at different resolutions to test the results. I also have three monitors and I had to download a multiple monitor fix thingy at one point to get Oblivion to run at all. I think it modified the monitor settings in Oblivion's ini. Those settings get copied each time I create a new instance of the game so it still works. I wish I had a 4K monitor to test with. I do have a Mac, which is a 5K monitor, but I'd have to mess with Boot Camp to get Oblivion running and it was too much hassle. :P

Yeah I guess we could have done a different design, perhaps even with some text to indicate that there were more skills on a different "page". I stuck to using a scroll bar so I didn't have to worry about getting it translated!

One last request: if there's a need to upload another package, could you just package up the files you modified? I gave you the full package so you could install Oblivion XP, but I need to pick out your files because I can't overwrite mine. I've released an update to Ob XP since we started. You can also upload them to the download area. This category is private so the public can't grab the files. Not sure it matters, but we have that option. Uploading files to the download area won't eat into your quota, not that that's an issue anyway.

Share this post


Link to post
Share on other sites

Yeah I guess we could have done a different design, perhaps even with some text to indicate that there were more skills on a different "page". I stuck to using a scroll bar so I didn't have to worry about getting it translated!

That's a wise choice! The vanilla game has scrollbars that auto-hide, and that makes sense for most list panes; it was also in use for your vanilla file, so it's what I went with. No localization needed. :)

Awful lucky you had a scrollbar setup there, too, because otherwise I wouldn't have been able to shrink the list of skills. Would've made it real hard to keep that hint in the dialog box.

One last request:

Uh, sure? Is that just if you spot anything that you need me to change, or do you need me to merge things with your update-in-progress?

Share this post


Link to post
Share on other sites

I see that you've redone the ribbons. Do the ribbons have to be vertical to work with your bars? Those ribbons are used by all the UI's, so they need to work for all. I can't change the names or I'd have to have separate code for Northern UI. I can try the vertical files with the other UI's.

Share this post


Link to post
Share on other sites
Just now, DavidJCobb said:

 

Uh, sure? Is that just if you spot anything that you need me to change, or do you need me to merge things with your update-in-progress?

I think I've figured out what you changed. Is it just the menus and the ribbons, as I mentioned in my last post, above?

Share this post


Link to post
Share on other sites
Quote

I see that you've redone the ribbons.

Oh--took me a moment to figure out what you were talking about. You mean the fills for the meters.

Those sort of have to be changed? I didn't realize it'd be an issue -- I thought the BAIN thing you have going on would make it possible to ship different versions of those files for NorthernUI.

At present, they have to be vertically sized to match the meter background. I could write separate meter code to stretch a thin fill image out, allowing images of any thickness. Not ideal, but it can be done if needed. I think it would pretty much entail just creating a copy of the "statbar" meter that has a predefined "height" for the fill image.

Quote

I think I've figured out what you changed. Is it just the menus and the ribbons, as I mentioned in my last post, above?

The timestamps oughta be different, so let me see...

  • menus/levelup_menu.xml
  • menus/main/hud_main_menu.xml
  • menus/main/hud_subtitle_menu.xml // for repositioning notifications below the XP bar
  • menus/main/stats_menu.xml
  • menus/prefabs/ObXP/levelup_av_template.xml
  • menus/prefabs/ObXP/levelup_config.xml
  • menus/prefabs/ObXP/generic/vert_floating_scroll.xml
  • textures/menus/Oblivion XP/xpbar_ribbon_full_COLOR_NAME_HERE.dds

That oughta be everything.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

I don't know if you could have withstood the torture or not, but it might have helped to play Ob XP with one of the other UI's so you could see what it does. I would have suggested DarkUId DarN.

Hmm, yeah I can probably just include Northern UI's version of the ribbons. I got caught up in what I call "core" which is the same for all UI's, versus the customizations. Right now, even the levelup_menu is in core and it's just the levelup_config that's packaged with each UI. So I'll have to remove the ribbons from core. BAIN might overwrite things properly, but I'd rather repackage it. I'm not sure how it handles conflicts in a single package. I think you're supposed to avoid that.

Share this post


Link to post
Share on other sites
14 hours ago, DavidJCobb said:

Thanks for reminding me about the screenshots in this thread. This RAR should have the files I'm currently editing.

LevelUpMenu is very preliminary I'll try to get the layout and style finished first; then I need to look into an incompatibility that's causing issues. MenuQue's "active(...)" tile selector is crashing with NorthernUI installed; this is something I've never been able to test for, because stuff like "active()" wasn't documented on MenuQue's mod page or on its CS wiki articles. I've commented out all traits using that selector, so there won't be any crashes for now, but the hover images and text for attributes and skills will be stuck or invisible. (The vanilla hover images and text are also still there; I didn't realize those would be inoperative (due to ObXP no-oping the vanilla attribute list) until after I got something that could render without crashing.)

MenuQue has this bizarre "TileLink" system -- apparently a subclass of the internal Tile class. A while back, I was able to patch a piece of MenuQue code that had crashed due to some bad assumptions (mainly, it would choke on a null TileLink pointer if a menu with a non-vanilla ID was open); I found TileLink while working on that and couldn't figure out how it worked.

The worst-case scenario is that we exclude this stuff to avoid the crashes, and users just won't see descriptions and images for attributes or skills when they hover over them. As long as MenuQue doesn't throw especially nasty surprises at me, I should be able to at least get this functional.

EDIT: Come to think of it, I could probably replicate the active() stuff just by checking mouseover traits by hand. Maybe. EDIT2: Nope, that won't work for anything templated. Hm.

 

I'm not sure if active(...) is one of them, but Kyoma refactored all the getters and setters in version 16, I think it was. Fortunately the old functions still work, so I didn't change them. I don't like his new tile_xxx syntax. :P I think this is the section where he attempts to document active(...):

Quote

Second is with how the root of the function is determined. Usually it will be the root of the menumode specified but there are also a couple of special values to access other parts of the UI (things that aren't directly part of any menu). They are:

1: Strings, this is where the content of "strings.xml" and any XML files in "Data\Menus\Strings".
2: Active, uses the currently active tile as the root.

Examples:


	; Changes the base string used by the BreathMenu to 'Oxygen'
	tile_SetString "_breath|Oxygen", 1
	; Gets the base string used in the TrainingMenu for how many times you've trained in its raw form (without the actual numbers in it)
	tile_GetString "_timestrained", 1

	; Set the user1 value to 100 for the active element
	tile_SetFloat "user1", 2, 100
	; Get the name of the active element (equivalent to GetActiveMenuComponent)
	tile_GetName "\", 2

None of Oblivion XP's scripts use GetActiveMenuComponent. You might try sending Kyoma a message on Nexus about this.

Share this post


Link to post
Share on other sites
14 hours ago, DavidJCobb said:

New fixes on my side:

  • Stats menu: the "level" bar/button can now be keyboard-navigated to from most of the menu panes, and can keyboard-navigate back to the panes as well. Can't navigate to it from an empty Factions pane or from the MiscStat pane; not sure how to work around engine limits for that; for those, just go to a different pane via left/right and then press up.
     
  • Stats menu: Fixed display of the player's level. Odd, though. I'd expect this to be broken for Vanilla!OblivionXP as well.

EDIT: Some fifty minutes of work has seen the following changes to the level-up menu:

  • The stat template now scales according to its parent width (or half its parent width minus the column gutter, for attributes).
  • Finished sizing and positioning for the attribute list.
  • Fixed scrolling code for the skill list: the scrolling setup is closer to vanilla, and all tiles clip properly.
  • Took advantage of the pre-existing scrolling setup for the skill list: the list is now smaller, so with a bit more work, I should be able to fit that hint text.

I've been trying to use the values in your "config" prefab where possible, though that does impose some limits (e.g. the hint text being bright white instead of the subdued grey). There are a few changes I made to some of the menus before I figured out what the "config" prefab was for, though, so there may be places that it no longer controls.

Anyway--screenshot:

22330_20181015105141_1.png

Yes, it's intended that the instructional text be brighter.  Why is the level-up so short? I'd like to get rid of that vertical scroll-bar if possible. Here's the menu with Darnified and Dark Darn:

DarNLevelUpMenuAttribDescrip.jpg

The instructional text with Darnified stands out without being too glaring so you might be able to tweak the values in the config file.

DarkUILevelUpSkillDescrip.jpg

I think people do appreciate the reminder of what the various skills and attributes do. I remember I found it pretty tricky to do at the time, so I'd like to see those preserved if possible.

I think it would also be nice to come up with a more Northern UI style for the scrollbars.

Share this post


Link to post
Share on other sites
13 hours ago, DavidJCobb said:

Oh--I almost forgot! Offhand, do you know if there's any difference between "ObXP\generic\vert_floating_scroll.xml" and the normal scrollbar prefab? The code looks vanilla, but I see comments like "DarN 39" on some traits and I don't know why they're there.

Just wanna make sure I don't break anything, once I set about reskinning the scrollbar.

EDIT: Got keyboard navigation mostly working for the level-up menu: you can navigate between list items (and between the two separate lists) using the up and down arrow keys, and you can increase or decrease a stat using the left and right arrow keys. This should generalize to the gamepad as well.

I don't know if the method I used is something that would work on your other compatibility files. Consider this: when you're at the end of the attribute list, pressing "down" needs to take you to a skill list... but which one? There are four list containers, and only one can be visible at a time. Normally, you can only specify one tile to try to navigate to, and if that tile isn't visible or targetable, then navigation simply fails. NorthernUI patches the game to let you specify multiple tiles to navigate to, with the game using the first one that works. There could be some other workaround (e.g. moving the XLIST stuff to the list containers' parent tile, and trying to navigate to that), but I haven't tested it (and frankly, don't want to break the setup that does work for NorthernUI at present).

Still, here's the general details.

  • Each list container (that is, the tile into which list items are inserted) needs to have an XLIST trait set to &xlist;, a TARGET trait set to false, an XDEFAULT trait, and an XSCROLL trait whose value is a REF operator pointing to the scrollbar. (The trait you specify is irrelevant; the game always uses user5.)
  • Each list item needs an XDEFAULT trait (should probably set it to true), an XUP trait set to &prev;, and an XDOWN trait set to &next;.
  • Each list item should have an XSCROLL trait that resolves to a numeric value (generally, you take the number of list items visible at once, divide that by half, and round it up; then, subtract that from the list item's index in the list). When the list item receives focus, the game takes the scrollbar that the list container's XSCROLL refers to, and uses the list item's XSCROLL to scroll it into view if it isn't already in view.
    • The level-up menu provides a bit of a wrinkle, since list items in two different lists use the same prefab and only one of those lists has a scrollbar. In that case, the attribute list container has its XSCROLL trait omitted, so that moving through attributes doesn't scroll the skill scrollbar.
  • If you want to allow keyboard navigation between two lists, then the first list needs an XDOWN trait pointing to the second list, and the second list needs an XUP trait pointing to the first list. To describe how that works: if you scroll to the bottom of the first list and then press "down" one more time, the list item's XDOWN won't resolve to anything valid, so the game will check the list container's XDOWN and act on that instead.
    • This, again, is where your design runs into problems, since without NorthernUI's DLL installed, you can only point to one tile -- and your first list needs to be able to point to any of four. You can try setting up the keyboard navigation stuff on the thing that contains your four skill list containers, but I can't guarantee that'll work; I haven't examined Bethesda's internals quite that closely.
  • XUP, XDOWN, XLEFT, and XRIGHT all work for the gamepad (control stick and D-Pad) as well as the keyboard.

So, ah, there's all that laid out.


EDIT 2: I almost forgot to do the skill category selector!  When you're in the skill list, that's mapped to the bumpers and triggers on a controller (triggers are aliased to Shift + Arrow Key on keyboards). The only issue is that switching categories while in the skill list boots you out to the bottom of the attribute list... I'm actually surprised that the engine handles the case of the currently-focused tile (in this case, a list item in a list that gets hidden) suddenly becoming unfocusable.

As to why it's the bottom of the attribute list: every time you keyboard-navigate to a tile with an XDEFAULT trait, that trait gets increased to be higher than all other tiles' values. If you navigate from List A Item 3 to List B Item 1, and then back to List A, you'll end up back at List A Item 3, because that's the item with the highest XDEFAULT. I... can't really think of a good, consistent way to move you to the newly-visible list instead of to the previous list you were on. This doesn't look like a use case that Bethesda had in mind when designing the engine.

One way to hide the problem would be to ditch the category selector and just display the four skill lists consecutively, with some magic to make them look like one merged list. I used that for the dialogue menu, to "add" the buttons to the top and bottom of the list as lines of dialogue (e.g. "Goodbye" as a selectable line); it was actually three separate lists end-to-end. That's not something I really want to do without your go-ahead, though.

As it stands, the UI/UX will work just fine for mouse users, and be a little weird (but still usable, which is an improvement) for keyboard and gamepad folks.

Ummm.... I've never even tried navigating the level-up menu with anything other than the mouse. I never even thought of using the keyboard. We could redesign the level-up menu to facilitate keyboard and gamepad navigation. Let me get a screenshot of your level-up menu and I'll mock up my ideas.

Share this post


Link to post
Share on other sites

Now to my findings so far. The Stats menu needs some changes, as I believe you suspected. First the level progress on the Stats menu is different than what's shown on the HUD. The two bars should be the same with the same colour.

HUD:

NUI HUD Progress.jpg

The progress bar is yellow, as it should be. I just realized the progress text isn't showing. I do have it turned on in the ini. I've found that it can be hit and miss, which is very annoying. Not just with NUI - all of them.

NUI Stats 1.jpg

I'm guessing this level progress hasn't been initialized properly. The bar starts out red or blue, but it needs to be reset with the proper progress value and colour, which would be the same as the HUD.

The third tab of the Stats menu needs to lose the progress bars:

NUI Stats 2.jpg

Here's how it looks in Darnified:

DarNCharacterSkillsMenu.jpg

Don't forget that skills do not change as you play with Oblivion XP, so the progress bars are meaningless and confusing.

Share this post


Link to post
Share on other sites

The progress bar in the Stats menu seemed to synchronize after playing for a bit, but the colour was still red. It should be yellow under normal circumstances. It should change to orange with rested XP. That's done with script, so I'm not sure what's going on there.

Also when it's time to level up, the levelling meter should just say "Click to Level Up" and not have the current level. The other UI's show the meter and the level separately, so it's obvious it's time to level up:

Stats Menu Level-up.jpg

Is the spacing between the elements the same as it is for Darnified or DarkUId Darn?  The attribute and skill names need to have enough space for the increased length with other languages.

NUI levelup menu.jpg

Also we really need to get rid of the vertical scrollbar, as I said previously. I love the arrows for switching between the skill panes. Much better!  I also like the arrows for changing the skills and attributes. They really fit with the design.

Edited by AndalayBay

Share this post


Link to post
Share on other sites

My idea for improving the keyboard/gamepad navigation of the levelup menu was to move the skill pane selector to the bottom:

NUI Levelup mockup.jpg

I think we'd also have to make the selector look more like a button or change the styling so that it stands out more.

Share this post


Link to post
Share on other sites

None of Oblivion XP's scripts use GetActiveMenuComponent. You might try sending Kyoma a message on Nexus about this.

The crash arose from some of your code using MenuQue's selector, not its script commands -- think <copy src="active(blahblahblah" trait="filename" /> and so on.

Is Kyoma active?

I think people do appreciate the reminder of what the various skills and attributes do. I remember I found it pretty tricky to do at the time, so I'd like to see those preserved if possible.

Your scripts have code that could compensate for the lack of active(), but I don't know if it's functional. I'll have to see. Alternatively, I could contact Kyoma and see if they'd be willing to help resolve whatever issue is happening here -- but that would likely take more time.

First the level progress on the Stats menu is different than what's shown on the HUD. The two bars should be the same with the same colour.

I forgot to reproduce the code for that in StatsMenu, and some image files needed editing. Changes made.

The third tab of the Stats menu needs to lose the progress bars:

Done.

Also when it's time to level up, the levelling meter should just say "Click to Level Up" and not have the current level.

Changed.

Is the spacing between the elements the same as it is for Darnified or DarkUId Darn?  The attribute and skill names need to have enough space for the increased length with other languages.

The spacing for the attributes and skills in LevelUpMenu? Would the spacing values for those menus still work, given NorthernUI's fonts?

If you know the foreign-language names for these attributes offhand, I can test them directly to make sure they fit. We could probably shrink the column spacing for attributes just a bit.

Also we really need to get rid of the vertical scrollbar, as I said previously.

Skill pane has been expanded to fit all seven rows for the three skill categories.

I've noticed that Oblivion XP has stub code and elements for "extra skills" -- the ones people can add with MenuQue, I presume? If someone were to have more than seven extra skills (and if ObXP were to render those), the scrollbar would appear as you've seen it before.

I love the arrows for switching between the skill panes. Much better!  I also like the arrows for changing the skills and attributes. They really fit with the design.

Thank you. The vanilla UI had already had widgets like this (I call them "enumpickers" internally) in its option menus, which is what led to my creating the graphics for that.

My idea for improving the keyboard/gamepad navigation of the levelup menu was to move the skill pane selector to the bottom:

That on its own wouldn't improve keyboard navigation... However, it occurred to me that I could just make the selector its own focusable element -- so, instead of pressing LB/RB to switch categories, I just make the selector itself able to gain mouseover/keyboard focus (keyboard navigation "between" lists goes to it instead of just taking you from one list to the other), so you can navigate "to" it and then press left or right "on" it.

Just implemented that, and it works!

I think we'd also have to make the selector look more like a button or change the styling so that it stands out more.

Took the opposite approach: the buttons for stats now explicitly have +/- symbols.

The updated level-up menu, with all changes:

22330_20181016202424_1.thumb.png.7d0029fac74a291bc6aab67bd9a7b85a.png

-----

Updated list of changed files:

  • menus/levelup_menu.xml
  • menus/main/hud_main_menu.xml
  • menus/main/hud_subtitle_menu.xml // for repositioning notifications below the XP bar
  • menus/main/stats_menu.xml
  • menus/prefabs/ObXP/levelup_av_template.xml
  • menus/prefabs/ObXP/levelup_config.xml
  • menus/prefabs/ObXP/generic/vert_floating_scroll.xml
  • textures/menus/Oblivion XP/stat_ribbon_full_green.dds
  • textures/menus/Oblivion XP/stat_ribbon_full_orange.dds
  • textures/menus/Oblivion XP/stat_ribbon_full_yellow.dds
  • textures/menus/Oblivion XP/xpbar_ribbon_full_blue.dds
  • textures/menus/Oblivion XP/xpbar_ribbon_full_green.dds
  • textures/menus/Oblivion XP/xpbar_ribbon_full_orange.dds
  • textures/menus/Oblivion XP/xpbar_ribbon_full_red.dds
  • textures/menus/Oblivion XP/xpbar_ribbon_full_yellow.dds
  • textures/menus/NorthernUI/buttons/hd_arrow_h_plusminus.dds

Package containing only the above files:

current.rar

Share this post


Link to post
Share on other sites

Oh whoops, lol, I forgot about trying to show stat images/descriptions because I got too caught up in the other fixes.

Any suggestions as to where images/descriptions could be shown? My thought is to have the hint text at the bottom get temporarily replaced with the stat info whenever a stat is hovered, but I don't know if that'd be enough room (or if you'd prefer something else).

Share this post


Link to post
Share on other sites

I just sent a note to Kyoma on Nexus. It looks like he has been around recently. I've asked him to drop in and I gave him a link to this thread. I'm sure his ears are burning... :D

You can actually see how things look in other languages by downloading the appropriate strings file. Just unzip the archive into your Data directory. It's a custom strings file, so it won't override anything else. I can do it if you want, but it might be faster for you to see it first-hand. I think French was the one that took the most space.

When we did the last round of overhauling the menus and the code, Kyoma set things up for X-skills, which are custom skills that you can create with MenuQue. Only one modder has taken advantage of that feature, so I decided not to implement the support for X-skills. It's good to know that if things change, our new level-up menu will work. :thumbsup: I'd have to take a peek at what you did and see about implementing it for the other UI's. :D

The new menu is looking great. If you look at the levelup menu for the other UI's, screenshots here, you'll see that we put the skills on the left so that there's enough space for the description and icon on the right. Both the attribute and skill descriptions and icons are displayed in the same spot. We also left-justified the instructions (Choose which...).

When the player increases a skill to a new level of mastery, the skill perk description pops up. Will that work with your menu?

Share this post


Link to post
Share on other sites

I grabbed the latest package and I see you've packaged your plus-minus arrow buttons with Oblivion XP. Do I need to include them with the Oblivion XP files or are you going to package them up with Northern UI?

Share this post


Link to post
Share on other sites
Quote

I just sent a note to Kyoma on Nexus.

If Kyoma decides to investigate the incompatibility, then pertinent code files for NorthernUI include:

  • Patches/CleanUpAfterMenuQue.h
    • Overview.
  • Patches/CleanUpAfterMenuQue.cpp
    • I readily admit that the code here is hideous.
    • Code identifies MenuQue's address space and tests for known MenuQue versions. Address space data is made accessible to other patch files, which call MQ subroutines directly when needed.
    • For known MQ versions: patches an unknown method in MenuQue's TileLink class; patch tests whether (this == nullptr), and returns immediately if so. This resolves crashes that occur if mouseover focus belongs to a tile in a non-vanilla menu (i.e. the extended menus that NorthernUI adds to the game) or a not-currently-active menu (the latter can happen due to vanilla edge-cases involving the fading of a submenu).
  • Patches/TagIDs/Operators.cpp
    • Overwrites MenuQue's hook to Tile::Value::DoActionEnumeration so that we can run custom operators. MenuQue's subroutine for operators is located in-memory and called directly; we attempt to supply it with the same data it would've pulled from the vanilla subroutine.
  • Patches/TagIDs/Main.cpp
    • We overwrite TileTemplate::AddTemplateItem; the replacement subroutine is based on my handmade translation of the vanilla subroutine from x86 to C++. We reproduce MenuQue's patched behavior for extended tag attributes by hand.
      • MenuQue's XML entities are also reproduced, but not in that file: I needed to patch how the game recognizes numbers (so that "..." didn't count as the number zero), I needed that "nbsp" entity, and I noticed MQ offered it, so I decided to offer the same entities but wrote my own code to do it during the number/string parsing code.

Known incompatibilities so far:

  • Use of the "active" selector causes crashes inside of the same TileLink subroutine that I patched per the above.
  • The "length" operator fails, but I can't tell how. <string><length...></string> returns an empty string, and <length...><gt>3</gt> always returns false.

I didn't test all of MenuQue's extensions to the UI engine, because I couldn't find documentation for any of them. The bundled readme and CS wiki pages only document the new script commands and a few basic concepts for using them; new traits, operators, and selectors are generally totally undocumented, as is the new tile class.

Quote

I think French was the one that took the most space.

Probably in the aggregate, but German actually has the longest skill name ("Überredungskunst"). I decreased the "_attr_column_spacing" config value from 48 to 40 in response.

...German's the longest out of the testable languages, that is. The Western build of Oblivion assumes a single-byte text encoding (in both the compiled code and the font files), but CJKV languages are multi-byte, so I wouldn't even be able to test those; they'd just produce mojibake.

Quote

we put the skills on the left so that there's enough space for the description and icon on the right. Both the attribute and skill descriptions and icons are displayed in the same spot. We also left-justified the instructions (Choose which...).

The positioning is doable. The larger issue is that we will need to fix the NorthernUI/MenuQue compatibility problem in order to get stat descriptions set up cleanly. We can do it filthily, though...

Your mod has script code to handle the image for the hovered stat, but not the text. If we can't get the active() selector to work, then there's no way to get the right text unless you make the following changes to your script:

  • ObXPUILevelUpMouseoverFn needs to write the value of the actorVal variable to any trait on any non-templated tile in the UI. Writing it to the menu root is permissible. If you want a "sticky" display (i.e. always show the last hovered stat if you're not hovering over a stat), then skip writing the value if it's -1.
  • The loop in ObXPUILevelUpOpenFn needs to be modified: when tempString gets set to an attribute or skill's description, its value needs to be written to a non-templated tile trait named "_statDesc_XXX", where XXX is replaced with the current value of actorVal. So, on a non-templated tile, there'd be _statDesc_1, _statDesc_2, _statDesc_3, and so on.

With those changes, I'd be able to do XML switch-casing. Obviously that'll be making a mess of your code, in order to solve something that shouldn't be your problem. That's a situation I've ended up in while working on NorthernUI, and my choice was to deal with it and make my code ugly, but I really don't like saying "deal with it and make your code ugly" to someone else as advice.

Quote

I grabbed the latest package and I see you've packaged your plus-minus arrow buttons with Oblivion XP. Do I need to include them with the Oblivion XP files or are you going to package them up with Northern UI?

You'll need to include them unless I update NorthernUI first. I created them specifically for this situation.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

I remember we had a lot of trouble with the translation of "Hand to Hand".  Right, Sita compromised on the translation. It's supposed to be "Combat à mains nues" but that wouldn't fit. Schleichfähigkeit is longer than Überredungskunst. :D I can load all the strings files, which is good since I have to edit them all with each new release. I just look for the version number and change it. :lol:

Yuck! Hopefully Kyoma will drop in and provide some guidance.

Yeah I meant long term. When you put the xml in a Northern UI directory, I suspected you wanted to package it with NUI.

Share this post


Link to post
Share on other sites

Yeah I meant long term. When you put the xml in a Northern UI directory, I suspected you wanted to package it with NUI.

Feel free to package it with Oblivion XP. I placed it in the folder that I did mostly because I was just too lazy to change the filepath I was already using in the XML. If I ever do package that file in NorthernUI, we'll just have "conflicting" files that are identical.

As for active(), I'll take another look at it (basically reverse-engineering Kyoma's code the same way I did Bethesda's) and see what I can do, but that, as with anything in disassembly, is a no-guarantees thing.

Share this post


Link to post
Share on other sites

Kyoma is on Github, but the MenuQue repository is empty.

So at this point, the mouseover stuff isn't working, correct? Users won't get the skill and attribute descriptions? What about the skill perk pop-up? I think you missed my question about that above. I posted a link to a screenshot to show you what I mean.

Share this post


Link to post
Share on other sites

What about the skill perk pop-up? I think you missed my question about that above. I posted a link to a screenshot to show you what I mean.

Seems to work.

Had to view the script code to test it, since I didn't understand the features involved... Apparently, there's a minimum level requirement for each skill "mastery level," i.e. novice, apprentice, journeyman, and so on. My test character was below the requirement; I had to console-command it down to 1 before I could test.

22330_20181017215056_1.thumb.png.7cfd3d0e3b808c1b97c947f77866f8bc.png

Share this post


Link to post
Share on other sites

Figured out the active() problem; it was an issue with one of my MenuQue compatibility fixes. I used the wrong register when returning to MQ code, so I was blowing away an important pointer and causing memory corruption (but only when that selector was used, and since your mod appears to be the only one ever made that uses it,...).

Working on publishing the patch now. After that, I'll take a look at getting stat descriptions set up for the LevelUpMenu.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×