Jump to content

primerib1

Resident
  • Posts

    395
  • Joined

  • Last visited

Reputation

369 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In theory, steps 2 and on can also be used to orthogonalize the Origin-Pos vector in 3D space, allowing detection for a non-upright prism volume. But the maths become so complex it gave me a headache ... plus Performance tanks due to how much float calculation is happening Debugging is a nightmare There is not much need to detect a pos in a non-upright-prism volume So I optimized the scenario and the code for an upright prism volume instead. Which covers like, probably 95% of use cases...
  2. Do note that for the "vertex1" and "vertex2" vectors, I purposefully set their Z value to 0.0, because the Z value for the vertices are ignored anyways.
  3. Thanks for the update! If LeTigre has it after today's restart, I can start testing my scripts for faster notecards.
  4. Is it actually widely available, though? I have scripter friends that say their scripts using llGetNotecardLineSync() refuse to compile... EDIT: Yup, does not compile for me. And I'm on RC LeTigre region.
  5. If the object is mod, as in, you can add a script to it, you can probably add a script that will try to set the transparency of that link to 100% every second. It seems the orange ball is the root prim? If so that would be Link #1.
  6. Basically, everything defined at the global level -- variables, functions, states -- are always initialized first, no matter where they exist in the source code. The compiler just parse for everything global and create references. By the time they are accessed within functions and event handlers, they already exist.
  7. The InPrism() function can probably be optimized further by pre-calculating the a, b, d, e, and divider values. But I'll leave that as a homework to y'all scripters 😉
  8. Here's an example how I used this to detect people inside of designated stall areas in my stable: list STALLS = [ <13.6, 122.8, 115.0>, <13.6, 120.0, 0.0>, <37.3, 122.8, 0.0>, 50, <13.7, 128.7, 115.0>, <13.7, 131.5, 0.0>, <28.5, 128.7, 0.0>, 50 ]; integer InStalls(vector pos) { vector origin; vector vertex1; vector vertex2; float height; integer i = -1; do { origin = llList2Vector(STALLS, ++i); vertex1 = llList2Vector(STALLS, ++i); vertex2 = llList2Vector(STALLS, ++i); height = llList2Float(STALLS, ++i); if (InPrism(origin, vertex1, vertex2, height, pos)) return TRUE; } while (i < 7); return FALSE; } 1 script, zero invisiprims, to watch over 2 disconnected areas of dissimilar sizes.
  9. Given a volume in the shape of an upright prism whose base is a parallelogram that lies flat/parallel to the world XY plane (plane of constant Z) The parallelogram defined by an origin vector, and 2 adjacent vertices (vertex1 and vertex2) all with the same Z as origin, And the prism additionally have a height Then the following function will return TRUE if a 3D coordinate (vector) pos is within the prism: integer InPrism(vector origin, vector vertex1, vector vertex2, float height, vector pos) { float m = pos.z - origin.z; if ((m < 0.0) || (m > height)) return FALSE; float a = vertex1.x - origin.x; float b = vertex2.x - origin.x; float c = pos.x - origin.x; float d = vertex1.y - origin.y; float e = vertex2.y - origin.y; float f = pos.y - origin.y; float divider = (a * e) - (b * d); m = ((c * e) - (b * f)) / divider; if ((m < 0.0) || (m > 1.0)) return FALSE; m = ((a * f) - (c * d)) / divider; if ((m < 0.0) || (m > 1.0)) return FALSE; return TRUE; } What is this useful for? Well, probably can be used in place of a multitude of invisiprims all with their own script all doing their own llVolumeDetect() ... EDIT: HOW IT WORKS First, it finds out if pos is between the lower bound and upper bound of the prism. Then, limiting to the 2D (X, Y) plane, it finds out the 2D vector for each of: O-V1, O-V2, O-pos Then, it orthogonalizes the O-pos vector into multiples of O-V1 and O-V2, let's call this m1 and m2. pos is within the parallelogram if and only if 0 < m1 < 1.0 and 0 < m2 < 1.0 The case where pos is on the edge of the parallelogram is kinda finicky to match (floating point accuracy limit), so the test is for inequality only.
  10. I just realized that the difference between "URL safe" Base64 and the "normal, non-URL-safe" Base64 is just replacing "+" and "/" of the latter, with "-" and "_", respectively. So if you need a fast but URL-safe Base64, you can use the one here and do a global replace of "+" and "/" with "-" and "_", respectively, at the end of the PackUuid2 function, just before the 'return' statement. Then, in the UnPackUuid2 function, perform the reverse at the very beginning of the function. In code: } result = llReplaceSubString(result, "+", "-", 0); result = llReplaceSubString(result, "/", "_", 0); return result + llGetSubString(hex, -2, -1); } and string UnPackUuid2(string packed) { packed = llReplaceSubString(packed, "-", "_", 0); packed = llReplaceSubString(packed, "_", "/", 0); string result; And there you have it! Fast, yet URL-safe.
  11. Because that's a place name not an adjective nor a demonym. Take, for example, the name of a country: Macedonia Macedonian refers to something related to Macedonia (e.g., "Macedonian culture", "Macedonian economy") or a demonym (i.e., referring to people who came from Macedonia.) Extend this to lots of country names. Australia. Indonesia. India. Guinea. Korea. Eritrea. Hence, Mediterranea without "n" at the end. If you're going to refer to things located there, or people who live there, then you add the "n". Mediterranean homes. "I live on Mediterranea, so I am a Mediterranean."
  12. My main purpose is to make maps. High-resolution maps, were each region is represented by a square of 256x256 pixels in size. Putting all Bellisseria in one map at that resolution is too big: I currently have a 19'968 x 24'576 pixels map of the whole Bellisseria supercontinent. The on-disk size is 327 MiB already. Too cumbersome. The map needs to be split, and every split should be named, and have a reason for why it is split so. The best reason for splitting a map is to highlight a certain named region in the map. Hence is why I decided to do some research and give the areas names. * The name Sakurasseria has been lifted from earlier BBB publications, for instance this one: Quote: "or Sakurasseria as some people now call ..." Of course you are free to shorten that to "Sakura". Just like people shortening the name "United States of America" to just America, never mind that there are a LOT of countries in the America continent, not just the USA. * Victoria has its subdivisions named because it is a really complex area, with land borders against Old Belli and Belli Forest. Four lines pointing to one name visually is not good. Not doing that, though, potentially confuses people of what the name of the division south of Old Belli is, or the name of the division west of Belli Forest is. So it's a necessary evil that the subdivisions of Victoria get named despite other subdivions of other areas not being named (for instance, there are several historical names for subdivisions in Old Belli). * The definition of a "chalet" from the Oxford Dictionary is: a wooden house or cottage with overhanging eaves, typically found in the Swiss Alps. Hence is why the region with the chalet-style Linden Homes are called Alps. Belli Alps to reflect Swiss Alps. And the area, though not mountainous, is not flat. Take a look at this video, starting 0:37 : https://youtu.be/2wAJqqmDlHw?si=71yeL4_fi3qyZyEO&t=37 At 0:37 the division I named "Belli Alps" just starting to enter the view from the left. You can see that the division is rugged, especially compared to the flat Stiltlands in the foreground, and Newbrooke that entered the view afterwards. If you compare with Mount Sojisan in the foreground, and considering perspective, the highest points of Belli Alps probably reaches about half the height of Mount Sojisan. * The names "Pickle" and "Squishy Pickle" is probably as near as official as can be if you ever watched the slideshow of how Belli came to be, in BelliHub. * All my hi-res maps are released under the CC-BY-4.0 license, free to use for whatever purposes you want, even as part of items you want to sell. All that is required by the license is to give credit to the maker. They are available on my Box.net here: https://app.box.com/s/13pi5ewojp5lsx9vap4uwtweg8h2tddq (Nearly all maps there are still September 2023 edition; I will be uploading the January 2024 edition in the coming days)
  13. Then please show me a use case where the current proposal for llRegex() and llRegexFound() cannot serve your needs. Actual use cases rather than just handwaving "oh there might be such and such needs that your functions do not cover" without any concrete examples. In both JIRA issues I've added example code & usage where I use llRegex() and llRegexFound() to great effect. Then just replace "" with something you won't really see in the search. Problem solved. Though that leads me to the same statement: Please show me a use case where that will happen. I found out that most of the time, a properly made regex can alleviate the issues. (Key word "most"; I do realize there might be cases that cannot be solved by better regex, or by combining regex with other simple facilities, but nothing I can think of at the moment) Without a clear example of "look, your proposal doesn't work in this situation", I cannot support adding complexity for the sake of hypothetical situations without any examples. You are, of course, free to make one (or more) JIRA Issue(s) with your ideas of how the function(s) should implemented. But don't forget to include sample code of the concrete use cases like what I have added to my issues. By what measure are you saying 80% and 20% there? Show me actual numbers, actual data rather than just handwaving make-believe number you pull out of thin air to dramatize the situation. The way I see it now, my proposals cover 95-98% of scripters' needs and it's too much effort for not enough return to do bikeshedding to increase it to 99%, especially since for the leftover 2-5% needs can be implemented by combining regex facility with other facilities already existing in LSL.
  14. Eh I don't care about the actual name of the functions. That's totally LL's prerogative. I just use llRegex() and llRegexFound() as a convenient placeholder. As long as the idea and the features are communicated perfectly and implemented well, LL can choose any function name they want. Case in point, this JIRA issue I submitted months ago: https://jira.secondlife.com/browse/BUG-233195 In that issue I suggested the name llLinksetDataDeleteKeys(), but it got implemented as llLinksetDataDeleteFound() https://wiki.secondlife.com/wiki/LlLinksetDataDeleteFound The functionality I asked for *are* implemented acceptably well, so I'm satisfied. (And yes a Linden told me that llLinksetDataDeleteFound() is totally made based on my JIRA issue.)
  15. Thanks! So it's confirmed that llJsonSetValue() indeed does automation escape double quotes. That should be in the documentation.
×
×
  • Create New...