ItHadToComeToThis
-
Posts
956 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by ItHadToComeToThis
-
-
9 minutes ago, Sid Nagy said:
And yet again, I can save me the money easily.
Idk Sid Starforge has a ring to it.
-
1
-
-
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
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.
-
15 minutes ago, Persephone Emerald said:
Second Life - our avatars have genitals!
Or do our genitals have avatars?
-
1
-
1
-
-
35 minutes ago, TheMainOtaku said:
When i log back in i'll make sure to check the message! Thank you sm!
Look up ThaPlug, they have six sims all done out nicely with houses, apartments etc to rent. Its basically a giant city / urban landscape community where people live.
-
1
-
1
-
1
-
-
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(); } }-
1
-
-
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.
-
1
-
-
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!
-
1
-
-
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.
-
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.
-
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";
}
} -
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.
-
1
-
-
7 minutes ago, Love Zhaoying said:
Interesting, you can do more than I thought..
https://wiki.secondlife.com/wiki/LlCastRay#RC_DATA_FLAGS
Which link, the "surface normal", only return the Root UUID..
I looked on there but I didn't see the answer to my question.
The target is one single object, so there won't be any other links.
-
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.
-
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.
-
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.
-
1
-
3
-
-
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.
-
1
-
-
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!
-
2
-
-
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?
-
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.
-
1
-
-
5 hours ago, Qie Niangao said:
There's a bunch of this I don't understand, but I can't imagine using object descriptions to communicate between objects.
It appears that Box A sets its description, rezzes Box B, and llSleep()s for two seconds in hopes Box B will finish rezzing and reading the description before Box A wakes up and rezzes the next Box B. That'll probably work almost all the time, but it's sure not to work some of the time, and there are multiple widely-used approaches for communicating between a rezzer and its rezzed children. See the object_rez wiki page for a couple cookbook examples, or try something else, perhaps communicating via the Experience's KVP persistent store (since all the scripts can be compiled to that experience), but whatever the medium, the logic mustn't assume the rezzed object is ready to do anything until it says it's ready.
This section, I'm sure, explains why there needs to be a separate Box B instead of just rezzing the HUD directly, but I've reread it a dozen times and can't understand:
It's not obvious to me why a freshly rez'd HUD can't just do everything Box B is doing and then decide whether to attach to the target avatar. If at all possible, I'd remove Box B from the architecture, removing a whole raft of potential failure modes with it.
With the llSleeps between rezzes, it's not surprising that some avatars will escape the region before anything asks whether they have a HUD attached, requests Experience permissions, or tries to attach, but if it remains unexplained after tightening up the delays you could log those attempts (to Experience KVP if nowhere else) to gather more info about which avatars are falling through the cracks, and maybe why.
Maybe somebody who deals with temp-attached objects across region borders will know if they just fall off sometimes, even if both regions have the Experience enabled. It wouldn't seem too surprising, considering that regular attachments fall off occasionally on teleport.
Sorry, I thought I had explained clearly enough but I can see how it might be confusing.
So, the reason for Box B is because of Box B asking the question of "is the hud on", and I wanted to be able to Rez multiple Box B's and leave Box A looping through the people on sim. Then I found out that Box B wasn't grabbing the UUID quick enough so had to start adding delays to allow it to do so.
However, I figured out a better method than asking "is the hud on" and that's checking the avatars attachments for the overhead meter. If the meter is attached, then Box B doesn't Rez and simply dies. The HUD has stopped occasionally detaching when you cross regions now which im happy with, but if theres a better method to be used here then Im happy to explore it.
I will play around with the object_rez method , I had forgotten that event existed to be honest.
-
Hey, so, I have a system setup where if you enter the region a hud auto attaches to the avatar.
The way it currently works is. Box A scans the sim and adds all avatars into a "inSim" list. Box A then works through the list, first setting the avatars key as the description of Box A. Box A then rez's Box B. Box B, using llGetObjectDetails, gets the description of Box A, aka avatar in sims key, and then sends a message to that avatar asking them if they already have the system attached. If Box B gets a response, Box B deletes itself. If Box B doesn't get a response after 10 seconds, Box B requests experience permissions and then rez's the system, which uses the same method but grabs the key from Box B description, and then auto attaches to the avatar. The reason Box B asks if you are wearing the HUD first is, this system is working across multiple regions joined together. The reason for so many boxes is....once Box B is Rez and has the key, that frees up Box A to continue working through the inSim list.
The issues im getting are as follows...
1. Occasionally when I cross from one sim into another, the system will detach itself, as if it's trying to attach another version. Which it shouldn't as it's supposed to answer Box B's question of is the hud on. And then delete Box B if it is.
2. The HUD / Box B is occasionally throwing an error about not being able to find an avatar to request the experience from. It should be getting the avatars key from the previous rez description.
3. Is there a better way to do this? The method im using seems like it would be the most sensible but is there a better and more efficient way?
You can ignore the dialog stuff, its just the experience attach and sim scan stuff that im having these issues with.
Box A Code - Keys for dev, admin, channel numbers and encryption stuff was removed for privacy reasons
list inSim=[]; //In sim already list grab=[]; //Temporarily grab all to be sorted list aMenu=[ //Admin menu "Update", "DetachAll" ]; list nMenu=[ //Normal menu "AttachHUD" ]; list admins=[ ]; key admin; //Channels integer sChan; integer sList; integer mChan; integer mList; integer mInd; //Keys key target; key dev=""; key player; //Encryption password string password=""; //Encrypt string encrypt(string msg){ return msg; } //Decrypt string decrypt(string msg){ return msg; } grabPlayers(){ //Scan players grab=llGetAgentList(AGENT_LIST_REGION,[]); integer i=-1; integer inCheck; //Determine if in the sim already or need to check exp while(++i<llGetListLength(grab)){ if(~inCheck=llListFindList(inSim,[llList2Key(grab,i)])){ //Already in sim //llOwnerSay(llKey2Name(llList2Key(grab,i))+" is already in the sim"); }else{ //Not in the sim //llOwnerSay(llKey2Name(llList2Key(grab,i))+" is not in the sim"); inSim+=[llList2Key(grab,i)]; target=llList2Key(grab,i); llSetObjectDesc((string)target); //if(target==admin)llRezAtRoot("SystemExpCheck",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); llRezAtRoot("SystemExpCheck",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); llSleep(2.0); //Check experience } } //Now check inSim list to make sure no one has left if(llGetListLength(inSim)>0){ list temp=inSim; i=-1; while(++i<llGetListLength(temp)){ if(~inCheck=llListFindList(grab,[llList2Key(temp,i)])){ //llOwnerSay(llKey2Name(llList2Key(temp,i))+" is already in sim"); }else{ inSim=llDeleteSubList(inSim,i,i); //llOwnerSay("Removed "+llList2String(temp,i)+" from list"); } } } } detachAll(){ integer i=-1; while(++i<llGetListLength(inSim)){ llRegionSayTo(llList2Key(inSim,i),sChan,encrypt(llList2String(inSim,i)+",detachHUD")); llRegionSayTo(llList2Key(inSim,i),sChan,encrypt(llList2String(inSim,i)+",detachMeter")); } } default{ state_entry(){ llListenRemove(sList); sList=llListen(sChan,"",NULL_KEY,""); llSetTimerEvent(5.0); } on_rez(integer param){ llResetScript(); } touch_start(integer x){ key admin=llDetectedKey(0); if(~llListFindList(admins,[(string)admin])){ mInd=1; llListenRemove(mList); mChan=11111+(integer)llFrand(99999); if(llDetectedKey(0)==admin){ player=admin; mList=llListen(mChan,"",player,""); llDialog(player,"\nHUD",aMenu,mChan); } }else{ llRegionSayTo(admin,0,"You do not have permission to use this item."); } } listen(integer channel, string name, key id, string message){ if(channel==mChan){ if(id==dev){ //Admin options if(mInd==1){ if(message=="Update"){ inSim=[]; detachAll(); grabPlayers(); }else if(message=="Notice"){ return; //mInd=2; //llTextBox(admin,"System Notice",mChan); }else if(message=="DetachAll"){ detachAll(); }else if(message=="AttachHUD"){ return; //llSetObjectDesc((string)dev); //llRezAtRoot("SystemExpCheck",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); } }else if(mInd==2){ integer i=-1; while(++i<llGetListLength(inSim)){ llRegionSayTo(llList2Key(inSim,i),sChan,encrypt(llList2String(inSim,i)+",hudNotice,"+message)); } } }else{ //Normal if(message=="AttachHUD"){ llSetObjectDesc((string)id); llRezAtRoot("SystemExpCheck",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); } } }else if(channel==sChan){ return; list pStr=llCSV2List(decrypt(message)); if(llList2String(pStr,0)=="attachHUD"){ llSetObjectDesc(llList2String(pStr,1)); llRezAtRoot("SystemExpCheck",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); llSleep(2.0); } } } timer(){ grabPlayers(); } }Box B Code - Keys, Channels etc removed for same reasons as above
//Channels integer sysChan; integer sysList; //Encryption string password=""; //Other key expCheck; key av; integer rezCheck=0; //Encrypt string encrypt(string msg){ return msg; } //Decrypt string decrypt(string msg){ return msg; } default{ on_rez(integer param){ key rez=llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]),0); av=llList2Key(llGetObjectDetails(rez,[OBJECT_DESC]),0); //llOwnerSay("Av is: "+(string)av); llSetObjectDesc((string)av); llListenRemove(sysList); sysList=llListen(sysChan,"",NULL_KEY,""); llRegionSayTo(av,sysChan,encrypt((string)av+",isHudOn,"+(string)llGetKey())); llSetTimerEvent(5.0); } experience_permissions(key id){ if(id){ llRezObject("HUD",llGetPos()+<0.0,0.0,2.0>,ZERO_VECTOR,ZERO_ROTATION,1); } } listen(integer channel, string name, key id, string message){ if(channel==sysChan){ //System chan list pStr=llCSV2List(decrypt(message)); if(llList2Key(pStr,0)==av){ if(llList2String(pStr,1)=="hudIsOn"){ //llOwnerSay("is on"); llDie(); } } } } timer(){ if(!rezCheck){ llRequestExperiencePermissions(av,""); rezCheck=1; llSetTimerEvent(0.0); llSetTimerEvent(20.0); }else{ llDie(); } } }Code inside the system that attaches to the avatar.
integer rez=0; default{ on_rez(integer param){ //Param code check if(rez==0){ rez=1; key rez=llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]),0); key target=llList2Key(llGetObjectDetails(rez,[OBJECT_DESC]),0); llRequestExperiencePermissions(target,""); llSetTimerEvent(5.0); } } experience_permissions(key id){ if(id){ if(rez){ rez=0; llAttachToAvatarTemp(ATTACH_HUD_CENTER_1); } } } timer(){ if(rez){ llDie(); } llSetTimerEvent(0.0); } }-
1
-
-
Oh look, more gimmicky last names, woo, anyway. The marketing team really pushed the boat out this time.
Wonder how long before some NSFW account takes Simp Gimp.
-
1 hour ago, Quistess Alpha said:
I haven't but given that you're doing testing at the moment, I'll presume there is some issue there.
The alternatives to tempAttach are regular llAttachToAvatar, and #RLV folder attaching. llAttach is a pain, because it doesn't handle ownership transfer, you have to get the recipient to buy the object (for 0L$) before it can attach, and #RLV folder attaching has all kinds of timing and communication issues that need to be handled delicately in the script.
Sadly the person wants this hud to attach via experience seamlessly
Maybe might have to fudge it using camera params and if the camera is x away then rest back to position or something.
-
Has anyone ever had issues or figured a way around issues regarding RLV in temp attachments?
llOwnerSay("camdistmax:10=n);
Works fine as a standard attachment.
Works sporadically as a temp attachment.
I tried putting in the attach event, delayed timer etc and it only works half the time when in a temp attachment.
Facebook
Instagram
Twitter
YouTube
Flickr
New last names spring 2024.
in General Discussion Forum
Posted
I was just wondering how it was pronounced. Is it "zoch-til", "x-och-til", "z-ogh-til".