Cain Maven

I'm surprised LL didn't try to increase their MP revenue before resorting to yet another fee increase. The 5% commission is actually very low, and I think an increase would be easier to swallow for many merchants. It might: Generate some revenue Encourage merchants to keep in-world stores, thus possibly increasing tier revenue Avoid angering a key demographic I haven't attempted to do the math, so it's quite possible that this would not be enough -- and the impact would of course depend on how much the commission were increased -- but it's still odd that that this wasn't the first option.

I don't think it's that hard from a technical point of view. There are of course trust/fraud issues that might be harder to solve, not to mention that LL would be very unhappy and probably throw the TOS book at any such system (and/or revise the TOS as needed.) That said, it's perfectly reasonable and predictable that people start looking for alternative solutions when something like this happens.

I agree. Ebbe et al have been pretty good at the helm, as far as I can tell. Hiking fees repeatedly and knowing that you're pissing off one of the most important demographics in SL (important in terms of the platform's future economic viability) cannot possibly be the first choice in any reasonable management strategy. So it does hint at deeper and recurring issues. Let's hope we are wrong.

This seems unwise. Given the decline in concurrency and private regions, stimulating the economy would normally be a better approach than attempting to squeeze it -- that can only lead to stagnation in the long term. I understand that LL has huge costs associated with the development of Sansar, and I realize that it hasn't become a real revenue stream yet. It's therefore logical that they attempt to increase revenues where they can. But simply increasing the fees on everyone -- especially creators -- is not likely to give them anything but a short-lived boost. It will not increase SL's popularity, concurrency, viability, or profitability in the future. It will, however, result in a lot of unhappy creators who are tired of fee increases and dwindling profits. If LL had also made revisions to the tier model that might have offset the higher fees, it would have been a different matter. That would have represented a shift from the current (and weird) model where everyone pays very high property taxes but almost no sales tax, to a more sustainable and realistic model. As it is, this is going to cause a lot of anger and frustration -- and with some justification. I'm perfectly fine with the Lab attempting to increase their revenue from SL. But this is not a well thought-out approach.

I mulled this over for 24 hours, and I've decided to bite. Here's why: (By way of background: I make houses, and I only have two regions -- so I realize that my logic may not apply to other people.) Short term: I hand over my $ 1200, and in 6 months I will break even. Barring a catastrophic event during those months, I will be exactly where I am now. The only downside is that I've tied up some capital for half a year, which I can live with. After that, there are basically three possible scenerios: 1. SL continues pretty much as it is today. If that happens, my net will increase by $ 200 / mo. Not a huge deal, but a good thing. 2. SL declines - perhaps because Sansar is the coolest thing ever, the RL economy tanks, or Bernie Sanders and Donald Trump get married. In this scenario, I have an additional cushion of $ 200 to help me weather the storm. It's obviously not a good development, but I'll still be better off than I would be with the current tier. 3. The SL economy grows -- maybe because more people now are willing to spend on land. If that happens, the multiplier effect will cause a boost in the arm for related industries, such as houses, furniture, etc. That would leave me with lower fixed costs and higher volume, i.e. an ideal outcome. Which is more likely? I have no idea, and it doesn't really factor into the decision. As far as I can tell, I'll be better off regardless of which scenario plays out. All of this of course hinges on the assumption that the universe doesn't come unglued in the next 183 days or so. But that's a risk I'm willing to take. Again, I do understand that my thinking won't make sense to everyone else. But for those in roughly the same boat as myself, I think this is a good deal. Reasonable people may disagree

I checked -- Blender does indeed replace spaces in material names with underscores. I usually export LODs to separate files, so I don't really see the association issue. I guess what I'll do as a workaround is to write a python script that temporarily renames the materials during export so the original order is preserved. Wish I didn't have to, though:)

To be clear, my issue is not related to meshes with more than 8 materials. It's the fact that the newest uploader automatically sorts the materials alphabetically rather than preserve the order in Blender (or whichever app you're using.) This change was made when the uploader was revised to split meshes with more than 8 materials into several meshes; a change we think we could have survived without. The result is that you cannot upload an existing file and be guaranteed that the face order is the same. If you had, say, the materials "wood", "metal", and "glass", the old face numbers would have been 0, 1 and 2, respectively. With the current uploader, the list is sorted and becomes "glass", "metal" and "wood", i.e. "glass" is now face 0 instead of face 2, and "wood" has become 2 instead of 0. Consequently, any scripts that rely on the original order break if you reupload the mesh. This is not good and there should at least be an option to disable it. I'm guessing that this was done to simply the comparison of material lists in LODs, but as I said in a previous post, comparing two unsorted lists isn't hard. As for material names with spaces, I have not seen any issues, so that is perhaps related to the applications' exporters rather than the importer?

Elsa Wellesley wrote: PS. And sorry for hijacking your thread !!! ^^ PPS. It really looks like that fixes it, I'm giddy with relief. Glad to hear it And no worries about the thread; it's all good.

Elsa Wellesley wrote: I don't think we needed more than 8 faces that much that it was worth breaking everything else for it. Should I create a seperate thread for my issue then, if my issue is not related to the original post ? I *think* this is a separate issue and so probably deserves its own thread so other with the same problem can see it and respond. I would have loved to have more than 8 materials... but not at the expense of content breaking

Drongle McMahon wrote: 'annoying habit of suffixing the mesh name with "_0"' There is a jira, which includes something resembling "explanation". Yes, I saw that earlier. Should be fairly easy to fix, no?

Drongle McMahon wrote: Sorting of materials by name is mentioned in this kb article. It also mentions ImporterLegacyMatching. While I guess it is ambiguous as written, I think thast applies only to the object name (which are now also used to sort the object list) matching, not the material names. There is no common code involved in getting the names of objects and materials. By the way, see my comment there - the new naming scheme applies to object names, not file names. I guess I was hoping for a debug setting or other workaround to disable the material sorting. I'm not even sure why this requirement was added, as it's trivial to compare two unsorted lists. Thanks for the clarification on object/file name matching. I assumed this feature would look for files with the specified file names ("duck_LOD2.dae" etc. when I select "duck.dae" for upload) and automatically populate the UI. Now that would have been a time saver...

I'm not sure what's causing the problem you're seeing, but some of the details of "improved" process can be found here: https://community.secondlife.com/t5/English-Knowledge-Base/Uploading-a-mesh-model/ta-p/974185 The original idea was to allow more than 8 faces per mesh. Instead, the uploader will now split your mesh into two or more meshes so that each has a maximum of 8 faces. Additionally, the uploader is now supposed to recognize LODs stored in separate .dae files based on a file naming convention (I haven't gotten that to work, but maybe I'm doing something wrong; I confess I haven't tried very hard.) This would be fine and well (although I don't really see the upside) if it hadn't been for the fact that it now reorders your materials alphabetically, which means that you can't reupload existing content and get the same face order. This quite obviously breaks scripts that rely on face numbers, for example. The uploader has also adopted the annoying habit of suffixing the mesh name with "_0" for reasons that I do not understand. Maybe I'm missing something here, but I actually wish they would roll back this whole update until they can solve the original problem, which was to allow more than 8 faces per mesh.

Indeed it will -- but you may find it more useful if you use an Add shader to mix the AO and diffuse/glossy node outputs. That way, you can keep the global AO setting turned off to prevent overall scene brightening and add the AO effect to some materials. Also note that instead of using the diffuse as input to the AO node, you can leave it unconnected and simply specify a color (typically a shade of gray) to tweak the effect. Btw, the Emission node can be used to achieve similar results.

Is there a known way of disabling the recently introduced automatic sorting of material names in the uploader? This "feature" is breaking existing content. I did try the ImporterLegacyMatching debug setting, but that did not seem to disable alphabetic sorting.

We know that much of the focus has been on the technical aspects of Sansar -- concurrency, render quality, scalability, etc. However: what has been done to ensure that you are implementing the "right" features from a user perspective? A couple of examples off the top of my head: • Many basic tasks (putting on shoes comes to mind) could be a lot easier. Removing some of these early hurdles could help with user retention. • From the perspective of builders and landscapers, the ability to create realistic water in everything from bathroom sinks to waterfalls would improve realism and probably also immersion. • Creating LODs is a very time consuming task for many mesh creators. Easing this requirement would likely speed up content creation and help Sansar reach the "critical mass" of available products sooner. This list, obviously, goes on -- depending on your perspective and needs. While I am of course aware that you have been working with a small group of creators in the closed alpha stage, one might be concerned that the feedback has been narrowly focused on technical aspects and not broad enough to reflect the needs of the user base as a whole. Will you take any steps to ensure that you cover as many bases as possible before committing to technical decisions that might make it costly or difficult to retrofit the platform with desired features?

Which processes, if any, do you have in place to ensure that you are developing the "right" features for Sansar? To give you a (possibly trivial) example, we lack the ability to control the presence or absence of water in SL. Among other things, this means that if you add a basement to your home, you will also automatically have an indoor pool -- whether you want one or not. Water has always been a thorn in the side of realism in SL. While the sea water looks good, we don't have many options for other forms, such as waterfalls, tubs, sinks, and pools (unless they are at sea level.) This is of course only one area where I believe you could benefit from gathering information and insight into what the current pain points are -- from seasoned creators and regular residents alike.

I agree that lowering tier is likely to stimulate the SL economy, at least in the medium to long term. However: given that LL is hiring 50 new people to develop "SL 2.0," I think it's highly unlikely that they're going to gamble with their primary revenue stream at this point. I think we also have to realize that these are not new ideas to the Lab -- I'm pretty sure they have analyzed this from every possible angle countless times in efforts to increase profits and/or improve retention. I do like the idea of introducing an "intermediate" region type, though. That might prove useful for a lot of merchants and organizations. However, I'm not sure it would do anything to solve the main headache, which is making land more affordable to private tenants. I think the Lab might listen if we present creative alternatives and new ideas, but I fear a simple demand for lower tier is very unlikely to meet with much success.

Same here -- every other page/site I tried works just fine.

Yeah, me too. It's interesting behavior, no?

Thanks for the reply. I too can load individual pages, such as my own page. The problem is with the home page, i.e. http://twitter.com. Are you able to repro the problem with that URL? I am aware that reloading sometimes takes a while, but in this case the page loads and the vanishes in a second or so, leaving just plywood to look at.

I've run into an odd problem with media on a prim. Almost all the sites I've tried work fine, but for some reason Twitter isn't working right. The page loads briefly and then disappears. I've tried http:/twitter.com as well as the https:// variety. I've tried scripting it using llSetLinkMedia() -- the behavior is the same, and no error is returned. Here's the really weird thing: if I go directly to a specific user's page -- say https://twitter.com/slofficehours -- it works. What's more, I can then navigate to the home page without problems. Is this a known problem, and is so, are there any known workarounds? Thanks, Cain

Ah, maybe that's why it flipped back to the other image. I'll experiment more and see what happens. Thanks

Chosen, I did understand what you meant, but for my purposes I suspect Gaia's method will provide the quickest workflow. I can see cases -- involving other meshes -- where I'll prefer your method, though. In any event, I seem to be back on track, thanks to the two of you. Thanks again

Well! That did the trick I was a bit confused at first, because the UV Editor likes to pop back to whichever image it was displaying previously, but once you select the just-baked image again, everything is peachy. Here are the steps I followed: • Select the object in 3D view, then hit Tab to enter Edit mode. • If any faces are selected, hit A to deselect all. • Select the desired material in the Materials list, then click Select. This selects just the faces with that material. • Enable the Pin tool in the UV Editor. • Create a new image for this material. • Hit Bake. • Save the image. • Repeat all steps for the next materials that you want to bake separately. I'm sure there are snags and gotchas here, but it worked smoothly on the first mesh I tried. I'll post updates if I discover useful tips or tricks (or whine if I can't make it work ) Thank you!

I was starting to fear that... and I guess it means that Gaia must have baked and saved the texture for the exterior before resizing the interior island so it overlapped. It would be *really* nice if Blender could let you determine which faces or materials to bake -- or at least ignore transparent materials (which I tried.) While I do agree that the workflow you suggest will do the trick, it's going to mean quite a bit of extra work, as I was hoping to reuse this element in several places in the build. Oh well. Thanks for the reply!