Jump to content

Jenna Huntsman

Resident
  • Posts

    672
  • Joined

  • Last visited

Everything posted by Jenna Huntsman

  1. Here's a draft script I knocked up when I had a couple of mins - it gives items to people who click it normally; or if someone long clicks the item, it will trigger a different action. string g_FolderName = "myFolderName"; //Name of the folder that items will be unpacked to. list g_Items2Give = ["myNotecard","myItem","myLandmark"]; //List of items in this object's inventory to give to the user integer g_UnixTime; //Store the time in integer format. Used to detect long touches. //Note that this script doesn't verify that the objects in the above list actually exist in the object's inventory; this can cause a script error to occur if one or more items is not present in inventory. An error will also be thrown if the perms of 1 or more objects in inventory are no copy / no transfer. // See http://wiki.secondlife.com/wiki/LlGiveInventoryList default { state_entry() { llSetMemoryLimit(llGetUsedMemory()+512); //Delete this line if you run into issues; This sets the script's max memory usage, which makes it look nicer to anyone using a script memory monitor. } touch_start(integer total_number) { g_UnixTime = llGetUnixTime(); //set g_UnixTime to the time the touch started. } touch_end(integer total_number) { if(llDetectedKey(0) != llGetOwner()) return; //If whoever touched me isn't my owner, don't do anything. Delete this line to work for all avatars. if(llGetUnixTime()-g_UnixTime < 2) //Replace the 2 here with another integer or float to change the touch duration required to trigger a long touch event. { //Give to toucher (short click) llGiveInventoryList(llDetectedKey(0),g_FolderName,g_Items2Give); //This is a nicer function than llGiveInventory as the user doesn't need to unpack the object for the second time. llRegionSayTo(llDetectedKey(0),0,"I've unpacked to the \"" + g_FolderName + "\" folder in your inventory."); //Give the user a nice message. } else { //Give to someone else. (long click / 2 sec. plus) //Put some code here to manage giving the item to someone else. } } } It's a good starting point, and I've put documentation in so you can see what things are doing - though you'll need to figure out how you want to approach giving the item to someone else (be it chat command, menu system, etc.)
  2. An important point of clarification: Do you mean the owner of the object, or the creator of the object? Reading through I'm thinking you're intending that the object's creator is allowed to offer the contents of the object to others, but customers (i.e. not yourself) use it as a regular unpacker.
  3. For this kind of thing I actually prefer using Json arrays instead of passing lists verbatim, as this allows me to query the item directly without having to perform any further operations on the string; as well as being able to pass multiple values while also performing validation. A great example of how this can be useful is when the script stores multiple bits of info about an avatar; for example, their key, their access level, and (possibly) a passkey to allow them access to the security system. For example, the following string is a Json value, which stores my avatar's key, my access level (0), and a passkey. {"keys":{"b8ddae03-525a-4993-97ff-c7a39d6a222b":{"lvl":"0","code":"1234"} } } This can be sent via llLinkMessage to a child script, and the child script can then use if(llJsonGetValue(msg, ["keys","\"" + (string)MyInterestedKey + "\""]) != JSON_INVALID) //will pass if MyInterestedKey is present in the Json string { userlvl = (integer)llJsonGetValue(msg,["keys","\"" + (string)MyInterestedKey + "\"", "lvl"]); //returns the value of lvl for MyInterestedKey passkey = userlvl = (integer)llJsonGetValue(msg,["keys","\"" + (string)MyInterestedKey + "\"", "code"]); //returns the value of code for MyInterestedKey }
  4. I've ran some debugging here and, it appears your server has an intermittent issue wherein instead of returning HTTP 200, it returns HTTP 502 (Bad Gateway). Here's the response I got: stat: 502 meta: body: <HTML> <HEAD> <TITLE>Could Not Connect</TITLE> </HEAD> <BODY BGCOLOR="white" FGCOLOR="black"> <H1>Could Not Connect</H1> <HR> <FONT FACE="Helvetica,Arial"><B> Description: Could not connect to the requested server host. </B></FONT> <HR> </BODY>
  5. You should contact the script creator for help. We aren't able to provide support for a closed-source script.
  6. It does; but at the cost of hammering your CPU - so if your CPU is weak, enabling texture compression may actually cause worse performance than leaving it disabled (especially with newer viewers that make use of the multithreaded asset fetching). Also not recommended if you're particularly low on VRAM (i.e. less than around 700mb) as you'll end up with a framerate in the single digits (this is caused by 'texture thrashing' - framerate drop is caused your CPU now has extra overhead when swapping textures out from the RAM as well as running the rendering thread) With that being said, if you've got a strong CPU and a weak GPU, it's a good option.
  7. It's all very well that LL themselves aren't doing NFT stuff, but I don't think they should actively be promoting it either; otherwise they're (in my eyes) just as much of a part of it as the actual creator.
  8. You may find it useful to add in some failover modes with some helpful messages to see where code goes wrong. For example, this version of your script will check the contents of msg and verify that the key is valid, and the HUD will warn the user if objKey is not populated. HUD: integer iOBJChannel = 10; integer iHUDChannel = 20; key objKey; // or string.... default { state_entry() { llListen(iHUDChannel, "", "", ""); } listen(integer channel, string name, key id, string msg) { if((key)msg) { //if the contents of msg is a valid key (not NULL_KEY or a random string). objKey = (key)msg; } else { //msg wasn't a valid key. llSay(0, "That's not a valid key!"); } } touch_start(integer total_number) { if(objKey) //if objKey is set and a valid key. { llRegionSayTo(objKey, iOBJChannel, "TEXTURE"); } else { llSay(0, "I don't know who to send this to!"); //Triggered if objKey isn't set } } } Object: integer iOBJChannel = 10; integer iHUDChannel = 20; default { state_entry() { llListen(iOBJChannel, "", "", ""); } listen(integer channel, string name, key id, string msg) { if (msg == "TEXTURE") llSay(0, "Done!"); } touch_start(integer total_number) { llRegionSayTo(llDetectedKey(0), iHUDChannel, llGetKey()); //Sending to llDetectedKey(0) will send the message to the avatar who touched this ONLY. } }
  9. Use a typecast, for example listen(integer channel, string name, key id, string msg) { objKey = (key)msg; //Use a typecast (key) to convert msg, a string, back into a key. }
  10. This line should be changed to: colorpick = llList2Vector(primcolor, 0); As you're attempting to create a local variable with the same name as a global variable. (Qie has an explanation above) Another note: llList2Vector can behave... weirdly at times. It's usually more reliable to use (vector)llList2String
  11. You're declaring colorpick inside a state, when it needs to be a global. Variables declared inside a state cannot be referenced by other states. In your script, you have switch as a global - declare colorpick as a global as well, and your script should work! As a note: llSetLinkPrimitiveParams forces the script to sleep for 0.2 seconds, so it's generally preferred to use llSetLinkPrimitiveParamsFast instead. (The command syntax is the same)
  12. What Rolig said - (p.s. The wiki article covers the caveats of the llGiveInventory command: http://wiki.secondlife.com/wiki/LSL_llGiveInventory )
  13. To add on to this part, If your body is using Blending as it's mask mode, if you wear a full body alpha, the mesh will not disappear, instead it turns red (at least, in some cases - not all).
  14. So, a bit of news! The Cinnamon and Chai UV is now available for any mesh body creator to use! Licenced under Creative Commons, see the post here: https://becomecinnamon.com/cinnamonchaiuv/
  15. Your GPU driver is quite outdated. Grab an update from here and see if that fixes the issue. https://www.nvidia.com/Download/driverResults.aspx/183939/en-us
  16. Your best bet is to file a Jira and hope the SL gods shine on you and LL accepts the feature request. With that said, the others are right. If you're designing a game that doesn't use any existing protocol, your best bet would be to write your own protocol that includes this as a feature, and prompt creators to add support for your API to their weapons.
  17. Okay, I did not know that the viewer on Mac was already based on Xcode. I'm sorry and I stand corrected. Anyway, please do not insult myself or other members (or communities for that matter). I'd like to point out however that [insert TPV name here] wouldn't exist if the viewer itself wasn't open source. Heck, SL would probably have died if the TPV community abandoned SL when LL themselves were too busy with Sansar. Also, let's not forget that the software that most people use to create meshes for SL (Blender) is open-source. Not to mention other software for creating textures (GIMP) is also open-source. OpenSimulator is a project which aims at making both sides of SL open-source. (LL only officially open-sourced the viewer, not the server). That's a neat idea. I don't use it personally. Anyway, to go around to the main point of the topic: Could SL be made to run natively on M1 (and derivatives)? Probably. Some viewers can be compiled for ARM (instead of x86, CoolVL is the example i'm thinking of specifically), but this has only been done on Linux. I don't know if anyone has tried doing so for Mac, but the CoolVL dev (Henri Beauchamp) isn't going to be the one to do it (as he does not have any Apple hardware, nor has an interest in getting any). But, the viewer is open-source so someone could make the required patches and upstream them. It'd still be running on OpenGL, but it would eliminate Rosetta 2 (which would qualify it as running natively).
  18. Developing the viewer to use Xcode would require a ground up rewrite, and, once again, does not work on Windows (where the majority of the existing userbase are), nor does it work on Linux (where a lot of the 3rd party SL developer community is). By that logic, you'd be better off going with GTK (which works on Windows, MacOS and Linux) or QT (which works on Windows, Mac and Linux alongside iOS and Android) I mean, this is just outright conjecture.
  19. OpenGL is still alive - SL performs badly on modern hardware because it just isn't optimised for it. The main issue is that the viewer is for the most part single threaded, sometimes in places where it could be multithreaded. That's not to say we shouldn't port the viewer to a more modern & efficient API (Vulkan), as this would facilitate the viewer's renderer to be multithreaded (And would be able to run on Apple devices through MoltenVK, which is very close to Vulkan 1.1 conformance and likely would be conformant before a Vulkan viewer is introduced) Actually, the US market share for Macs has been stagnant since 2015. It's been hovering at around 13% of the market since then. iOS has seen growth in the US market, however only has around 16% of the worldwide market (compared to Android at 40 - 42%) Stats from: https://gs.statcounter.com/os-market-share
  20. LL's handling of mobile is separate from the viewer development team, moreover as far as I know LL don't have any plans to overhaul the UI anytime soon. LL were developing a chat client for mobile up until recently, but they scrapped it to "go in a new direction" (whatever that may mean, although I wouldn't expect it to be a whole viewer port to mobile; or if it is, it'd likely leverage OpenGL / OpenGL ES which works on both Android and iOS (and, conveniently wouldn't require an engine rewrite)).
  21. Double check that your remote server has the header formatted correctly. SL is quite picky about headers. http://wiki.secondlife.com/wiki/Http_response#Unicode In your case, the header should be something like this: Content-Type: application/json; charset=utf-8 If the header is just Content-Type: application/json; , SL may interpret that as ASCII as no charset was defined
  22. This is caused by the body having the alpha mode set to Blending. You can change this in the Belleza HUD (Under Skin, in a box which will say either None, Blend or Mask). Click this to cycle through alpha modes. If you're using BoM, this should be set to Mask.
  23. Agree with pretty much all the points here. LeLutka put in a huuuuuge amount of work to make the introduction of Evo X a success. I'll be following Cinnamon & Chai, but the new UV... eh. I'd be more interested if it was an open standard (or freely licensed) so that other bodies can adopt the same UV mapping to reduce market fragmentation (in a way that actually helps consumers).
  24. Pedantic correction (sorry!): Cyberpunk 2077 uses REDengine4, developed in-house by CDProjekt
  25. 100% get an AMD Ryzen - you can't beat the performance right now - Try getting something from the Ryzen 3000 (cheaper, but slightly older) or 5000 (latest at time of writing) series. The rest of your options seem sensible.
×
×
  • Create New...