Tonya Souther

Resident
  • Content count

    76
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Tonya Souther

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Hello from Linden Lab’s New CEO

    Welcome to LL, Ebbe! I'm one of the developers of Firestorm, the most widely used viewer for Second Life. There's a thriving third party viewer developer community, and we do a lot of things for users that the LL-supplied viewer doesn't. There's a good guy, Oz Linden, in place to do the seemingly impossible job of working as a bridge between LL and the TPV community, but it's tougher than it should be: there's a lot of secrecy around what LL does int eh viewer space, and we're constantly playing catch-up. That makes it harder and takes longer to roll out new features on SL. The answer is obvious: less secrecy, more collaboration and openness. The implementation of materials was an example of how it should be done. Let me pile on the JIRA topic, too. I wrote a blog post about it. The post before it is relevant, too. This is all part of the same thing: LL has acquired a reputation of not listening to its users as it pursues whatever this week's big push is. That needs to change, badly. You should arrange to come to one of Oz's Third Party Viewer Developer meetings soon. We'd love to see you and give you a piece of our minds...
  8. Mandatory Update for Power PC?

    Quite frankly, I'm stunned you are able to do anything at all useful with 1.23.5. Second Life has long since passed it by. What problem are you referring to about the latest Mac OS X?
  9. SSB via T-Mobile cellphone

    I'm going to add that to Firestorm and see what happens. Edit: I've added it as Firestorm Mercurial revision 38682. If it passes testing, it'll be in the next release of Firestorm. FIRE-11448 is the Firestorm JIRA entry for this issue; if you're interested, you can follow the progress there.
  10. [AMD Radeon] Crash on boot with latest AMD drivers

    I get this crash on my Linux system as well, but not a development build of Firestorm with materials and CHUI. I filed a BUG JIRA against it, BUG-3582.
  11. I'm looking to make some specialized clothing. To do this, I need mesh bodies that work well: properly rigged, deforming well with movement, nicely proportioned. I need both male and female. For my application, I need them in a format I can feed to Blender, edit, then export to SL. I've tried using the Avastar plugin to make a mesh of the SL avatar, and while I can edit that and uplaod it fine, it's lacking in geometry in a few critical areas (notably, the crotch), and the weighting is terrible in several places. I tried a MakeHuman body; while it looks quite good, and deforms well, I can't get it uploaded properly after editing it in Blender. The FATEcreate female catsuit would work well for my purposes, but when I import it into Blender, it loses all the vertex weight groups, and I can't upload to SL afterwards and keep the weighting. Yes, I'm willing to pay a fair price for the work. It's worth it to me not to have to weight the doggone thing myself; I find that process incredibly frustrating. Anyone out there know where I can get what I need?
  12. Thank You Firestorm Team

    Qie Niangao wrote: On the other hand, there were certainly Emerald developers who were shafted much worse than the general public by the shenanigans of a couple of "bad apples" and we know some of them contribute to Firestorm. I expect they're more than usually cautious that nobody's naughty code ever again gets into a viewer with which they're associated. There are plenty of folks who would love nothing more than to see Firestorm go down in flames, and especially to see it go down in the flames of the same kind of controversy that killed Emerald. We know that there are plenty of folks watching every commit to the repository for just such things - and we watch ourselves so nothing gets through, not only so those folks have no ammunition, but also because we know trust is a fragile thing, easily lost. Indeed, the reactions of some folks here show just how easily it can be lost. What annoys me (speaking very personally, and only for myself) is that some people insist on holding the current team responsible for actions of former team members, when we've worked hard to purge the team of the kind of shenanigans that the former team members committed and the people likely to commit them in the future. It is very much guilt by association, and I resent it more than just a little bit. Qie Niangao also wrote: *Or maybe not. My recollection of the whole sorry episode is (happily) vague now, but I seem to recall that one of Emerald's worst sins (perhaps the DDoS scheme?) was buried in code using a licensed third-party library (Kakadu), which I can imagine may have been delivered pre-compiled to the rest of the Emerald team without source. If so, yeah, it should have set off alarm bells, but I can also imagine a tale spun around licensing legalities... and anyway, hindsight is always 20/20. There were two components to the malicious code. One, the code that added the user's computer name and account login to the image metadata, was in an interface to the KDU image decoding library; that interface code was itself closed source, as the code license and LL's interpretation of it required at the time. That has since changed, and the interface code itself is now open source. The second, the DDOS, was in the Emerald login screen code as saved on the Emerald website. The equivalent code is now tightly controlled, with only a very few people given write access (I'm not even sure I have it), and placed under the same Mercurial change control as the viewer source code - so that changes can be tracked and, if malicious code is added, the culprit can be found and dealt with.
  13. Thank You Firestorm Team

    Peggy and Teagan, you do know that there are major features under development for the LL viewer that are being written by TPV developers, don't you?
  14. Deploys for the week of 2012-10-29

    Can you describe *how* RLV doesn't work? (Or get your renters to?) Most of RLV is viewer-side, not server-side, and so the server shouldn't affect it.
  15. A couple of days ago, CommerceTeam Linden posted: "We are aware that some Merchants are still having problems with the Merchant Outbox. We are are working with TPVs and our internal development teams to address this issue." As the lead Mac developer for the Phoenix and Firestorm viewers, all I can say is: Huh? To the best of my knowledge and the others on the team I've spoken to, nobody has approached us about this. I think I can speak for the whole team when I say we'd love to help, but we don't know of anything we need to do to fix problems.