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

Here's the new plugin. It seems to work with the other UI's, but I haven't tested all of them yet. If it works with one, it should work with them all.

Could you upload your new levelup menu? I've got a placeholder image that I'd like to play with and I don't feel like figuring out how to get it coded up. :P

Share this post


Link to post
Share on other sites
Quote

tile_SetString "%z\_descript|%z", pathName, descr, 1027

But I think I better understand how that works, at least. Try this instead:

tile_SetString "\user6|%z", descr, 1027

I also still need to know what actor value is being hovered over. I think that would be this line? It would need to run regardless of what kind of actorVal we're working with (in particular, we want to write -1 to the trait when not hovering over anything).

tile_SetFloat "\user7" 1027 actorVal True

That last argument would be either "True" or "1". I can read OBSE script, but I don't fully know how to write it, else I'd have been happy to do so myself.

Again, if we can't get this figured out in script, I can try and do something similar in my DLL to meet the same need.

 

New menu files: updated only.rar

GIMP file for the placeholder I made: OblivionXP_NorthernUI_Working.xcf

I'm pretty sure this just sets the description to itself? Like, you get the description from the tile indicated by pathName, and then write the value you get right back to that same tile.

EDIT: The new menu file is, uh, without the removal of the "Skills"/"Attributes" label yet. Working on that now.

Also, how do I edit a post in raw BBCode? The "quote" button completely broke here, as you can probably see...

The part of my post that got eaten by the broken editor is that the top line of code won't work. You get a trait from the tile specified by pathName, and then you write that trait right back to that same tile.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

I can do the scripting, I'm just not following what you're trying to do. Is user6 used by all UI's? Is it always the description?

In the mouseover function, the actor value is _actorVal. The local variable is set to -1 when the mouse isn't passing over an attribute or skill. So you're saying you want the -1 to be applied to the menu? User7 seems to be a scroll bar, which doesn't make any sense to me. :P If you want the actor value to be set to -1 in the menu, then I would be inclined to do it this way:

tile_setFloat "%z\_actorVal", pathName, 1027, -1

I don't know what the "canCreate" boolean is for. Do you? If you're sure that user6 is the description and user7 is the actor value, then I can certainly switch to using them.

For the record, here are some values for pathName:

pathname: levelup_background
pathname: bottom_bar\controls\levelup_exit_button
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV3
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV2
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV1
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV0
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV1
pathname: levelup_background\OXP_attributes\OXP_attributes_pane\OXP_AV1\enumpicker\_plusImg
pathname: levelup_background\OXP_skills\OXP_skills_pane\OXP_combatskills\OXP_AV15
pathname: levelup_background\OXP_skills\OXP_skills_pane\OXP_combatskills\OXP_AV16
pathname: levelup_background\OXP_skills\OXP_skills_pane\OXP_combatskills\OXP_AV15
pathname: levelup_background\OXP_skills\OXP_skills_pane\OXP_combatskills\OXP_AV16
pathname: levelup_background\OXP_skills\OXP_skills_pane\OXP_combatskills\OXP_AV18

I really wish the syntax was consistent for those tile_xxx functions. :mad:

Share this post


Link to post
Share on other sites
38 minutes ago, DavidJCobb said:

 

I'm pretty sure this just sets the description to itself? Like, you get the description from the tile indicated by pathName, and then write the value you get right back to that same tile.

Pretty much. It doesn't make sense to me, but I thought that's what you wanted. If I set the String attribute, it didn't work. I had to let the menu do its thing with the active() call.

Share this post


Link to post
Share on other sites

In the mouseover function, you set a script variable named actorVal to the value of the trait _actorVal on the tile that has mouseover focus. If the tile in question is not a skill or attribute, you set the script variable actorVal to -1. Similarly, you set the script variable descr to the value of the trait _descript on the tile that has mouseover focus.

What I need you to do is write the values of those two script variables to traits on the menu's root tile, so that I can use XML-side <copy/> operators to access them. The user6 and user7 traits aren't used for anything on that specific tile in that specific menu, which is why I picked them. In essence, I want to be able to do this:

<visible>
   <copy src="menu()" trait="user6" /> <!-- actorVal, supplied by the script -->
   <gt>-1</gt>
</visible>
<string>
   <!-- I'd comment out the copy active() stuff -->
   <copy src="menu()" trait="user7" /> <!-- descr, supplied by the script -->
</string>

What you're doing at present is setting the _descript trait on the tile that has menu focus, and you're setting it to the value that it already has. You're also not writing the actorVal variable to any tile in the menu. To write to the menu's root tile, you should just be able to do "\traitNameHere".

I also (and I just remembered this) need you to get me the name of the actor value as well -- so I need you to get the _name trait, store it in some variable, and write it to... let's say user8 on the menu's root tile. Then, I'll be able to grab that just like the stat description.

The "canCreate" boolean should create the trait that you're trying to set if it isn't already specified in the XML. Shouldn't be needed, but it just kinda feels thorough to me.

EDIT: And again, if at any point this becomes too bothersome, I can probably set up a DLL-side fix fairly easily. I just don't want to go about messing with that if you're willing to try doing it through script; no use having both of us write code to do the same thing.

Edited by DavidJCobb

Share this post


Link to post
Share on other sites

I know what the mouseover script does, but I missed the part about you wanting the values written to the menu's root tile. Initially I tried setting the String trait as you indicated here and that didn't work at all. We need to make sure the code continues to work for those using a mouse. We also need to make sure we don't break the other UI's.

If you're using the keyboard or gamepad, what would trigger the mouseover function? The mouseover function is the event handler for the OnMouseover event. Is that a function of your DLL?

If user6 and user7 aren't used, then yes, it would be better to use those. I guess I'll have to use the canCreate boolean because user8 won't exist in the other UI's. I'll get complaints if I have Ob XP writing errors to the console.

Here's the new script if you'd like to install the CSE and give it a try yourself:

scn ObXPUILevelUpMouseoverFn

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

Begin Function { menuType, pathName, buttonId }

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

	let descr := tile_GetString "%z\_descript", pathName, 1027
	let sName := tile_GetString "%z\_name", pathName, 1027

	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
	elseif ( buttonId == 100 || buttonId == 110 )
		; _plusImg or _minImg
		let actorVal := tile_GetFloat "%z\...\_actorVal", pathName, 1027
		let picture := tile_GetString "%z\...\_smallpicture", pathName, 1027
	else
		let picture := "Bla"
		let actorVal := -1
	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
	
	; write current values to user traits for Northern UI
	tile_SetFloat "\user6", 1027, actorVal
	tile_SetString "\user7|%z", descr, 1027
	tile_SetString "\user8|%z", sName, 1027, 1

	if ( actorVal >= 0 && actorVal < 8 )
		tile_SetString "levelup_background\OXP_attributes\OXP_attribute_picture\filename|%z", picture, 1027
	elseif ( actorVal >= 11 && actorVal < 33 )
		tile_SetString "levelup_background\OXP_skills\OXP_skill_picture\filename|%z", picture, 1027
	endif
	
	sv_Destruct pathName, picture, descr, sName
End

I haven't tested that yet, so it may not work. I'm hoping that you'll only expect the user traits to have real values when the actor value isn't -1. And yes, the damned editors and other forum bits are all kinds of busted. This is IPS 4 and it sucks. We will be switching to other forum software, if I ever get time to finish my evaluations. :P

Edited by AndalayBay
Fixed small error in script

Share this post


Link to post
Share on other sites

Here's what I came up with for the placeholder. What do you think?

ScreenShot25.jpg

The forums aren't doing a good job of resizing that image. It looks crisper than that. :P Also, the image is still too big. I set _allowStretch to false, but I guess there's still a zoom factor. I don't think the image needs to fill that spot.

Share this post


Link to post
Share on other sites

I tested my script changes against DarkUId Darn and they seem to work, so here's the full package. That also includes my placeholder image with the appropriate changes to the level-up menu. I called the image OblivionXPLogo.dds as I'm thinking of adding it to all the UI's.

Share this post


Link to post
Share on other sites

Looking good! I gave the new version a quick test run with Northern UI and DarkUId DarN and the level-up menus seem fine. Now I need to fix up the installation scripts. I might add the placeholder to the other menus too. I’ll see how much work it is. :P

Thanks again for your help. :beerchug:

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

×