Jump to content

Why are so many HUDs so large?


Jim Crisp
 Share

You are about to reply to a thread that has been inactive for 1567 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

On 12/6/2019 at 11:41 PM, Orwar said:

I take it we shouldn't become pen pals then ... Those squares are 5 mm (roughly 5 squares per inch, for those across the pond!). The x-height is 1.5 mm, and it's written with a mechanical pencil with a 0.3 mm gauge.

I see you're a man of good taste in hand-writing. People look at me weird when I give them my 0.25 mm.

6 hours ago, Nalates Urriah said:

Also, there is the LlDetectedTouchPos function that will allow use of a single prim. Paint your buttons on the texture and use LlDetectedTouchPos to tell if they clicked within the area that is the button. I made a script to help me get the button's location/area when building a script. I used to try and sell it. The downside is lots of buttons makes for a complex script.

If you exchange llDetectedTouchPos and coordinate-checking (which is hard to maintain) with llDetectedLink, this is the correct way to do a multi-button HUD with one script. This way, you can have one texture for the HUD (or per HUD page if you don't want to figure out offsets) and only need to move the buttons around to get the exact placement/size you need.

  • Like 1
Link to comment
Share on other sites

On 12/6/2019 at 1:11 PM, janetosilio said:

Funny story: When Genus heads were in beta, they were asking for feed back. One of the main complaints that first week was “the hud is too small! Make it bigger.” Now it has a large hud and a small hud that comes with the head.

I like how Catwa's current HUD (and the version prior to it) has resize buttons.

I like even more when the 'prim' side of a HUD is just mod... so I can do as I wish with it.

 

That said, any HUD not in ACTIVE use; I detach. Though I imagine the issue being spoke of here is the mess when trying to customize an avatar - you need to see both your avatar and all those HUD on the screen at the same time...

 

  • Like 1
Link to comment
Share on other sites

On 12/7/2019 at 1:28 AM, Orwar said:

   Hm ... No idea, but that's an interesting question ... Goes off to dig around in the Firestorm wikis.

I believe no.

What I did was write a super small script that runs the animations for my bento addons.

Here's the one for my ears:

testMemory()
{
    llScriptProfiler(PROFILE_SCRIPT_MEMORY);
    integer usedMemory = llGetUsedMemory();

    // a tiny buffer to please my sanity. Up this by a small amount if you get stack heap errors in testing.
    // Alternatively considering changing the formular to: (usedMemory * 1.2).

    llSetMemoryLimit((usedMemory + 500));


    llScriptProfiler(PROFILE_NONE);
}

default
{
    state_entry()
    {
        llSetMemoryLimit(18888);
        llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION);
        testMemory();
    }
    on_rez(integer start_param)
    {
        llSetMemoryLimit(18888);
        llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION);
        testMemory();
    }
    run_time_permissions(integer parm)
    {
        if(parm == PERMISSION_TRIGGER_ANIMATION)
        {
            llStartAnimation("Ears");
        }
    }
}

 I am planning to include it with the one for my tail as well...

My tail one responds to a chat command on a special channel to change the animation - and has 30+ animations, which is why I haven't combined it yet.

Ear script: 5kbs, +64 for a second script that the ear maker put in there that I have yet to reverse engineer because it runs a deformer...

Tail script: 14kbs.

- That's allocated memory. They also use very little script time, which is the actual important metric...

My tail script:

// channel to listen on.
// 43 was just a random number that I saw as unused but could remember easy.
integer LISTEN_CHANNEL=43;

// Put the default you want on rezzing here. Or set to "" to have the script randomize it
string currentAnim = "SwingCenterMedium";

// Leave these blank.
string lastAnimState = "";
integer choice = 0;

// Cap the script to this memory usage. Dummy value replaced by test.
// 18888 just happens to be what the test returned the first time I ever wrote
// this function for another script, and has no importance.
integer memoryLimit = 18888;

/*
 * clearAnims
 * This function is critical in memory management and to avoid 'animation conflicts / ghosts'. Without this, old anims
 * can sometimes 'pop back up' and start playing when the avatar transitions to a new state.
 * Sitting/standing, changing sim, etc. There will also be an eventual stack heap collision error if this is not run,
 * once you have 'too many' anims lingering. Note that this is written to specifically ONLY clear out anims that were
 * put onto the avatar by this script - anims residing in the same prim as this script. That is a security choice. We
 * don't want to go messing with other things a user might be trying to do. Besides I was unsure how to get a list of those anims
 * anyway, and didn't see a good reason to research it.
 *
 * I have encountered a few objects made by others in SL that do close all anims, even bento anims, though the objects
 * themselves were made before even mesh existed. Thus I couple this function with a timer that restarts our currentAnim if
 * the right conditions are met. See the timer() function below.
 */
clearAnims()
{
    integer i = 0;
    for(i=0;i<llGetInventoryNumber(INVENTORY_ANIMATION);i++)
    {
        llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, i));
    }
    // Specific to my brand of tail, this is a deformer that fixes how short the tail I bought was.
    // Put any other needed 'deformer' here, or remove this line.
    llStartAnimation("*LENGTH M");
    testMemory(FALSE); // rerun to avoid stack heap errors.
}

/*
 * This is a function called manually by the chat listener, to 'surprise' us with a random animation choice.
 * I have considered a feature to put this on a timer, effectively making this a cycling AO.
 */
randomAnim()
{
    integer number = llGetInventoryNumber(INVENTORY_ANIMATION);
    float rand = llFrand(number);
    choice = (integer)rand;
}

/*
 * testMemory
 * There is too much memory bloat in scripts in SL.
 * The memory a script shows is allocation, not actual - but allocation is still removal of resources from a sim.
 * So we should always allocate no more than we need.
 * There is a risk that the value set for 'memoryLimit' will be too low. Test results and adjust if there is a stack heap error.
 */
testMemory(integer verbose)
{
    llScriptProfiler(PROFILE_SCRIPT_MEMORY);
    integer usedMemory = llGetUsedMemory();

    // a tiny buffer to please my sanity. Up this by a small amount if you get stack heap errors in testing.
    // Alternatively considering changing the formular to: (usedMemory * 1.2).
    memoryLimit = usedMemory + 2000;
    llSetMemoryLimit(memoryLimit);

    // The code for verbose can be removed on a release version to save memory.
    if (verbose) {
        llOwnerSay("Limited Memory " + (string)llGetMemoryLimit() +
                   "\nUsed Memory " + (string)usedMemory +
                   "\nFree Memory " + (string)llGetFreeMemory());
        llOwnerSay("AnimationController script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test.");
    }
    llScriptProfiler(PROFILE_NONE);
}

default
{
    state_entry()
    {
        // The value here is pointless because we change it in testMemory below.
        // But not running this locks it to a maxed value.
        llSetMemoryLimit(memoryLimit);

        if (currentAnim == "")
        {
            randomAnim();
            currentAnim = llGetInventoryName(INVENTORY_ANIMATION, choice);
        }

        llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION);
        // We need awareness of our current 'pose': standing, sitting, flying, etc.
        // Later when the state changes is when we make sure our animation keeps running.
        lastAnimState = llGetAnimation( llGetOwner() );
        llListen(LISTEN_CHANNEL,"",llGetOwner(),"");
        testMemory(FALSE);
    }

    run_time_permissions(integer parm)
    {
        if(parm == PERMISSION_TRIGGER_ANIMATION)
        {
            clearAnims();
            llStartAnimation(currentAnim);

            // Occasional test to see if something stopped it.
            // 2 seconds was chosen so as to not tax sim resources, but be frequent enough to 'recover' before a typical
            // user is likely to become notably frustrated.
            llSetTimerEvent(2.048);
        }
    }
    timer() {
        string curAnimState = llGetAnimation( llGetOwner() );
        // It mostly likely freezes from a script in a state change shutting off all animations.
        // I have encountered a few objects in SL that do this intentionally even for animation outside of their
        // scope of control. The timer will let the user recover from this IF the user does an animState change.
        if ( currentAnim != "" && curAnimState != lastAnimState ) {
            clearAnims();
            
        }
        llStartAnimation(currentAnim);
        lastAnimState = curAnimState;
    }
    on_rez(integer st)
    {
        currentAnim = "";
        lastAnimState = "";
        choice = 0;
        llResetScript();
    }

    attach(key id)
    {
        clearAnims();
    }

    /*
     * listen
     * channel - the chat channel used to control the script
     * name - unused
     * id - who has sent a message on the channel
     * msg - the message sent
     *
     * I do not like HUDs that obscure my view of SL. That was the original reason for writing this script.
     * The script's purpose grew when I realized bento animations often shut off on state changes or on login,
     * but it was originally intended to just let me play with my tail without having to click my mouse
     * somewhere where I could not see what was going on because of somebody's giant art project
     * they called a 'HUD'. :)
     * All of this functionality can be removed if chat based control is not desired.
     * At that point, the script's value is in the timer and clearAnims functions.
     *
     * Alternatively, chat based control can be left in as an option for people like me who dislike HUDs. Please...
     */
    listen(integer channel, string name, key id, string msg)
    {
        if (msg == "list")
        {
            string response = "\n\nYou have these tail animations:\n+-----------------------------------------+\n";
            integer i = 0;
            for(i=0;i<llGetInventoryNumber(INVENTORY_ANIMATION);i++)
                response += (string)i + ": " + llGetInventoryName(INVENTORY_ANIMATION, i) + "\n";
            llOwnerSay(response + "-----------------------------------------+\n");
        }
        else if (msg == "current")
        {
            list anims = llGetAnimationList(llGetOwner());
            string response = "\n\nYou have these current animations:\n+-----------------------------------------+\n";
            integer i = 0;
            for (i=0;i<llGetListLength(anims);i++)
            {
                response += llList2String(anims, i) + "\n";
            }
            llOwnerSay(response + "-----------------------------------------+\n(This is all sources: your AO, furniture, any HUDs or attachments, etc.)\n");
        }
        else if (msg == "stop")
        {
            clearAnims();
            currentAnim = "";
        }
        // This routine is for accessing verbose memory testing - as in telling the user how much memory the script is using.
        // If for some reason you desire to conceal that information from the user, know that they can still guess it from looking at avatar script
        // info in About Land...
        else if (msg == "memory" || msg == "test")
        {
            testMemory(TRUE);
        }
        else
        {
            // Manually request a random animation. I have not placed this into a timer based AO setup in order to save memory and because I have not yet needed such.
            // However for something like hand poses of facial expressions that might make a lot more sense. Or... if I put together a more fluid set of tail animations
            // than the jumbled mess I have at present. I'm a scripter, not an animator... so my animation choices didn't give me a good AO result...
            if (msg == "random" || msg == "rnd" || msg == "rng" || msg == "r")
            {
                randomAnim();
            }
            else
            {
                choice = (integer)msg;
                integer number = llGetInventoryNumber(INVENTORY_ANIMATION) -1;
                if (choice > number)
                {
                    llOwnerSay("Choice invalid. Please use between 0 and " + (string)number);
                    return;
                }
            }
            clearAnims();
            currentAnim = llGetInventoryName(INVENTORY_ANIMATION, choice);
            llOwnerSay("Choice: " + (string)choice + " Anim: " + currentAnim);
            llStartAnimation(currentAnim);
        }
    }
}

 

ISSUES with combining:

All I need to do to combine these is add:

llStartAnimation("Ears");

After:

llStartAnimation("*LENGTH M");

In the clearAnims() function.

- only reason I haven't is I haven't taken the time to yet because I want to also add a routine into 'list' on Listen to not display those two animations...

I just need to sit down for a minutes and clean that up...

 

I'm showing both scripts here because if you have a single bento animation you always run you want the first script, if you have a selection of animations you want a modification of the second script.

Edited by Pussycat Catnap
Link to comment
Share on other sites

You do know that in most cases there is no need to keep the HUD on you screen unless you want to make changes to your look? I never have my mesh body or head HUDS on as I make use of the auto-hide system to manage alpha layers via a worn item I configure per outfit and my mesh head has no need for a HUD unless I need to change the look.

HUDS are notoriously texture and script heavy on the main and your SL experience will improve greatly if you really do try and avoid wearing any at all.

Link to comment
Share on other sites

On 12/11/2019 at 3:20 AM, Zak Westminster said:

You do know that in most cases there is no need to keep the HUD on you screen unless you want to make changes to your look? I never have my mesh body or head HUDS on as I make use of the auto-hide system to manage alpha layers via a worn item I configure per outfit and my mesh head has no need for a HUD unless I need to change the look.

HUDS are notoriously texture and script heavy on the main and your SL experience will improve greatly if you really do try and avoid wearing any at all.

Agreed.

I have to say I am a bit befuddled by this whole thread. It seems obvious the reason many HUDs are so big is because that makes them easier to use.

But beyond that, I get the feeling that people wear their HUDs even after they have finished using them. The only HUD I wear constantly is an AO, and that's only when I have been to lazy to transfer the animations into Firestorm's built-in AO. Hell, I even detach the HUD for my genitals when I am nude, but don't need to sport an erection.

Guys you don't need to walk around with your mesh body and head HUDs all the time, only when you need to make changes. Even if they are minimized they are still using up texture memory and contributing to your script count. The same goes for HUDs used to customize textures or "styles" on clothing and hair. Once you set it, detach it.

If you use Firestorm, HUDs that you use often, should be added to your "favorite wearables" window for easy access.

https://wiki.firestormviewer.org/fs_wearable_favorites

Edited by Orion Pastorelli
spelling
  • Like 4
Link to comment
Share on other sites

2 hours ago, Orion Pastorelli said:

Agreed.

I have to say I am a bit befuddled by this whole thread. It seems obvious the reason many HUDs are so big is because that makes the easier to use.

But beyond that, I get the feeling that people wear their HUDs even after they have finished using them. The only HUD I wear constantly is an AO, and that's only when I have been to lazy to transfer the animations into Firestorm's built-in AO. Hell, I even detach the HUD for my genitals when I am nude, but don't need to sport an erection.

Guys you don't need to walk around with your mesh body and head HUDs all the time, only when you need to make changes. Even if they are minimized they are still using up texture memory and contributing to your script count. The same goes for HUDs used to customize textures or "styles" on clothing and hair. Once you set it, detach it.

If you use Firestorm, HUDs that you use often, should be added to your "favorite wearables" window for easy access.

https://wiki.firestormviewer.org/fs_wearable_favorites

Get that common sense outta here!!!!

Link to comment
Share on other sites

My recent favorite - said sarcastically - was a HUD for an event that took up half the screen and did not have a minimize button. So you had to attach it, click the location you wanted to go and then detach it to be able to see to actually purchase the item.  Then re-attach, click the next location, detach again to shop.  Rinse, repeat.

Whereas another event at least has a minimize button so you can get it out of the way between locations for easier shopping wherever it sent you.

 

Yes, I know that HUDs can add to scripting and texture lag - and I don't keep my body HUD attached unless at home actually using it.  The shopping HUDs that only take me to a few places are just plain easier to leave attached but minimized rather than constantly attach/detach/attach/etc...

Edited by LittleMe Jewell
Link to comment
Share on other sites

10 hours ago, Fauve Aeon said:

D7BB70C7-C30C-46F0-97EF-2036180905B2.jpeg

   This is why I tend to focus on one thing at a time. If I start off by picking out my outfit, I'll have the Maitreya HUD open to put the right foot shape and alphas in place, then I'll minimize it (I do tend to wear it even when I don't use it, as the ankle lock stops working if I detach it). Then I'll open the outfits' HUDs to pick the colours I want (or just add them when I add the item itself). Then I pick out my hair, and when I've chosen the style (these days it's 99% Stealthic, and just a question of which one I want) I'll pick colours, and see whether I want to change the style any through the HUD.

   It does seem like I'll end up with a larger monitor after Christmas, but I've already got the ductus down a way that works for me.

   Besides, some HUDs can be resized, by simply editing them - not all (although I can't think of any real reason to make the HUD itself no-mod; scripts, sure, actually absolutely, you might not want people taking your UUIDs from the scripts and leaking free colour options to others, but you can put no-mod scripts in a modifiable HUD!).

Link to comment
Share on other sites

I had the hairstyle and outfit set. The huds were just for makeup/coloring. 😹 I leave my body hud on in case I decide to swap skin tones if the makeup isn’t working as I need it, or to adjust the shine if it needs to be more/less according to the highlighter. Otherwise my body often looks flat in photos. Can I dodge in PS? Yes, but with a few hud clicks, I don’t always need to. I have 2 big monitors though. 

Link to comment
Share on other sites

I have a few items in Firestorm's Favorite Wearables function, and do indeed find that useful. The most useful tool I have ever come across, however, is the FASTer Hud -

https://marketplace.secondlife.com/p/FASTer-HUD-Avatar-Clothing-and-Attachment-Manager/13829155

Although primarily designed for quick attachment/detachment of wearable items, I use it substantially as a "HUD-for_HUDs", especially for appliers too. The buttons on the FASTer HUD have a picture on them, which makes for very easy selection. I've had to make my own pictures up (which can be a bit fiddly if you're not well versed in this sort of thing); the provided button pictures, although plentiful, are unlikely to cover all of your requirements. To keep the texture loading as low as possible, I have a "Master FASTer HUD", with text-only button pictures, e.g. "U/ware", "Hose", "Shoes", "Catwa", "Omega" etc, and some of these buttons add, not a wearable item, but another FASTer HUD containing all the huds or appliers for that particular category.

Another bonus feature is the ability to group items together. Selecting an item from a group will automatically detach any other item from that group that might be live.

Its taken a while to get it all set up properly, but has proved invaluable in the long run.

  • Like 1
Link to comment
Share on other sites

On 12/12/2019 at 4:12 PM, Orion Pastorelli said:

Guys you don't need to walk around with your mesh body and head HUDs all the time, only when you need to make changes.

The body and head HUDs serve also other functions than just to change appearances. For example Maitreya body HUD has animations for the hands. Genus head HUD has animations for the face. So you need to wear those HUDs all the time if you want the parts to be animated (unless you wear an AO which has animations for the corresponding parts).

Link to comment
Share on other sites

1 hour ago, Coby Foden said:

The body and head HUDs serve also other functions than just to change appearances. For example Maitreya body HUD has animations for the hands. Genus head HUD has animations for the face. So you need to wear those HUDs all the time if you want the parts to be animated (unless you wear an AO which has animations for the corresponding parts).

The Maitreya body also includes a smaller more discreet HUD just for the hand AO, I use a LeLutka head i selected all the animation sequences i want to use and they work with out the HUD i only really need it attached if i want to use the individual animations as i use BoM so depending on the body part there isn't always a need to wear main HUDs all the time for animations

  • Like 2
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1567 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...