Jump to content

TailBlue

Resident
  • Posts

    26
  • Joined

  • Last visited

Posts posted by TailBlue

  1. 15 hours ago, Flea Yatsenko said:

    If you want to fix your existing code instead of trying a different solution, make the

    if (llGetLinkName(counter) == "Engine Cell 1")

    line instead match a variable, then add that as an argument to your function

    Engine(string engineName){

    ...

    if (llGetLinkName(counter) == engineName)

    ...

    }

     

    It also lets you get rid of

                if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 1")
                {Engine1();}//Cell 1
                else if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 2")
                {Engine2();}//Cell 2
                //Else if Repeats more of above ^ that would other wise be placed here.

    and replace it with Engine(llGetLinkName(llDetectedLinkNumber(0)));

     

     

    20 hours ago, Quistess Alpha said:

    when you have a list of true/false values with less than 32 entries, you can do some boolean arithmetic to store it in a single integer.

    integer engine_active = 0; // no engines are active.\
    // ... test if engine #n is active:
    if(engine_active&(1<<n))
    {   // if #n was active make it inactive; if it was inactive, make it active:
        engine_active=engine_active ^ (1<<n);
        // make engine #n active
        enginve_active = engine_active | (1<<n);
        // make engine #n inactive
        engine_active = engine_active & (~(1<<n)); // redundant parentheses.
    }

     

    Yeah, you can manage 'sets of parts' in a more generic way now:

    get_links()
    {
       llLinksetDataReset(); // somewhat bad form, but works for a simple example.
       integer prim = llGetNumberOfPrims();
       // for each link, write its link # to the linksetData key 'Link:<linkName>'
       do{   
         string name = llGetLinkName(prim);
         string key = "Link:"+name;
         // conversion to a list technically unneccessary.
         list prev = llCSV2List(llLinksetDataRead(key);
         prev += prim;
         llLinksetDataWrite(key,llList2CSV(prev));
         
       }while(--prim);
       llLinksetDataWrite("LinksReady","True");
    }
    // after the function has run, llCSV2List("Link:"+linkName) shjould return a list of all links with the given name.
    
    state_entry()
    {   if(llLinksetDataRead("LinksReady")!="True") get_links();
    }
    changed(integer c)
    {   if(c&CHANGED_LINK)
        {	get_links();
        }
    }

     

     

    20 hours ago, Frionil Fang said:

    You could of course build a list of prims once on start-up/on linkset change event and assign those to a global variable. Or you could just skip doing that entirely based on what your example shows: you've already gotten the link number by matching it in the touch_start event, so you can pass that to a generic engine toggle function. Also instead of a separate engine state flag for each engine, you can have a list instead, and also pass the list index along in the call.

    key owner;
    list engine_active = [FALSE, FALSE]; // holds the activation state for all engines
    EngineToggle(integer engine_num, integer link)
    {
        integer active = llList2Integer(engine_active, engine_num); // get the chosen engine active state
        list params = llGetLinkPrimitiveParams(link, [PRIM_DESC]);
        list detailz = llParseStringKeepNulls((string) params, [":"], [""]);
        integer detail_num = 0; // the only difference between calls is the list entry being used
        if(active) // so choose the correct detail to use based on active state
            detail_num = 1;
        // if you were to put the transparency change back in, you could also just determine that based on the active flag
        llSetLinkPrimitiveParamsFast(link, [PRIM_POS_LOCAL, (vector) llList2String(detailz, detail_num), /*PRIM_COLOR, 0, <0.596,0.596,0.596>,1,*/ PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]);
        engine_active = llListReplaceList(engine_active, (list)active, engine_num, engine_num); // update active state list
    }
    
    default
    {
        state_entry()
        {owner = llGetOwner();}//Dont mind this.. just part of an Access System.
        touch_start(integer total_number)
        {
            integer linkno = llDetectedLinkNumber(0);
            list details = llParseStringKeepNulls(llGetLinkName(linkno), [" "], [""]);
            key id = llDetectedKey(0);
            if (llGetOwnerKey(id) == llGetOwner())
            {
                integer link = llDetectedLinkNumber(0); // store & pass along the prim number
                string linkname = llGetLinkName(link);
                integer engine_num = -1; // match link name to an engine cell number, -1 means not valid
                if (linkname == "Engine Cell 1")
                    engine_num = 0; //Cell 1 (#0)
                else if (linkname == "Engine Cell 2")
                    engine_num = 1; //Cell 2 (#1)
                //Else if Repeats more of above ^ that would other wise be placed here.
    
                if(engine_num >= 0) // only toggle if it's a valid engine cell
                    EngineToggle(engine_num, link);
            }
        }
    }

    There's probably more things to optimize and turn into a more generic, expandable form, but generally speaking: the fewer function definitions and calls, the better.

    Thanks! I see, never thought of it those ways, I did redo my whole script to clean it up some but the less code the better.

    I'm going half to play around with those new ways above and make my scripting even more efficient.

    llLinkSetData, that's the command I was trying to remember. I see now how it suppose to work somewhat, still need to play with it more.

  2. Are their other ways of writing this code that's more efficient and less demanding of script memory?

    Feels like I'm writing the same code over and over for each child prim that is scripted to move. Wondering if any better ways of cleaning this up, perhaps some kinda Getting of Linkset Names as a global list in the state_entry() inside of having to spam the same code to always re-seek the the same info?

    Wasn't a new lsl function added not to long ago where one could store a linkset's data in the root prim or something like that and call stuff from that.. kinda acts like a list but isn't? Im not so sure on that one as I've forgotten what it was called or did but vaguely remember details. XD

    Gist of it, script sits inside the root prim, touch event searches the linkset child prim that is defined below, then searches the linkset again for said child prim and does the code to move it.

    Anyways, the code Snippet!

    key owner;
    integer eng1 = FALSE;
    Engine1()
    {
        if (eng1 == FALSE)
        {   
            eng1 = TRUE;
            //llPlaySound(sound_gear,volume);
            integer prims = llGetNumberOfPrims();
            integer counter = 0;
            for (counter = 0; counter < prims; counter++)
            {
                if (llGetLinkName(counter) == "Engine Cell 1")
                {
                    list params = llGetLinkPrimitiveParams(counter, [PRIM_DESC]);
                    list detailz = llParseStringKeepNulls((string) params, [":"], [""]);
    llSetLinkPrimitiveParamsFast(counter, [
    PRIM_POS_LOCAL, (vector) llList2String(detailz, 1),
    //PRIM_COLOR, 0, <0.596,0.596,0.596>,1,
    PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]);
                }
            }
        }
        else if (eng1 == TRUE)
        {
            eng1 = FALSE;
            //llPlaySound(sound_gear,volume);
            integer prims = llGetNumberOfPrims();
            integer counter = 0;
            for (counter = 0; counter < prims; counter++)
            {
                if (llGetLinkName(counter) == "Engine Cell 1") 
                {
                    list params = llGetLinkPrimitiveParams(counter, [PRIM_DESC]);
                    list detailz = llParseStringKeepNulls((string) params, [":"], [""]);
    llSetLinkPrimitiveParamsFast(counter, [
    PRIM_POS_LOCAL, (vector) llList2String(detailz, 0),
    //PRIM_COLOR, 0, <0.596,0.596,0.596>,0,
    PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]);
                }
            }
        }
    }
    Engine2()
    {}//Would repeat more of the same code above for other child prims. Just for example.
    default
    {
        state_entry()
        {owner = llGetOwner();}//Dont mind this.. just part of an Access System.
        touch_start(integer total_number)
        {
            integer linkno = llDetectedLinkNumber(0);
            list details = llParseStringKeepNulls(llGetLinkName(linkno), [" "], [""]);
            key id = llDetectedKey(0);
            if (llGetOwnerKey(id) == llGetOwner())
            {
                if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 1")
                {Engine1();}//Cell 1
                else if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 2")
                {Engine2();}//Cell 2
                //Else if Repeats more of above ^ that would other wise be placed here.
            }
        }
    }

     

  3. When the GLTF viewer was released around mid December of 2022, my pc was able to open and log into the viewer just fine. Late Dec 2022 with the newer releases, it will load the viewer, get to the login screen then when trying to log in the viewer would crash as the world started loading. Now with the recent releases Jan-Feb 2023, the viewer will run after the Icon is clicked and once it says "Intilizting Cache" it crashes completly not even getting to the login screen. I have tried putting --noprobe and many many other tests in hopes to get it working but little success. Im left to belive this may be a hardware limitation.

    I heard the GLTF viewer will only run on supported hardware that has OpenGL version 3.0. Which my computer supports 3.0 to 4.0 100% with 4.1 to 4.5 being 85% supported, missing some extended shader files. I've tested this on another pc with latest drivers also running Intel iGPU 4000, 6000 and Geforce 812 but the same results happens. Both are running the latest Win10 22H2 Builds with 16GB dual channel memory and OS/viewers running on SSD's. Intel i7 proccessors 3632QM and 3650U.

    The offical release of the Second Life Viewer will open and run just fine.

    What OpenGL version(s) are required for the the GLTF PBR Materials Project Viewer to run among other required hardware specs?

    Will the GLTF Viewer beable run on aging hardware (2013-2014) mainly Intel Graphics HD 4000, 5000, & 6000 series? I do have the latest driver for these.

    Same with GeForce 710, 820, and Radeon HD 7550.

    I will be getting a newer spec pc (MSI Stealth 16) in the coming months and haven't seen any posts while searching about this topic/issues.  Im asking here in hopes the responces could help while also help other Second Life Residents on aging hardware with upcoming PBR being introuced to Second Life.

  4. Hi Hi,

    Iv'e been testing diffrent ways of setting camera parms for vehicles.

    Keep getting script errors stateing: "Camera control currently only supported for attachments and objects on which you are sitting."

    Searched wiki and other sites, not much info can be found. With the Root Prim containting the scripts to run the vehicle, Get Premissions Code, and setting Camera Parms.

    I want to know is the avi 'required' to sit on the root prim to stop such errors or is it ok for them to sit on a child prim?

    Most of my testing has been done with the avatar sitting on a child prim containing a script that link_message the avi's UUID to the root. I can cross 80 regions then get the error while others can sometimes cross a single region and get the error.

    One thing I've narrowed it down to is the simulator having to play catchup with the perms which can sometimes cause this issue. Done wacked code to play with the region crossings and delaying the perms and even using llGetTime() for things...

    That said, I decided to script the avatar to sit directly on the root and call camera perms, it seems to be working minus crossing on a cornor region and the issue happened again. This time it seemed to be region lag.

    Maybe im doing something wrong I dont know. Never had these issues untill LL updated their server side stuff months ago and people started complaining about it for awhile. Not blaming LL any info I may or may not know about this issue will be helpful.

    I have tried the changed(integer change) > if((change & CHANGED_REGION), putting llSetCameraParams() on a timer, also using llRequestPermissions(agent, PERMISSION_TRIGGER_ANIMATION | PERMISSION_CONTROL_CAMERA); to call the camera among other ways people in the BB Group have said.

    • Like 1
  5. 38 minutes ago, Qie Niangao said:

    At first glance, I'm not seeing where the command token ("Add") gets delimited from the access name list when being sent. Maybe you need the llMessageLinked() command to be "Add," instead of "Add" ?

    When I do "Add," it comes out in local chat as Add,,Name1,Name2, it has two commas in it which is why I went with "Add"

    Ill half to look more into llParseString2List() and thanks for the suggestions on both this and the <> button. I'll use it in future posts. I didn't think about the broadcasting of NC's UUID. That could be an interesting way of going about it but for now I want to learn how to get communication of what im doing down first. I'm in the process of centralizing more stuff to the root scripts. Like instead of having 10 scripts in 10 mesh objects in a linkset that does various effects, I could do that all from a single script using linkset names. Im getting there ^^ just a learning curve.

     

     

     

  6. I've been scripting a white list/security system for a linkset and its pretty much finished at this point minus one last hurtle.

    Im using llMessageLinked to send a list of Avatar names from a Central script to a sitting script. My central script takes care of reading a White List NC and stores that info internally along with other main tasks like if someone clicks a door and it checks to see if they match X parameters to grant access or denies them. The options are Owner only, Owner + Group/Public/White List. I then made a sitting script which has the 4 modes inside it. When an option is changed in the Central Script it sends a message to the sitting script to change to that mode. It all works as intended minus one bit when it comes to the White List.

    My issue comes up with the translation of data sent from my central script to my sitting script. Im using this line of code in my central script:

    llMessageLinked(LINK_ALL_OTHERS, 0, "Add" + llDumpList2String(access_list, ","), owner);

    This line sends out a list like this to my sitting script:  Command,Name1,Name2,Name3,  (For the names, im using legacy names.)

    Inside my sitting script im using this code which works with one avatar name using a command to separate the list.. (Dont mind the code not have { } I removed those to look cleaner)

    integer comma = llSubStringIndex(message, ",");
    if (names > 0)
    string command = llGetSubString(message, 0, names - 1);
    string avi = llGetSubString(message, names + 1, -1);
    if (command == "Add")
    if (llListFindList(access_list, [avi]) == -1)
    access_list = llListInsertList(access_list, [avi], 0);

    I've been trying out different ideas but im still sorta new to this whole llGetSubStrings and llParseString2List, etc. Is it possible for SL to take a list with what im trying doing to store it internally into the sitting script with llMessageLinked? If so how exactly should I go about it?

    Thanks, Stellar

  7. Ive scripted a small missile system that uses a hud to send a selected avatar key using llRegionSay to a mech. There is a relay script inside the mech that listens and sends the avatar key to the mechs linkset and that in return is picked up by the script that rezzes the small missile. The script that rezzes the missile sends the avatar key to region using llRegionSay. It all works like it should but my issue comes when I fire the missile a second time. The missile rezzing script doesn't remember the avatar key to send it to the region again so the missile can lock on to same avatar or object.

    My question is how can I get the missile rezzing script to remember the avatar key every time I click fire from my hud until I issues a reset command which resets the script?

    Few things ive considered was inside of my hud sending the avatar key every time i click fire or maybe putting my missile rezzing script on a looping timer. I think the best way to go about this is to either A have the hud send the command and avatar key every time I click fire or somehow have the missile rezzing script itself member the avatar key.

    Im using a string to send the commands and the avatar key.

    Thank you

  8. 3 hours ago, Mollymews said:

    Thank you so much! Your a life saver! Been on and off trying to figure this out for little over a year. Just really kept poking at it honestly but it works and so simple to!.
    For anyone wondering I did this.

    
    vector AVI_OFFSET = <0,0,-0.3>;
    
    {
    llSetLinkPrimitiveParamsFast(llGetNumberOfPrims(), [PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(llGetNumberOfPrims(), [PRIM_POS_LOCAL]), 0) + AVI_OFFSET]);
    
    }

     

     

    • Like 1
  9. Ive been scripting a lift within a linkset as a child prim and I have the lift itself working where it goes up and down. Im wondering how I should go about having the agent(avatar) sitting on the linkset to move with the lift (child prim). I know I could make my own animation that simply has an offset when it plays but that is just some kinda hack or go around the problem. I know its possible dont know how exactly. Ive looked and asked around and there isn't anything to move an agent like it would be for a child prim so it require more scripting to accomplished this.

    Not asking people to make a script for me but I guess some tips on how to go about it if thats how I should say that. XD

    Thank you for your help.

  10. Thanks for your inputs,

    I understand so there isnt any command as such like I thought >_< I could do the prim where it moves to the location of the doors opening but to me i think that would be little to much as this is a spaceship its being used on with tight quarters and all. Person walks through one door then a second later walking to the hangar etc. We did go with the other approach of having a slave script. It listens to a string from the controller script using  link_message for the sound UUID and plays that sound when the door opens. To my amazement its fairly low impact. So thats a plus! ^^  The controller script has all the code to open each door and the sound. Slave scripts are literally just 14 lines of sound listen and play.

    Arigato to both of you for answering.

  11. I build spaceship meshes and Ive made an interior kit for the ship with doors and all. On all of the doors I use a main controller script in the root prim that uses Fast Pramerters and the description and name of the child prims inside the linkset. So ONLY the door meshes are named Door will open or close if touched in the linkset. How ever I ran into an issue thinking of a way to play a single door sound from the root prim to the child prims. I dont want to have to put a single script inside each door 16 in total to play sound when the doors are touched and open. So im wondering if there is a way to do this? My scripter tells me there isnt such a command but ive been looking into it and just curios if there was any way of doing it. I want the sound to play local from the door it self NOT the root prim, because honestly that kinda ruins the immersion of the ship if i open a door and the sound plays in the back of the ship where the root is.

    Thanks

  12. Announcing the Flying Circus Combat League! A new and exciting SL sport. Inspired by a recent Anime series called Aokanta: Four Rhythm Across the Blue which is a story about the invention of shoes that enable people to fly (just like SL) and the sport that develops from this technology called Flying Circus. Come see the course, join the group and become a FCCL Flier.

    Info below-

    -Contact for info: Queen Nakajima

    secondlife:///app/agent/dc687756-7327-4026-b762-5b6769e0caec/about

     

    -Group URL: secondlife:///app/group/347dd4e2-9e67-d0fa-5698-6e55a2a4aa03/about

    -FCCL course location: http://maps.secondlife.com/secondlife/Herzogtum%20Zentral/28/15/3931

     

×
×
  • Create New...