Kadah Coba
-
Posts
207 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Kadah Coba
-
-
On 10/12/2022 at 6:32 PM, Wulfie Reanimator said:
Genuine question: For the things we would expect to be able to link together (like sim scenery or clothing), how often do we imagine them to be using object-shared persistent data storage, instead of in-memory storage (or something in the description)? Are key-conflicts (and loss of data) in a situation like this something that's likely to become a common problem?
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.
On 10/12/2022 at 6:55 PM, Quistess Alpha said:The main use-case problem I'm envisioning is texture-change clothing. But, I think with the improved efficiency of utf-8 over utf-16, assuming you don't have any name-conflicts, I'd expect to be able to link 5+ really fat ones together before memory overflow, and that's assuming they don't make any effort to compress the keys (with utf-8, I'd think you could get a UUID down to 18~20 bytes? vs theoretical minimum of 16.)
(back of the envelope: 14+36 ~= 50 characters for texture name+key, *200 texture options = 10,000 bytes, or 1/6 of the local database.)
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.262833On 10/13/2022 at 5:12 AM, Qie Niangao said:Right, so for my first big LinksetData project I'll claim llChar(0xDF) —looks like "×"—as my namespace prefix. Nobody collide with it, okay? 😛 Just one extra byte per row.
And I promise never to call llLinksetDataReset(), so nobody else ever call it either, okay? 😛 Because you can never know when somebody might have your script in an object that gets linked with one that has my scripts inside.
Instead we'll all just call llLinksetDataDelete() one row at a time for keys found in batches until llLinksetDataFindKeys() gets no results for our personal namespace prefix. Because we'll all just agree to do that, okay?
(Am I the only one who sees a problem here?)
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.
23 hours ago, Frionil Fang said:This is strictly my personal feeling on linkset data:
Trying to safeguard against what every other user/scripter might do seems like an unreasonable expectation, and from my point of view linkset data is meant to be a "sane", spacious replacement for hacks like storing data in description/other string fields of an object, not a secure remote server replacement.
Maybe it should be thought as more of a cache rather than a file, it could be invalidated at any time.
Personally, I'll be very happy to have what's basically a free 64 kB of data storage for my projects, since they tend to be single-script and not expected to allow linking to random things.
Edited to add: I understand that now would be a good time to expand the spec to have more than just the "sane bigger replacement", but the extra complexity... would we ever actually get it then?
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.
8 hours ago, Elisabeth Ohmai said:Everything nice with LSD, but what about commercial NO-MOD scripts? With description field customer can to set initial values for script without permission to edit the script itself. We need UI for view/edit LSD, or this is not full replacement for description field.
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.
1 hour ago, Extrude Ragu said:To be honest I would have been quite happy with just an extra hidden string field like the description, the async stuff just adds a layer of complexity IMO , but I suppose its a whole lot better than nothing, hopefully this will bring about the end of the days of notecard configurations
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.
-
2
-
Per link stores.
-
52 minutes ago, Coffee Pancake said:
KADAH !! OMG.
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.
33 minutes ago, Fenix Eldritch said:I don't think that's the case anymore. I recently tested in-world on the official viewer and people nearby (also using the official viewer) didn't report seeing anything sent to DEBUG_CHANNEL from my scripted objects. Wulfie did a similar test with FS and saw the same result.
For sure it and llOwnSay spam yourself still though. llOwnerSay has less overheard and throttling, so generally I prefer it debugging.
33 minutes ago, Fenix Eldritch said:This was mentioned briefly at the server meeting and I don't think anyone commented on it (conversation was deep on something else at the time) :
But... I've been having a heck of a time getting it to work. I made a bunch of entries with keys named firstkey01, firstkey02, etc. and am struggling to get anything with a basic regex returned.
Admittedly, I'm not very experienced in regex, but from the online aids I've found, a regex of "/key/g" should find all instances of the string "key" amongst the KVP key names. I've tried other examples, but am always getting an empty result. Am I missing something really basic? (probably)
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).
15 minutes ago, Quistess Alpha said:"/key/g" look like a sed string, not regex.
I'm not really a regex expert either, but I'd try "*key*" to find anything with the string "key" in it.
ETA: looking at Wikipedia, if that doesn't work, try ".*key.*"
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.
-
8 hours ago, Coffee Pancake said:
It's not fool proof by any means. How many scripters don't know that DEBUG_CHANNEL is a thing even though it has some popup UI they must have seen at some point.
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
7 hours ago, Qie Niangao said:The big problem I'm not able to get my head around now is how multiple unrelated scripts from different sources can share an object's Local KVP store. I have a particular application in mind that would otherwise just reset KVP whenever it starts, but that could be disastrous for some other unknown scripts that also use KVP. And very much vice versa.
At the user group yesterday here was talk about permissions and protection of the KVP as a whole (which degraded into a typically religious cryptographic debate about a functionality that wasn't even specified yet).
It would be ideal if there were some sort of object-scope quota system that the owner could specify, to which scripts would comply. In lieu of such a thing in the implementation, could scripters devise a "voluntary" sharing protocol?
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.-
2
-
1
-
-
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~
2 hours ago, Coffee Pancake said:Exposure of feature to users beyond the minority of elite scripters paying attention.
Ease of debugging without the need to develop debugging tools, especially useful when changing linksets.
Increases accessibility of the feature and makes wide spread adoption more likely.
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.
-
1
-
1
-
-
2 hours ago, Love Zhaoying said:
Fun, annoying use-cases are abound!
- Bots can use it to collect data without HTTP, then send the data after TP'ing home.
- Zero-Second Orbs can use it to create ban lists without using an HTTP-based server.
I meant what use cases for a viewer UI for realtime table view of lkvp. :p
-
1
-
-
8 hours ago, Coffee Pancake said:
A simple real time table view would be sufficient.
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...
-
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.
-
4
-
-
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.
-
1
-
-
10 hours ago, Jaylinbridges said:
I gave up wondering why their viewer doesn't have some of the most basic and useful features that everyone uses.
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
-
4 hours ago, Blaise Glendevon said:
I wish LL would make it mandatory for TPV to match their ratios to the Second Life official viewer and scrape out all the cruft from V1 that seems to serve no purpose other than some people being unwilling to change.
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.
-
1
-
-
4 hours ago, animats said:
Does it?
Try putting emoji in a notecard. Doesn't work n FS 6.5.6.
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.
-
6 hours ago, Fenix Eldritch said:
With ordinary text, usually one character equals one byte. For fancy unicode characters, the character may take up more than one byte. I'm not sure what encoding the profiles use (UTF-8, UTF-16, etc) but the bottom line is that the 2nd life, 1st life and notes sections have been given considerably more space.
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. -
41 minutes ago, Henri Beauchamp said:
They do still use it... and in fact, due to the bug I explained in my former post here, LL's current viewer does not even use the new AgentProfile capability (i.e. the new API).
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.
-
4 hours ago, missyrideout said:
Is it a new web profile or are the changes to the legacy profile? One profile that will eventually be in TPV or just another aspect ratio?
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.
10 hours ago, Henri Beauchamp said:Thankfully, they did not remove the related UDP messages (and are actually today reusing them (*)) and the TPVs could keep the v1-style profiles all this time.
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
-
1
-
1
-
-
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'.
-
1
-
-
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.
-
2
-
-
5 hours ago, Love Zhaoying said:
What solution do you suggest?
@Madelaine McMasters, Puppetry could also enhance the possibilities for those with disabilities in Second Life. Example: ASL via puppetry!
This is where Leap Motion Controller support would be perfectly suited.
-
1
-
2
-
-
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://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.
-
8
-
1
-
-
2 hours ago, LittleMe Jewell said:
LL has always balked at increasing groups very much because they are apparently extremely problematic performance wise. Why in the heck did they double the number of groups for PP then, rather than roughly 1.5 times? If a high number of groups really is a big performance issue, why not 100-105 instead of the full doubling to 140? Or are they expecting few enough PP accounts that it won't really matter overall?
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.
38 minutes ago, Qie Niangao said:In case anybody else was wondering too, I asked at the Concierge and Land User Group meeting a few minutes ago and confirmed that the 2048 Linden Homes are planned to be exclusive to Plus subscribers, not available to non-Plus Premiums by adding tier above the 1024 "bonus" tier of that subscription.
What I didn't ask was whether there's any throttle or cap on the number of free uploads a Plus subscriber can generate. When stuff is completely free, there's a temptation to divide by that zero—and a business motivation: Say a Plus-connected "scripted agent" will upload all your .pngs to textures delivered to your Inventory for a low monthly fee. How many non-Plus subscribers might be recruited, making that agent's Plus subscription profitable while simultaneously undermining the market for Plus subscriptions?
It feels like bot uploading of assets would be against TOS already...
-
1
-
1
-
-
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.
On 6/20/2022 at 5:04 PM, Qie Niangao said:Obviously, two Premium non-Plus accounts also get two "land scope" Experiences. I suppose there are a handful of folks who want two distinct Experiences under the same recognizable account identity, perhaps somebody famous running role-play regions whose users will trust them but need to use separate and distinct Experiences for some reason (?).
As one point I'd hoped for a grid scope Experience as part of Plus, but those hopes faded a long time ago.
All in all, for my purposes, I'm having a hard time working up the enthusiasm for a lukewarm "meh".
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.
-
1
-
-
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.
-
1
-
-
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.
-
1
-
-
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.
-
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.
Facebook
Instagram
Twitter
YouTube
Flickr
"Linkset Data" is coming.
in LSL Scripting
Posted
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).