That link shows you the concept art alone; this one shows you the 3D modeling (before coloring). I'm definitely interested in seeing what Robin looks like, once fully colored and animated.
But there's a catch--if you want to see him in the game, you have to pre-order the game through Best Buy. Folks not in the US? I guess you're out of luck, unless they ship internationally.
Another JIRA, another day...but this one is intriguing more for the comments than anything else. To wit, a few quotations to show you what I mean.
First of all, an explanation of the issue. Tapple Gao, who uses official viewer 2.6.3, changed shape from Tiny to 'normal' avatar shape--yet people around that avatar using the Phoenix viewer still saw the Tiny shape. Nothing Tapple did fixed this issue; only having the other parties switch to other viewers, or clear cache and relog themselves, fixed the issue. And only until Tapple switched base shapes again...
Help, came the outcry! This is a major bug! Showstopping even! THIS MUST BE FIXED FORTHWITH!
Not so, said Dan Linden:
This is a known incompatibility with 3rd party viewers. We are not going to commit to fixing this.Well. That's rather bald. But does state the point succinctly.
Of course, this is the JIRA. Bugs are frequently misfiled, personal grievances are aired, and there's a lot of drama without reason going on. So there were several more "OMG THIS MUST BE FIXED/WHAT'S WRONG WITH YOU/YOU MONSTER!" comments, until we got to Oz Linden:
It is not possible to fix this in the current viewer code, because the problem is that the old code did not do proper handling of unrecognized avatar parameters.Now, I quoted the entirety of his response, because I think it's that important. If you didn't parse all that, let me restate:
In the old code, any unrecognized avatar parameter caused the entire update to be discarded, including all recognized parameters. In the new code (and the old code as modified by the attached patch), only the unrecognized parameters are ignored.
Given that poor handling of unrecognized parameters, the only way to preserve perfect backward compatibility would be to never again introduce any new flexibility or features into avatars, which is not acceptable. There is nothing distinctive about the Avatar Physics feature in this regard: any new avatar parameter would have the same effect. The problem can be demonstrated with older viewers as well, it's just that the popularity of Avatar Physics has increased the probability of encountering the bug.
Actively maintained third party viewers will have no trouble incorporating the attached fix (feel free to contact me by email if there is a problem).
Viewer 1.23 and Snowglobe are no longer maintained; no new version will be made available for them.
Users of those and other viewers that are no longer actively maintained are encouraged to find actively maintained alternatives so that they can experience Second Life with all the features that it has today and in the future.
- The 1.x viewer structure (which includes the 'official' Linden Labs offshoots of 1.23 and Snowglobe 1.x viewers) would perceive a change in the base shape. If that change was internally consistent and understandable, the client would update. If that change was in any way confusing--like, for example, switching from a 'crushed' Tiny form to a 'normal' large-person form--the old code would discard the change in all aspects. A sort of internal "Oh, you can't have meant THAT" clause.
- The 2.x viewer structure, beyond its annoying and crazy-making surface changes, also changed a lot of the buggier bits of code behind the scenes that the Lindens had, up until the development of the buggy viewer 2, pretty much just patched and patched and patched again, in hopes that the last patch would fix the unfixable. So when an "unexpected" change happens--a full-size av changes to a Tiny, say, or a humanoid av changes to a beetle, or a butterfly, or a floating glowing orb, whatever--if there's any bit of code glitching in doing so, the 2.x code overall will say, "Okay, that bit didn't make sense--and we'll just set that to the side--but we get what you were trying for with everything else." And it tells the server to make the change.
- When the server makes this change, if there was anything about it that any viewing client found inconsistent, if those clients have a 2.x structure, those clients will do the same thing. Only if the client is 1.x, with the old bugged code, will it not work out properly.
- The Labs see no reason to maintain 1.x past the existing extensions of 1.23 official, and Snowglobe. There's no reason for them to; the newer code, in terms of crashing, broadcast visuals, speed of downloading graphics and media, and speed of displaying graphics and media once loaded, is--after over a year of insane crazymaking glitches--now pretty stable. And they've been fairly consistent with putting out opensource extensions of what they're doing now. In fact, since launching the Snowstorm project, they've been putting them out every week.
- The recommendation, therefore, makes sense: if we're on viewers that aren't patched up to 2.x--at least behind the scenes--then it's no longer the Lindens' fault that we aren't seeing things properly. This is not a Linden code bug, in terms of the new code. It's a bug in terms of the old code.
- So Oz--politely--and Dan--rudely--is stating that and making it plain: Update. Because while they won't kill 1.x viewer access any time soon, they're also no longer updating that era of the code. The code has moved on; the code has been rewritten. Update or be left behind.
It is unusual for Disney to hand over one of its iconic characters to an illustrator who's made a career of designing beautiful young girls that get boned in games.That's stone truth, that is. Still, it might be a...good thing? New look, new eyes, new concepts for traditional Disney characters, right? And collaboration always gets the creative juices flowing...
(from the media album |
Or...not. I guess we'll just see how she does.
0 comments:
Post a Comment