Tonya Souther

Resident
  • Content count

    86
  • Joined

  • Last visited

Community Reputation

10 Good

About Tonya Souther

  • Rank
    Advanced Member
  1. Bakes on Mesh Feedback Thread

    OptimoMaximo and Klytyna, Get a room, you two. This endless back and forth of name-calling and chest-thumping is getting in the way of those of us who are trying to use and understand this feature. Frankly, the level of invective is high enough that I'm surprised the Lindens haven't told you to knock it off. And if either of you actually understand the SL render engine, how about sticking to how that works? (Although I'm still convinced that only five people on the planet understand the SL renderer, and two of them work for LL.)
  2. Bakes on Mesh Feedback Thread

    I'm sorry to say that getting the UUID of the texture of any wearable isn't quite trivially easy, but it's not difficult if yo know where to look...it's let me make Maitreya appliers for myself for los of system clothing I've purchased over the years. This sucks for skin creators in particular, but there's no good way around it. Disabling HUD display of a baked texture is probably something that should be done - I can see no valid use case for it - but don't delude yourselves that it'll stop copybotting in any real sense.
  3. Bakes on Mesh Feedback Thread

    The avatar maker would need to add the ability to set the layer to use one of the bake slots. I would expect that would be a button on the avatar's controlling HUD.
  4. Bakes on Mesh Feedback Thread

    Yes. Each layer is a separate face or set of faces, and each face has its own texture.
  5. Bakes on Mesh Feedback Thread

    Even with onion layers, this is still a win. Tattoos on the skin layer, a leotard on the underwear layer, and something else on a clothing layer over the top of that. The biggest thing that has been missing from mesh bodies (aside from uniformity enough that clothing makers don't have to make 40 different versions, one for each mesh avatar, each one of which is just different enough to screw things up) is the ability to composite textures on the fly. Clothing creators don't have this problem, but those of us who actually own mesh bodies and want to use the piles of clothing we'd bought before they became a thing without having to buy it all over again and reorganize the world do. Yes, materials support is important, but so is getting it right.
  6. Bakes on Mesh Feedback Thread

    You folks can ***** all you want. I'm just going to happily and somewhat impatiently await its arrival. The alternative for me is uploading 100,000 textures to take care of 10,000 possible IDs time five ranks times two sexes, or else spending an hour or so to set up each new member's textures and then creating an applier for the mesh-avatar-of-the-week (and buying all of the development kits to go with that).
  7. Bakes on Mesh Feedback Thread

    It's not at all unusable, for folks who have system layer clothing they want to use with a mesh avatar. It saves having to create appliers for it.
  8. Bakes on Mesh Feedback Thread

    I'm really looking forward to this. Right now. my RP sim members are restricted to using system bodies because of a technique I use. The member's clothing displays their member ID; I get there without having to make an individual texture for each member by using the tattoo layer for the clothing itself (it's latex) and a series of four undershirts, each with one digit of the ID. Thus, by uploading 40 textures, I got the ability to do 10,000 IDs. The uniform giver automates the entire process. This doesn't work on mesh avatars because they can't composite multiple textures onto a single layer. I've been struggling to make my own mesh avatars to give out to my members so that nobody does without, but this may obviate the need for that. I don't see this as being an issue for mesh body creators at all, as long as there's scripting support for setting a mesh face to use a baked texture. (There is, isn't there, Vir? If not, you're crippling things.) All they need to do is add a picker to their HUDs to let the user select a baked texture. Creators can continue as before, or they can use baked textures; many will probably stick to appliers, because of the total lack of support for materials in the baking process. (A really dumb decision, but that's water under the bridge now.)
  9. Suddenly Unassociated products

    So will people's rankings and reviews be back? The last time this happened - and it was fixed less than a week ago - Casper Warden of Caspertech wound up spending I don't know how much in Marketplace commissions getting people who already had his products to rebuy them and then refunding their purchase price so he could get back where he was at the top of the rankings in his category. Come on, folks...once was bad enough, especially since it took nine days to fix. Twice? Casper's comment about incompetence is looking on-target.
  10. ENOUGH IS ENOUGH

    TDawg, Lindal's right on the money. Packet loss and ping time problems are not anything that Linden Lab's technical support - and certainly not their billing support! - or Firestorm's technical support can fix. Those problems happen before Second Life gets into the picture. You are going to have to isolate your problem to either the network in your home or else your ISP. Either or both may be at issue here. Given your ISp's reaction, it's probably best to eliminate your own home's network as an issue. How is your PC connected to your Internet router? Is it wireless, or is there an Ethernet cable? Try turning off anything and everything else in the house that connects to the net. Do you still have a problem then? If not, then check out your Internet router. Try moving your computer next to it and plugging in an Ethernet cable, if it's wireless. Most of all, though, you are going to have to concentrate on where the problem actually lies. Giving LL or Firestorm tech support a hard time because they can't fix your packet loss issues is only going to frustrate you both.
  11. Why is Firestorm not a favorite?

    At the risk of the old saying about rolling in the mud with pigs... Prokofy Neva wrote: Yes, indeed Emerald phoned home Yes, it did. Among other things. That's why it got banned, and the developers responsible for that permanently banned from TPV development. -- and Phoenix was under suspicion as well because they were made by the same developers. Only by ignorant conspiracy theorists who refused to recognize that the developers who added the malware are long gone. Every last line of code that went into Phoneix was and is available for download and examination, even now. Nobody has ever found a single exploit, and lots of people have had more than a little incentive to look. The Phoenix/Firestorm team has operated under a great big microscope from day 1, and we're well aware of the fact. Of course griefer viewers were an offshoot of these viewers. That's well-established. Read the history. And just what are we supposed to do when others take our code and add griefer features to it? We are required by LL to keep the viewer code open source. That means anyone can take it and add anything they want to to it, and we can't stop them. Indeed Firestorm is a descendent of Emerald and Phoenix. Philosophically, indeed it is. However, there's not a single line of code in Firestorm that was ported from Emerald, or even Phoenix, without being carefully scrutinized, examined, vetted, and understood - and, more often than not, rewritten anyway. Again, we're working under a microscope, and quite aware fo the fact. We know that there are lots of people who'd love to see us fall. We're not going to give them the satisfaction. It doesn't matter if Firestorm is one of the most popular and used. There is always an amazingly odd factor here in Second Life that the maker's own viewer is not the one most used -- and should be -- but this odd third-party viewer This is the inevitable result of one factor: We take great pains to listen to what the user actually wants. Rightly or wrongly, the LL viewer doesn't have that reputation, and that stretches back at least to the time of introduction of Viewer 2. We provide a powerful, feature-rich viewer that gives users what they want but doesn’t force them into things they don’t want. Some of those things I doubt the LL viewer will ever add, like RLV (or an equivalent capability). Firestorm is a particular problem in my view because it enables people using it to return group-set prims when they were not granted that power in a Second Life group -- a function they could not perform on a regular viewer made by Linden Lab. That's a serious exploit and serious undermining of the rules/technicalities of Second Life, but LL turns a blind eye to that for reasons I can surmise but which are never stated. Yeah, real serious...so serious that this is the first I've heard of it in my 6+ years on SL. Funny, though...VWR-5491 reports it against the LL viewer (1.23, so we know how long that's been around). Even so, if this is something the LL viewer does not allow but Firestorm does, then it's truly a bug, and we will fix it. It would help if a simple reproduction would be written up0 so that we can run the test case against Firestorm and the LL viewer, so we can understand what's going on. I have a sim, and can set parcel and region permissions as I need to, as well as group settings, so anything you can describe, I can try. I have no idea who you are, what your story is, and why you feel the need to defend Firestorm and misreport the known history. It doesn't matter. Let the buyer beware. I, on the other hand, do know who you are: someone who's had an irrational dislike of Phoenix, Firestorm and the people associated with them for far longer than the actual facts justify. Let the buyer beware, indeed.
  12. Gee, thanks, LL. Way to tell TPV developers and their users to see figure 1. For that matter, telling merchants that their only option to manage their Marketplaces - for some, their RL livelihoods - is to use a pre-release viewer is...uhm...trying to find polite words here... I blogged about this. The Firestorm team is deciding what to do about this right now. We'll give our users something. It's too important not to. None of the options are good.
  13. Thank You Firestorm

    Qie Niangao wrote: I think it's not so much a feature of Firestorm's code that causes it to be so intricately intertwined with the LL viewer source as it is the fact that LL simply threw open the viewer source without any consideration for how contributors might sensibly contribute. Quite possibly, but that train left the station years ago. V2 would have been a good opportunity to do the necessary rearchitecting, but it wasn't done, and we're stuck with the results.
  14. Thank You Firestorm

    Pussycat Catnap wrote: Caught up to what? Everything that's happened in the last 5 months - from materials to fitted and all the bug fixes in between. Read Firestorm's own list of changes to see the list. In case you hadn't noticed, Firestorm has had materials support since 4.5.1. The point is that until 2 days ago, the ability of FS users to see what others saw was not there. If you're referring to materials, you're simply wrong. If not, then what are you referring to Why does no other TPV have these issues? Singularity and Cool Viewer manage just fine - and they're on v1 UIs. The nightmare their devs face making this new stuff work for their UI is even worse. But they usually have a patch within days of an official viewer going live. Sometimes on the same day. Sometimes via the betas, they release their update a few hours BEFORE LL's puts up the final official. They cheerfully run risks that we can't. They risk having to go back and manually do merges when LL releases code in a different order than what they merge. They risk LL's wrath from releasing code that hasn't been in an LL project viewer. They risk having to go back and do it all over again when LL changes the code they stuck in their viewer. I work in Silicon Valley. I know how an agile dev team operates. FS needs to splinter out its various projects and its code that stays current - and work in faster, smaller releases for each on different schedules from each other. Have you looked at the Firestorm codebase? (Or that of any other viewer?) It's not that neatly divided. It's one big 1MLOC mess. It's grown by accretion over a period of years, and to get to the point where we could neatly separate LL work from FS enhancements would take a major rearchitecting of the code. If you think you can do better, I cordially invite you to try. They need to just cut those people loose in terms of support. Shunt them back to LLs. Get back to focusing on the things that can make them competative as a TPV, and a split release cycle so they don't fall behind on the things from official sources. Easy for you to say. Firestorm is competitive as a TPV as it is. The numbers prove it. If you don't like our pace of updates, then you're welcome to do better...or pick another viewer...or quit complaining and help out.
  15. Thank You Firestorm

    Caught up to what, exactly? Fitted mesh hasn't been out but for about a month. Monty's HTTP changes haven't been out but for a week or so. In fact, we delayed this release specifically so we could pick up Monty's work. We don't pick up stuff from LL until it's been merged into the release viewer. That way, we aren't fighting to merge things out of sequence, which causes a mountain of headaches. In addition, LL develops lots of things in secret and doesn't release the code until it's almost ready to go in the release viewer. It takes time for us to merge those changes into the Firestorm codebase. It will be exceedingly rare for us to release features at the same time as LL. More often, we'll be behind by a month or three. We can't prioritize LL changes over our own; most of our work as it is is wedging LL code into Firestorm. If you really want to stay on the bleeding edge of LL features, you'll have to run the LL viewer. The rest of us will be just a bit behind, using the viewer for power users...Firestorm.