Henri Beauchamp

Same problem: these textures used to be *.j2c files distributed with the viewer, but in recent (?) viewers, they are no more bundled and must instead be downloaded from the servers. Obviously, someone at LL did a blunder and removed the corresponding texture UUIDs from the servers tables/database... I wonder why LL removed the textures from the distributed files in the first place: the latter allowed (and still allow, for v1 viewers) a much faster ”rezzing” of all those commonly used textures...

And the Cool VL Viewer allows to use both GLOD (old mesh simplification library) and meshoptimizer (new library that replaced GLOD in LL's viewer), also with slightly different algorithms for (hopefully) better/more coherent results.

LL is pretty adamant about Dullahan/CEF ”pre-loading” to ”speed up” browsing with the web media plugin (*)... See this commit, for example, with my comment in it (un-replied and ignored by LL). Once more, LL, I told you so ! You may try the Cool VL Viewer (it won't load extra CEF instances), and see if it solves your memory consumption issue. Note however that, if the place where you log in got a lot of web media on surrounding objects (”media on a prim”) and you configured the viewer to auto-load all media, you will get a lot of Dullahan instances fired up... Try turning off media in the viewer to see whether it makes a difference, and if it does, turn it back on but limit the playing media to the agent parcel, for example. If none of the above solves your issue, then this is most likely a driver issue, and you need to find an old graphics driver version that won't be affected by it. (*) in your task manager, you will see several (up to 6 or so, IIRC) dullahan_host.exe instances per playing web SLPlugin.exe+CEF instance; this is because CEF uses several threads to render a single web page. The processes themselves do not consume that much RAM, but each CEF instance will also load the GPU and use the graphics driver, which may worsen your memory issue if the driver is the culprit.

Not saying it is impossible to do, but just that, currently, inventory folders are not coded that way (even item picker lists are in fact based on a filter applied to the whole inventory tree). Yep. An inventory object (which includes folders) only reference their parent folder. This is not to say you cannot get the contents of a given folder either, but you need the whole tree in memory to get it...

Not sure at which point, but apparently, all those environment textures that used to be bundled with the viewer ”UI” textures have vanished from the distributed package and are now loaded from the servers... Of course, if LL pulled off the corresponding server textures, or if the servers are slow or fail to serve the textures, you cannot see them properly any more with the new viewers. Being a v1 viewer, the Cool VL Viewer is not affected by this bug (textures are on file).

Thing is, as the inventory is currently implemented, the whole inventory tree is always loaded when a new inventory floater (”window”) is opened... So the ”it (currently) takes age” reason for BUG-229278 won't be addressed, I'm afraid, and the best you could do is opening a new floater with the whole inventory tree loaded, but the target folder already opened/made current... As for BUG-229279, you can already open another inventory floater (as many as you wish, actually): for LL's viewer, click on the gear in the first inventory floater and choose ”New inventory window” (note that the shortcut it gives, CTRL SHIFT I, won't work, because it toggles the ”current” inventory window on/off). So, you can already drag and drop inventory items from one window to the other...

More fun numbers: while ”idle”, my overclocked system consumes 143W.h in total, so the over-cost of running SL is less than 45W.h with the frame limiter on and set at 60fps, and less than 150W.h with it off... Being a lucky French guy, I got cheap electricity, and even anticipating coming price increases, it's about 20 cents per kW.h... So running SL without the frame limiter costs me 3 cents of so per hour and less than 1 cent per hour with the frame limiter on, when compared to letting my PC idling (or just surfing the Web)...

I'm a bit skeptical about your calculation... Let's say your computer consumes 1kW.h (which is already an enormous amount of energy: my overclocked 9700K + overclocked 1070Ti consume less than 300W.h in average (*) when running SL with the Cool VL Viewer without any frame rate limitation). Given L$4000 is equivalent to around US$16 (= 16 Euros too, right now), it would mean you pay that much for each kW.h of electricity ?... My guess is that there's an error of at least an order of magnitude (x10) in your calculation. (*) I just made a measurement with a (true RMS) Watt-meter connected so that it accounts for all the power consumptions (PC + LCD screen, etc) in my system. The total power consumption averages at 280W.h without frame rate limitation and with ALM on; it can reach 300W.h while rezzing after a login or TP, and when the FPS rate reaches 210+ fps; it is of only 185W.h with the frame limiter set at 60 FPS. And this is for a PC in which the CPU and GPU have all cores permanently locked at their overclocked frequency, which is 5.0GHz for the 9700K cores and 1980MHz for the CUDA cores (and 9200 MHz for the VRAM), meaning it is indeed not a PC set up for energy savings !

This is not exactly true. The more optimized the viewer, the less energy it consumes per rendered frame (because less CPU and/or GPU instructions are executed per frame), but if you let it run freely, then it will render more frames per second, and thus consume more power in the end... The solution is a well optimized viewer with a well conceived frame limiter (a frame limiter that won't kill your rezzing experience by lengthening the rez time). The Cool VL Viewer fills the bill, of course, but you'd have guessed it, I'm sure !

This is called a WYSIWYG editor, and would be the cause of an immense bloat in the viewer note card code (as it would involve implementing a full flegded text word processing software inside the viewer). It won't solve either the issue of ”old” viewers not able to display the ”enhanced” text... And why would you think that they would spend less time writing down a documentation in an in-viewer note-card WYSIWYG editor than one in some common word processing software with its file posted on any free hosting service ? It's all the same for them. All they need is a good way to point to the formatted text from SL (thus my URL asset proposal, which could even be part of a boxed product: double click on the asset, and the in-viewer CEF plugin would open the formatted document, or the video tutorial, or whatnot: not even any need for a note card).

If you see the same issue happening with different viewers, then it is indeed likely a graphics driver issue: did you try reverting to an older driver version ?

Problem with mark-down: you cannot view and edit the note card like you do currently (i.e. you would need a ”View” mode, used by default when opening the note card, and an ”Edit” mode for changing it), and viewers not implementing it would see the mark-down language, and never the final result. No. If you do need formatted contents, then just have the note card text pointing to a formatted document (thus my suggestion for the addition of an URL asset addition, instead).

Quite a bit excessive, IMHO... It would be better to restrict auto-closing to sessions opened by residents not on your Friends list. With the Cool VL Viewer, you may use Lua to achieve whatever result you wish. Here is an example (add or merge to your automation.lua script), to auto-close sessions initiated by non-friends: known_sessions = {} function OnInstantMsg(session_id, origin_id, session_type, name, text) -- Track known conference sessions, so that only the session originator -- is checked for against the Friends list (as the session could comprise -- non-friends as well)... if session_type ~= 2 or known_sessions[session_id] then return end known_sessions[session_id] = true if not IsAgentFriend(name) then CloseIMSession(session_id) end end

Building with pre-made and fixed size elements, as is expected from a world based on a game engine... I.e. forget about making your own design, it's all pre-designed... Thanks, but no thanks, I prefer battling with SL's primitives, even if better build tools would of course be most welcomed.

This is indeed one thing I have been wondering about ever since LL decided to use CDN and then do the ”uplift” (”up”, really ?) to AWS. I won't be surprised if the net result was a significant increase in costs for LL, not to mention the loss of their independence towards such big companies (*), and the loss of the ”know how” in maintaining their own farm of servers... (*) And not just financial independence, but also independence in regard to the technical choices, such as, for example, enabling the HTTP servers with HTTP/2 or other upcoming protocols, and when. I agree, but we must first think about what kind of users we want for, and can actually hope attracting to SL. But as you say, it is of the uttermost importance to hit the initial expectations for the targeted users. I do not promote elitism for SL, just natural selection. Do not try and retain (or even attract) people who won't stay and enjoy SL in the end, but on the contrary target people who can enjoy it... But it does not mean either that SL should not try and adapt itself as well to a wider audience (e.g. mobile devices users). It simply means that until this SL-side of the adaptation is done, you cannot hope attracting that audience. It is by far better not to fail retaining a user, by not attempting to attract them in the first place if they are not ready to enjoy the virtual world, or the said world is not ready for them; a disappointed user will almost never come back and do a second try.

Excepted that Fortnite is a game, with rules, a goal, etc. Second Life is not a game (even if you may find games in SL). Her method supposes that the attention span of the player is consistent enough and they are motivated to learn how to play in that game. Without a minimum of ”computer literacy” (I'm not speaking of ”expertise” here, but just some knowledge about how to find features and learn using them in a software), and curiosity and/or perseverance, a new user cannot get ”hooked” long enough in SL to discover all what this virtual world could offer to them. As I see it, it is a total waste of time to try and attract everyone to SL: some people will just never get the motivation to learn how to use and explore SL.

If you stayed, then you are not among computer-illiterates... Or perhaps perseverance and curiosity largely made up for it. QED. 😜 And yes, I do believe that ”natural selection” is beneficial. This also works for virtual worlds: people who stay are resilient and/or adaptive enough, and too bad for the others...

Frankly, thinking it is possible to improve the retention of new users who do not even spent 10 minutes before deciding that SL is not for them, is a mistake; the same mistake LL made back in 2009 when they removed the second name from the registration form on the pretext it would help more people to complete that form and gain a larger number of newcomers as a result (but LL since back-pedaled, and monetized the second name choice by users: I'm sure complotists are seeing an evil plan behind this all 😛). SL is too complex to hope that computer-illiterate people, or people with a short attention span will become long term ”SL residents”. LL should not worry about them, but instead try and attract ”competent” and curious people (who are also usually among the productive and creative folks). And yes, giving them fun tools to play with is a good way to keep them coming back to SL !

Well, making the note card editor into a browser and HTML editor (HTML is a markup language too, which would fulfill all those requests...) is not really a solution... But certainly a good way to bloat the code ! 😝 However, perhaps something could be done to allow storing in the inventory new ”external link” assets, that could then be embedded into note cards (like other assets) and, when clicked, would open the CEF plugin for viewing the external link (HTML page, PDF file, streaming media, etc) the asset is pointing to... The formatted text (or whatever, including demo videos or whatnot) would then be displayed in a full featured browser, and no fancy markup language would have to be invented for note cards. You can of course already use URLs in note cards, but an embedded asset would allow to hide the gory details of the URL behind a simple name for that URL (with, of course, potential security issues, but not worst than what is already possible today via media in SL)... Also, the URL asset could be copied as an inventory item, given away, etc (easier than copy/pasting URLs via text)...

Just like you, when I joined SL, flexi prims just got implemented, and we did not yet have sculpties either... But building in SL was fun and easy, even for the newbie I was back at that time ! So, I cannot agree more (see third advice in this old post of mine) : we indeed need in-viewer (possibly with servers cooperation) build tools adapted to SL modern features.

I changed that, over 5 years ago, when I implemented skin-able script editor colors (color values have been replaced with Lsl*Color setting names that are themselves mapped to actual color values in each skin colors_base.xml file).

That's one of the very reasons why I did not change the original v1 fonts for another in my v1 viewer... Finding a font that looks as good as the original one in all UI elements is close to an impossible task. That's also why the ”one font fits all viewers” wish of the OP will never happen (at least never for my own viewer), but I just added a debug setting to allow changing the note card editor font with any font present in your system... Yes, in all viewers, via the debug settings floater... Just give the color name as the debug setting name. Colors are defined in the skin/whatever/color_base.xml file in v1 viewers, and this file can be overridden by the user (as I already explained in my former posts) to avoid having to edit it every time they update the viewer. Well, yes, you do, if you want to make it a user-friendly changeable option: you need to add color reverting code support in a preference tab menu, for example... Firestorm obviously coded it as a separate preference floater for the script editor. You can in the Cool VL Viewer, since I added skin-able color names for all script editor colors years ago already. And I just added new skin color names for the note card editor, so there, people will be free to change that as well (including via Lua now), if they so wish...

What a nice colour for a demonstration !... In French it is called ” jaune caca d'oie” (which would translate to ”goose poo yellow”). 🤣

I can only speak for myself, but my main motivation for new features is their actual usefulness to me in the first place (after all, the Cool VL Viewer has been created for myself in the first place, I never pretended it would suit everyone's needs and preferences). This is, for example, the case of the viewer-side Lua scripting feature that I developed. I wanted it for myself, in order to customize the viewer for circumstantial or specific needs, that would be too much of a burden (and too much added bloat) to implement in C++... This feature also happens to offer to all users a way to customize the viewer features and even UI to their own needs... I could well add a way to change text fields background color or fonts in Lua, rather than adding yet another setting to only note card floaters.

I'm sure Firestorm (like almost all TPVs, mine included) offer an even more interesting option for long editing sessions: editing scripts and note cards in your preferred external editor program... Also, please consider that your view on what is ”essential” (like the background color) is likely not what is essential to other users (the font choice is among those ”not so essential” things as well). Developers must make a choice between the features they implement, based on actual ”popularity” of the said features in regard to their free time (which is limited for unpaid Open Source developers)... There is always a trade off for new features in term of performances; even if the feature implementation is not in a hot code path, the larger the final binary, the more likely useful and critical parts of the viewer code will get evicted from the caches, and this is what I call ”bloat”.