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

47 minutes ago, DavidJCobb said:

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,...).

I'm special. :lmao:

That's great news. I had to restructure the BAIN package, so I've been testing it with each UI to make sure I got everything.

Share this post


Link to post
Share on other sites

Updated files only: updated only.rar

Just make sure your users know that the LevelUpMenu will CTD if used with a version of NorthernUI older than 1.0.15.

22330_20181020211625_1.thumb.png.bbeff1ee3de131136dee8ad6df016a7c.png

22330_20181020211638_1.thumb.png.e5faed8622645e7fbf03c0c9839c59a8.png

I decided to have the stat description also show the name and type of the hovered stat just because I needed something to fill that space. There's no way to do floated content (i.e. the description text wrapping around the image) in Oblivion, so there wasn't any way to have the stat image by itself without it looking awkward. The stat-name tiles also use the active() selector and honestly? I can totally see why Kyoma implemented that. Super useful idea!

Share this post


Link to post
Share on other sites

One slightly awkward thing, though: that space is just totally blank when you're not hovering over a stat. Looks a bit awkward to me, but maybe not to you?

I kinda wish I could put a subtle, generic image (think of, like, a faded grey symbol with no shading) there whenever you're not hovering over something. It's absolutely doable from a technical standpoint, but believe it or not, I'm not exactly a graphical artist, and I don't know what graphic I would want there anyway.

Eh. I understand the comparable space in other UIs would also show up blank, given how that's been designed. If it's awkward, then it's consistently awkward.

Share this post


Link to post
Share on other sites

First, that's super! Second, I really never thought about the empty space. We could use the Oblivion XP icon. I'm good enough at Photoshop to make it semi-transparent or faded, but it might be more work than it's worth. People aren't in the level-up menu all that long. They are bumping up their stats and moving on. I've never had anyone comment on the empty spot. :)

Share this post


Link to post
Share on other sites

We have a problem. While setting up the filler-image idea and testing it, I just discovered that MenuQue's active() selector doesn't appear to react to keyboard navigation. This means that:

  • When the menu is first opened, the wrong values are displayed, because the initially-focused tile is considered to have focus from keyboard navigation.
  • If you use keyboard navigation while the mouse isn't over a stat, then you only see the image and stat type (because your script updates the image).
  • If you use keyboard navigation while the mouse is over a stat, then the image and type of the keyboard-navigated stat is shown, but the description and name of the moused-over stat is shown.

Not sure if this is my fault or MQ's fault, and I can't easily test it since your files for other UIs don't have keynav support. Either way, it means that unless Kyoma stops by or you handle this script-side like I described, stat descriptions aren't going to be viable.

EDIT: That said, if we do get stat descriptions working (however we do it), I set up a NorthernUI-themed variant of your logo as a placeholder image (but of course, we can use anything you prefer!), and it looks like this:

Spoiler

22330_20181020220055_1.thumb.png.90175e7b491ef7641b2b42807cc4de06.png

And just so I remember: I've got the image for that at Textures\Menus\Oblivion XP\OblivionXP_NorthernUI.dds.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

Would having the placeholder image help with the problem? As I said, I didn't even know keyboard navigation was an option. I really don't think anyone will use it. Could you set the focus to the Strength attribute? You might have to also set the image and description to Strength as well. I don't know what to do about the mouse pointer though.

I'm hesitant to handle this script-side because the other UI's don't have this issue. I'd have to detect that it's Northern UI and have custom code for it.

In terms of the placeholder image, that's the idea, but I think it should be a bit smaller and fainter. It really dominates the menu.

Share this post


Link to post
Share on other sites

Would having the placeholder image help with the problem?

No. The placeholder is entirely an aesthetic thing.

I really don't think anyone will use it.

Gamepad navigation is keyboard navigation, so those folks, at a minimum, would be using it as their default mode of interaction.

Could you set the focus to the Strength attribute? You might have to also set the image and description to Strength as well.

There is no XML-only way to compensate for any problems with the active() selector.

I could update my DLL to patch the internal LevelUpMenu class to have Oblivion XP-specific mouseover code, and then forego the active() selector in our XML. Not the nicest way to go about things, but not impossible.

Notes on this for my own reference:

  • We need to find the LevelUpMenu class within the game's code, and decode it as we would any other menu.
  • We need to reserve an ID value for Oblivion XP's AV template to use; I usually start at 9001 for injected tile IDs.
  • We could make things easier on ourselves by having the template copy its pertinent values into user## traits for easy reading; otherwise, we'd have to call RE::GetOrCreateTempTagID.
  • For writing the current values to the root tile -- likewise.
  • It's easy to forget, but the Menu class does have a mouse-out event that we can use to catch the case of no stat having mouseover focus.
    • Mouse-over needs to check this, too; we may not be mousing over a stat.
  • We should probably also pass the actor value index to the root tile. That way, we don't actually have to reorganize the setup we already have.
    • Set it to -1 when not hovering over a stat.

I'm hesitant to handle this script-side because the other UI's don't have this issue. I'd have to detect that it's Northern UI and have custom code for it.

It would only be different if you have any UI setups wherein OXP_skill_descr and OXP_attribute_descr don't use the active selector as follows (with the attribute description using the attribute pane instead of the skills pane):

<string><copy src="active(OXP_skills_pane)" trait="_descript" /></string>

If all of your UI setups do that for their string trait, then the script code needed for NorthernUI compatibility would basically just be doing what every UI already does with their active() traits.

In terms of the placeholder image, that's the idea, but I think it should be a bit smaller and fainter. It really dominates the menu.

22330_20181020230131_1.thumb.png.6c68aba903903d12d4e578b347799ae6.png

How 'bout this?

Share this post


Link to post
Share on other sites

Ok, so what would I need to do via script? As I said before, there’s actually only one level-up menu for all the other UI’s. I just had to change the levelup_config xml to set the sizes, fonts and colours. So yeah if I don’t have to detect NUI, I can take a look. I’m just not clear on what I’d need to do. :P

Share this post


Link to post
Share on other sites

Ok, so what would I need to do via script?

You'd need to modify the ObXPUILevelUpMouseoverFn script:

  • In addition to getting the _actorVal and _smallPicture traits, also store the _descript trait in a string variable. (In the else branch that sets the actorVal variable to -1, set the string variable to a blank string.)
  • When setting the OXP_skill_picture\filename trait and OXP_attribute_picture\filename traits in the existing script, add code to set the OXP_skill_descr\string and OXP_attribute_descr\string traits to that new string variable.
    • If you're super worried about compatibility with your code for other UIs, then you can set a trait other than string on those two tiles, e.g. user10. Other UIs shouldn't be using that, so we can use it freely.
  • This isn't super important, but if you want the menu to be able to display whether we're hovering over a skill or attribute ("Attributes" or "Skills" next to the stat icon), then your code also needs to set the user6 trait (or any other user## trait after user5) on the menu's root tile to the actorVal variable. This needs to be a "set float" call, not a "set string" call (check the MenuQue docs); I can't do integer comparisons (e.g. AV less than 12 = attribute) on the string "5" as opposed to the number 5, for example.

Again, I should be able to accomplish the same goals by editing my DLL (but not tonight; maybe tomorrow) if you don't want to bother. If you don't run into any trouble with it, then it'll be faster for you to write the script for it; if you do run into trouble with it, then I can still do it in the DLL.

I basically rely on the email notifications from this thread as my to-do list, so reply to me with how you want to play this, and I'll see to it probably tomorrow.

Share this post


Link to post
Share on other sites

Yeah let me take a look. One thing we need to keep in mind are the translations. I don’t think I have a line for “Skills” or “Attributes” as a single word, so we should probably remove that. I’ll take a look at the placeholder image as well. I won’t be back to modding until later tonight though. I’m UTC - 4, btw.

Do we need to remove the active() calls from the menus then?

Share this post


Link to post
Share on other sites

One thing we need to keep in mind are the translations. I don’t think I have a line for “Skills” or “Attributes” as a single word, so we should probably remove that.

I used the game's own strings() for that. It should match whatever language the base game is in.

Do we need to remove the active() calls from the menus then?

Probably not; a "set trait" call from a script should overwrite whatever's in the XML.

Share this post


Link to post
Share on other sites

Got it! This turned out to be tricky. Setting the string value caused a conflict between the mouseover code in the plugin versus the active() call in the menu. As you moved the mouse around, you'd get overlapping descriptions due to the difference in timing. The solution was to set the actual trait and let the menu code continue to set the string.

I decided not to mess with the skills or attributes sub-title on the description. Can we remove that? The skill or attribute should be highlighted so people will know whether it's a skill or attribute description. Trust me, they'll know anyway. :P

Here's the new mouseover function code:

scn ObXPUILevelUpMouseoverFn

; Parameters
short menuType
string_var pathName
short buttonId
; Locals
long actorVal
string_var picture
string_var descr


Begin Function { menuType, pathName, buttonId }

	; Safety check 
	if ( menuType != 1027 )
		return
	endif

	if ( tile_HasTrait "%z\_smallpicture", pathName, 1027 )
		; top-level template
		let actorVal := tile_GetFloat "%z\_actorVal", pathName, 1027
		let picture := tile_GetString "%z\_smallpicture", pathName, 1027
		let descr := tile_GetString "%z\_descript", pathName, 1027
	elseif ( buttonId == 100 || buttonId == 110 )
		; _plusImg or _minImg
		let actorVal := tile_GetFloat "%z\...\_actorVal", pathName, 1027
		let picture := tile_GetString "%z\...\_smallpicture", pathName, 1027
		let descr := tile_GetString "%z\_descript", pathName, 1027
	else
		let picture := "Bla"
		let actorVal := -1
		let descr := ""
	endif
	
	; reset pictures
	tile_SetString "levelup_background\OXP_attributes\OXP_attribute_picture\filename|Bla", 1027
	tile_SetString "levelup_background\OXP_skills\OXP_skill_picture\filename|Bla", 1027
	if ( actorVal >= 0 && actorVal < 8 )
		tile_SetString "levelup_background\OXP_attributes\OXP_attribute_picture\filename|%z", picture, 1027
		tile_SetString "%z\_descript|%z", pathName, descr, 1027
	elseif ( actorVal >= 11 && actorVal < 33 )
		tile_SetString "levelup_background\OXP_skills\OXP_skill_picture\filename|%z", picture, 1027
		tile_SetString "%z\_descript|%z", pathName, descr, 1027
	endif
	sv_Destruct pathName, picture, descr
	
End

This was a function that Kyoma wrote after he switched to the new syntax. I was hoping that he allowed for more than one parameter and indeed he did. I'll do a bit more tidying up and then will post a new plugin.

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

×