Jump to content

Kadah Coba

Resident
  • Posts

    207
  • Joined

  • Last visited

Everything posted by Kadah Coba

  1. This. Its been a really weird hangup in this thread for some reason. If that many users really must have this kind of crutch, fund/bribe/convince one of us FOSS devs to make a front-end. I'm pretty sure a viewer component is well outside of the scope for this project, and I'd greatly prefer LL dev time going to expanding LSD or other LSL functionality first and those are things we cannot affect ourselves (plus I'm not allowed to add server features without permission anymore).
  2. Considering this is possibly one of the most generally useful things to be added to LSL is a very very long time... I expect its gonna see a lot of use in new stuff as it gets know about. Most obvious use that I envision causing conflicts either with keys or overruns is pose systems. Take a decorative item that uses LSD for texture info then link it to a sitting apparatus with a pose system and was already using nearly 64KB of data and you've suddenly have unpredictable data loss. LSL string don't support every unicode character (would be nice to have a byte array type...). From the ASCII block, all but null work, which is kinda of annoying for this. BASE127 works, which is typically doing to be 18-19 bytes per key (less if there are many leading zeros, but that's very uncommon). I think that's the best achievable without compression. BASE64 uses 24 bytes per key. The trade-off of BASE127 over BASE64 is that it takes much more time and uses more byte code. Here's the result of a quick benchmark on a slightly laggy region. Each test is encoding and decoding 100 random keys and storing the encoded keys to a list in script mem. [03:39] base: 127 Start: 13934 Current: 19596 Change: 5662 SPMax: 20948 Size Bound: 18 - 19 Runtime: 12.400760 [03:39] base: 127 Start: 13934 Current: 19614 Change: 5680 SPMax: 20902 Size Bound: 18 - 19 Runtime: 11.949040 [03:40] base: 127 Start: 13656 Current: 19576 Change: 5920 SPMax: 20850 Size Bound: 17 - 19 Runtime: 11.935850 [03:40] base: 127 Start: 13656 Current: 19586 Change: 5930 SPMax: 20796 Size Bound: 18 - 19 Runtime: 9.685167 [03:41] base: 127 Start: 13656 Current: 19602 Change: 5946 SPMax: 20762 Size Bound: 18 - 19 Runtime: 10.044070 [03:41] base: 127 Start: 13656 Current: 19552 Change: 5896 SPMax: 20832 Size Bound: 18 - 19 Runtime: 11.290470 [03:41] base: 64 Start: 10862 Current: 17574 Change: 6712 SPMax: 17574 Size Bound: 24 - 24 Runtime: 2.442940 [03:42] base: 64 Start: 10584 Current: 17526 Change: 6942 SPMax: 17526 Size Bound: 24 - 24 Runtime: 2.270569 [03:42] base: 64 Start: 10584 Current: 17526 Change: 6942 SPMax: 17526 Size Bound: 24 - 24 Runtime: 2.274925 [03:42] base: 64 Start: 10584 Current: 17526 Change: 6942 SPMax: 17526 Size Bound: 24 - 24 Runtime: 2.372391 [03:42] base: 64 Start: 10584 Current: 17526 Change: 6942 SPMax: 17526 Size Bound: 24 - 24 Runtime: 2.252426 [03:42] base: 64 Start: 10584 Current: 17526 Change: 6942 SPMax: 17526 Size Bound: 24 - 24 Runtime: 2.262833 Yeah... this could be like the whole "reserved" channel mess again. Would really prefer each prim/link being able to have its own store so we can just avoid the future mess and headaches mergers. Plus more storage is always more better. Its about as persistent as script mem, if the user has mod on the object, they can reset any script, and also deal with whatever that breaks. The extra new thing on top of that is object mod also also allows read/write assess, which some people are getting really hung up on.The lack of not being able to have mod and block other scripts from messing with the LSD store is not a blocker for me (beyond that it will likely result in more no-mod/no-buy objects in the future). I welcome the 64KB of shared storage. As-is now, its totally usable for me. Buuuut.... If adding features is still on the table, I'll take, in order of importance to me: Per link stores. So we can allow for sidestepping the mess merges and conflicts can cause. More storage is always welcome. Would need link param on the functions to specify the store. I could add memory submissive scripts and get at least 32KB of storage per script. Pretty sure LSD stores are less impactful than twice as many scripts. :p Pin/keyed access. Avoid having to make objects no-mod/no-buy, and/or using time expensive encryption, to prevent undesired access/tampering to stored data. Could be a dedicated KVP entry in the store with each script needing to call an unlock function for the read/write/find functions return successfully. Per key encryption would work too, which is something we could already. Ability to access from other objects. Would mostly want pin/key for this. While long-distance access would be cool, but that's just Exp KVP at that point. Simply the same rules as llGetObjectDetails would be good to me. And I can't think of anything else. A viewer-side bower is defiantly getting in to feature creep. Would rather have that for Exp KVP, but if we want it that badly, we could make such ourselves. I could likely make something that sync's KVP stores to/from a Google Sheet if someone want to fund my time. Use the mem savings to make a menu system or notecard reader. Description config has always been rather user-unfriendly for anything more than something simple. Nothing is taking away using descriptions in that manner in the future, so you can keep using them if you want. :p I'm starting to wonder if I missed all the requests back in the day for a viewer front end list browser for llList. Its not async though. You can use it similar to llList2String and llString2List. On scripts that use a lot of mem for storage, they could use the savings to have a better menu system.
  3. Not sure if that's a possitive response, but if ya want to use it, the setting should still be in the main prefs panel (unless FS removed it as they still love to mess with hiding prefs for some reason, lol), just search for llOwnerSay, or its still in the script settings panel, the same one where you would set your preproc include path. For sure it and llOwnSay spam yourself still though. llOwnerSay has less overheard and throttling, so generally I prefer it debugging. Hold up, we have an LSL function that can use regex finally? That's a first. I wish we could get a function do regex on strings directly (I'd also love an llFormat too, just saying). That looks like a full expression, but almost nothing I have used ever needs/uses the starting / or end /g (which I think means global). .* is greedy match any or none of any length. If you are trying to match JUST a UUID, then try: [a-zA-Z0-9]{8}-[a-zA-Z0-9]{4}-[a-zA-Z0-9]{4}-[a-zA-Z0-9]{4}-[a-zA-Z0-9]{12} If there is ALWAYS extra data before or after, add .+, if there is OPTIONALLY extra data, use .* https://regexr.com/ is good site to test expression on.
  4. I use llOwnerSay and added an option to FS to route all llOwnerSay to the object's own script panel, but not the main panel too. Its a lot better than spamming everybody with debugs while also not making your local chat completely unusable. :p As somebody that will link different things together when building out my region... or even as someone that would make things that could be linked later to random things by end users... How about each object has their own LSD store, which can be accessed from other links, and maybe has some optional method to restrict access, possibly via a pin. That would resolve the issue of unwanted collisions when linking things that could have incompatibilities when they are trying to share the same LSD store, and things that can support sharing can just always use LINK_ROOT and handle the merging themselves via the on link event. If there is some issue with each object being able to have an LSD store, make a limit of how many their can be per link set and either prevent linking (preferable) or block/wipe the additional ones being added. Edit: Also want to add my +1 to wanting the ability to access LSD from other objects. I'm cool if its limited to within same region or similar limits for llGetObjectDetails. Grid wide would be cool, but also seems out of scope given how LSD is likely implemented and probably would require too much to implement.
  5. Be doing some testing. Keys and values are stored as UTF-8. That's probably ideal for most uses because ASCII only data sucks for limits with UTF-16 (which is what LSL strings use as far as I could tell). So don't try do something silly like using custom high base encoding to try squeezing more, that just uses more to store less since all the flags for UTF-8 and the deadzone blocks eat up any possible saving. LSL actually support the full ASCII charset, so I think the best that could be done was around BASE96 or something (or some cross char encoding scheme, which would be way more complicated) , not really worth the overhead verse the building in BASE64 functions. There's no data overheard per entry. A single ASCII char key with the same for the value will cost 2bytes. Cool that's there is no "tax" for the data structure being used under-the-hood. No noticeable additional throttles. Could hammer with 300-16000 write+read cycles per second depending on the code and it was always pretty stable latency range (see chart below). I might have to benchmark my old PSRAM library to see how that compares. There's a time penalty/trade-off for larger value lengths. Below is chars-per-value vs write+read/s at 2k cycles per point using max storage for the given value length. Looking like its best to trade complexity of custom serialized data and use LSD (well that's unfortunate acronym) if the usage of unique keys is going to add additional data size to the application or it is worth the trade-off. What little I've played with it tonight, I'm liking it. Its fast. It can be treated like llList2String+llString2List. Can replace some uses of link messages. We've hoping for more script mem for a decade. This isn't quite that, but it'll likely be very handy for freeing up mem elsewhere since the low latency on LSD is (as of right now) really appealing. We've also be wanting shared prim data. Would have been kinda happy with a new prim param type that was just a string. This is possibly better than we were wishing for. Thanks~ I'm not sure how obtuse it can seem to a new scripter when it can essentially be treated similar to llList2String() llString2List() with a single linkset global list. The main difference is strings keys instead of integer indexes, which could arguably be considered more beginner friendly. I wouldn't mind having that, but I'll totally live without it. Mostly not sure LL would consider it worth the time to add such though.
  6. I meant what use cases for a viewer UI for realtime table view of lkvp. :p
  7. For what use case would you need this though? Unless there's going to be some API for the viewer to directly access it, the latency of script relaying it to a TPV to do this would be pretty bad and likely slower than the object's scripts ability to update the store...
  8. A discussion on Discord a few days reminded me of this, its a prim with the physics of an avatar. Its an old cursed object I can rez which doesn't require everybody connected to the region to relog or uses an exploit I already fixed. x3 Its nice to see it still work. Remind me of the "keep upright" flag from the Source engine.
  9. Nothing in the release notes for 6.6.4.574724 stands out as a potential cause. Looks like its fixed now. I updated from 6.6.3.574158 to 6.6.4.574885, which is what the installer for 6.6.4.574724 automatically updated to during install, and I cannot repo the issue.
  10. Because LL hasn't asked me to port any of them in the 3 years since legacy profiles and copy-paste build tools? The only one I can remember that was still pending is "edit at root", and that pull request got lost years ago when Bitbucket nuked all the hg repos. lol
  11. LL is the one that has repeatedly change these ratios. Web profiles was possibly the only "correct" solution on that as it auto-cropped thumbnails to a 1:1 while the original image would maintain its aspect ratio. LL broke that in this update, even though they kept the free upload from disk part. Re "V1 cruft": If you could tell me what in the modern LL UI triggers my migraines that would be great. Until then, I'm going to keep maintaining those at least for myself. I've already subjected myself to months of making the text rendering and various UI contrasts in FS physically compatible with people like me. I am not keel on doing that again as a few minutes of a failed test change would often result in up to several days of being incapacitated and was the main reason why it took so long to resolve without finding the distinct triggers. This condition sucks. I have no idea what it is. I have literally had to quit lifestyle positive activities over closed source UI changes due to it. Somebody using their own time to maintain accessibility forks of something you do not use does not detriment you.
  12. Anywhere that supports unicode that is. Though I just tired in FS 6.5.7, both unicode and emojis are working in notecards. You might be using a typeface that has poor unicode coverage, I don't use the default DejaVu as it causes migraines for me (this is also why I can be very defensive over certain UI changes and have maintained my own viewer forks since 1.2x) and instead use a custom font profile I've been using for over a decade.
  13. SL uses UTF-8 everywhere (I've recent tested that). So ASCII characters are 1-byte, the bulk majority of extended characters used by Latin and European based languages are 2-bytes, and, I believe, most Asian and others language characters may use between 3-bytes and 4-bytes. While 65KB limit is a bit excessive for profile info (thats >800 lines of 80 ASCII chars per line), this change does make it more fare for Asian language profiles as they are no longer limited to around 170 chars while English only could do 510.
  14. How are they getting 65KB support in the about fields? The legacy message was capped at 510B. I hadn't check loading of non-self profiles with long abouts, though I can see it does sync the full size to web profiles.
  15. I think this is targeted to be the default going forward and web profiles, other than the feed page, will get sunset officially at some point. Dev on web profile had been pretty much inactive since shortly after release. Have not explicitly checked, but I think FS upstream has already adopted some variant of this design with the 1:1.013 ratio. You welcome on that. I documented the legacy profile API for LL at their request back then so, I'm guessing, they'd know what not to break. I have not looked in to the new code yet, but suspect the new viewer-based profiles aren't using only the legacy API since the info fields now support 65KB instead of just ~501B. I still kinda laugh at one of the reasons that was given for the move to web-based profiles, (paraphrasing) "it's easier to get web developers than C++ devs that are familiar with a custom UI code base." My response to that then was something like "Ya know I'm right here and would do it for free right?" We sorta did loop back around to that in the end though, I gave them back a v1 profiles starting point in 6.1.1, I just didn't expect it'd take 3.5 years to ship. :p
  16. I would be surprised if USDp actually goes anywhere long term. Short term is possibly like any other industry fad buzzwords, which 'metaverse' has become since the fade out of 'blockchain' and the crash and burn of 'NFTs'.
  17. While I'm not keen on the new layout, its nice to see they finally did something with my legacy profile feature contrib LL asked for like 3.5 years ago. Not sure how much involvement FS has other than referring LL over to me for that request, but maybe they were, nobody ever tells me anything. lol Andrey appears to have done most of the work bringing this this release, so thanks goes to them, and also to Vir and Alexa for doing their best to answer my questions on things nobody else had touched or looked at in many years. It might have already been in the viewer before this release, but it looks like this branch may have brought in my old copy/paste project, also from 2019. I kinda stop doing contribs the last couple years as there nothing seemed to be happening on these last two requested projects. The inability to access much of anything on jira anymore didn't help either. 😛 FYI, if you Lindens still want OPEN-311 / STORM-2123, point me to a fix for compiling the LL viewer on Linux and I'll remake the thing from scratch after a C++ refresher. I've still had no luck recovering that project repo after BitBucket wiped all hg repos a few years ago. Edit: A few things I've noticed playing around with this release. Documentation needs to be updated, display names kb appears to be generic to both web profiles and pre web profile methods. Its cool feeds was kept. I never used it myself, but it was one of the few features from web profiles I felt was a good idea. Any reason why "interests" tab was removed? The web profile ones didn't ever seem to be used for much, and the legacy one had some useful fields that search had indexed from in the past. Yet another profile image ratio, awesome... Web profile used native from what I remember, can understand not doing that, but everything else had always been 4:3 or close to that. These are 3px narrower than 1:1 at 157x159, so like 1:1.013~... that's a thing I guess, lol. The textures look pretty bad being so tiny and squished. Would have been nice our profile photos weren't squished thumbnails. The layout makes it look even narrower. meh It is nice having picks back to something residents on the LL viewer might actually notice is there. Had lost track of the number of LL viewer users I had to explain what "picks" where and how to access them. Pick images are undersized to the pick panel and looks weird, ratio might also be something different from all previously used. Ditto with classifieds. x3 Profile text fields appear to be something new not on the old API since it seems to be supporting a massive data size. I got to around 22KB before giving up, would bet the limit is the same as note cards (65KB I think). I'm gonna guess changes saved on the new profiles are incompatible with actual legacy profiles. Completely unrelated, but the text in the LL viewer is still really harsh on my eyes. DejaVu on this render does not agree with me. So glad I don't have to read anything while using it.
  18. This is where Leap Motion Controller support would be perfectly suited.
  19. So I spent the evening getting puppetry code merge over to a Firestorm fork just so I could run it on Linux, it was easier than trying to fix LL's viewer to compile on there... Got it to work without having to change any of the python code, which was a shock since I don't think they tested this on anything other than Windows. I'm thinking that part is all down to OpenCV "just working", which it was quite well. The previewer of the OpenCV output was working well even in my terrible lightening and noisy background. Some caveats though, the plug-in scripts need executable perms, and none of this works with conda env. Might look in to fixing those in the future. What wasn't working too well was the actual puppetry part. Was able to test with somebody I ran in to on the test region who was running the project viewer on Windows, we were both having similar cases of virtual boneitis. At least it seems like my merge didn't seem to break anything. Likely a "need more info on how this should be setup" sort of things. This is a pretty good start though. :3 Hopefully we can get Leap Motion working on this at some point later on, I've known some people over the years that have wanted better ASL support. https://cdn.discordapp.com/attachments/319806009814155264/1014470334084304896/2022-08-31_02-38-48.mp4 https://github.com/Kadah/phoenix-firestorm_puppertry_exp Edit: Camera track is cool and all, but the really neat part is that the inputs on this aren't specific to camera tracking and pretty much wide open to anything somebody wants to code.
  20. LL would know how what group slot utilization regular Premium users are at and likely based it off that. Not everybody joins the maximum number of groups they can, only some. The few percent of users that get Plus and then join that many groups is going to be a very small. Almost everything about groups is broken and in need of an extremely overdue overhaul. Any time I check for repo on BUG-40824, offline group notices still fail to deliver anywhere from 20-95% of the time on any group or account tested. And that's one of the lesser apparent forms for group fail; almost anybody would have dealt with all the various group chat issues over the years. It feels like bot uploading of assets would be against TOS already...
  21. I'm just gonna wait for the official announcement of what exactly PP (lol, not sure LL anticipated that acronym) comes with, but so far seems possibly useful to me. Free upload on non-mesh assets, yes please. A discounted rate on mesh uploads would make Plus pretty damn enticing. Beta grid works for test uploads, but the lack of having your own land there can be annoying. I'd be happy with an optional Linden Home sized personal sandbox on Aditi. I think there used to be a way to get land on Aditi back in ye olde days. More bonus land tier is always more better. The square increments of tier subscriptions has always been annoying; ie. can only go from 8K to 16K when you only want another 1K and thus begins the cost analysis of premiuming an alt. Experience tools in general have been disappointing. The only use in the wild I have come across have been on-bump auto-TP and auto-attach of region specific HUDs. If Experiences were worth using (outside of those previously mentioned limited use cases), then I could see maybe using the second key for betas or experimental stuff. KVP could have been useful, but the implementation is too disadvantaged to previously existing solutions. Its only upside is the lack of needing external hosting. though in the face of the ease of implementing gsheet-as-a-DB.... lol Grid scope and some more usable features would have been welcome.
  22. Looks like hotlinking doesn't work for some reason (likely some modern browser thing), but if you go to http://www.furware.de/products/text/ first then TextureCreator.zip to the URL, the download works. Alternately, the source is still on github and appears to be just python2.
  23. The username part will change overtime, even from the same source. From a quick check on the constant stream of these I get, they seem to change every 24 hours. Just a guess, but the username part maybe per-region-per-avatar or something like that. In the quite datamine of my emails I did, I noticed the address were seemingly always unique per avatar, but not always the same per message within a short period with context clues that each may have been sent from different regions.
  24. Likely caused by changes/depreciation in the MediaWiki extensions being used in the spaghetti of templates. The visibility:hidden parts are in if statements, I think is how these tables worked previously for which one(s) to embed. It's been about a decade since I admin'd a MediaWiki and I can't even begin to guess what extensions are in use, or which could be causing the various issues the wiki has had since the last update. My quick guess is that some templates need a redo.
  25. More script memory would be nice. Would love to trade script-time, comms use, complexity and increased mem usage for doing more in individual scripts. Even if its gated behind needing to be compiled for an experience. Better experience tools. Outside of walk-in-to-teleporters, I haven't seen or thought of any use for experiences. The required land permission issues nerf using them over non-exp methods. Some form of supported synchronous object data storage. KVP-store is rather limited, async, and land permissions kill it. Just gimme like a MB of binary buffer. lol Generally hoping Plus has a bunch of creator concentric improvements.
×
×
  • Create New...