Jump to content

Kadah Coba

Resident
  • Posts

    207
  • Joined

  • Last visited

Everything posted by Kadah Coba

  1. What's with all the human mesh bodies needing to be cursed? Skimming over the talk around this one, it kinda sounds like they might have confused the list of general complaints about other mesh bodies for a design spec. The only possible upside I'm seeing is maybe its easier to get access to the devkit, but this appears to be offset by restrictive and limiting license terms. Couldn't we have commissioned a few permissive open source bodies instead?
  2. I too would prefer the old stuff be flagged as such instead of nuked.
  3. Why do the bots need EM verse just being allowed via the allowlist?
  4. Awesome, gonna enable this on my estate. And maybe the policy change to further increase the requirement to have bot accounts flagged properly actually has some affect. I hope something like this eventually comes to the parcel level. I have some mainland which has been seeing exponential increase is roaming bots visiting with unknown purposes. It's nearly useless to ban them individually as repeat names rarely are seen. One of our rental parcels has seen over a dozen bots in the past 24 hours, this was typically 1-3 per day max just last week going back over a year. No clue what's with a recent massive uptick in bot traffic. And this is just what's our parcels alone are seeing, the regions themselves might be getting even more bot traffic that we're not checking for. :s
  5. Contributors grant LL a license which would allows LL to change the license in the future. There was actually some various issues in the distant past, which was part of the reason LL changed the license to LGPL from GPLv2. The current CLA for reference. The license they release the code as is what everybody else can use it under. Internally their license is full ownership. However, LL is just unlikely to do a restrictive license change as they are not arseholes.
  6. Holiday week. Larger projects in progress. No bugs that needed fixing. Not bad reasons for a restart only week. :p
  7. Getting super off topic but... The "mid sized" EV charge station I'm currently getting installed will use more electricity than our entire commercial/industrial block and the surrounding residential area. Most of our power comes from natural gas or coal, especially at the hours when its going to be used the most. The possibly sad part is that this station is barely going to put a dent in the EV charge infra that's going to be needed. On the scale of "caring about the environment", it probably would go something like this for socal: pedestrian power, e-bike or similar, bus on a busy route, carpool, ev charged only on home solar, LNG, CNG, fuelcell, hybrid, ev charged from grid, literally anything else, bus on a low volume route (eg. most buses on the majority of routes).
  8. Run Win7 in a virtual machine, then run whatever currently supported OS you want on the host. The number of hax and compromises you'll need to stay on 7 has already beyond those needed in the opposite situation, and this will only increase during this year. I'm saying this coming from a position of still having to support a bunch of Win7 machines at work and have a very strong dislike for 8/10/11. Also, what ancient and probably long EOL'd MCUs and FPGAs are you working with that don't have tool chains that work on anything newer than 7? I'm pretty sure every single MCU I've worked with over the past decade is supported by the current tools, though I could see that happening with some old FPGAs.
  9. There has been only reasons to migrate to a 64-bit OS and viewer for a very long time. This ancient chart of mine of FS crash stats is exactly 10 years and 1 month old today.
  10. If I was still involved with FS, I'd have pushed for just nudging it to 1:1. From what I remember, its like 1 or so pixels off being 1:1, which makes the choice even more confusing. The entire web profile project was like that from what I saw. After [I forget his name, the one that was lead web profiles] left LL, the whole project quickly came to a halt and what had been testing be beta was moved to release as-is. The only thing I ever saw using the tag cloud was that one email campaign trying to do match making on seemingly accounts with few friends and/or in frequent use and/or at random. Good point, being able to grab preferred language in LSL could be handy. Though without some means to handle storing a lot of translations effectively and easily in LSL, its possible the feature wouldn't see much use. I'm only saying free text field if the only other option is a single selection from a predefined list. Its not-quite-markdown, something like [url Text for link] Some actual markdown support in text would be nice to have.
  11. When I contributed the viewer profiles to LL, it included the interests and web tabs. Sometime in the 2-3 years they were working on it, those got removed. I do not known any details as to why. Similarly, I do not know why we ended up with yet another profile image aspect ratio. I had reused either v2's or v1's (I forgot since that was years ago), webprofile's would have also made since, but they went for "not quite 1:1" for whatever reason. lol I can kinda understand dropping most of the fields in the interest tab as they were too limited. Web profiles kinda tried to have similar-ish functionality with its interest tag cloud thing, which as far as I saw, was highly underutilized and possibly only fed the short lived match-maker email campaign. Had that or something like it been carried over, and it had some use in search, and been redesigned to be used more, it could have been neat. One thing web profiles and LL viewer profile did miss is the language field. I feel that the boat left on that being a "should have been kept" back when it was not added to web profiles; which is possibly for the best as back then, I would have fully expected if them to have made it a single choice drop-down instead of free-text or at least a multi-select. The loss of the web tab, specifically the website field, was rather annoying. A lot of residents made use of that for linking to their MP store or other useful links. Largely a lot of my complaints are minimized by the increased character length of the bio fields to 64KB and LL adopting parsing of links in bios as officially supported. An easier method in-viewer to create/format links would be nice as you otherwise have to locate and RTFM the markup documentation for that on your own (getting a WYSIWYG editor control would be a pretty big request). The one key thing legacy interests tab did was to prompt many residents to share a certain set of common data points. So I'm a hard +1 to bring back the "languages' field and a soft/"sure why not" +1 to bring over something like web profile's interest tag cloud under the stipulation that it'll works for search since it is otherwise kinda useless.
  12. Since the deploy was causing damage to existing objects, I believe the rollback also reverted the sim state and not just reverting the simulator version. If you manage to loose no-copy items due to having rezed them during the short window before the rollback, may want to contact support and see if they can do anything.
  13. Kinda surprised the new JWT functions were in this roll, had expected they were gonna be in beta for like a week first before hitting an Aditi RC. Unless they were already and I just heard about them late.
  14. Its possibly about as bad as lists in that example, though lists have the upside that duplicate values are stored as references, though that is kind of an edge case to make happen. There might also be some referencing happening on retrieved values, I can't remember, its been years since I tested this.
  15. Native binary stored JSON within LSL would be nice, the stringized we have now is very memory inefficient. Its fine for save/storing, comms to other scripts and for interfacing with external services, but will eat a lot of mem if uses much within a script as a list.
  16. I found out last night that the JSON functions are stupidly fast. By an order of magnitude, this is the fastest way to convert lists to/from strings while keeping types. Will have some benchmarks on this "eventually". Having support for lists naively in LSD, or other places outside of an individual script runtime, isn't currently possible for technical reasons. It would be nice, but we're gonna have to wait for a bunch of other changes first.
  17. I think what I meant was, once you get data down to being a list of ints, encoding generally becomes easier to manage. x3 I really wish there was a way to transmit binary data between scripts, and if LSD could have supprted lists (TL;DR I got is that it would have required a much bigger project, eg. wouldn't have happened). All the stringization we have to do because code has to be divided up amongst multiple scripts is painful, and all of that eats up so much resources that could be doing more with less. Larger scripts would be great, but there's a lot that needs to change on the backend before that could happen... If the data is going to be mostly large ints, IMO llIntegerToBase64 is still the best option for speed and code size, the fixed 6 char length makes indexing a lot simpler. I used this method for storing large amounts of binary data via media faces (something which could be directly ported to LSD). Currently kicking around a few ideas for non-fixed length encoding with arbitrary lists. Code for fixed structures would be more efficient, but a pain to have to customize for each data exchange type.
  18. I don't think there would ever be much call for needing that many keys at once in live memory. More so storing a lot of data for lookup when needed or to step through to do larger processes where size is of greater importance than raw speed. The most obvious common use-case I could see would be for caching modified poses in furniture. With maximum floating point value limits (either fixed point or split decimal), should be able to store poses for quite a lot of residents. The use-case we've had is storing level/map data. While it may not have many UUIDs in the structure, a UUID is essentially just 4 integers with a minorly inconvenient periodic hyphenation. Those have been the two targets I've been working on supporting in a generic/template-able library. I'll test this later if I remember, but might only be slightly more execution-time to do a higher base instead and maybe still be URL-safe too. Either Base85 or BasE91 seem like decent options as they are somewhat standards that'll be easier to support on a remote server.
  19. I have a few I've been working on, was planning to get it out last month, but been sick so much this Winter that everything is a mess. One's have have so far: Base64 Just a bunch of utility functions that wrap the built-in Base64 support. By far the fastest executing method. BaseE91 The capital E is significant. This one is compatible with the existing BaseE91 implementations out there. Requires a lookup table due to the non-ordered dictionary used by this standard. Base91 Base127 (which is bugged due to BUG-233015) Any base from 91 through 127 can be done with the same method by just swapping out a couple constants and a magic number. I'd have to go back through my workbook, but I think <base91 wasn't worth the trade-offs over using the built in Base64, and >129 is getting in to the "bad for UTF-8". If staying within UTF-16, larger bases might make sense (I might have already figured that out and which, do need to check that workbook again...). Base32k/Base32768 Not as space efficient as the others, but what I remember from the benchmarking, it was faster due to being a power of 2, which makes being unable to use Base128 more sad. Base1T/Base1099511627776 Kinda similar to the last one with one of the ideas from the non-square bases. This was mostly an experiment to see if it was possible. It stores 40bits of data per two Unicode chars, so the number of actual bits used varies on if its UTF-8 or UTF-16 and per char depending on what codeblock its in. Code was pretty fast due to how simple this it is, the most complicated thing is that it uses 3 different blocks of unicode. BaseN I've had a generic BaseN implementation for years. It takes a list of integers of one arbitrary base and coverts it to another arbitrary base. Can get some good packing for binary data, but its like O(n^2), lol. With small lists, its not bad, but it becomes insane pretty quickly. If speed is more important, stick with llBase64ToInteger(str) / llGetSubString(llIntegerToBase64(num),0, 5). I'll try to finish and publish this library with benchmarks SOON-ish.
  20. From my understanding, the LSD store is a standard data type on the sim object. It probably adds only a fairly trivial amount of extra time to the (de)serialize of the object on region change. We could likely test this if viewer already has a teleport-time metric we can access (or if we add one) and just do a bunch of TPs with and without a bunch of full LSD stores.
  21. FYI, we have an actual feature request filed for remote LSD access: https://jira.secondlife.com/browse/BUG-233201 All the string processing that's required in LSL is really painful. I would not be surprised if your script is getting random sleeps during that. I was working on some data packing code a couple weeks back and randomly some cycles will just take 10x longer. That behavior will only be worse the more loaded a region is, which is extra FUN. :p
  22. That was my assumption. Had forgotten about that term for it. x3
  23. An attachments state is only committed back to asset on detach/clean logoff (there is no difference, logoff=detach). What is "Attachments change their data permanently"? An argument could be make for any single object attribute being permanent or temporary entirely on how its being used in a particular application. I do not know the reasons for why timeout (ie crash or forced logout) does not result in a detach. Its possible this is to avoid unwanted results of commit at an unexpectedly point, eg. safer to assume that last intentional detach/logout is going to be consistent to what the user wants/expects. Committing back to asset on region change would increase the time it takes to do region changes. Detached everything then reattach it, now add that time to every TP and region cross and ask if you would want that additional delay. If you are crashing/disconnecting often enough that this is an actual issue, you may want to address what is causing that to happen. Generally the loss of changes on attachments on DC hasn't been that big of a problem, more of a possible annoyance for a user when it happens at an inconvenient time, like forgetting/not knowing to do a detach cycle after doing a lot of changes before the rest of their session do stuff that has higher risk of ending in a timeout/DC.
  24. The release notes page hasn't been getting updated that timely either lately it seems... We'd get a new roll, I'd go to check what changed, and maybe later that week the release notes would be up. >.>;
×
×
  • Create New...