Tonya Souther

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.

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.

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.

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.

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.

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...

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?

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.

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.

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?

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.

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?

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.

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.

Thanks. As it happens, I think my fix will fix this case too, but I'll be sure to test.

Crud. If so, that's going to make life more complex...but if it's a common use case, then I'll need to handle it correctly. Thanks.

I'm not sure I understand what you mean by setting the texture surface of the sculpty to 4:4. Do you mean to set it to 4 repeats vertical and horizontal on that face? Or do you mean you have an animation that's a matrix of 4x4 cels? What's the call to llSetTextureAnim() you use in that temporary script? In any case, I think it's happening because the animation definition inside the viewer for that prim is reset when you get back in view of it, and the object update from the sim to the viewer sends the parms again - and overwrites the correct ones wiht repeats of 1 in both directions.

The bug is in how the viewer displays animated textures on a prim, not in the script code or the server. Currently, a prim can only have one animation applied, to either one face or ALL_SIDES. I'm not proposing to change that. To understand the issue, let's first think of a cylinder. It has one face around the outside. That face can be animated with a repeat pattern, say 4 wide by 2 high for 8 animation frames. So far so good. But let's say you don't want the whole cylinder. You just want a pie-shaped slice of it, say a quarter of the way around. So you use the path cut to select the part from 0.0 to 0.25. That gives you the piece of the cylinder you want , but now you only see the leftmost 1/4 of the texture. To see the whole texture, you change the number of horizontal repeats from 1 to 4. This works fine; the other three copies of the texture are on the parts of the cylinder that have been path cut away, so you're left with what you expect. Now say you want to animate the texture by displaying those 8 frames I discussed earlier. In a script you drop in the prim, you do: llSetTextureAnim(ANIM_ON|LOOP, 1, 4, 2, 1.0, 8.0, 1.0); to turn on the animation in loop mode, on face 1 (the outside of the cylinder), for a 4x2 matrix of frames, starting at frame 1 for 8 frames, changing at one frame every second. This works fine if you're animating the face of a cube, or the whole cylinder, or anything else where you have let the texture repeats per face default to 1 in each direction and the offset default to 0. Otherwise, it ignores the values you set, and so the quarter-cylinder in my example only shows the leftmost quarter of each frame. The fix I'm working on fixes this case so that the repeat and offset values you specify on the prim are honored wihtout any other fiddling. The problem I'm asking about comes along when you specify ALL_SIDES instead of face 1 (or whatever). That prim can have different numbers of repeats per face. If you specify ALL_SIDES in the llSetTextureAnim() call, what's the right answer? Do you ignore the repeats and offsets as is done now? Do you apply the values from one face, and if so which one? Or do you do it separately for each face on the prim? That's feasible, but it might eat up a lot of horsepower if there are many prims with ALL_SIDES being animated in a scene. Note that you can only have one llSetTextureAnim() in effect for a prim, so you can't have one side animated with a 4x2 sequence of frames and another with a 3x3, or even a 2x4. Changing that would not only be even more expensive, but require server-side changes that are well out fo the scope of this fix.

Actually, the frame animation is exactly the case where repeats and offset should be honored. Animating the scale or rotation, pretty much by definition, changes the repeats and offset values.

Ah, but if the prim has ALL_SIDES specified, which face would be animated? I suppose I could see if there's just one face that's not set to totally transparent and convert the call to just that one face, but that might get interesting.

Actually, the solution would work for ALL_SIDES, but would require that the animation process be repeated separately for each face. For a cube, that means 6 separate animations would need to be done for each step. That can get expensive.

You can have one texture animation on all sides of the prim at the same time, though, and that's what I'm asking about. How often do people do that and have faces with non-default repeat and offset parameters? And yes, the situation you describe is exactly what I'm trying to do: animate the face of a path-cut cylinder. It looks terrible with the resized and cropped texture I had to use. Yes, it's been a bug for years. Doesn't mean it's too late to fix it, though.

I got bit by the bug described in STORM-1909, that doing llSetTextureAnim() on a face with repeats and an offset specified ignores both. This bug also has been known as VWR-28409 and VWR-4018 and possibly others. (Since it's a STORM JIRA, you will be able to see it by clicking the link.) I've got a fix mostly figured out, and will be hammering it out today. In the process, I've come across a question, and I'm not sure wht the right answer is: it depends on what content creators expect the function to actually do. Specifically: It is possible for faces on the same prim to have different repeat and offset values from each other and from the default. Do you expect it to animate the texture on every face correctly if you specify ALL_SIDES in the llSetTextureAnim() call, or if you're doing this, do you animate only one face? The tradeoff is that it's pretty simple to have the repeat and offset values work on one face; doing it for all faces on a prim can be much more computationally intensive, since every face would have to be animated separately. This could build up fast in the presence of several prims with ALL_SIDES specified. My guess, putting on my content creator hat, is that getting it right only in the case of one side would suffice. But I don't want to make that decision for the entire SL community. What do you tolks think?

LL to JIRA helpers: See figure 1.

I blogged about this...in short, it's a truly boneheaded move.