Ability to make Abstract Widget "classes" or user defined Widget Types?

[jeremyosborne]

For relative positioning, the parentWidget and parentLinked are god sends.

I'm modding the Conjurer party pet status bars that normally appear below the character status along the left hand side of the screen.

Since all of the partyMember*.mnu files contain reused data, I was trying to figure out how to build an abstract widget type that would lend repeated values to descendant widgets.

Example pseudo code of what I want to do:

// In some file named abstractPartyMenu.mnu
name PartyMemberType

// Below I define the Widget, StatBar, and StatusEffectIcons
// curently found in the partyMember*.mnu files
// and give all of the widgets internalName values

and in another file

name PartyMember1
inheritsFrom PartyMemberType
// I supply the positioning for this widget 
position 5.0 80.0

// For each of the properties that are not generic
// I set the non-generic values. For example,
// the Health bar widget
StartBar
{
    // operates like the parentWidget property
    inheritsFrom PartyMemberType::HealthBarForegroundType
    // size, color, texture aren't needed, but the
    // entityIndex would need to be modified
    entityIndex 0
    // and so would any specific activities
    highlightRedirect PartyMember1::Portrait
}

Is this, or something like it, possible?

[Shadow]

No there's not. I keep wishing I had some way to inherit or include but I've never implemented anything for it.

[jeremyosborne]

I did a bit more experimentation yesterday with the UI and was able to package up "widget families" a bit better. I made what I called a PartyMembers::Container which positioned all of my lackies in an absolute location on the screen. From there I contained each PartyMemberN widget family in a PartyMemberN::Container, and from there, even though I had to Copy+Paste each widget instance, it was much easier and almost classlike to just copy paste things.

The only changes I needed to make were to the entities that each referred to.

The fact that you allow me at least a ParentWidget type of relationship is good enough in my view... although if you ever get the inheritance thing working, I'll be the first to try it out.

[jeremyosborne]

By the way, I did notice something that others making UI changes might wish to know, so I'll just jot it here for archiving purposes.

Version I'm working with: 1.010

When I built said PartyMembers + PartyMemberN position relationships for my UI, I noticed that if I create the following sort of parent relationship in a single file, like so:

// This is a snippet from my partyMember1_override.mnu file
// A PartyMembers UI object is created in an external file
name PartyMember1

Widget
{
    // SNIP: This internalName would allow me to reference
    // PartyMember1::Container throughout the file, and it does
    //at load time
    internalName Container
    
    // This relationship, I believe because the widgets live in
    // different files and the files are read at different times does
    // not cause a "cannot find" error when using reloadMenus
    parentWidget PartyMembers::Container
}

Widget
{
    //SNIP:
    // Referencing a named widget within the same file will
    // cause a "cannot find" error when using the reloadMenus
    // command.
    parentWidget PartyMember1::Container
}

To repeat the code comments:

Relationships work fine at load time.

I had a problem with the reloadMenus console command giving me errors when using parentWidget and the associated parentLinked (snipped out of the code above) for positioning.

If reloadMenus doesn't seem to work and is returning errors, before giving up on the UI modifications, try quitting/restarting din's curse.