EnCore Mayne

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.

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

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.

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.

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.

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.

vid showing the process for correcting the newest Firestorm's XML for the "Buy Contents" floater (floater_buy_contents.xml). JIRA report

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.

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.