Jump to content

ItHadToComeToThis

Resident
  • Posts

    961
  • Joined

  • Last visited

Posts posted by ItHadToComeToThis

  1. 19 hours ago, Coffee Pancake said:

    We're not getting a substitute for blender or maya in the viewer, nor would that be practical or in the end, any simpler than needing to learn blender. We're also not getting special in viewer only tools. The move has been towards industry standard work flows so transferable skills can be used to create content for SL, not in SL.

    I submitted a Jira a few years back asking for this to be looked at. My suggestion was "mesh like prims". So a new type of prim where you can move the edges and points of the prim and rather than having a cube that is divided into 6 faces, you have one that divided into 24 faces, each with it own points and various edges. Its not "blender in the viewer", but it would make "prims" interesting again. Especially if you included a way to bake shadows, cast by prim lights maybe, onto the objects texture, or as a separate layer entirely. Doing that, would probably get some people interested in creating again as you would be able to create much more complex objects without needing to learn Blender, Substance and ZBrush.

    • Like 2
    • Thanks 2
  2. 1 minute ago, Zalificent Corvinus said:

    I wonder...

    Is "Xochitl" intended as a "Mayan" name, or as Uzbek for "wish"?

    Hmm

    Gotalotabotl Xochitl - Perfect name for a Mayan Milk Delivery diver.

     

    I was just wondering how it was pronounced. Is it "zoch-til", "x-och-til", "z-ogh-til".

    • Like 1
  3. On 4/4/2024 at 12:13 AM, Phil Deakins said:

    Granted, but the rest of your life will be terribly boring.
     

    I wish that Love would realise that it's the midday sun that only mad dogs and Englishmen go out in :D

    Granted but at midday each day, she bursts forth into a full Noel Coward performance, regardless of where she is. On the toilet? Noel Coward. In work? Noel Coward.

    I wish that I could travel the galaxy, via teleportation.

  4. 15 minutes ago, Quistess Alpha said:

    llGetRegionList returns up to 100 avatars, in no sensible order; Sensor only up to 20 or so, and sorted by distance. In the (extremely unlikely) case that there are over 100 agents in the region, you may fail to find one even if it's right in front of you.

    This works pretty well each time, iv used it in a system in the past. I was trying to achieve it a number of years ago, and managed to get quite far, but was unsure of how to calculate the angle as it wasn't something I had done before in this way. @Rolig Loon was kind enough to help me figure it out at the time. Though I do get what you are saying about +100 avatars, you would need to figure out a way to factor that in if possible.

    avatarInFront(){
        list avatars=llGetAgentList(AGENT_LIST_REGION,[]);
        integer i=-1;
        while(++i<llGetListLength(avatars)){
            list temp=llGetObjectDetails((key)llList2String(avatars,i),[OBJECT_POS]);
            vector myPos=llGetPos();
            vector avdir=llVecNorm((vector)llList2String(temp,0)-myPos);
            vector lookdir=llRot2Fwd(llGetRot());
            float dp=avdir*lookdir;
            if(RAD_TO_DEG*llAcos(dp)<45.0){
                if((key)llList2String(avatars,i)!=llGetOwner()){
                    if(llVecDist(myPos,(vector)llList2String(temp,0))<2){
                        llOwnerSay("Found Avatar : "+llKey2Name(llList2Key(avatars,i)));
                    }
                }
            }
        }
    }
    
    default{
        touch_start(integer x){
            avatarInFront();
        }
    }

     

    • Like 1
  5. 22 hours ago, KeeperS Karu said:

     Well, I hadn't intended to build a whole combat system. Like I said, I was just trying to see if the controls feel okay enough in Third Person Mode for others to adopt the control scheme in their systems. I like the idea of SL combat, but it's all done in First Person, and I can't really do First Person. While the combat system supposedly works in Third Person, the problem is that the strikes are activated by holding down the left mouse button along with the directional keys. This takes away the ability to use Mouse Steering (where you left click on your avatar and drag the mouse left and right to rotate it), which is essential for smooth navigation in Third Person. So my hope is to come up with a control scheme that works in Third Person and lets you use Mouse Steering while still activating the strikes. I'm hoping people like this enough to want to see it in popular combat systems.

    I make all my melee work via left click in general that Includes both standard and mouse look clicking. A good method I found was to use gestures. Use left click for your base rotation of moves and use gestures to activate more complex attacks on your next click.

    If you really want to do multi key combos. I posted something a while back that was a VERY rough draft of exactly that. I managed to achieve quite a significant number of combinations and there were still more that could be done. If you go back through this forum you will find it. It’s very rough though and not even remotely polished. More of code dump brain storming session.

    If you wanted avoid sensors and raycast. You could use llGetRegionList. Then loop through and detect how many avatars are around you, and how many of those are in front of you within X angle.

    It works just as well as a sensor and just as quickly.

    • Thanks 1
  6. 9 minutes ago, Rolig Loon said:

    Oh, you're concerned about this test?

    If you are hoping to detect hits that are not on the torso, then what you want is more like

    if (hitPos.y>=((hitPos.y >= theirPos.y-(0.1*sizeY)) || hitPos.y>=(theirPos.y+(0.1*sizeY))) 

    assuming that the torso is centered on the bounding box and is only 20% of its total width.

     

    Ahhh thank you! Much appreciated!

    • Like 1
  7. Just now, Rolig Loon said:

    Where you're going wrong is that arms might be anywhere from the extreme left side of the bounding box to the extreme right side, including right in the middle. You won't be able to distinguish between a hit on an arm and a hit on the torso, and you won't even be able to tell the right arm from the left arm, since it's hard to get the av's rotation reliably.  Your vertical method works pretty well because the torso's a big target and your Z slices can distinguish fairly reliably between a hit on the head and one in the stomach. 

    What I mean is, where did I go wrong in the Y line. Why won't it divide up the hit box horizontally using the same method for the Z axis. I understand I can't do arm hits, which is sad but it's whatever. I just want to know what im missing in the code to do it horizontally on the hit box. More just for my own knowledge.

  8. 2 minutes ago, Rolig Loon said:

    I'm not surprised that you have fair success with shots on the torso, but it's going to be harder to target left and right. avSize.y is the Y dimension of the av's bounding box, but the arms could be anywhere inside that. Depending on the anim, your target's arms might be stretched out or folded in, or anywhere in between, but the cast ray will simply report that it hit the bounding box. 

    Even if that's the case. Do you know where I have gone wrong? I would still like to solve the issue even if the plan I was after won't work.

  9. So, I have managed to get to the following point. The sizeZ values are working and detecting the crotch, stomach etc perfectly fine. When shooting an avatar with raycast.

    But, I can't get the same process to work on Y. What am I missing here. I want to include arm hits and pref leg hits

    string calcHitPos(vector hitPos, key theirKey, vector theirPos){
        llOwnerSay((string)hitPos);
        vector avSize=llGetAgentSize(theirKey);
        float sizeZ=avSize.z/2.0;
        float sizeY=avSize.y/2.0;
        
        if(hitPos.y>=(theirPos.y-(0.1*sizeY))&&hitPos.y<=(theirPos.y+(0.1*sizeY))){
            
            if(hitPos.z>=(theirPos.z-(0.1*sizeZ))&&hitPos.z<=(theirPos.z+(0.25*sizeZ))){
                return "crotch";
            }
            if(hitPos.z>(theirPos.z+(0.25*sizeZ))&&hitPos.z<=(theirPos.z+(0.5*sizeZ))){
                return "stomach";
            }
            if(hitPos.z>(theirPos.z+(0.5*sizeZ))&&hitPos.z<=(theirPos.z+(0.8*sizeZ))){
                return "chest";
            }
            if(hitPos.z>(theirPos.z+(0.8*sizeZ))){
                return "head";
            }
        }

  10. 5 hours ago, Wulfie Reanimator said:

    It's not possible to get a surface position, because of what Animats said:

     

    The physics shape of objects have no face numbers, and don't relate to the visible mesh at all. But since you're trying to create targets for a scoring system, you can fortunately do a bit of math to figure out how far away from the object's center the hit was.

    The moment you said that I was like ohhhh you can as well….not even difficult. I think I have a problem of over thinking sometimes.

    • Like 1
  11. If I shoot a ray at a prim, I can detect the position that the ray hit at in region coords. Is there a way to convert this to a surface position. Similar to how you can use llDetectedTouchST to determine click coords, can you do anything similar with raycast? I have a target that has circles in, each circle has a number, I would like to be able to create a scoring system.

  12. 11 hours ago, Quistess Alpha said:

    using linkset data can greatly simplify remembering handles:

    Instead of:

      key gHandleRequestStat; // global variable
      //... later in some event:
      gHandleRequestStat=llReadKeyValue("my_stat");
      //...
      dataserver(key ID,string value)
      {   if(ID==gHandleRequestStat) { /*...*/ }
      }

    consider:

      llLinksetDataWrite("Handle:"+(string)llReadKeyValue("my_stat"),"read:my_stat");
      //...
      dataserver(key ID,string data)
      {   string request = llLinksetDataRead("Handle:"+(string)ID);
          if(0==llSubStringIndex(request,"read:"))
          {   string stat = llGetSubString(request,5,-1);
              // set stat to data
          }// ...else ...
      }

     

    That's interesting, I will def give that a go. At present I have five scripts in the hud, all requesting their own experience key storage. I want to streamline it a bit and have it all happening in one script.

  13. 3 hours ago, Qie Niangao said:

    I went back and listened to the link Pantera supplied to her recording of the Concierge meeting, and Wendi said the Lab Gab session would include "developers and such" so the plan at the time of the announcement (Feb 21) probably didn't include any big name appearances.

    Finding Lab Gab announcements seems to be more difficult than I expected, searching the Blog history. There was one about the WelcomeHub's Community Exhibition opening that ended up being hosted by Strawberry and Patch but I don't see any names on that announcement either. On the other hand, the five SL20B Lab Gab live events were detailed in the omnibus birthday announcement.

    The original announcement did list who would be in it, he was one of them, and it was listed for Thursday. It then changed on the day I originally posted this to what it is now. Given the thing about the thing, it's probably the thing.

    • Like 1
    • Thanks 3
  14. If I use a single script to store data to an experience from a combat system. That would store the data for multiple sets of stats. Is it better to use a single key for requesting. Or am I better splitting it up into key mainStats, key meleeStats and have each set of stats have its own if(reqID==

     

    if I did the second method I would have to have a request, modify and save key for each set of stats.

    • Like 1
  15. Wasn't there supposed to be a Lab Gab tomorrow?

    Post has been changed from Thursday to "airing on socials in the near future".

    Dammit, I wanted to know about the mobile viewer!

    • Like 2
  16. On 2/15/2024 at 11:46 PM, elleevelyn said:

     

     

    That was really helpful advice, thank you.

    Am I right in thinking that when you cross into a region, the attachments you have on, for a brief second, aren't attached to you while they load into that region? It seems adding a short delay to the meter check, fixed an issue where the HUD would sometimes attach when you enter a new region, as if it couldn't find the meter you were wearing?

  17. 2 hours ago, Qie Niangao said:

    Yeah, but… I understand that Box A needs to rez something quickly so it can get through potentially multiple avatars in a loop, but what I'm being dense about is why it needs to rez another level of rezzer rather than directly rezzing the HUD and have it determine for itself if it should attach (make sure there's not a HUD attached already) and either llDie or try to temp-attach.

    So… the overhead meter (which would be in llGetAttachedList) will always be attached iff the HUD is? 

    Yeah, the meter and the hud coexist, if you detach one it detaches the other. You have to be wearing both or none at all.

    I guess i could just Rez the hud directly. It would technically just do the same as Box B I guess. I think I was over thinking that bit.

    • Thanks 1
×
×
  • Create New...