EnCore Mayne
-
Posts
527 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by EnCore Mayne
-
-
twenty three pages in and i'm thinking it's time to speak my mind if i've not forgotten just what it was i was gonna write.
i'm actually quite surprised the lab has allowed us to express our opinions on this matter. good on them. there might be some changes already taking place. if the allegations have caused some internal deliberations as to how THEY police the perverts in our midst all good. doing better, and we're only human is an acknowledgement that there should be some system wide policy changes in the pipe. the reputation of SL, industry wide, really couldn't take any more degradation.
face up to it. SL wouldn't have achieved such popularity if it weren't for the freedom on sex play. the unfortunate overarching issue is that rl societal norms don't jive with our freedoms in this little virtual world. up to this recently revealed horrendously controversial revelation, the lab's ability to police their forced-upon policies governing our behaviours was not something a software company was capable of administering. saying one thing to get the feds off their back isn't the same as intermittently excusing their non-compliance to following their own laws. this is a serious matter, enough so that the top dog has to acknowledge their lackadaisical approach is not something to be admired or allowed by their much more powerful and much less forgiving powers-that-be outside the walls.
SL is not an island unto itself. the sooner that reality hits home the better.
"this has been a harsh wake-up call" -Brad Oberwager, Linden Lab Executive Chairman
-
4
-
-
-
well, that was a deep rabbit hole.
i don't think we give graphical illustrators enough credit.
making sense of the code is one thing. i think i have the capacity for that. but putting together a cohesive rendering of the exploratory vision is sending my time accounting for this topic outside of expected parameters. following this seemingly endless journey to understand what-does-what-and-how may seem unweildy in its length but hang in there it's best if you were committed.
as referenced earlier, the login graphic has a small number of elements that appear on our screens. i've reordered them to better illustrate the coherence between the graphic and the code behind it.
each of the elements are easily recognizable, they're graphical, that's easy. recognizing that particular element's actual code amonst all the other foreign terms can get a mite difficult if you don't know how the xml file is constructed.
that's why i've arranged the elements the way they are. as the code is written/read top to bottom, that's how the elements are arranged. it's not always that way, but for this instance, it works. how that exception is understood, think of it like putting the element code on the inside of a box bracketed by start and stop tags. so, if you put the code for a bottom appearing element in a box at the top of the xml code it might not show up where you might think it might. fun huh?
non the matter, our current example follows a top down design.
so, keep in mind that the code for each element can be shown as a box as i've illustrated by the red box below. that code, depending on where it goes in the overall package, paints the code's instructions. for example, this is the code for the web browser:
we're not going to get into the attribute details of this element yet. we have to address the box that these various graphic elements go into. a box within a box.
in this case the <web_browser /> code goes into the initial box as constructed by the xml code's tag <panel> ...content... </panel>. the initial panel tag, called the root in xml speak, contains ALL of the elements. everything between the starting tag to the end.
so everything written in the xml file, the entire 298 lines, falls within the start/stop tags of the root panel and is constrained by the attribute's quoted string values.
there's a bunch of attributes that can be utilized for any element. since we're only editing the existing code, we're not going to experiment in the XML Preview Tool to find out just which attribute works. most terms are pretty much common sense as to what they describe. remember, these xml tags were conceived by the original designers of the viewer. they're proprietary and won't work in any other application.
i'll explain each of the individual attributes next post.
-
10 hours ago, erineni said:
One year ago me tried to change the font that SL Viewer uses to show all Unicode characters. There's not much to tell 'xcept it was like useless to change coz it wont work. . . nonetheless me had a dream a dream for a videogame-level kind of UI. one that was immersive...
Your approach seems feasible. And I would love to learn more about all thisTa for the info! and me will deff try 10/10
i feel ya. it's a nightmarish hellhole to be sure. the Linden responsible for the xml upkeep (if they exist at all) should be ashamed.
not so clued in about unicode. i have added some extended ascii symbols to the menus tho, so there's that....
glad to see the vision is still alight. check out:
for a real futuristic feel. not sure they are still with us tho.
true genius no matter.
-
1
-
-
if you really want to get serious in personalizing your viewer, have a look at mine above and picture one for your self. it's only one xml file (panel_fs_nui_login.xml) and no you can't mess up your logins fiddling around with the look and feel the xml files provide. no functions or calls are altered, we're just arranging graphic blocks again.
i can't stress this enough, for those squeamish in wrangling the xml files, i assure you, no code has been harmed in any of the processes we've done to date. the consequences may result in numerous crashes (if you don't dot your t's and cross your i's) but at worse you'll just have to revert to an earlier backup. nonetheless, you won't destroy anything that the far more daunted code-monkeys-underlying-it-all have
avoided/created.the scary C++ references are in there, inside the xml code, but we just move their entire functional "blocks" from one place to another. not having a GUI to help in moving text-based graphic elements is certainly no fun but once your head is sufficiently programmed in the basics it'll become natural, hahahaha....
i suppose we should delve into some of the commonly used elements we're trying to arrange. continuing along with the login page example the most significant blocks used in this particular screen are:
- web browser,
- icons,
- drop down boxes (or combo boxes as they're referred to in SLspeak),
- check boxes,
- buttons,
- line edit boxes, and
- text boxes.
i'll have another graphic that illustrates how, what, where, and why these elements appear in the code. until then, you're more than welcome to chat with me inworld. don't be shy.
-
2
-
i've come to rely on the XUI Preview Tool for tweaking the viewer's xml files. it's so much better than waiting through the login process just to see one itty bitty change; a pixel here, a pixel there. the tedium of perfection is always challenging.
unfortunately, when the tool was designed there was no such thing as Firestorm's medley of skin choices. now that the devs have been made aware of the monstrous amount of foraging through code to fix the Tool's issues, i can only offer them my condolences. the way the open sourced viewer has been put together the viewer's capacity for utilizing multiple skins is not something i'd want to rethink. but what do i know, it could just be a simple variable and all the files the Tool lists could one day be from the applicable user defined skin files.
until that day i've altered the Tool's xml to have additional details presented as to how it can be confidently used. don't mind the removal of some of the peculiar non sensical buttons and options they just complicate matters.
as it is, the file listed in the Tool only displays default skin files BUT the preview shown is derived from the user defined skin, in this case my customized Starlight silver_blue theme. knowing which default file has an overriding user defined skin file is going to take some exploring. at this time i've only needed to edit 11 of the available 78. so there's a good chance you'll only be editing the default files. you'll know when nothing happens to the shown preview. time to go looking for the alternate.
if anyone wants to swap in this file it's here. it's from the 6.6.14 version of FS but it should work with the 6.6.17 version. need i remind you? backup, backup, backup....
nonetheless, the only way to know is to see if the filename listed has a user defined file.
-
i've completely lost the key element to this look (the dress) from its saved outfit. there's no link there and when i look for the original i couldn't find any objects in the main inventory. trying to reproduce this ancient outfit (2010) kinda bums me out. everything else is attachable but no dress!!!!
i'm doing my own searches for a similar look. the brand Lo*momo has left. if anyone else has this design, or something similar in their mind, i'd appreciate your help.
-
okay, looks like the problem is loading a file into the XUI Preview Tool. everything works just the same if you edit outside the tool. as in, load the file into your editor from its directory, saves will be updated in the tool's viewer. DON'T load from inside the tool's Browse to Editor Path option.
thanks to fabulous Zi Ree for jumping on this. fix will be in the next release.
-
! DANGER WILL ROBINSON DANGER !
if anyone using the XUI Preview Tool is having a hard time reconciling what the preview tool is showing from the edits they are doing you're not going insane. seems there's a bug that, in my case, shows the Starlight file instead of the default skin's file.
until i can get my head around this new information i can't recommend using the XUI Preview Tool. i'm thinking maybe NOT having a copy in the Starlight folder might suffice. updates on this issue may be forthcoming.
-
i've chosen another floater, this one; the viewer's newest feature to add thumbnails to any inventory item, to illustrate the capacity for the simplest XML edits for making remarkable changes in the look and feel to the user's experience. take a look at the illustration below and see if the changes don't fulfill your every desire.
instead of a YouTube vid i've posted a heavily documented file online for anyone to peruse. it's just one file, so if you're brave enough you can copy and paste it into your skin folder as: floater_change_item_thumbnail.xml. just make sure you've made a backup of your original because, well, come on, you should know by now.
there are a few other files affected by this floater (the snapshot button opens a new floater floater_simple_snapshot.xml) that i've edited but not documented as of yet. i'll put it up later and post its link when i can. as it is now you'll just have to deal with the jarring inconsistencies.
-
1
-
-
vid showing the process for correcting the newest Firestorm's XML for the "Buy Contents" floater (floater_buy_contents.xml).
-
another method of divining which xml files are used to create the various interactive components is the XUI Preview Tool that can be brought up before one actually logs in. that can be handy since a lot of the edited components need a relog to see what changes you've made. the intention of the Preview Tool, i suppose, was to give one a live view of the affects made in editing the xml.
unfortunately, the title column isn't normally populated with anything for the majority of the components and relying on the filename supposes a greater knowledge than one might have should one be idly wanting to fool about with editing the UI. but, nonetheless, it does reveal some semblance of usability.
it lists all the files within the default skin folder. in this instance for my install, that's C:\Program_Files\FirestormVersion\skins\default\xui. if you are using any variant of the Firestorm's skins (i'm using the Starlight skin) you won't be able to use the Preview tool unless you swap out the default file with the Starlight file you'd like to be privileged to get a live preview of. unless you have a good grasp of where your skin files are and you have considerable experience replacing edited files with your backups (an absolute must!) i wouldn't adventure into changing the default skin files.
as it is, should one want to fool about with any of the skin files i would HIGHLY RECOMMEND you make a backup of any or all files before you edit anything. a single errant button press can stall the viewer from loading.
if you do take on the challenge, i suggest you save frequently. perhaps after a single width= edit or whatever may appear as an insignificant alteration. you'll be amazed at just what havoc you can cause with the simplest attempts.
with my chosen editor Notepad++ (you can plug in whatever is your choice in the Editor Path) Ctrl-Z will soon become your best friend. no, editing the XUI is not for the timid. but formidable graphical eyecandy can be achieved should one venture to learn. just be prepared to undo what you just broke. there are plenty of peculiar unforseen traps.
once you've taken the appropriate precautions of backing up any file you wish to alter you can mash away at the system file with abandon. let's just be a little circumspect as to just what you are atempting to do.
the columns are alphabetically sortable. sorting the "File" column will reveal there are essentially three types, floaters, menus, and panels. floaters are the overarching container that houses panels. menus don't have a preview. choose any particular file by highlighting its listing and then Show will reveal what the component looks like. it's dragable and the various elements are active. so, changing sliders, radio options, and number parameters WILL affect inworld settings! we're only editing the look and feel so don't mess with those settings. there's no X for closing what's showing so it must be closed with the Hide button. clever, huh?
i'm not sure what the other buttons available buttons are but if you want to experiment with them be my guest, just don't blame me when your entire life's destroyed. did i mention you should BACKUP BACKUP BACKUP and BACKUP?
i think we've gotten ourselves in as much trouble as necessary for this segment. next we'll find a XUI bug in the newest version of Firestorm and fix it ourselves.
-
i grabbed one of my flickr files (~4800X3500), not cause i'm a freeloader bandit, it was the first thing that came to me, it came out scrumptuous.
i'm not sure everyone knows what you have here. why the world didn't stop and take notice is amazing.
i tried looking up who to "blame" for this monster on GitHub but couldn't pin any one specific dev on it. whoever it is, thank them from the bottom of my little graphic heart.
-
1
-
-
holy *****!
how come no one's ever raved about this? REVOLUTIONARY i say. maybe i should read the Lab's blogs more. thanks Wulfie, off to load up the servers.
-
1
-
-
incroyable!!!
so it's on the Lab's servers somewhere?
-
trying out the new whizbang feature for adding photos/textures to the outfit folders in the newest 6.6.17 Firestorm viewer. it APPEARS i never had to pay for a snapshot. can't find anyone else mentioning this process. if it does what i think it does, hallelujah. am i being taken for a ride?
here's what i did:
in the outfit gallery folders, right click on the folder, choose "Image...",
choose "Use snapshot tool" icon,
choose "Save" button and then...it just magically appears!where's the photo? no link? no copy in inventory? i never had to pay for an upload (nothing in my transactions). where's the catch?
-
1
-
-
the xml (eXtensible Markup Language) files used in the SL viewer are similar to HTML files as they utilize opening and closing tags containing elements with attributes. and, please, if you do consult the wiki be prepared for the state of confusion inherent in having C++ code monkey ENGINEERS describing a graphical interface. it's like they were from a different world altogether. did they ever imagine their little toy would be used by non-geeks? in the present state, with far too little effort concentrated on the code's graphical look and feel, i think not.
there's a right way and a wrong way to dump data. without a graphical and workflow sensitivity, as we are attempting to communicate with this series, one can accept all manner of defects and flaws as long as it runs. praise be to whatever gods they prayed to that they left us with a way to move the bits and bytes around without tromping on their viper's nest of code. whoever conceived of using xml for the viewer was a far-sighted genius and belongs in the SL Hall of Fame.
nonetheless, suffice it to say, xml should be a simple way to graphically represent the underlying code data. at its best it's like arranging graphical blocks. unfortunately, at this retarded level of development no none's decided there should be a graphical interface to preview changes on the xml file so it's all text based editing. yes, after 20 years. it is what it is.
there are a couple of rudimentary methods to view the results of your xml edits i'll get to later, but since there are sometimes a complex number of files dictating the look of any one specific element their usefulness is clearly limited. that's another failure of the overall development strategy. since, from my study, there doesn't seem to have been any overarching policy regarding adhering to any existing norms it's devolved into a "do whatever works" attitude. so; duplications, redundancies, and complications abound. can you say, "a mess"?
a closer look to streamlining or decluging the entire repository of xml files would take a higher level project authorization. a small number of xui zealots might take a month or two to throw together something were they supervised correctly. it's not impossible, would NOT affect any code, and would certainly make editing a smooth forward trajectory.
unfortunately, we are where we are. so before they catch up and ruin our fun, let's describe how changes are made (by me) presently.
this is a snippet of some of the language and formatting used in an xml file to communicate back to the SL app. this particular file controls what elements the SL program puts onto the screen when you click on a store's vendor.
there's a whole bunch of gobbledeegoo happening behind the scenes (the source code referencing this xml file is here) but essentially the xml tells the program where various bits like buttons, checkboxes, icons, sliders, etc. should go. where the money goes is anyone's guess.
how we came to find this particular file for the Pay Resident window/floater/whatsit takes a bit of sleuthing. it's not just a matter of right clicking the object in the development viewer and you're given all the files that paint this on the screen. i wonder if the Lab has a tool for that? (call me). one must resort to doing a text search for the floater's heading text. there are other ways to narrow down all the files but that will have to be in the next installment. there's a lot of guessing and praying.
as it is for this instance, i use Notepad++ for one of its primo features. not only is it a good lsl and xml editor but it's a formidable tool for looking for search terms inside an entire directory's text files.
plug in the "Pay Resident" as the search term, match the case, and Search in Files brings up two resultant files that are subsequently loaded into the editor. the code snippet appears in the image above.
that's as far as i'll go for now, stay tuned as we go into specific elements applied to resolve the nuisance of not having the creator's entire product text showing in the window as well as revealing some handy dandy tools divining what's hiding in plain sight.
-
welllllll, if i only knew what kinda work it was gonna take to put some coherent details of this process online, ....
sheesh.
when it comes to explaining just how to get to where i've gotten it takes a mite stepping back into memory and routines that i've developed to a comfortable level of functionality and efficiency. unravelling that horrific pile of interwoven entangled mess (my education as well as the order the code has revealed to me) is a grueling chore. least alone illustrating the various poignant points along the way. you're welcome. it's a calling. i expect nothing but the best.
getting that out of the way, yes i'll soldier on, just don't expect installments to be rapid fire. these posts will NOT be on a schedule. should i get to the dishes, or put another graphic together.... decisions, decisions.
of course, i'm sure everyone's got their own way of organizing their flow. i'll just lay out what i've been doing and some fundamentals might fall out along the way. in other words, you don't have to follow all the steps i've taken (if there are workarounds and alternate paths please inform me).
this adventure began with a noodle in my head saying: wouldn't my second life be better if i could move that button over there, what about reducing the screen size of some floaters?, how about making that widget smaller, larger, etc., etc.. come along for the ride if you've ever had similar notions as to making the viewer conform to what you think is best for you.
just be warned. there are a total of 634 xml files in the default folder. not counting the files for the Starlight variant (10), i've tweaked 150 in some manner or another. nonetheless, if you only want a menu option moved you might stick to only editing a few. but believe me, once you know how, you won't want to stop on just that one.
anywho, to another day. (how to find the xml files you will need to tweak)
-
1
-
1
-
-
a long, long time ago ... sometime around or about the v2 rewrite there was a lot of talk about tweaking the revolutionary changes made to the viewer's UI to make it more palletable for new users. of course, since i didn't have a computer science degree i thought some genius would heed the call and generate a viewer that was both useful and far less "feature rich". something more atuned to a new user's sensibility, not one providing mana to a nuclear physicist (as it is currently).
not that all the bells and whistles aren't technically applicable (to the short list of hackers and coding doctoral candidates) it's just a little much to be offering up tweaks that at a single button press could undermine the actual ability to ever launch the damned thing again. so, yeah, providing these scrumptuously powerful functions (to any and everyone) may have had some deliterious affects on maintaining and/or preserving the unwitting curious user.
aside from all the other myriad amount of applied excuses for plunging user retainment, to which i'm unable to facilitate anything other than complaining to the wind, i've actually taken up a new study that seems to warrant wasting an inexorably lengthy amount of my time. and, without having any other skills outside of editing text inside the viewer's xml files i seem to have created what i think is a better UI.
no C++, python, GitHub pulls, or similarly antithetical computer/human interface logic. the whole user experience can be customized just by tweaking the viewer's xml files! what a boon to humanity. how come no one ever told me: your world, your imagination...?
so..., after countless hours pouring over the extraordinarily excessive xml skin files my viewer's look and functionality is getting closer and closer to being what i had wished for for far too long.
hence, the reason to originate this topic. i'll be using it to release significant "code" snippets that alter the status quo. some are subtle while others completely revolutionize how one interacts with our little world. i'm hoping those "in the know" can offer helpful advise and discussions. if any disruptors wish to send the topic sideways i would suggest compiling a voluminous Ignore page. if i don't respond, you'll know why.
that being said, i'm looking forward to using this forum to promote and encourage others who might want to reduce their frustrations with the way things are with a little effort on their part to make the viewer act the way you want it to. no excuses, it's really quite simple.
i'll try to format my posts along the way with a feel for a non-technical, ordinary human language. thanks for your indulgence and patience as i organize my findings. tooodly-do.
-
1
-
2
-
-
SUE THEM!!!
-
1
-
-
3.6 Audit. Licensee hereby agrees to keep reasonable, written records in the English language regarding this Agreement, Licensee’s use of the SDK Materials, and the creation and status of all Avatar Items (“Records”). During the Term and for one (1) year thereafter, Linden Lab shall have the right to obtain true and correct copies of all such Records, and to audit such Records (either by itself, or through a reputable third-party accounting firm) to confirm Licensee’s performance of and compliance with the terms of this Agreement.
-
1
-
-
https://wiki.secondlife.com/wiki/Linden_Lab_Official:Senra_Body_SDK_License
"3.5 Inspection and Review. Upon completion of each Avatar Item, Licensee shall submit such Avatar Item to Linden Lab (in such form and format as Linden Lab may require) for review and approval upon Linden Lab’s request. Licensee shall fully cooperate with Linden Lab in the course of such review and approval, providing to Linden Lab such information and assistance as Linden Lab deems desirable."
-
1
-
1
-
-
3 minutes ago, Wulfie Reanimator said:
After your stream is created and you view it, the URL of the page is unique to that stream and anyone can visit it. For example, the 200th stream is this one: https://community.secondlife.com/discover/200/ (Incidentally, it was created by you. I don't know if there's a listing for all the custom streams people have created.)
that is bizarre!
discover/1-200 are all activity streams made? how did you know 200 was the latest stream?
https://community.secondlife.com/discover/22
https://community.secondlife.com/discover/44
https://community.secondlife.com/discover/66
https://community.secondlife.com/discover/88https://community.secondlife.com/discover/201 i guess i'm gonna have to perve this directory for all the newest stream configs... good thing my naming scheme's have always been PG(not!).
-
just make sure when you select the forums you want (open Topics in their Create Activity UI) you can't edit your selections after it's saved.
@Wulfie Reanimator where are these "public" activity streams?
-
1
-
true 
Facebook
Instagram
Twitter
YouTube
Flickr
Official Statement from Oberwolf Linden
in General Discussion Forum
Posted
i'm not totally aware of how effective the registration goes for signing up to play in SL at present but in making a number of alts over the years there was not any challenge to verify my age, sex, location, or anything real worldly. the ToS does seemingly require any new signup be 18 but anyone can subvert their humanity and lie (it's a free online resource, who doesn't?). so, essentially, any unsupervised child or deviant webaholic can be engaged in all manner of roleplay from the get go. do you know who you're bumping pixels with?
[just ran through the registration sign up thingy. all that's required to engage in the hooha is a valid email account.]
if that's all that's required to verify a random account to be adult, that's another reason we run into less-than-mature behaviour from the "expected" adults we encounter.